This test performs basic SRAM initialization procedure and tests basic memory function:

• Initialize SRAM memory to zero
• Perform some random memory operations, verify that they all succeed with an all-zero key and nonce
• Request a new scrambling key from the OTP interface and verify that:
  • A valid key is received
  • The key seed used by OTP is valid
• Perform a number of random memory accesses to the SRAM, verify that all accesses were executed correctly using the mem_bkdr_if

Verify the reset values as indicated in the RAL specification.

• Write all CSRs with a random value.
• Apply reset to the DUT as well as the RAL model.
• Read each CSR and compare it against the reset value. it is mandatory to replicate this test for each reset that affects all or a subset of the CSRs.
• It is mandatory to run this test for all available interfaces the CSRs are accessible from.
• Shuffle the list of CSRs first to remove the effect of ordering.

Verify accessibility of CSRs as indicated in the RAL specification.

• Loop through each CSR to write it with a random value.
• Read the CSR back and check for correctness while adhering to its access policies.
• It is mandatory to run this test for all available interfaces the CSRs are accessible from.
• Shuffle the list of CSRs first to remove the effect of ordering.

Verify no aliasing within individual bits of a CSR.

• Walk a 1 through each CSR by flipping 1 bit at a time.
• Read the CSR back and check for correctness while adhering to its access policies.
• This verify that writing a specific bit within the CSR did not affect any of the other bits.
• It is mandatory to run this test for all available interfaces the CSRs are accessible from.
• Shuffle the list of CSRs first to remove the effect of ordering.

Verify no aliasing within the CSR address space.

• Loop through each CSR to write it with a random value
• Shuffle and read ALL CSRs back.
• All CSRs except for the one that was written in this iteration should read back the previous value.
• The CSR that was written in this iteration is checked for correctness while adhering to its access policies.
• It is mandatory to run this test for all available interfaces the CSRs are accessible from.
• Shuffle the list of CSRs first to remove the effect of ordering.

Verify random reset during CSR/memory access.

• Run csr_rw sequence to randomly access CSRs
• If memory exists, run mem_partial_access in parallel with csr_rw
• Randomly issue reset and then use hw_reset sequence to check all CSRs are reset to default value
• It is mandatory to run this test for all available interfaces the CSRs are accessible from.

In this test we request multiple scrambling keys from OTP and verify that the memory scrambling is performed correctly even with multiple seeds. Perform the following steps:

• Initialize the memory to zero
• Perform some random memory operations, verify that they succeed with an all-zero key and nonce
• Repeat the following steps a number of times:
  • Get a scrambling key from the OTP interface
  • Perform a number of random memory accesses to the SRAM
• Verify that all memory access succeed even if the scrambling key changes at arbitrary intervals

This test is the same as the multiple_keys_test but we now do a series of back-to-back memory accesses at each random address in order to create read/write conflicts and stress the encryption pipeline.

In this test we iterate through each address in the SRAM memory. For each address write the current address to the SRAM.

After this is done, read every address and check that the stored data is equivalent to the current address.

This will verify that the SRAM encryption mechanism is actually bijective, and will not cause any address collisions.

e.g. if the encryption scheme causes addresses 0x1 and 0x2 to collide and we write 0x1 and 0x2 respectively, we will see a return value of 0x2 when we read from 0x1, instead of the expected 0x1.

This process will be repeated for a number of new key seeds.

This test will reuse the common tl_access_tests to run TLUL error sequences on the SRAM TLUL interface to verify that erroneous TLUL transactions are handled correctly.

This test is the same as the multiple_keys test, except we make sure to sequence some memory transactions while a key request to OTP is still pending. Verify that these transactions are completely ignored by the memory.

TODO: Behavior might change in future to throw an error instead of ignore, should be reflected in TB.

This test is the same as the multiple_keys test, except we now randomly assert the lifecycle escalation signal. Upon sending an escalation request, we verify that the DUT has properly latched it, and all scrambling state has been reset. In this state, we perform some memory accesses, they should all be blocked and not go through. We then issue a reset to the SRAM to get it out of the terminal state, and issue a couple of memory accesses just to make sure everything is still in working order.

This test is the same as the multiple_keys test, except we randomly inject a parity error into the memory (TODO: figure out how exactly to do this). Verify that the SRAM reports the error and the faulty address correctly, and that the alert is sent out properly. We then perform some memory accesses and verify that none of them go through. This error is terminal, so like the lc_escalation test, issue a reset and then perform some memory accesses to make sure everything comes back online correctly.

Verify common alert_test CSR that allows SW to mock-inject alert requests.

• Enable a random set of alert requests by writing random value to alert_test CSR.
• Check each alert_tx.alert_p pin to verify that only the requested alerts are triggered.
• During alert_handshakes, write alert_test CSR again to verify that: If alert_test writes to current ongoing alert handshake, the alert_test request will be ignored. If alert_test writes to current idle alert handshake, a new alert_handshake should be triggered.
• Wait for the alert handshakes to finish and verify alert_tx.alert_p pins all sets back to 0.
• Repeat the above steps a bunch of times.

Access out of bounds address and verify correctness of response / behavior

Drive unsupported requests via TL interface and verify correctness of response / behavior. Below error cases are tested

• TL-UL protocol error cases
  • Unsupported opcode. e.g a_opcode isn't Get, PutPartialData or PutFullData
  • Mask isn't all active if opcode = PutFullData
  • Mask isn't in enabled lanes, e.g. a_address = 0x00, a_size = 0, a_mask = 'b0010
  • Mask doesn't align with address, e.g. a_address = 0x01, a_mask = 'b0001
  • Address and size aren't aligned, e.g. a_address = 0x01, a_size != 0
  • Size is over 2.
• OpenTitan defined error cases
  • Access unmapped address, return d_error = 1 when devmode_i == 1
  • Write CSR with unaligned address, e.g. a_address[1:0] != 0
  • Write CSR less than its width, e.g. when CSR is 2 bytes wide, only write 1 byte
  • Write a memory without enabling all lanes (a_mask = '1) if memory doesn't support byte enabled write
  • Read a WO (write-only) memory

Drive back-to-back requests without waiting for response to ensure there is one transaction outstanding within the TL device. Also, verify one outstanding when back- to-back accesses are made to the same address.

Access CSR with one or more bytes of data For read, expect to return all word value of the CSR For write, enabling bytes should cover all CSR valid fields

TODO: This feature is not yet implemented, so this description will become more detailed at that time.

This test is meant to test executable SRAM (Ibex fetching data from SRAM).

This test is the same as the multiple_keys test, except now we randomly set the sram_fetch (name TBD) input(s) from the OTP controller.

Verify that in this scenario all memory transactions matching the Host user ID go through, but all transactions with mismatched user IDs error out.