Verify transmission of data over the TX and RX port.

SW test sends a known payload over the TX port. The testbench, at the same time sends a known payload over RX. On reception, both payloads are checked for integrity. SW validates the reception of TX watermark, RX watermark, and the TX empty interrupts. Choosing the max supported baud rate for the UART is sufficient.

Verify each UART instance at the chip level independently. Verify there is no aliasing on all UART ports across the instances.

Verify the RX overflow interrupt.

The testbench sends a random payload of size greater than the RX fifo size (32). The SW ignores the received the data to allow the RX overflow interrupt to assert.

Verify each UART instance at the chip level independently. Verify there is no aliasing on all UART ports across the instances.

Verify UART transmission of data at various speeds.

Randomly pick one of the UART instances and configure it to run with any of these baud rates - 9600bps, 115200bps, 230400bps, 128Kbps, 256Kbps, 1Mkbps, 1.5Mkbps.

Verify the transmission of UART via using external clock as uart core clock.

Extend from chip_sw_uart_rand_baudrate with following added settings.

• Configure LC to RMA state, so that it allows clkmgr to use external clock.
• Configure clkmgr to select external clock.
• Randomize HI_SPEED_SEL, so that uart core clock frequency can be either ext_clk_freq / 4 or ext_clk_freq / 2.

Verify GPIO outputs.

SW test configures the GPIOs to be in the output mode. The test walks a 1 through the pins. The testbench checks the value for correctness and verifies that there is no aliasing between the pins.

Verify GPIO inputs.

The SW test configures the GPIOs to be in input mode. The testbench walks a 1 through the pins. SW test ensures that the GPIO values read from the CSR is correct.

Verify GPIO interrupts.

The SW test configures the GPIOs to be in input mode and enables all of them to generate an interrupt. The testbench walks a 1 through the pins. SW test ensures that the interrupt corresponding to the right pin is seen.

Provide example tests for different testing scenarios / needs.

These tests do not verify the hardware. They are meant to serve as a guide for developing actual tests under different testing scenarios. These example tests demonstrate the capabilities of the DV infrastructure which enables these scenarios:

1. Implement test in the ROM stage itself
2. Implement test in the flash stage, using test ROM
3. Implement test in the flash stage, using production ROM
4. Enable external maufacturer hooks in existing tests developed in the open source
5. Enable concurrent threads in tests

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.

Verify regwen CSR and its corresponding lockable CSRs.

• Randomly access all CSRs
• Test when regwen CSR is set, its corresponding lockable CSRs become read-only registers

Note:

• If regwen CSR is HW read-only, this feature can be fully tested by common CSR tests - csr_rw and csr_aliasing.
• If regwen CSR is HW updated, a separate test should be created to test it.

This is only applicable if the block contains regwen and locakable CSRs.

Sequentially test each host to access any device

Verify the transmission of data on the chip's SPI device port in firmware mode with single mode.

• The testbench sends a known payload over the chip's SPI device input port.
• The SW test, at the same time sends a known payload out over the chip's SPI device output port.
• On reception, both payloads are checked for integrity.
• SW validates the reception of RX fifo full, RX fifo over level, TX fifo under level, RX overflow and TX underflow interrupts.
• Run with min (6MHz), typical (30-48Mhz) and max(48MHz) SPI clk frequencies. should use
• Also, ensure that the spi_device does not receive transactions when the csb is high.
• TODO, consider to test this mode with a real use case. The actual use case of this mdoe is not clear right now.

Verify the SPI device in flash mode.

• SW puts the SPI device in flash mode
• Load a firmware image (bootstrap) through flash commands to the spi_device memory.
• SW verifies the integrity of the image upon reception by reading the spi_device memory.
• Ensure the image is executed correctly

Verify the pass through mode from an end-to-end perspective.

• Configure the SPI device and host in pass through mode.
• Program the cmd_filter_* CSRs to filter out random commands.
• Configure and enable both spi_host0 and spi_host1
• Send a random flash commands over the SPI device interface (chip IOs) from the testbench.
• Verify the flash commands which pass through spi_host0, are received on chip IOs.
• Verify that only the payloads that are not filtered show up on the SPI host interface at chip IOs.
• Verify spi_host1 doesn't send out any data from spi_device
• Run with min (6MHz), typical (24Mhz) and max (30MHz) SPI clk frequencies.
• Run with single, dual and quad SPI modes.
• Testbench should test the following commands:
  • Read Normal, Fast Read, Fast Dual, Fast Quad, Chip Erase, Program

Verify the collisions on driving spi_host is handled properly

• Enable upload related interrupts and configure the spi_device in passthrough mode.
• Configure a command slot to enable upload for a flash program/erase command.
• Excecute two parallel threads:
  1. SPI host agent.
  • Send this command via an upstream SPI host agent, then the agent keeps sending read_status to poll the busy bit.
  • When the busy bit is low, issue a read command to read data from the downstream SPI port, and check data correctness.
  2. A SW process.
  • SW receives an upload interrupt and reads the command in the upload fifo to check.
  • SW configures the SPI host that shows the same downstream port, to send the uploaded command to the downstream SPI port.
  • SW clears busy bit to allow the upstream SPI host to proceed to the next command.

Verify the basic operation of the spi tpm mode..

• The testbench sends a known payload over the chip's SPI device tpm input port.
• The testbench sends a read command.
• The software test should playback the data received in the write command as the read response.
• The testbench should check if the written and read data match.

Verify the transmission of data on the chip's SPI host port.

• Program the SPI host to send a known payload out of the chip on the SPI host ports.
• The testbench receives the payload and plays it back to the SPI host interface.
• The SW verifies the sent payload matches the read response and services SPI event interrupts.
• Run with min and max SPI clk frequencies and with single, dual and quad SPI modes.

Verify all SPI host instances in the chip.

Verify the transmission of data over the chip's I2C host interface.

• Program the I2C to be in host mode.
• The SW test writes a known payload over the chip's I2C host interface, which is received by the testbench.
• The testbench then loops this data back to the chip's I2C host and exercises the read interface.
• SW validates the reception of FMT watermark and trans complete interrupts.
• SW validates that the data read matches the original data written.
• Verify the virtual / true open drain capability.

Verify all instances of I2C in the chip.

Verify the transmission of data over the chip's I2C device interface.

• Program the I2C to be in device mode.
• The testbench writes a known payload over the chip's I2C device interface, which is received and verified by the SW test for correctness.
• The testbench reads and verifies a known payload over the chip's I2C device interface,
• SW validates the reception of tx empty and trans complete interrupts.
• Verify the virtual / true open drain capability.

Verify all instances of I2C in the chip.

Verify the MIO muxing at input and output sides.

• Enable stub_cpu mode.
• Add a forcing interface to pinmux's pad-facing DIO and MIO ports, including the output enables; and a sampling interface for the peripheral facing DIO and MIO ports.
• Similarly, add a driving / sampling interface for all DIOs and MIOs at the chip pads.
• In the output direction:
  • Program all MIO outsel and pad attribute registers to random values.
  • Force the pad-facing pinmux MIO ports and output enables to random values.
  • Verify all MIO pad values for correctness.
• For the input direction:
  • Program all MIO insel and pad attribute registers to random values.
  • Drive the MIO pads to random values.
  • Probe and sample the peripheral facing MIO ports of the pinmux and verify the values for correctness.
• Follow a similar testing procedure for DIOs.

Verify pad attribute settings for all MIO and DIO pads.

• Follow the same procedure as the chip_pin_mux test, ensuring the padctrl attribute registers for all MIOs and DIOs are also randomized when verifying the outcomes.
• Verify weak pull enable, output inversion and virtual open drain and drive strength (bit 0) signaling in the output direction.
• Verify weak pull enable and input inversion in the input direction.
• Verify multiple pad attributes for each pad set at the same time through randomization.

Cross-references the chip_pin_mux test.

Verify the MIO output values in any sleep states.

• Pick between normal sleep and deep sleep randomly
• Pick between tie-0, tie-1, or High-Z randomly for all muxed, dedicated outputs coming from non-AON IPs.

SW programs the MIO OUTSEL CSRs to ensure that in sleep it randomly picks between tie-0, tie-1 or hi-Z for all muxed outputs coming from non-AON IPs. If an AON peripheral output is muxed, then that peripheral's output is selected to ensure in deep sleep the peripheral can continue its signaling even in deep sleep. The testbench verifies the correctness of the reflected values once the chip goes into deep sleep. This is replicated for DIO pins as well.

In this test, passthrough feature is not tested. The feature is covered in other tests such as chip_sw_sleep_pwm_pulses.

Verify pin wake up from any sleep states.

Verify one of the 8 possible MIO or DIO pad inputs (randomly configured) can cause the chip to wake up from sleep state. Verifying wake on posedge is sufficient for the chip level integration testing. Upon wake up, SW reads the wake cause CSR to verify correctness.

Verify the retention logic in pinmux that is activated during deep sleep.

• Pick a pin (such as GPIO0) and enable it in output mode. Set a known value to it (0 or
  1. and verify the correctless of the value on the chip IO..
• Program the pin's retention value during deep sleep to be opposite of the active power value programmed in the previous step.
• Reuse an existing deep sleep / low power wake up test, such as chip_sw_sleep_pin_wake test to enter low power.
• Once the chip enters the deep sleep state, verify that this pin holds the correct retention value throughout the low power state.
• Wake up the chip from sleep using the chosen method.
• Verify the pin value at the chip IOs is no longer holding the retention value once the chip is back in active power.

Verify tap accesses in different LC states.

Verify pinmux can select the life_cycle, RISC-V, and DFT taps after reset. Verify that in TEST_UNLOCKED* and RMA states, pinmux can switch between the three TAPs without issuing reset. Verify in PROD state, only the LC tap can be selected. Verify in DEV state, only the LC tap and RISC-V taps can be selected. Verify DFT test mode straps are sampled and output to AST via top_earlgrey.dft_strap_test_o in TEST_UNLOCKED* and RMA states. Verify top_earlgrey.dft_strap_test_o is always 0 in the states other than TEST_UNLOCKED* and RMA, regardless of the value on DFT SW straps.

Note: these tests require the ROM init stage to complete. So a test ROM image is loaded, but the software does not test anything. The CPU boots and runs to completion while the host (SV testbench) performs these stimulus / checks.

Verify pattern generation to chip output pads.

• Program the pattgen to generate a known pattern in each lane.
• Program the pinmux to route the chosen output to the chip IOs.
• Verify that the correct pattern is seen on the IOs by hooking up the pattgen monitor.
• Validate the reception of the done interrupt.
• Verify both pattgen channels independently.

Verify PWM signaling to chip output pads during deep sleep.

• Program each PWM output to pulse in a known pattern.
• Program the pinmux to route the chosen PWM output to the chip IOs.
• Program the pwrmgr to go to deep sleep state, with AON timer wakeup.
• Initiate the sleep state by issuing a WFI.
• Verify that in the sleep state, the PWM signals are active and pulsing correctly, by hooking up the PWM monitor.
• Repeat the steps for all 6 PWM signals.

Verify the alert signaling mechanism due to integrity violations of load ops.

An SW test which performs the following on main and retention SRAMs to verify the memory end-to-end integrity scheme:

• Corrupt a random data / integrity bit in the memory using SV force.
• SW reads that address and the corrupted data is sent to ibex.
• Verify that ibex detects the integrity violation and triggers an alert.
• Check the alert up to the NMI phase and make sure that the alert cause is from Ibex.

Verify the alert signaling mechanism due to integrity violations of instruction fetches.

An SW test which performs the following on main SRAM to verify the memory end-to-end integrity scheme:

• Corrupt a data / integrity bit in a test function in the main SRAM using SV force.
• SW jumps to that test function in the main SRAM.
• Verify that ibex detects the integrity violation and triggers an alert.
• Check the alert up to the NMI phase and make sure that the alert cause is from Ibex.

Verify accessibility of all the CSRs in the chip over JTAG.

• Shuffle the list of CSRs first to remove the effect of ordering.
• Write all CSRs via JTAG interface with a random value.
• Shuffle the list of CSRs yet again.
• Read all CSRs back and check their values for correctness while adhering to the CSR's access policies.
• Accesses to CSRs external to rv_dm go through RV_DM SBA interface into the xbar.

Verify accessibility of all the memories in the chip over JTAG.

This test will target the following memories in the chip: sram_main, sram_ret, otbn i|dmem, ROM

• Shuffle the list of memories first to remove the effect of ordering.
• Write a location in a randomly chosen set of addresses within each memory via JTAG interface with random values.
• For read-only memories, preload the memory with random data via backdoor.
• Shuffle the list of memories again.
• Read the previously written addresses in the memories back again and check the read value for correctness. Pick some random addresses to verify in case of read-only memories.

Verify non-debug reset request initiated from RV_DM when the chip is awake.

• Program some CSRs / mem that are under life cycle reset tree and system reset tree.
• Configure RV_DM to send NDM reset request to reset sytem reset tree.
• While NDM reset is ongoing, ensure the RV_DM debug module registers can still be accessed.
• Read the programmed CSRs / mem to ensure that everything under system reset tree is reset to the original values, while values under life cycle reset will be preserved.
• Read CSRs / mem in the debug domain to ensure that the values survive the reset.

Verify non-debug reset request initiated from RV_DM when the CPU is in halted state.

• Initialize the DUT in a HW-debug enabled life cycle state.
• Activate the RISCV debug module.
• Run some SW test on the CPU.
• Initiate a CPU halt request via JTAG.
• Wait for the CPU to be in halted state via JTAG by polling dmstatus.anyhalted.
• Deassert the CPU haltreq and verify that we are still in halted state.
• (Optional) Using the abstract command, read the dcsr register to verify the cause reflects the debug halt request.
• Issue an NDM reset request. All non-debug parts of the chip should reset. Read the dmstatus.anyhalted / dvstatus.allhalted and verify that they are cleared.
• De-assert the NDM reset request and wait for the CPU to reboot and finish the post-NDM reset phase of the test.

Verify RV_DM works after wakes up from sleep.

• Put the chip into sleep mode and then wake up (both deep sleep and normal sleep).
• If waking up from normal sleep, an activation should not be required for RV_DM CSR accesses to work.
• If waking up from deep sleep, an activation is required for RV_DM CSR accesses to work.

Verify ability to select all available TAPs.

• Put life cycle on Test or RMA state, so that TAPs can be selected between life cycle RV_DM and DFT.
• Verify the TAP is selected correctly.
• X-ref'ed with chip_sw_tap_strap_sampling.

Verify that the debug capabilities are disabled in certain life cycle stages.

• Put life cycle in a random life cycle state.
• Verify that the rv_dm bus device is inaccessible from the CPU as well as external JTAG if the life cycle state is not in TEST_UNLOCKED*, DEV or RMA.
• The bus access check is performed by randomly reading or writing a CSR inside the RV_DM and checking whether the TL-UL bus errors out.
• The JTAG access check is performed by writing and then reading a register that is accessible via the TAP/DMI inside the RV_DM. If the JTAG wires are gated, it is expected that the RV_DM returns all-zero instead of the written value.
• X-ref'ed with chip_tap_strap_sampling

Verify the timeout interrupt assertion.

• Configure the RV_TIMER to generate interrupt after a set timeout.
• Issue a WFI to wait for the interrupt to trigger.
• Service the interrupt when it triggers; verify that it came from rv_timer.
• Verify that the interrupt triggered only after the timeout elapsed.

Verify the AON timer wake up interrupt in normal operating state.

• Program the PLIC to let the AON timer wake up interrupt the CPU.
• Program the AON timer to generate the wake up timeout interrupt after some time.
• Issue a WFI to wait for the interrupt to trigger.
• Service the interrupt when it triggers; verify that it came from AON timer.
• Verify that the interrupt triggered only after the timeout elapsed.

Verify that AON timer can wake up the chip from a deep sleep state.

• Read the reset cause register in rstmgr to confirm that the SW is in the POR reset phase.
• Program the pwrmgr to go to deep sleep state (clocks off, power off).
• Program the AON timer to wake up the chip in a reasonable amount of time.
• Have the CPU issue WFI to signal the pwrmgr to go into sleep state.
• Verify via assertion checks, the wake up request occurs after the timeout has elapsed.
• After reset followed by AON timer wake up, read the reset cause register to confirm the AON timer wake up phase.
• After the test sequence is complete, read the wake up threshold register - it should not be reset.

Verify the watchdog bark reception in normal state.

• Program the PLIC to let the wdog bark signal interrupt the CPU.
• Program the AON timer wdog to 'bark' after some time and enable the bark interrupt.
• Service the bark interrupt upon reception.

Verify that the LC escalation signal disables the AON timer wdog.

• Program the AON timer wdog to 'bark' after some time and enable the bark interrupt.
• Start the escalation process and fail the test in the interrupt handler in case the bark interrupt is fired.
• Program the alert handler to escalate on alerts upto phase 2 (i.e. reset) but the phase 1 (i.e. wipe secrets) should occur and last during the time the wdog is programed to bark and bite.
• Trigger an alert to cause an escalation condition before the bark signal asserts.
• After the reset ensure that the reset cause was due to the escalation to prove that the wdog was disabled.

Verify the watchdog bite causing reset in the normal state.

• Read the reset cause register in rstmgr to confirm that the SW is in the POR reset phase.
• Program the AON timer wdog to 'bark' after some time.
• Let the bark escalate to bite, which should result in a reset request.
• After reset, read the reset cause register in rstmgr to confirm that the SW is now in the wdog reset phase.

Verify the watchdog bite causing reset in sleep state.

• Repeat the steps in chip_aon_timer_wdog_bite_reset test, but with following changes:
• Program the pwrmgr to go to deep sleep state (clocks off, power off).
• Issue a WFI after programming the wdog, so that the reset request due to bite occurs during deep sleep state.
• After reset, read the reset cause register in rstmgr to confirm that the SW is now in the wdog reset phase.

Verify that the wdog can be paused in sleep state.

• Repeat the steps in chip_aon_timer_sleep_wakeup test, but with following changes:
• Program the wdog to 'bite' a little sooner than the AON timer wake up.
• Also, program the wdog to pause during sleep.
• Issue a WFI after programming the wdog, so that the reset request occurs during deep sleep state.
• After reset followed by AON timer wake up, read the reset cause register to confirm that the AON timer woke up the chip, not the wdog reset.
• Un-pause the wdog and service the bark interrupt.

Verify all interrupts from all peripherals aggregated at the PLIC.

The automated SW test enables all interrupts at the PLIC to interrupt the core. It uses the intr_test CSR in each peripheral to mock assert an interrupt, looping through all available interrupts in that peripheral. The ISR verifies that the right interrupt occurred. This is used as a catch-all interrupt test for all peripheral integration testing within which functionally asserting an interrupt is hard to achieve or not of high value.

Verify the SW interrupt to the CPU.

Enable all peripheral interrupts at PLIC. Enable all types of interrupt at the CPU core. Write to the MSIP CSR to generate a SW interrupt to the CPU. Verify that the only interrupt that is seen is the SW interrupt.

Verify the ability to turn off the transactional clock via SW.

Ensure that the clock to transactional units will be turned off after any activity completes in the transactional IP. Verify it is off via spinwait in hints_status CSR. Verify that turning off this clock does not affect the other derived clocks.

Verify the turned off transactional units.

Verify CSR accesses do not complete in units that are off. Using the watchdog timers, turn off a transactional unit's clock, issue a CSR access to that unit, verify a watchdog event results, and verify the rstmgr crash dump info records the CSR address.

A stretch goal is to check the PC corresponds to the code performing the CSR access (stretch since it could be difficult to maintain this check).

Verify the ability to turn off the peripheral clock via SW.

Verify CSR accesses do not complete in peripherals that are off. Using the watchdog timers, turn off a peripheral's clock, issue a CSR access to that peripheral, verify a watchdog event results, and verify the rstmgr crash dump info records the CSR address.

Verify clk division logic is working correctly.

The IP level checks the divided clocks via SVA, and these are also bound at chip level. Connectivity tests check peripherals are connected to the clock they expect. Use the clkmgr count measurement feature to verify clock division.

Verify the clkmgr requests ext clk src during certain LC states.

On POR lc asserts lc_clk_byp_req on some LC states, and de-asserts it when lc_program completes. This also triggers divided clocks to step down. It may be best to verify this via SVA, unless we implement clock cycle counters.

Verify SW causes the clkmgr requests ext clk src during certain LC states.

In RMA and TEST_UNLOCKED lc states the external clock is enabled in response to extclk_ctrl.sel CSR writes. In addition extclk_ctrl.hi_speed_sel CSR causes the divided clocks to step down. Verify this via SVA bound to clkmgr, and clock cycle counters. X-ref with chip_sw_uart_tx_rx_alt_clk_freq, which needs to deal with this as well.

Verify the clock jitter functionality.

Enable clock jitter setting the clkmgr jitter_enable CSR high. This causes the jitter_o clkmgr output to toggle. Verify this output is connected to AST's clk_src_sys_jen_i input using formal.

X-ref with various specific jitter enable tests.

Verify that the system can run at a reduced, calibrated clock frequency.

This test should check that the system can run at a reduced, calibrated clock frequency (70MHz) with jitter enabled (which can lower the frequency down to ~55 MHz momentarily). This option is intended as a fall-back in case there are issues running the system with at 100MHz (calibrated).

This testpoint can be covered by extending the DV environment to support the extended range clock option via a flag, and running several existing chip-level tests with that option.

Test the following functionalities with reduced clock:

• flash_ctrl initialization
• flash_ctrl program, read and erase operations
• AES, HMAC, KMAC and OTBN operations
• Keymgr key derivation
• Scramble-enabled access from the main SRAM
• Csrng edn concurrency

Verify the frequency measurement through deep sleep.

Enable clock cycle counts. Put the chip in deep sleep. Upon wakeup reset the clock measurements should be off, but the recoverable fault status should not be cleared.

Verify the frequency measurement through shallow sleep.

Enable clock cycle counts. Put the chip in shallow sleep with pwrmgr's CONTROL CSR keeping some clocks disabled. Upon wakeup the clock measurements should be on, and the recoverable fault status should show no errors for the disabled clocks.

Verify the frequency measurement through reset.

Enable clock cycle counts, configured to cause errors. Trigger a chip reset via SW. After reset the clock measurements should be off and the recoverable fault status should be cleared.

Verify the clock manager resets to a clean state after an escalation reset.

Trigger an internal fatal fault for the regfile onehot checker and let it escalate to reset. Upon alert escalation reset, the internal status should be clear and clkmgr should not attempt to send out more alerts.

Verify the flash ctrl fatal error does not disturb escalation process and operation of ibex core.

Trigger an internal fatal fault (host_gnt_err) from flash_ctrl and let it escalate to reset. Upon alert escalation reset, the internal status should be clean and should not send out more alerts.

Verify the cold boot sequence by wiggling of chip's POR_N.

This ensures that both FSMs are properly reset on the POR signal. The check is that the processor ends up running. Also verify, the rstmgr recorded POR in reset_info CSR by checking retention SRAM for reset_reason.

Verify that the chip can go into random low power states and be woken up by ALL wake up sources.

This verifies ALL wake up sources. This also verifies that the pwrmgr sequencing is working correctly as expected. X-ref'ed with all individual IP tests. For each wakeup source clear and enable wake_info CSR, enable the wakeup from that source with the wakeup_en CSR, bring the chip to both normal and low power sleep, optionally disabling the source's clock, have the source issue a wakeup event and verify wake_info indicates the expected wakeup.

Each test should perform a minimum of 2 low power transitions to ensure there are no state dependent corner cases with wakeup interactions.

Verify that the chip can go into normal sleep state and be woken up by ALL wake up sources.

This verifies ALL wake up sources. This also verifies that the pwrmgr sequencing is working correctly as expected. X-ref'ed with all individual IP tests. For each wakeup source clear and enable wake_info CSR, enable the wakeup from that source with the wakeup_en CSR, bring the chip to normal sleep, optionally disabling the source's clock, have the source issue a wakeup event and verify wake_info indicates the expected wakeup.

Verify that the chip can go into normal sleep state and be reset by ALL reset req sources.

This verifies ALL reset sources. This also verifies that the pwrmgr sequencing is working correctly as expected. X-ref'ed with all individual IP tests. For each reset source, enable the source and bring the chip to low power, issue a reset, and verify the rstmgr's reset_info indicated the expected reset by checking retention SRAM for reset_reason.

Verify that the chip can go into deep sleep state and be woken up by ALL wake up sources.

This verifies ALL wake up sources. This also verifies that the pwrmgr sequencing is working correctly as expected. X-ref'ed with all individual IP tests. Similar to chip_pwrmgr_sleep_all_wake_ups, except control.main_pd_n is set to 0.

Verify that the chip can go into deep sleep state and be reset up by ALL reset req sources.

This verifies ALL reset sources.

• 7 resets are generated randomly with deep sleeps
• POR (HW PAD) reset, SW POR, sysrst, wdog timer reset, esc rst, SW req
• esc reset is followd by normal mode because it does not work with sleep mode

Verify that the chip can go into normal sleep state and be reset up by ALL reset req sources.

This verifies ALL reset sources.

• 7 resets are generated randomly with normal sleeps
• POR (HW PAD) reset, SW POR, sysrst, wdog timer reset, esc rst, SW req
• esc reset is followed by normal mode and cleared by reset because it does not work with sleep mode

Verify that the chip can be reset by watchdog timer reset source.

This verifies watchdog timer reset source. This also verifies that the pwrmgr sequencing is working correctly as expected. X-ref'ed with all individual IP tests. Similar to chip_pwrmgr_sleep_all_reset_reqs, except the chip is not put in low power mode.

Verify the cold boot sequence through an AON power glitch.

Pulsing the AST vcaon_supp_i input causes an AON power glitch which becomes a POR. This ensures that both FSMs are properly reset on the POR signal. The check is that the processor ends up running. Also verify, the rstmgr recorded POR in reset_info CSR by checking retention SRAM for reset_reason.

Verify the effect of a glitch in main power rail.

The vcmain_supp_i AST input is forced to drop once the test is running. This triggers a MainPwr reset request, which is checked by reading retention SRAM's reset_reason to see that the reset_info CSR's POR bit is not set when the test restarts.

Verify the effect of a glitch in main power rail in random sleep states.

The vcmain_supp_i AST input is forced to drop right after putting the chip in a random sleep state. This triggers a MainPwr reset request, which is checked by reading retention SRAM's reset_reason to show that the reset_info CSR's POR bit is not set when the test restarts.

Note: the glitch has to be sent in a very narrow window:

• If sent too early the chip won't have started to process deep sleep.
• If too late the hardware won't monitor main power okay so the glitch will have no effect, and the test will timeout.

Each test should perform a minimum of 2 low power transitions to ensure there are no state dependent corner cases with power glitch handling.

Verify the effect of a glitch in main power rail in deep sleep.

The vcmain_supp_i AST input is forced to drop right after putting the chip in deep sleep. This triggers a MainPwr reset request, which is checked by reading retention SRAM's reset_reason to show that the reset_info CSR's POR bit is not set when the test restarts.

Note: the glitch has to be sent in a very narrow window:

• If sent too early the chip won't have started to process deep sleep.
• If too late the hardware won't monitor main power okay so the glitch will have no effect, and the test will timeout.

Verify the effect of a glitch in main power rail in shallow sleep.

The vcmain_supp_i AST input is forced to drop after putting the chip in shallow sleep. This triggers a MainPwr reset request, which is checked by reading the retention SRAM's reset_reason shows that the reset_info CSR's POR bit is not set when the test restarts.

Verify that this chip can be reset by All available reset sources.

• 12 resets are generated randomly with normal/deep sleeps
• POR (HW PAD) reset, SW POR, sysrst, wdog timer reset, esc rst, SW req
• esc reset is followd by normal mode because it does not work with sleep mode

Verify the effect of a sysrst_ctrl output in main power rail.

• Read the reset cause register in rstmgr to confirm that the SW is in the POR reset phase.
• After sysrst reset is generated by forcing, read the reset cause register in rstmgr to confirm that the SW is now in the sysrst reset phase.
• Generate sysrst by driving input PAD.
• After reset, read the reset cause register in rstmgr to confirm that the SW is now in the sysrst reset phase.
• Program the AON timer wdog to 'bark' after some time.
• Let the bark escalate to bite, which should result in a reset request.
• After reset, read the reset cause register in rstmgr to confirm that the SW is now in the wdog reset phase.
• Program the AON timer wdog to 'bark' after some time.

Verify that the pwrmgr sequences sleep_req and reset req coming in almost at the same time, one after the other. Use POR_N PAD to trigger reset.

Verify that the chip does not go to sleep on WFI when low power hint is 0.

This calls WFI with low_power_hint disabled and pwrmgr interrupts enabled, and fails if the pwrmgr ISR is called.

Verify the power manager resets to a clean state after an escalation reset.

Trigger an internal fatal fault for the regfile onehot checker and let it escalate to reset. Upon alert escalation reset, the internal status should be clear and pwrmgr should not attempt to send out more alerts.

Verify the reset_info CSR register for lc or higher resets.

Generate the 5 types of reset at lc level or higher, and check the retention SRAM's reset_reason to show that reset_info CSR is as expected. This and other rstmgr testpoints that require different resets cross-reference the individual IP tests that generate those resets, and this testpoint merely adds reset checks in them. Those IP blocks are pwrmgr, alert_handler, aon_timer, and sysrst_ctrl.

This should also check the reset's destination IP to make sure some reset side-effect is present. Setting some intr_enable CSR bit when the test starts and checking it after reset seems suitable. The spi_host IPs receive multiple resets so they will need special consideration. TODO(maturana) Add specific tests once they are developed.

Verify the reset_info CSR register for sys reset.

Generate reset triggered by rv_dm, which results in a sys level reset, and check the retention SRAM's reset_reason to show that the reset_info CSR is as expected. This testpoint cross-reference the rv_dm tests that generate this reset, and this testpoint merely adds reset checks in them.

This should also check the reset's destination IP to make sure some reset side-effect is present. Setting some intr_enable CSR bit when the test starts and checking it after reset seems suitable. The spi_host IPs receive multiple resets so they will need special consideration.

X-ref with chip_rv_dm_ndm_reset_req.

Verify the expected values from the cpu_info CSR on reset.

For some software induced resets we can predict the expected contents of cpu_info; reads of writes to unmapped addresses for example. Generate these resets and verify the cpu_info register contents when reset is handled. Refer to chip_*sys_rstmgr_reset_info.

Verify software requested device reset.

Generate a reset request by directly writing the reset_req CSR. The reset created should be identical to those caused by hardware sources. After reset, the retention SRAM's reset_reason should show that the reset_info CSR reflects that a software request was the reset cause.

Verify the expected values from the alert_info CSR on reset.

Various alerts can be created, for example, timeouts, and integrity errors, and at least part of the alert_info CSR can be predicted. To cause some of these to cause a reset, mask the relevant processor interrupts. Trigger these resets and verify the alert_info register contents when reset is handled. Refer to chip_*sys_rstmgr_reset_info.

Verify sw_rst_ctrl_n CSR resets individual peripherals.

• Pick a rw type CSR in each peripheral and program arbitrary value that does not cause any adverse side-effects.
• Pulse the reset to the peripheral via software.
• Read the resister after reset and verify it returns the reset value.
• Repeat these steps for each of these software resettable peripherals: spi_device, spi_host0, spi_host1, usb, i2c0, i2c1, i2c2.

Notice the two spi_host IPs receive two different resets, spi_host*.

Verify the reset manager resets to a clean state after an escalation reset.

Trigger an internal fatal fault for the regfile onehot checker and let it escalate to reset. Upon alert escalation reset, the internal status should be clear and rstmgr should not attempt to send out more alerts.

Verify all alerts coming into the alert_handler.

An automated SW test, which does the following (applies to all alerts in all IPs):

• Program the alert_test CSR in each block to trigger each alert one by one.
• Ensure that all alerts are properly connected to the alert handler and cause the escalation paths to trigger.

Verify all alert escalation paths.

Verify all escalation paths triggered by an alert.

• Verify the first escalation results in NMI interrupt serviced by the CPU.
• Verify the second results in device being put in scrap state, via the LC JTAG TAP.
• Verify the third results in chip reset.
• Ensure that all escalation handshakes complete without errors.

Verify escalation from all unit integrity errors

Inject integrity errors in any unit that has a one-hot checker for CSR register writes, and verify escalation is triggered. Allow escalation to go through reset. Use the rstmgr alert info and the unit's fault CSRs to check the alert cause is right. Each run of the test randomly chooses some one-hot checker for the error to be injected. Keep state across resets in flash to check the expected interrupts and the right number of resets occur.

• Verify the integrity error results in a regular interrupt.
• Verify the first escalation results in NMI serviced by the CPU.
• Verify the alert id in both these interrupts.
• Verify the unit's fault CSR correctly captured the fault kind.
• Verify any timer interrupts are disabled by escalation.
• Verify after the escalation reset all faults are cleared, and that the alert info captured the correct alert.
• Check that no additional resets occur.

Verify all classes of alert handler interrupts to the CPU.

X-ref'ed with the automated PLIC test.

Verify the alert handler entropy input to ensure pseudo-random ping timer.

• Force alert_handler_ping_timer input signal wait_cyc_mask_i to 8'h07 to shorten the simulation time.
• Verify that the alert_handler can request EDN to provide entropy.
• Ensure that the alert ping handshake to all alert sources and escalation receivers complete without errors.

Verify the alert handler crashdump signal.

When the chip resets due to alert escalating to cause the chip to reset, verify the reset cause to verify the alert crashdump.

Xref'ed with chip_sw_rstmgr_alert_info.

Verify the alert senders' ping timeout.

Set alert_handler's ping timeout cycle to 2 and enable alert_senders. Verify that alert_handler detects the ping timeout and reflects it on the loc_alert_cause register.

Verify alert_handler can preserve alerts during low_power mode.

• Trigger fatal alerts for all IPs but configure alert_handler so it won't trigger reset.
• Randomly enter normal or deep sleep mode.
• Wait random cycles then wake up from the sleep mode.
• After wake up from normal sleep mode, clear all alert cause registers and check that all alerts are still firing after waking up.
• Repeat the previous steps for random number of iterations.

Verify alert_handler's ping mechanism works correctly during sleep and wake up.

There are two scenarios to check:

• Configure alert_handler's ping timeout register to a reasonble value that won't cause ping timeout in normal cases. Then randomly enter and exit normal or deep sleep modes. Check that no local alerts triggered in alert_handler. This scenario ensures that ping mechanism won't send out spurious failure.
• Configure alert_handler's ping timeout register to a small value that will always causes ping timeout. Then randomly enter and exit normal or deep sleep modes. Clear local alert cause register and check that alert ping timeout continue to fire after wake up. This scenario ensures the ping mechanism will continue to send out pings after waking up from sleep modes.

Verify alert_handler's works correctly when sender clock is turned off.

• Configure clkmgr to randomly turn off one of the IP's clock and check alert_handler won't trigger a ping timeout error on that block.

Verify alert_handler's works correctly when sender reset is toggled.

• Configure rstmgr to randomly toggle one IP block's SW reset and check alert_handler won't trigger a ping timeout error on that block.

Verify escalation reverse ping timer disabled in sleep mode.

Check that escalation receivers located inside always-on blocks do not auto-escalate due to the reverse ping feature while the system is in deep sleep.

Reverse ping timeout calculation

The reverse ping timeout calculation is done using the following formula available in prim_esc_receiver:

4  * N_ESC_SEV * (2 * 2 * 2^PING_CNT_DW)

pwrmgr is the only block consuming the N_ESC_SEV and PING_CNT_DW compile time parameters:

alert_handler_reg_pkg::N_ESC_SEV = 4
alert_handler_reg_pkg::PING_CNT_DW = 16

The alert escalation responder inside pwrmgr is connected to the io_div4 clock, yielding a target 24MHz frequency. The result expected timeout based on the above parameters is thus:

reverse_ping_timeout = 0.175s = (4 * 4 ( 2 * 2 * 2^16)) / 24e6

Procedure

• On POR reset:
  • Enable all alerts assigning them to ClassA.
  • Enable all local alerts and assign to ClassB.
  • Set escalation configuration to trigger before test wake up time.
  • Set ping timeout to a time less than wake up time.
  • Lock alert configuration and enable ping mechanism.
  • Wait for polling counters to cycle through by busy polling on Ibex for reverse_ping_timeout >> 2 usec.
  • Configure AON to wake up device at a later time, making sure it is greater than the reverse_ping_timeout calculated in the previous section.
  • Enter deep sleep.
• On wake up from sleep:
  • Ensure reset status is low power exit. A kDifRstmgrResetInfoEscalation signals that there was a local escalation and should result in test failure.
  • Disable AON timer.
  • Check there are no flagged local alerts.

Verify that the escalation signals from the alert handler are connected to LC ctrl.

• Trigger an alert to initiate the escalations.
• Check that the escalation signals are connected to the LC ctrl:
  • First escalation has no effect on the LC ctrl. Read LC_STATE CSR to confirm this is the case.
  • Second escalation should cause the lc_escalation_en output to be asserted and for the LC_STATE to transition to scrap state. Confirm by reading the LC_STATE CSR
  • Verify that all decoded outputs except for escalate_en are disabled. X-ref'ed with the respective IP tests that consume these signals.

X-ref'ed with chip_sw_lc_ctrl_broadcast test, which verifies the connectivity of the LC decoded outputs to other IPs. X-ref'ed with alert_handler's escalation test.

Verify enable to access LC ctrl via JTAG.

Using the JTAG agent, write and read LC ctrl CSRs, verify the read value for correctness.

Verify the device_ID and ID_state CSRs

• Preload the hw_cfg partition in OTP ctrl with random data.
• Read the device ID and the ID state CSRs to verify their correctness.
• Reset the chip and repeat the first 2 steps to verify a different set of values.

Verify the LC ctrl initialization on power up.

Verify that the chip powers up correctly on POR.

• The pwrmgr initiates a handshake with OTP ctrl and later, with LC ctrl in subsequent FSM states. Ensure that the whole power up sequence does not hang.
• Verify with connectivity assertion checks, the handshake signals are connected.
• Ensure that no interrupts or alerts are triggered.

Verify the LC ctrl can transit from one state to another valid state with the correct tokens.

• Preload OTP image with a LC state and required tokens to transfer to next state.
• Initiate an LC ctrl state transition via SW if CPU is enabled, or via JTAG interface if CPU is disable.
• Ensure that the LC program request is received by the OTP ctrl.
• Verify the updated data output from OTP ctrl to LC ctrl is correct.
• Ensure that there is no background or otp_init error.
• Verify that the LC ctrl has transitioned to the programmed state after a reboot. Re-randomize the lc_transition tokens and repeat the sequence above.

X-ref'ed chip_sw_otp_ctrl_program.

Verify the token requested from KMAC.

• For conditional transition, the LC ctrl will send out a token request to KMAC.
• Verify that the KMAC returns a hashed token, which should match one of the transition token CSRs.

X-ref'ed with chip_kmac_lc_req.

Verify the keymgr div output to keymgr.

• Verify in different LC states, LC ctrl outputs the correct key_div_o to keymgr.
• Verify that the keymgr uses the given key_div_o value to compute the keys.

Verify broadcast signals from lc_ctrl.

• Preload the LC partition in the otp_ctrl with the following states: RMA, DEV, TEST_LOCKED[N] & SCRAP.
• Verify that the following broadcast signals are having the right effect in the respective IPs that consume them:
  • lc_dft_en_o: impacts pinmux, pwrmgr, otp_ctrl, AST
  • lc_hw_debug_en_o: impacts pinmux, pwrmgr, sram_ctrl (main and ret) & the rv_dm
  • lc_keymgr_en_o: impacts keymgr
  • lc_clk_byp_req_o: impacts clkmgr (handshake with lc_clk_byp_ack_i)
  • lc_flash_rma_req_o: impacts flash_ctrl (handshake with lc_flash_ram_ack_i)
  • lc_flash_rma_seed_o: impacts flash_ctrl
  • lc_check_byp_en_o: impacts otp_ctrl
  • lc_creator_seed_sw_rw_en_o: impacts flash_ctrl & otp_ctrl
  • lc_owner_seed_sw_rw_en_o: impacts flash_ctrl
  • lc_iso_part_sw_rd_en_o: impacts flash_ctrl
  • lc_iso_part_sw_wr_en_o: impacts flash_ctrl
  • lc_seed_hw_rd_en_o: impacts flash_ctrl & otp_ctrl
• These outputs are enabled per the [life cycle architecture spec]({{< relref "doc/security/specs/device_life_cycle/#architecture" >}}).

X-ref'ed with the respective IP tests that consume these signals.

Note that the following signals are already verified with connectivity tests and SVAs:

• lc_dft_en_o (AST connection)
• lc_cpu_en_o (rv_core_ibex)
• lc_nvm_debug_en_o (flash_ctrl)
• lc_escalate_en_o (multiple)

Verify that the SYSRST ctrl input pin values can be read.

• Drive a known value on ac_reset, ec_rst_l, flash_wp_l, pwrb, lid_open and key* pins at the chip inputs.
• Read the pin_in_value CSR to check for correctness.

Verify that the SYSRST ctrl output pin values can be set.

• Drive a known value on ac_reset, ec_rst_l, flash_wp_l, pwrb, lid_open and key* pins at the chip inputs.
• Verify that SYSRST ctrl correctly loops them back to the chip outputs.
• Write the pin_allowed_ctl register to allow some of the pins to be overridden with either 0 or 1 or both.
• Write the pin_out_ctl register to enable the override on some of the pins.
• Write the pin_out_value register to set known values on those pins.
• Verify that at the chip outputs, pins on which override should be active is reflecting the overridden values. All others should reflect the values driven on chip inputs.
• Via assertion checks (or equivalent) verify that the transitions at the inputs immediately reflect at the outputs, if not intercepted / debounced by sysrst_ctrl.

Verify the SYSRST ctrl can detect an input combination to signal an interrupt.

• Program a specific combination of transitions on pwrb, key*, ac_present and ec_reset_l pins to trigger an interrupt by writing to key_intr_ctl register.
• Program the key_intr_debounce_ctl register to debounce an appropriate time.
• Enable the interrupt at SYSRST ctrl as well as at the PLIC.
• Create glitches only for some time less than detection time and check that there is no
• interrupt triggered.
• Glitch the inputs at the chip IOs before stabilizing on the programmed transitions.
• SW services the interrupt when triggered, verifies the pin input value and key_intr_status for correctness and clears the interrupt status.
• Verify separately, each key combination sufccessfully generates an interrupt.

Verify the SYSRST ctrl can wake up the chip from deep sleep.

• Read the reset cause register in rstmgr to confirm we are in POR reset phase.
• Program one of the com_sel_ctl_* CSRs to choose a set of inputs to be detected as a low power wakeup signal for the pwrmgr.
• Program the associated detection timer.
• Program the detection outcome CSR's (com_out_ctl) interrupt bit to 1.
• Program the pwrmgr to put the chip in deep sleep state and wake up on chip wake up event.
• Issue a WFI to bring the chip in low power state.
• After the chip has entered low power mode, set the SYSRST ctrl inputs at the chip IOs to the programmed combination for the duration of the detection timer.
• Read the reset cause register to confirm wake up from low power exit phase.
• Read the pwrmgr wake up status register to confirm chip wake up.
• Read the pin input value and the combo_intr_status CSRs to verify the correct combination on inputs woke up the chip from sleep.

Verify the SYSRST ctrl can reset the chip from normal state.

• Read the reset cause register in rstmgr to confirm we are in POR reset phase.
• Program one of the com_sel_ctl_* CSRs to choose a set of inputs to be detected as the chip reset signal.
• Program the associated detection timer.
• Program the detection outcome CSR's (com_out_ctl) chip reset bit to 1.
• After some time, set the SYSRST ctrl inputs at the chip IOs to the programmed combination for the duration of the detection timer.
• The pwrmgr will power cycle the chip once it receives the chip reset input.
• Check that ec_rst_l and flash_wp_l (on pads IOR8 and IOR9) are asserted right after the pwrmgr has power cycled the system.
• Read the reset cause register after boot up to confirm peripheral reset phase.
• Read the pwrmgr reset status register to confirm chip reset.
• Read the com_sel_ctl_* CSR in SYSRST ctrl we programmed earlier - it should have been reset.

Verify the SYSRST ctrl can reset the chip from deep sleep.

• Read the reset cause register in rstmgr to confirm we are in POR reset phase.
• Program one of the com_sel_ctl_* CSRs to choose a set of inputs to be detected as the chip reset signal.
• Program the associated detection timer.
• Program the detection outcome CSR's (com_out_ctl) chip reset bit to 1.
• Program the pwrmgr to put the chip in deep sleep state and allow it to be reset by the chip reset bit.
• Issue a WFI to bring the chip in low power state.
• After the chip has entered low power mode, set the SYSRST ctrl inputs at the chip IOs to the programmed combination for the duration of the detection timer.
• The pwrmgr will power cycle the chip from the deep sleep state once it receives the chip reset input.
• Read the reset cause register after boot up to confirm peripheral reset phase.
• Read the pwrmgr reset status register to confirm chip reset.
• Read the com_sel_ctl_* CSR in SYSRST ctrl we programmed earlier - it should have been reset.

Verify that the ec_rst_l stays asserted on power-on-reset until SW can control it.

• Verify that ec_rst_l stays asserted as the chip is brought out of reset.
• Verify that the pin continues to remain low until SW is alive.
• Have the SW write to pin_allowed|out_ctrl CSRs to control the ec_rst_l value and verify the value at the chip output.
• Optionally, also verify ec_rst_l pulse stretching by setting the ec_rst_ctl register with a suitable pulse width.

Verify that the flash_wp_l stays asserted on power-on-reset until SW can control it.

• Exactly the same as chip_sysrst_ctrl_ec_rst_l, but covers the flash_wp_l pin.

Verify the z3_wakeup signaling.

• Start off with ac_present = 0, lid_open = 0 and pwrb = 0 at the chip inputs.
• Program the ulp_ac|lid|pwrb_debounce_ctl registers to debounce these inputs for an appropriate time.
• Enable the ULP wakeup feature by writing to the ulp_ctl register.
• Read the ulp_wakeup register and verify that no wakeup event is detected, after some amount of delay.
• Glitch the lid_open input at the chip IOs before stabilizing on value 1.
• Read the ulp_wakeup register to verify that the wakeup event is detected this time.
• Verify that the z3_wakeup output at the chip IOs is reflecting the value of 1.

Verify that the ADC correctly detects the voltage level programmed for each channel.

• Program both ADC channels to detect mutually exclusive range of voltages. Setting only one filter CSR is sufficient.
• Program the ADC intr ctrl CSR to detect the selected filter on both channels. Enable the debug cable interrupt at ADC ctrl as well as PLIC.
• Enable the ADC ctrl to run with defaults in normal mode (depending on simulation runtime).
• Verify through assertion checks, the ADC with AST stays powered down periodically in slow scan mode.
• After some time, force the ADC output of AST to be a value within the programmed range for each channel. Glitch it out of range for some time before stabilizing to ensure that debouce logic works.
• Service the debug cable irq. Read the intr status register to verify that the selected filter caused the interrupt to fire. Read the ADC channel value register to verify the correctness of the detected value that was forced in the AST for each channel.

Verify that in deep sleep, ADC ctrl can signal the ADC within the AST to power down.

• Read the reset cause register in rstmgr to confirm we are in POR reset phase.
• Follow the same steps as chip_adc_ctrl_debug_cable_irq, but instead of programming the selected filter to interrupt, program it to wake up the chip from sleep.
• Program the pwrmgr to put the chip in deep sleep state and wake up on debug cable detection.
• Issue a WFI to bring the chip in low power state.
• After some time, force the ADC output of AST to be a value within the programmed filter range. That should cause the pwrmgr to wake up.
• Read the reset cause register to confirm wake up from low power exit phase.
• Read the pwrmgr wake up status register to confirm wake up was due to debug cable detection.
• Read the ADC channel value register to verify the correctness of the detected value that was forced in the AST.
• Repeat for both ADC channels.

Verify the AES operation.

Write a 32-byte key and a 16-byte plain text to the AES registers and trigger the AES computation to start. Wait for the AES operation to complete by polling the status register. Check the digest registers for correctness against the expected digest value.

Verify the AES entropy input used by the internal PRNGs.

• Write the initial key share, IV and data in CSRs (known combinations).
• Configure the entropy_src to generate entropy in LFSR mode.
• Write the PRNG_RESEED bit to reseed the internal state of the PRNG.
• Poll the status idle bit to ensure reseed operation is complete.
• Trigger the AES operation to run and wait for it to complete.
• Check the digest against the expected value.
• Write the KEY_IV_DATA_IN_CLEAR and DATA_OUT_CLEAR trigger bits to 1 and wait for it to complete by polling the status idle bit.
• Read back the data out CSRs - they should all read garbage values.
• Assertion check verifies that the IV are also garbage, i.e. different from the originally written values.

Verify AES idle signaling to clkmgr.

• Write the AES clk hint to 0 within clkmgr to indicate AES clk can be gated and verify that the AES clk hint status within clkmgr reads 0 (AES is disabled).
• Write the AES clk hint to 1 within clkmgr to indicate AES clk can be enabled.
• Initiate an AES operation with a known key, plain text and digest, write AES clk hint to 0 and verify that the AES clk hint status within clkmgr now reads 1 (AES is enabled), before the AES operation is complete.
• After the AES operation is complete verify that the AES clk hint status within clkmgr now reads 0 again (AES is disabled).
• Write the AES clk hint to 1, read and check the AES output for correctness.

Verify the AES sideload mechanism.

• Configure the keymgr to generate an aes key.
• Configure the AES to use the sideloaded key.
• Load the plaintext into the AES.
• Trigger the AES encryption and wait for it to complete.
• Verify that the ciphertext is different from the plaintext.
• Load the ciphertext into the AES.
• Trigger the AES decryption and wait for it to complete.
• Verify that the output is equal to the plain text.
• Clear the key in the keymgr and decrypt the ciphertext again.
• Verify that output is not equal to the plain text.

Verify HMAC operation.

SW test verifies an HMAC operation with a known key, plain text and digest (pick one of the NIST vectors). SW test verifies the digest against the pre-computed value. Verify the HMAC done and FIFO empty interrupts as a part of this test.

Verify the HMAC clk idle signal to clkmgr.

• Write the HMAC clk hint to 0 within clkmgr to indicate HMAC clk can be gated and verify that the HMAC clk hint status within clkmgr reads 0 (HMAC is disabled).
• Write the HMAC clk hint to 1 within clkmgr to indicate HMAC clk can be enabled. Verify that the HMAC clk hint status within clkmgr reads 1 (HMAC is enabled).
• Initiate an HMAC operation with a known key, plain text and digest. Write HMAC clock hint to 0 and verify the HMAC clk hint status within clkmgr reads 1 (HMAC is enabled), before the HMAC operation is complete.
• After the HMAC operation is complete, verify the digest for correctness. Verify that the HMAC clk hint status within clkmgr now reads 0 again (HMAC is disabled).
• This process is repeated for two hmac operations needed to verify the resulting hmac digest.

Verify the SHA3 operation.

SW test verifies SHA3 operation with a known key, plain text and digest (pick one of the NIST vectors). SW validates the reception of kmac done and fifo empty interrupts.

Verify the keymgr interface to KMAC.

• Configure the keymgr to start sending known message data to the KMAC.
• Keymgr should transmit a sideloaded key to the KMAC as well.
• KMAC should finish hashing successfully (not visible to SW) and return digest to keymgr.
• This digest is compared against the known digest value for correctness.
• Verify that the keymgr has received valid output from the KMAC.

X-ref'ed with keymgr test.

Verify the LC interface to KMAC.

• Configure the LC_CTRL to start a token hash using KMAC interface.
• KMAC should finish hashing successfully (not visible to SW) and return digest to LC_CTRL.

X-ref'ed with LC_CTRL test/env.

Verify the ROM interface to KMAC.

• Backdoor initialize ROM memory immediately out of reset.
• ROM will send message to the KMAC containing its memory contents,
• KMAC will hash and return the digest to the ROM.
• ROM will compare received digest against its first 8 logical memory lines for correctness.

X-ref'ed with ROM_CTRL test/env.

Verify the EDN interface to KMAC.

Requires EnMasking parameter to be enabled. SW randomly configures the KMAC in any hashing mode/strength, and enable EDN mode. Randomly enable/disable the entropy_refresh. Randomly configure wait_timer values (zero for disable, non-zero for timer expire).

• Program wait_timer to a small value. Check if EDN timeout error occurs after issuing the hashing op.
• Adjust wait_timer greater than expected EDN latency (with correct prescaler too). Then check if Digest is correct. KMAC should send EDN request after entropy_ready is set. KMAC also should send out another request to EDN when either:
• kmac hash counter hits the configured threshold (assuming it is non-zero)
• Hash count exceeds the threshold. SW verifies that KMAC produces the correct digest value.

TODO: This is pending security review discussion. It is unclear if this feature will be implemented.

X-ref'ed with EDN test/env.

Verify the KMAC idle signaling to clkmgr.

• Write the KMAC clk hint to 0 within clkmgr to indicate KMAC clk can be gated and verify that the KMAC clk hint status within clkmgr reads 0 (KMAC is disabled).
• Write the KMAC clk hint to 1 within clkmgr to indicate KMAC clk can be enabled. Verify that the KMAC clk hint status within clkmgr reads 1 (KMAC is enabled).
• Initiate a KMAC operation with a known key, plain text and digest. Write KMAC clock hint to 0 and verify the KMAC clk hint status within clkmgr reads 1 (KMAC is enabled), before the KMAC operation is complete.
• After the KMAC operation is complete, verify the digest for correctness. Verify that the KMAC clk hint status within clkmgr now reads 0 again (KMAC is disabled).

Verify the RNG req to ast.

• Program the entropy src in normal RNG mode.
• Route the entropy data received from RNG to the FIFO.
• Verify that the FIFO depth is non-zero via SW - indicating the reception of data over the AST RNG interface.
• Verify the correctness of the received data with assertion based connectivity checks.

Verify the transfer of entropy bits to CSRNG.

Verify the entropy valid interrupt. At the CSRNG, validate the reception of entropy req interrupt.

• Disable edn0, edn1, csrng and entropy_src, as these are enabled by the test ROM.
• Enable entropy_src in fips mode routing data to csrng.
• Enable csrng and enable the entropy request interrupt.
• Issue csrng instantiate and reseed commands. Check that for each csrng command, there is a corresponding entropy request interrupt.
• Generate output and ensure the data output is valid, and that csrng is not reporting any errors.
• Issue instantiate and reseed commands from edn0 and edn1. Check that for each command, there is a corresponding entropy request interrupt.

Verify the fuse input entropy_src.

• Initialize the OTP with the fuse that controls whether the SW can read the entropy src enabled.
• Read the OTP and verify that the fuse is enabled.
• Read the entropy_data_fifo via SW and verify that it reads valid values.
• Reset the chip, but this time, initialize the OTP with with the fuse disabled.
• Read the OTP and verify that fuse is disabled.
• Read the internal state via SW and verify that the entropy valid bit is zero.

Verify our ability to run known-answer tests in SW.

• Configure the device in firmware-bypass mode.
• Feed NIST test-defined entropy sequences into the conditioner
• Read the entropy_data_fifo via SW; verify that it reads the expected values.

Verify incoming command interface from EDN.

• Have each EDN instance issue an instantiate, reseed and generate command to CSRNG.
• On each command done, verify the reception of edn cmd req done interrupt.
• Run OTBN randomness test to test the output from EDN0 and EDN1.
• Check the data returned to EDN via connectivity assertion checks.

Verify the fuse input to CSRNG.

• Initialize the OTP with the fuse that control whether the SW can read the CSRNG state enabled.
• Issue an instantiate command to request entropy.
• Verify that SW can read the internal state values.
• Reset the chip and repeat the steps above, but this time, initialized the OTP with fuse disabled.
• Verify that the SW reads back all zeros when reading the internal state values.

Verify the effect of LC HW debug enable on CSRNG.

lc_hw_debug_en is used to diversify the csrng seed.

• Configure entropy_src into bypassing the conditioner and directly inject known entropy.
• Instantiate CSRNG with the known entropy while in TEST state (hw_debug_en = 1).
• Retrieve entropy from csrng and save it in flash and reset the system.
• Run the process again and ensure the exact same result can be reproduced (similar to KAT).
• Advance the device to PROD or DEV state.
• Again configure entropy_src to bypass the conditioner and use direct injection.
• Instantiate CSRNG with the same fixed seed and fetch entropy again while in the NEW state.
• The newly fetched entropy and the old entropy stored in flash should not match.

Verify our ability to run known-answer tests in SW.

• Configure the software instance with the expected seed (as per the NIST-specified test for CTR_DRBG operation). Compare the DRBG internal K and V state against the test vector expected values.
• Perform generate operations as required by the test vector.
• Compare the results to test expectations.

Verify the entropy requests from all peripherals.

Verify that there are no misconnects between each peripheral requesting entropy. TODO: system level scenario: have all entropy sources request entropy in the same test one after to show boot to post boot load, cycling all entropy blocks off and on again. Ensure there are no deadlocks and everything works as expected. X'ref'ed with each IP test that requsts entropy from EDN.

Verify the keymgr advances to all states and generate identity / SW output.

• In the SW test, write fixed value to OTP for root_key and write creator and owner seeds in flash. And then roboot the chip.

• In the SV sequence, backdoor read Device ID and ROM digest through CSRs.

• For HardwareRevisionSecret, use the constant values in design.

• Configure the keymgr and advance to CreatorRootKey and OwnerIntermediateKey.

• Check keymgr internal keys after advance operations.

• Generate identity / SW output for the Sealing CDI.

  • No need to test the Attestation CDI in chip-level as the only difference is to use another set of CSR values, and the rest of inputs are the same as the Sealing CDI.

• KMAC should finish hashing successfully (not visible to SW) and return digest to keymgr.

• Read keymgr CSRs SW_SHARE* and verify the return values.

• Advance to Disabled and verify keymgr enters the state successfully.

• For each operation, wait for the interrupt op_done to be triggered and check CSR op_status is DONE_SUCCESS.

• Note: there are 3 ways of calculating the expected digest for comparison. Any of them is acceptable.

  • Use SW to calculate that, and it will also exercise the Ibex.
  • SW sends all the keys through CSRs to KMAC to generate the degist data.
  • DV calls C functions to generate and backdoor load to a specific memory location for SW. (Adpot this approach.)

X-ref'ed with kmac test.

Verify the keymgr sideload interface to KMAC.

• Configure the keymgr and advance to the OwnerIntKey state.
• Request keymgr to generate hw key for KMAC sideload key slot.
• Request KMAC operation with sideload key configuration.
• Verify the digest for correctness (should match the DV-side result).
• Clear keymer's KMAC sideload key slot.
• Request KMAC operation with sideload key configuration.
• Verify the digest value has changed.
• Request keymgr to derive the same key for the KMAC sideload key slot.
• Request KMAC operation with sideload key configuration.
• Verify the digest for correctness (should match the DV-side result again).

X-ref'ed with chip_kmac_app_keymgr test.

Verify the keymgr sideload interface to AES.

Same as chip_keymgr_sideload_kmac, except, sideload to AES.

Verify the keymgr sideload interface to OTBN.

Load OTBN binary image, the rest is similar to chip_keymgr_sideload_kmac, except sideloading to otbn.

Verify an OTBN operation.

• SW test directs the OTBN engine to perform an ECDSA operation.
• SW validates the reception of the otbn done interrupt once the operation is complete.
• SW verifies the correctness of the result with the expected value which is pre-computed using a reference model.

Verify OTBN can fetch RND numbers from the entropy src.

• SW initializes the entropy subsystem to generate randomness.
• SW loads an OTBN app that executes instructions to read the RND bits.
• The OTBN app ensures that the values when read consequtively do not match, and its not all 0s or all 1s, as a basic measure to ensure that the entropy subsystem is returning some data.

Verify OTBN can fetch URND numbers from the entropy src.

• Similar to chip_otbn_rnd_entropy, but verifies the URND bits.

Verify the OTBN idle signal to clkmgr.

• Write the OTBN clk hint to 0 within clkmgr to indicate OTBN clk can be gated and verify that the OTBN clk hint status within clkmgr reads 0 (OTBN is disabled).
• Write the OTBN clk hint to 1 within clkmgr to indicate OTBN clk can be enabled. Verify that the OTBN clk hint status within clkmgr reads 1 (OTBN is enabled).
• Start an OTBN operation, write the OTBN clk hint to 0 within clkmgr and verify that the OTBN clk hint status within clkmgr reads 1 (OTBN is enabled) before the OTBN operation is complete.
• After the OTBN operation is complete, verify that the OTBN clk hint status within clkmgr now reads 0 again (OTBN is disabled).
• Write the OTBN clk hint to 1, read and check the OTBN output for correctness.

Verify the OTBN can receive keys from the OTP to scramble the OTBN imem and dmem.

• Initialize the entropy_src subsystem to enable OTP_CTRL fetch random data (already done by the test_rom startup code).
• Extract random address offsets from RV_CORE_IBEX_RND_DATA.
• Wait for OTBN to be idle.
• Write random address offsets in OTBN imem and dmem.
• Read back the written address offsets and compare against expected values. All values must match, no integrity errors must be triggered.
• Have OTBN fetch new keys and nonces from the OTP_CTRL.
• Wait for OTBN to be idle.
• Read back the written address offsets. Most reads should trigger integrity errors. It is possible that after re-scrambling the integrity bits are still valid. But this is expected to happen rarely. If the number of observed integrity errors is below a chosen threshold, the test fails.
• Verify the validity of EDN's output to OTP_CTRL via assertions (unique, non-zero data).

Verify that the CPU can access the rom contents.

• Verify that the CPU can fetch instructions from the ROM.

Verify that the ROM ctrl performs the integrity check of the ROM on power up.

• In non-PROD LC state, the computed digest does not have to match the top 8 words in the ROM. Verify that we can successfully power up the chip in this case.
• In PROD LC state, verify that the pwrmgr does not fully power up if the computed digest does not match the top 8 words of the ROM.

Verify scrambled memory accesses to both main and retention SRAMs.

• Initialize the entropy_src subsystem to enable OTP_CTRL fetch random data (already done by the test_rom startup code).
• Trigger both SRAMs to fetch a new key and nonce from the OTP_CTRL
• Drive the CPU to perform random accesses to both RAMs and verify these operations complete successfully by using the backdoor interface
• Fetch a new key from the OTP_CTRL and ensure that the previous contents cannot be read anymore.
• Verify the validity of EDN's output to OTP_CTRL via assertions (unique, non-zero data).

Verify that the data within the retention SRAM survives low power entry-exit.

Ensure that the data within the retention SRAM survives ALL low power entry-exit variations.

Verify that CPU can fetch instructions from SRAM if enabled.

• Create the following combinations of 8 scenarios:

  • The fetch enable bit in the HW_CFG partition of OTP controller set and not set.
  • A life cycle state that enables (TEST_UNLOCKED, DEV or RMA) and disables (PROD) hardware debug.
  • The execution CSR programmed to be enabled and disabled.

• For both, main and the retention SRAM in each of these 8 scenarios:

  • Load instruction data into the SRAMs.
  • If the instruction execution is enabled, verify that the CPU can fetch and execute the instruction from the SRAM correctly.
  • If the instruction execution is not enabled, verify that the SRAM throws an error response via an exception handler.

The following table indicates in which of these scenarios should the instruction execution be enabled, for both, main and the retention SRAM instances.

For the retention SRAM, instruction fetch is completely disabled via design parameter.

Verify the LC escalation path to the SRAMs.

• Configure the LC_CTRL to trigger an escalation request to the SRAMs.
• Verify that the SRAMs stop accepting and responding to new memory requests.
• Reset the system to exit the terminal escalation state.
• Re-initialize the SRAMs and verify that they can now respond correctly to any further memory requests.

X-ref with chip_sw_all_escalation_resets and chip_sw_data_integrity.

Verify the OTP ctrl initialization on chip power up.

Verify that the chip powers up correctly on POR.

• The pwrmgr initiates a handshake with OTP ctrl and later, with LC ctrl in subsequent FSM states. Ensure that the whole power up sequence does not hang.
• Verify with connectivity assertion checks, the handshake signals are connected.
• Ensure that no interrupts or alerts are triggered.

Verify the proliferation of keys to security peripherals.

• Verify the correctness of keys provided to SRAM ctrl (main & ret), flash ctrl, keymgr, (note that keymgr does not have handshake), OTBN and the CPU instruction cache.
• Ensure that the test requests a new key and verifies the previously written data to an address now returns a garbage value.

X-ref'ed with the following IP tests that consume these signals:

• chip_sw_sram_scrambled_access
• chip_sw_flash_scramble
• chip_sw_keymgr_key_derivation
• chip_sw_otbn_mem_scramble

Verify the entropy interface from OTP ctrl to EDN.

This is X-ref'ed with the chip_otp_ctrl_keys test, which needs to handshake with the EDN to receive some entropy bits before the keys for SRAM ctrl and OTBN are computed.

Verify the program request from lc_ctrl.

• Verify that upon an LC state transition request, LC ctrl signals the OTP ctrl with a program request.
• Verify that the OTP ctrl generates the LC data output correctly and is sent to the LC ctrl before it is reset.
• Verify that the lc_check_byp_en_i from LC ctrl is set.
• Ensure that the whole operation does not raise any interrupts or alerts or errors.
• After reset, verify that the LC state transition completed successfully by reading the LC state and LC count CSRs.

Verify the otp program error.

• Initiate an illegal program request from LC ctrl to OTP ctrl by forcing the lc_otp_program_i.
• Verify that the LC ctrl triggers an alert when the OTP ctrl responds back with a program error.

Verify the correctness of otp_hw_cfg bus in all peripherals that receive it.

Preload the OTP ctrl's hw_cfg partition with random data and verify that all consumers of the hardware configuration bits are receiving the correct values.

Xref'ed with corresponding IP tests that receive these bits.

Verify the broadcast signals from LC ctrl.

• lc_creator_seed_sw_rw_en_i: verify that the SECRET2 partition is locked.
• lc_seed_hw_rd_en_i: verify that the keymgr outputs a default value when enabled.
• lc_dft_en_i: verify that the test interface within OTP ctrl is accessible.
• lc_check_byp_en_i: verify that the background check during LC ctrl state programming passes when enabled.

Note that lc_escalate_en_i is verified via a connectivity test.

The lc_seed_hw_rd_en_i signal can be tested by attempting a keymgr advance operation into the CreatorRootKey state, which should fail since the root key will be tied off to all-zero when the SECRET2 partition is not locked in OTP.

X-ref'ed with chip_sw_lc_ctrl_broadcast test, which verifies the connectivity of the LC decoded outputs to other IPs.

Verify that the SW can read / write the prim tlul interface.

• The prim tlul interface is a open source placeholder for the closed source CSRs that will be implemented in a translation 'shim'.
• Verify that when lc_dft_en_i is On, this region can be read / written to by the SW. When lc_dft_en_i is Off, accessing this region will result in a TLUL error.

Verify that flash initialization routine works correctly.

• Initialize the flash ctrl by writing 1 to the INIT register.

• Poll the status register for the initialization to complete.

• Verify that during the init process, the flash ctrl requested keys from OTP. Verify with different sets of key values programmed in OTP.

• Verify the flash ctrl can read seeds when lc_seed_hw_rd_en is set, otherwise all 1s.

• Verify that the flash ctrl sent the creator and owner seeds to keymgr. Verify with different seed values.

• This test needs to execute as a boot rom image.

Verify that the flash memory contents can be read by the CPU.

Nothing extra to do here - most SW based tests fetch code from flash.

Verify the SW can initiate flash operations via the controller.

Verify that the CPU can read / program and erase the flash mem. Pick an operation on all data and info partitions. Erase both, bank and page. SW validates the reception of prog empty, prog level, rd full, rd level and op done interrupts.

Verify the flash memory contents can be accessed after in RMA unlock.

• Provision an RMA_UNLOCK token in OTP.

• Repeat the following a few times:

  • Randomize the otp contents for device id, manufacturing state and RMA_UNLOCK token..
  • Reset the chip.
  • Ensure chip revision, device id and manufacturing state can be read through the LC JTAG.

• Enable RMA mode, and verify that the SW can access the flash after RMA completion.

• RMA entry should be done through the JTAG interface.

• X-ref'ed with manuf_ft_provision_rma_token_and_personalization from the manufacturing testplan.

Verify flash scrambling via the controller.

• Extends the chip_flash_init test.

• Verify flash scrambling with different key values programmed in OTP.

• Verify read of scrambled contents via both, controller and direct host read.

• Program a new scramble key in OTP and reboot - this time we need to backdoor load the flash with new test image that is re-scrambled with the new key.

• Need to understand the bootstrapping requirements.

Verify flash_idle signaling to pwrmgr.

• Initiate flash program or erase over the controller.
• Program the pwrmgr to go into deep sleep.
• Issue a WFI.
• Ensure that the low power entry does not happen due to the ongoing flash operation.

Verify the creator and owner seeds are read on flash init provided lc_hw_seed_rd_en is set.

X-ref'ed with keymgr test.

Verify the lc_creator_seed_sw_rw_en signal from LC ctrl.

• Transition from TEST_LOCKED to DEV/PROD to ESCALATION/SCRAP state via OTP and verify that this LC signal transitions from 0 to 1 and back to 0. Verify that the SW accessibility of the corresponding partition depending on the signal value.

Verify that the creator seed is wiped by the flash ctrl on RMA entry.

Verify the lc_owner_seed_sw_rw_en signal from LC ctrl.

• Transition from TEST_LOCKED to DEV/PROD to ESCALATION/SCRAP state via OTP and verify that this LC signal transitions from 0 to 1 and back to 0. Verify that the SW accessibility of the corresponding partition depending on the signal value.

Verify the lc_iso_part_sw_rd_en signal from LC ctrl.

• Transition from DEV to PROD to ESCALATION/SCRAP state via OTP and verify that this LC signal transitions from 0 to 1 and back to 0. Verify that the SW accessibility of the corresponding partition depending on the signal value.

Verify the lc_creator_seed_sw_wr_en signal from LC ctrl.

• Transition from TEST_LOCKED to DEV/PROD to ESCALATION/SCRAP state via OTP and verify that this LC signal transitions from 0 to 1 and back to 0. Verify that the SW accessibility of the corresponding partition depending on the signal value.

Verify the lc_seed_hw_rd_en signal from LC ctrl.

• Transition from TEST_LOCKED to DEV/PROD to ESCALATION/SCRAP state via OTP and verify that this LC signal transitions from 0 to 1 and back to 0. Verify that the flash ctrl does (or does not) read the creator and owner partitions to fetch the seeds for the keymgr.

Verify the lc_escalate_en signal from LC ctrl.

• Trigger an LC escalation signal by generating an alert.
• Verify that all flash accesses are disabled when the escalation kicks in.
• Confirm flash accesses are disabled by erroing if the device executes the ISR.
• Use assertion based connectivity check to prove that this signal is connected to the flash ctrl.

X-ref with chip_sw_all_escalation_resets.

Verify that the SW can read / write the prim tlul interface in flash phy.

• The prim tlul interface is a open source placeholder for the closed source CSRs that will be implemented in a translation 'shim'.
• Verify that this region can be read / written to by the SW in any LC state.

Verify flash program and erase operations over the ctrl over a range of clock freqs.

• Enable jitter on the clock while performing erase, write and read operations to the flash.
• This sets the test for closed source where the flash access timing matters.

Verify that the AST generates the 4 clocks when requested by the clkmgr.

Verify the clock frequencies are reasonably accurate. Bring the chip to deep sleep, and verify that upon wakeup reset the clock counters are turned off, measure ctrl regwen is enabled, and errors are not cleared.

Verify the clk and rst inputs to AST (from clkmgr).

Details TBD.

Verify that the AST sys clk jitter control.

X-ref with chip_sw_clkmgr_jitter

Verify the USB clk calibration signaling.

• First place the AST into a mode where usb clock frequency significantly deviates from the ideal.
• Verify the clock is "off" using the clkmgr measurement mechanism.
• Then, turn on the usb sof calibration machinery and wait a few mS.
• Afterwards, measure the usb clock again using the clkmgr measurement controls, at this point the clock should be significantly more accurate.
• Note, while the above is ideal, usbdev chip level testing is not yet ready and this test fakes the usb portion through DV forces.
• Note also the real AST calibration logic is not available, so the sof testing in the open source is effectively short-circuited.

Verify the alerts from AST aggregating into the sensor_ctrl.

X-ref'ed with chip_sensor_ctrl_ast_alerts.

Verify the alerts from AST aggregating into the sensor_ctrl.

Check that AST events can be triggered from sensor_ctrl and that the resulting AST outputs are observed in both sensor_ctrl and the alert_handler.

For the alert handler case, make sure to test each alert configured as either recoverable or fatal.

Verify the io power ok status from AST.

Check that when the IO POK status changes, an interrupt is triggered from sensor_ctrl. After triggering, the IO status can be read from a sensor_ctrl register.

Verify the sensor control is able to wake the device from sleep mode when an alert event is triggered from AST. X-ref'ed chip_sw_pwrmgr_sleep_all_wake_ups.

Verify the NMI interrupt to the CPU and correctness of the cause.

Randomly use these two methods (simultaneously or choose one of them) to trigger the NMI interrupt:

• Trigger the alert_handler escalation pair that maps to NMI.
• Trigger a watchdog bark.

Check rv_core_ibex's NMI interrupt register and clear the interrupt. If the NMI interrupt is triggered by alert_handle and the class_clr_regwen register is not locked, check that alert_handler can clear this NMI escalation stage. Then make sure that the alert_handler won't move forward to the next escalation stage.

Verify the functionality of the random number generation CSRs.

• Enable entropy complex so RND_DATA can get entropy.
• Perform multiple reads from RND_DATA polling RND_STATUS in between to only read valid data. Check different random bits are provided each time and that the random data is never zero or all ones.
• Ensure RND_STATUS indicate invalid data immediately after RND_DATA read.
• Perform repeated reads from RND_DATA without RND_STATUS polling to check read when invalid doesn't block.

Verify the simple address translation functionality.

• Setup address translation for both slots on the the I and D side and check correct translation for I and D accesses.
• Switch address translation to use different regions that overlap for both slots and check translation again. Ensure some test accesses match both regions, where the lowest indexed one takes priority.
• Turn off address translation and confirm regions are no longer being remapped.

Verify scrambled memory accesses to CPU icache.

• Initialize the entropy_src subsystem to enable OTP_CTRL fetch random data (already done by the test_rom startup code).
• Execute the fence instruction to invalidate the icache.
• Verify using probes, that this resulted in a new scrambling key fetched from the OTP ctrl.

Verify the functionality of the ibex fault dump.

• Purposely create an ibex exception during execution through reads to an ummapped address.
• Ensure the rstmgr fault dump correctly captures the related addresses to the exception.

Verify the functionality of the ibex double fault dump.

• Purposely create an ibex double exception during execution, by performing an unmapped read and in the exception handler perform another unmapped read.
• Ensure the rstmgr fault dump correctly captures both dumps correctly and indicates the previous dump is valid.

Run smoke tests developed for each IP.

The smoke tests are developed by the SW team to test each IP is alive, and can be actuated by the DIF. We need to ensure that they work in DV as well.

Run some ROM functional tests with test ROM.

ROM functional tests test ROM drivers and libraries by exercising these components in the flash stage, launched via the test ROM. They primarily are tested on the FPGA, however, we ensure they run in DV as well.

Run some chip-level tests with ROM.

In addition to ROM E2E tests, we select at least one (or a few) tests defined in this file to sign, and run via ROM instead of test ROM. We need to ensure our test infrastructure and ROM can boot and run one (or a few) of the same tests our test ROM can.

Verify the full flash image download with bootstrap signal set.

• SW puts the SPI device in firmware mode
• Load a firmware image (bootstrap) through spi input pin to the spi_device memory.
• SW verifies the integrity of the image upon reception by reading the spi_device memory.
• Ensure the image is executed correctly

Note: This flow will be replaced by using spi_device flash mode. For detail, refer to chip_spi_device_flash_mode

Verify the secure boot flow.

X-ref rom_e2e_smoke. In reality this can be any rom based test, which requires secure boot.

Ensure it is possible to enter scrap state from every legal life cycle state.

• Request transition to SCRAP state using the JTAG interface.

• It should be possible to transition from every legal state using external clock.

• Where it is allowed, transition using internal clocks should also be checked.

• After transition, verify that the device is in SCRAP state through LC read.

• Verify while in SCRAP state:

  • RV JTAG interface is unavailable.
  • Ibex is not executing.
  • RV_DM is unreachable by the stub CPU.

• X-ref'd with manuf_scrap from the manufacturing testplan.

• X-ref'd with chip_lc_test_locked.

• X-ref'd with chip_tap_strap_sampling

Transition from TEST_UNLOCKED to TEST_LOCKED using LC JTAG interface.

• Check in TEST_UNLOCKED RV JTAG interface is available.

• Verify When in TEST_LOCKED state:

  • RV JTAG interface is unavailable.
  • Ibex is not executing.
  • RV_DM is unreachable by the stub CPU.

• X-ref'd with manuf_cp_test_lock from the manufacturing testplan.

• X-ref'd with chip_lc_scrap.

• X-ref'd with chip_tap_strap_sampling

• X-ref'd with chip_sw_lc_walkthrough

• X-ref'd with chip_rv_dm_lc_disabled

Walk through the life cycle stages from RAW state and reseting the chip each time.

• Pre-load OTP image with RAW lc_state.
• Initiate the LC transition to one of the test unlock state.
• Program test_unlock_token, test_exit_token, rma_unlock_token into OTP partitions.
• Move forward to next valid LC states via JTAG interface or SW interface if CPU is enabled. Verify that the features that should indeed be disabled are indeed disabled.

Concurrency test modeling load conditions in idle state

This concurrency test models an average idle scenarios.

The test should be made configurable so that the type of power state and the time spent in a particular power state can be configured via a flag (or similar). This will make it easier to reuse the test for power simulation and characterization later on.

The test should set a GPIO (mapped to the IOA2 pin) to high while the power state of interest is active.

The test should cover the following scenarios:

• Processor polls for nmi interrupt
• Background checks enabled wherever possible
• rstmgr background checks
• alert_handler ping checks
• OTP background checks
• Timers (regular and AON) are active
• Check whether transactional clocks should be enabled or disabled
• Check whether PWM should be active

Concurrency test modeling load conditions in idle state

This concurrency test models average sleep scenarios.

The test should be made configurable so that the type of power state and the time spent in a particular power state can be configured via a flag (or similar). This will make it easier to reuse the test for power simulation and characterization later on.

The test should cover the following scenarios:

• System can be in deep or light sleep
• The system has the following AON / IO activity:
• aon_timer active
• adc_ctrl active in low power mode
• TBD: check whether sysrst_ctrl and pinmux wakeup detectors should be active
• TBD: check whether PWM should be active

This test should leverage the OTTF test framework for supporting concurrency in a FreeRTOS environment. See also the design docs linked in #14095 for more details on how to approach the implementation.

End to end test to ensure rom boot strap can be performed after transitioning from TEST states to PROD staets. .

• Pre-load the device into TEST_UNLOCKED state and ROM_EXEC_EN = 0.
• In the same power cycle, advance device to PROD, PROD_END or DEV through LC JTAG request and set ROM_EXEC_EN in OTP to logically true.
• Reboot the device and perform boot strap of a simple image, (e.g Hello World).
• Ensure boot strap succeeds.

X-ref'ed with manuf_ft_exit_token from manufacturing test plan.

End to end test to ensure boot strap can succeed after injecting scramble seeds.

• Pre-load the device into PROD, PROD_END or DEV state.
• Backdoor load an unscrambled value into flash isolated partition.
• In the test program, populate the scramble seeds (flash / sram).
• In the test program, populate OTP entries to inform ROM to scramble flash upon next boot.
• Reboot the device and perform boot strap of the same test image, ROM should now program the flash image with scramble enabled.
• Upon successful boot strap, ROM jumps to the newly programmed image and de-scrambles the instructions.
• In the test program, check whether the OTP partition containing the scramble seeds is locked. Also check that the unscrambled value progarmmed into flash isolated partition can be correctly read back when the region is set to scramble disable.
• If either of the above checks is incorrect, return error.

X-ref'ed with manuf_ft_sku_individualization from manufacturing test plan.

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 bases on the [TLUL spec]({{< relref "hw/ip/tlul/doc/_index.md#explicit-error-cases" >}})

• TL-UL protocol error cases
  • invalid opcode
  • some mask bits not set when opcode is PutFullData
  • mask does not match the transfer size, e.g. a_address = 0x00, a_size = 0, a_mask = 'b0010
  • mask and address misaligned, e.g. a_address = 0x01, a_mask = 'b0001
  • address and size aren't aligned, e.g. a_address = 0x01, a_size != 0
  • size is greater than 2
• OpenTitan defined error cases
  • access unmapped address, expect d_error = 1 when devmode_i == 1
  • write a CSR with unaligned address, e.g. a_address[1:0] != 0
  • write a CSR less than its width, e.g. when CSR is 2 bytes wide, only write 1 byte
  • write a memory with a_mask != '1 when it doesn't support partial accesses
  • read a WO (write-only) memory
  • write a RO (read-only) memory
  • write with instr_type = True

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.

Enable all hosts to randomly send transactions to any device

Control delays through plusargs to create tests for below types of delay

• Zero delay for sending a/d_valid and a/d_ready
• Large delay from 0 ~ 1000 cycles
• Small delay (0-10 cycles) for a_channel, large delay (0-1000 cycles) for d_channel

• Host randomly drives transactions with mapped and unmapped address
• Ensure DUT returns d_error=1 if address is unmapped and transaction isn't passed down to any device

• Drive any random value on size, mask, opcode in both channels
• Ensure everything just pass through host to device or device to host

• Randomly pick a device, make all hosts to access this device
• If the device isn't accessible for the host, let the host randomly access the other devices

Test all hosts use same ID at the same same

• Combine all sequences and run in parallel
• Add random reset between each iteration

• Inject reset while stress_all is running, after reset is completed, kill the stress seq and then start a new stress seq
• Run a few iteration to ensure reset doesn't break the design

Verify that ROM can boot a ROM_EXT with default infrastructure configurations.

• The valid ROM_EXT should be a test program that returns true, optimizing for speed.
• The test program should be launched via the OTTF.

Verify that ROM can boot a ROM_EXT with default OTP values (all zeroes).

• Create an OTP with all zeros except:
  • OWNER_SW_CFG_ROM_BOOTSTRAP_EN set to 0x739 (true)
  • CREATOR_SW_CFG_ROM_EXEC_EN set to 0xffffffff (enabled)
  • LC_STATE in the TEST_UNLOCKED0 state
  • LIFE_CYCLE count value set to 1
• Ensure that the ROM can boot.

Verify that ROM can properly report errors over UART.

• Attempt to boot without a valid ROM_EXT.
• Verify that we can receive the 28 character long (BFV:xxxxxxxx\r\nLCV:xxxxxxxx\r\n) error output in all life cycle states where Ibex is enabled, i.e. TEST_UNLOCKED*, PROD, PROD_END, DEV, and RMA.
  • BFV should be 0142500d for all life cycle states.
  • See the table below for the expected LCV value.

Verify that ROM redacts errors properly.

• Attempt to boot without a valid ROM_EXT.
• Verify that there is no redaction in TEST_UNLOCKED* and RMA.
• For DEV, PROD, and PROD_END:
  • Verify that BFV value is redacted according to the ROM_ERROR_REPORTING OTP item.

Verify that ROM configures the watchdog properly.

• Attempt to boot with a valid ROM_EXT.
  • ROM_EXT needs to print something and busy loop (bounded) until watchdog resets the chip.
• Verify that the chip does not reset in TEST and RMA.
• For DEV, PROD, and PROD_END:
  • Verify that the chip resets when the WATCHDOG_BITE_THRESHOLD_CYCLES OTP item is 0x00061a80 (2 s).
  • Verify that watchdog is disabled when WATCHDOG_BITE_THRESHOLD_CYCLES is 0.

Verify that ROM asm exception handler resets the chip.

• Power on with the CREATOR_SW_CFG_ROM_EXEC_EN OTP item set to 0.
  • Execution should halt very early in _rom_start_boot.
• Connect the debugger and set a breakpoint at _asm_exception_handler.
  • Note: We need to use a debugger for this test since mtvec points to C handlers when rom_main() starts executing.
• Set pc to 0x10000000 (start of main SRAM) and execute one machine instruction, i.e. stepi.
• Verify that execution stops at _asm_exception_handler since code execution from SRAM is not enabled.
• Continue and verify that the asm exception handler resets the chip by confirming that execution halts at _rom_start_boot.

Verify that ROM C exception handler triggers shutdown.

• Boot a valid fake ROM_EXT that doesn't register any interrupt handlers.
• Trigger an exception in the second stage.
  • Set pc to 0x10000000 (start of main SRAM). This should trigger an exception since code execution from SRAM is not enabled.
• Verify that the chip resets with the correct BFV: 01495202, i.e. instruction access fault in the interrupt module.

Verify that alerts trigger a chip reset when enabled.

• For PROD, PROD_END, DEV, and RMA life cycle states
  • Use an OTP image with an alert enabled.
• Boot a ROM_EXT that triggers this alert by writing to a ALERT_TEST register.
• Verify that ROM_EXT boots and the chip resets after the write to the ALERT_TEST register.

Verify that ROM enters bootstrap when enabled in OTP and requested.

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip reports bootstrap:1 over the UART.
• Verify that the chip responds to READ_STATUS (0x05) with 0x00.

Verify that ROM does not enter bootstrap when enabled in OTP but not requested.

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• Do not apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip outputs the expected BFV: 0142500d over UART.
  • ROM will continously reset the chip and output the same BFV.
• Verify that the chip does not respond to READ_SFDP (0x5a).

Verify that ROM does not enter bootstrap when disabled in OTP but requested.

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolFalse (0x1d4).

• Apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip outputs the expected BFV: 0142500d over UART.
  • ROM will continously reset the chip and output the same BFV and LCV.
• Verify that the chip does not respond to READ_STATUS (0x05).
  • The data on the CIPO line must be 0xff.

Verify that ROM does not enter bootstrap when disabled in OTP and not requested.

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolFalse (0x1d4).

• Do not apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip outputs the expected BFV: 0142500d over UART.
  • ROM will continously reset the chip and output the same BFV and LCV.
• Verify that the chip does not respond to READ_STATUS (0x05).
  • The data on the CIPO line must be 0xff.

Verify that bootstrap handles READ_STATUS correctly.

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip responds to READ_STATUS (0x05) with 0x00.

See rom_e2e_bootstrap_enabled_requested.

Verify that watchdog is disabled upon entering bootstrap.

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739). OWNER_SW_CFG_ROM_WATCHDOG_BITE_THRESHOLD_CYCLES OTP item must be 0x30d40

• For TEST, DEV, PROD, PROD_END, and RMA life cycle states:
  • Apply bootstrap pin strapping.
  • Reset the chip.
  • Verify that the chip responds to READ_SFDP (0x5a) correctly.
  • Release bootstrap pin strapping and wait for 2 seconds.
    • Note: Watchdog is always disabled in TEST and RMA. In other states, the threshold is set to OWNER_SW_CFG_ROM_WATCHDOG_BITE_THRESHOLD_CYCLES.
  • Verify that the chip responds to READ_SFDP (0x5a) correctly.
  • Verify that there was no output from UART.

Verify the JEDEC ID used during bootstrap.

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip responds to READ_JEDEC_ID (0x9f) with
  • 12 repetitions of the continuation code 0x7f,
  • manufacturer ID 0xef,
  • device ID 0x08, and
  • density 0x14.

Verify the SFDP table used during bootstrap.

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip responds to READ_SFDP (0x5a).
• Verify the SFDP header structure. See this document.
• Verify the JEDEC Basic Flash Parameter Table. See this spreadsheet.

Verify that bootstrap handles WRITE_ENABLE (0x06) and WRITE_DISABLE (0x04).

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip responds to READ_STATUS (0x05) with 0x00.
• Send WRITE_ENABLE (0x06) and READ_STATUS (0x05).
• Verify that the chip responds with the WEL bit set, i.e. 0x02.
• Send WRITE_DISABLE (0x04) and READ_STATUS (0x05).
• Verify that the chip responds with 0x00.

Verify that bootstrap phase 1 ignores RESET (0x99).

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping.
• Reset the chip.
• Send RESET (0x99).
• Verify that the chip does not output anything over UART for at least 1 s.

Verify that bootstrap phase 1 ignores PAGE_PROGRAM (0x02).

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping.
• Reset the chip.
• Write 0x4552544f_00000000 (ASCII "\0\0\0\0OTRE") at byte offset 0x80330.
  • Note: Writes must start at a flash-word-aligned address and we must write to the second slot since ROM returns the last error.
• Reset the chip.
• Verify that the chip outputs the expected BFV: 0142500d over UART (`kErrorBootPolicyBadIdentifier').
  • If the write succeeds, which shouldn't happen, ROM outputs 0242500d (kErrorBootPolicyBadLength).
  • ROM will continously reset the chip and output the same BFV and LCV.

Verify that bootstrap phase 1 handles erase commands correctly.

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• For erase in {SECTOR_ERASE (0x20), CHIP_ERASE (0xc7)}:
  • Apply bootstrap pin strapping and reset the chip.
  • Send erase.
  • Write 0x4552544f_00000000 (ASCII "\0\0\0\0OTRE") at byte offset 0x80330.
    • Note: Writes must start at a flash-word-aligned address and we must write to the second slot since ROM returns the last error.
  • Release pins and reset.
  • Verify that the chip outputs the expected BFV: 0242500d over UART (kErrorBootPolicyBadLength).
    • ROM will continously reset the chip and output the same BFV and LCV.
  • Apply bootstrap pin strapping and reset the chip.
  • Send erase.
  • Release pins and reset.
  • Verify that the chip outputs the expected BFV: 0142500d over UART (kErrorBootPolicyBadIdentifier).
    • ROM will continously reset the chip and output the same BFV and LCV.

Verify that phase 1 of bootstrap ignores READ (0x03).

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping and reset the chip.
• Send CHIP_ERASE (0xc7).
• Write 0x4552544f_00000000 (ASCII "\0\0\0\0OTRE") at byte offset 0x80330.
  • Note: Writes must start at a flash-word-aligned address and we must write to the second slot since ROM returns the last error.
• Reset the chip.
• Verify that the chip outputs the expected BFV: 0242500d over UART (kErrorBootPolicyBadLength).
  • ROM will continously reset the chip and output the same BFV and LCV.
• Apply bootstrap pin strapping and reset the chip.
• Verify that the chip responds to READ_STATUS (0x05) with 0x00.
• Send READ (0x03) followed by the 3-byte address 0x80330.
  • This is the start address of the write operation performed above.
• Verify that the data on the CIPO line does not match 0x4552544f_00000000.

Verify that bootstrap phase 2 handles RESET (0x99) correctly.

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• For erase in {SECTOR_ERASE (0x20), CHIP_ERASE (0xc7)}:
  • Apply bootstrap pin strapping and reset the chip.
  • Send erase transition to phase 2.
• Release pins and send RESET (0x99).
• Verify that the chip outputs the expected BFV: 0142500d over UART (kErrorBootPolicyBadIdentifier).
  • ROM will continously reset the chip and output the same BFV and LCV.
• Verify that the chip does not respond to READ_SFDP (0x5a).

Verify that bootstrap phase 2 handles PAGE_PROGRAM (0x02) correctly.

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping and reset the chip.
• Send CHIP_ERASE (0xc7).
• Write 0x4552544f_00000000 (ASCII "\0\0\0\0OTRE") at byte offset 0x80330.
  • Note: Writes must start at a flash-word-aligned address and we must write to the second slot since ROM returns the last error.
• Release pins and reset.
• Verify that the chip outputs the expected BFV: 0242500d over UART (kErrorBootPolicyBadLength).
  • ROM will continously reset the chip and output the same BFV and LCV.

Verify that bootstrap phase 2 handles erase commands correctly.

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• For erase in {SECTOR_ERASE (0x20), CHIP_ERASE (0xc7)}:
  • Apply bootstrap pin strapping and reset the chip.
  • Send erase.
    • For SECTOR_ERASE (0x20) use the lowest page-aligned address, i.e. 0x80000.
  • Write 0x4552544f_00000000 (ASCII "\0\0\0\0OTRE") at byte offset 0x80330.
    • Note: Writes must start at a flash-word-aligned address and we must write to the second slot since ROM returns the last error.
  • Send erase.
  • Release pins and reset.
  • Verify that the chip outputs the expected BFV: 0142500d over UART (rom_e2e_bootstrap_phase2_page_program).
    • ROM will continously reset the chip and output the same BFV and LCV.

Verify that phase 2 of bootstrap ignores READ (0x03).

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping and reset the chip.
• Send CHIP_ERASE (0xc7).
• Write 0x4552544f_00000000 (ASCII "\0\0\0\0OTRE") at byte offset 0x80330.
  • Note: Writes must start at a flash-word-aligned address and we must write to the second slot since ROM returns the last error.
• READ (0x03) 8 bytes starting at 0x080330.
  • This is the address of the identifier that was written earlier.
• Verify that the response is not equal to 0x4552544f_00000000.
• Release pins and reset.
• Verify that the chip outputs the expected BFV: 0242500d over UART (kErrorBootPolicyBadLength).
  • ROM will continously reset the chip and output the same BFV and LCV.

Verify that invalid addresses trigger shutdown.

OWNER_SW_CFG_ROM_BOOTSTRAP_EN OTP item must be kHardenedBoolTrue (0x739).

• For command in {SECTOR_ERASE (0xc7) and PAGE_PROGRAM (0x02)}
  • Apply bootstrap pin strapping and reset the chip.
  • Send CHIP_ERASE command to transition to bootstrap phase 2.
  • Send command with an invalid 3-byte address, e.g. 0xffffff.
  • Verify that the chip outputs the expected BFV over UART.
    • For SECTOR_ERASE: BFV:01425303 (kErrorBootstrapEraseAddress) followed by BFV:0142500d (kErrorBootPolicyBadIdentifier)
    • For PAGE_PROGRAM: BFV:02425303 (kErrorBootstrapProgramAddress) followed by BFV:0142500d (kErrorBootPolicyBadIdentifier)

Verify that ROM triggers shutdown when there is no valid ROM_EXT.

• Reset the chip.
• Verify that the chip outputs the expected BFV: 0142500d over UART.
  • ROM will continously reset the chip and output the same BFV and LCV.
• Repeat for all life cycle states: TEST, DEV, PROD, PROD_END, and RMA.

Verify that ROM chooses the slot with the greater security version.

• Apply bootstrap pin strapping and reset the chip.
• Write the ROM_EXT images to the chip.
• Verify that ROM chooses the slot with the greater security version.
• Repeat for all life cycle states: TEST, DEV, PROD, PROD_END, and RMA.

Verify that ROM performs some basic checks on manifest fields.

CREATOR_SW_CFG_MIN_SEC_VER_ROM_EXT OTP item should be 1, and CREATOR_SW_CFG_DEFAULT_BOOT_DATA_IN_PROD should be kHardenedBoolTrue for PROD and PROD_END for the sake of simplicity.

• For slot in {slot_a, slot_b}
  • Write the image to slot.
    • The other slot remains empty.
  • Verify that the chip outputs the expected BFV over UART.
  • Repeat for all life cycle states: TEST, DEV, PROD, PROD_END, and RMA.

Verify that ROM chooses the slot with the valid signature.

• Apply bootstrap pin strapping and reset the chip.
• Write the ROM_EXT images to the chip -- same security_version.
• Verify that ROM chooses the slot with the valid signature, otherwise triggers a shutdown.
• Repeat for all life cycle states: TEST, DEV, PROD, PROD_END, and RMA.

Verify that ROM rejects rollbacks.

CREATOR_SW_CFG_MIN_SEC_VER_ROM_EXT OTP item should be 1, and CREATOR_SW_CFG_DEFAULT_BOOT_DATA_IN_PROD should be kHardenedBoolTrue for PROD and PROD_END for the sake of simplicity.

• Apply bootstrap pin strapping and reset the chip.
• Write the ROM_EXT images to the chip -- valid signatures.
• Verify that ROM chooses the slot with acceptable & newer seurity version, otherwise triggers a shutdown.
• Repeat for all life cycle states: TEST, DEV, PROD, PROD_END, and RMA.

Verify that ROM can use the default boot data when configured to do so.

• Apply bootstrap pin strapping and reset the chip.
• Write the ROM_EXT images to the chip -- valid signature, security version = 2.
• Verify that ROM boots the slot when boot data is available.
• Repeat for all life cycle states: TEST, DEV, PROD, PROD_END, and RMA.

Verify that ROM performs signature verification in all life cycle states.

• Prepare a ROM_EXT image with a valid signature generated using an authorized key.
• Flip a bit/make all zeros/make all ones at random.
  • Log so that test can be reproduced.
• Apply bootstrap pin strapping and reset the chip.
• Load the image.
• Verify that boot fails with the expected BFV: kErrorSigverifyBadEncodedMessage.
• Repeat the steps above for TEST, DEV, PROD, PROD_END, and RMA.

See rom_e2e_boot_policy_valid.

Verify that ROM only uses authorized keys for signature verification.

• Prepare a ROM_EXT image with a valid signature generated using an unauthorized key.
• Attempt to boot.
• Verify that boot fails with BFV:kErrorSigverifyBadKey.

Verify that ROM only uses authorized keys that are not invalidated.

• For each key entry in CREATOR_SW_CFG_KEY_IS_VALID,
  • Invalidate the key by setting the entry to a value other than kHardenedBoolTrue.
  • Prepare a ROM_EXT image with a valid signature generated using the invalidated key.
  • Verify that boot fails with BFV:kErrorSigverifyBadKey

Verify that ROM only uses appropriate key types for each life cycle state.

• For each life cycle state and key type,
  • Prepare a ROM_EXT image with a valid signature generated using a key of that type.
  • Verify that boot fails with BFV:kErrorSigverifyBadKey or succeeds depending on the life cycle state and key type. See the table below.

Verify that ROM can verify signatures using both implementations of mod_exp.

Note: The chip can be in any life cycle state except TEST since we use the software implementation without reading from the OTP in TEST.

• Prepare a ROM_EXT image with a valid signature generated using an authorized key.
• Apply bootstrap pin strapping and reset the chip and load the image.
• Verify that boot succeeeds. Repeat with the following values:

Verify that ROM enforces usage constraints.

• Generate an otherwise valid ROM_EXT image for the following cases:
  • No constraints specified
  • Constrained to a specific device ID
    • Device ID matches
    • Device ID doesn't match
  • Constrained to a family of devices
    • Device ID matches
    • Device ID doesn't match
  • Constrained to TEST, DEV, PROD, PROD_END, RMA
    • Life cycle state matches
    • Life cycle state doesn't match
  • Constrained to a creator manufacturing state
    • CREATOR_SW_CFG_MANUF_STATE matches
    • CREATOR_SW_CFG_MANUF_STATE doesn't match
  • Constrained to an owner manufacturing state
    • OWNER_SW_CFG_MANUF_STATE matches
    • OWNER_SW_CFG_MANUF_STATE doesn't match
  • All constraints specified
  • Corrupt usage constraints data, e.g. wrong unselected word value.

Verify that all address translation configurations work.

• Bootstrap the chip with a valid second stage image. See the table below.
• Verify that the chip behaves as expected.

Verify that ROM can be debugged in appropriate life cycle states.

CREATOR_SW_CFG_ROM_EXEC_EN should be set to 0.

• Verify that ROM cannot be debugged in PROD and PROD_END.

Verify that ROM_EXT can be upgraded.

CREATOR_SW_CFG_MIN_SEC_VER_ROM_EXT OTP item should be 0, and CREATOR_SW_CFG_DEFAULT_BOOT_DATA_IN_PROD should be kHardenedBoolTrue for PROD and PROD_END for the sake of simplicity.

• Load a ROM_EXT image that will
  • print the current minimum required security version,
    • The initial value of the minimum required security version should be 0.
  • increment it to 1, and
  • reset the chip.
• Verify that the minium required security version is incremented using UART output.
• Load a ROM_EXT with securiy version = 0.
• Verify that ROM fails to boot with BFV:kErrorBootPolicyRollback.

Verify that an interrupted upgrade does not brick the chip.

CREATOR_SW_CFG_MIN_SEC_VER_ROM_EXT OTP item should be 0, and CREATOR_SW_CFG_DEFAULT_BOOT_DATA_IN_PROD should be kHardenedBoolTrue for PROD and PROD_END for the sake of simplicity.

• Load a ROM_EXT image that will
  • print the current minimum required security version,
    • The initial value of the minimum required security version should be 0.
  • increment the minimum required security version, and
  • reset the chip while flash is being accessed.
• Verify that the chip can boot after first attempt.
• Verify that ROM_EXT can detect the interruption and increment the minimum required security version.

Verify that asm interrupt handler resets the chip.

CREATOR_SW_CFG_ROM_EXEC_EN should be set to 0 and the chip should in a life cycle state where debugging is enabled, i.e. TEST, DEV, or RMA.

• Connect a debugger.
• Set a breakpoint on the asm handler.
• Trigger an exception, e.g. by setting PC to an address (end of ROM) that will trigger an instruction access fault.
• Verify that execution breaks at the asm handler.

Verify that watchdog is initialized in rom_start.S.

CREATOR_SW_CFG_ROM_EXEC_EN should be set to 0 and the chip should in a life cycle state where debugging is enabled, i.e. TEST, DEV, or RMA.

• Connect a debugger.
• Set breakpoints on right after watchdog is initialized in rom_start.S and the asm handler.
• Wait until execution breaks at the first breakpoint, wait ~1s before continuing.
• Verify that watchdog expires and execution breaks at the asm handler.

Verify that rom_start.S configures the ROM C interrupt handler and it triggers shutdown.

Using a ROM_EXT image (preferred)

See #14274.

Using a debugger

CREATOR_SW_CFG_ROM_EXEC_EN should be set to 0 and the chip should in a life cycle state where debugging is enabled, i.e. TEST, DEV, or RMA.

• Connect a debugger.
• Set a breakpoint on rom_main() and the ROM C handler rom_interrupt_handler().
• Continue until rom_main().
• Trigger an exception, e.g. by setting PC to an address (start of flash) that will trigger an instruction access fault.
• Verify that execution breaks at the C interrupt handler.
• Verify that chip resets with BFV:kErrorInterrupt.

Verify that ROM initializes peripherals properly.

Note: While the following can be checked at ROM_EXT stage, using a debugger in FPGA-based tests would avoid depending on rom.c. Doing so would give us more information and help us narrow down possible issues if we end up having a problem in ROM. For DV, we don't have to use the JTAG interface: we can wait until Ibex accesses rom_main() and backdoor check specific values.

This test should be run in all life cycle states where the processor is allowed to execute instructions (TEST_UNLOCKED*, DEV, PROD*, RMA).

Also, we may want to break this into multiple tests.

• Verify that the following peripherals are initialized properly:
  • AST
    • CREATOR_SW_CFG_AST_INIT_EN: kMultiBitBool4True enables, kMultiBitBool4False disables. Both configurations should be tested.
    • If CREATOR_SW_CFG_AST_INIT_EN is set to kMultiBitBool4True, check that the AST_INIT_DONE signal is correctly set to 1 in sensor_ctrl once the AST initialization is complete.
  • Clock jitter
    • CREATOR_SW_CFG_JITTER_EN: kMultiBitBool4False disables, all other values enables. CREATOR_SW_CFG_AST_INIT_EN must also be kMultiBitBool4True to enable.
  • Entropy complex
    • Entryop_src, csrng, and edn must be configured at boot mode.
  • ePMP
  • Interrupts should be disabled
    • Trigger a test interrupt and verify that nothing happens.
  • SRAM
    • Must be scrambled with a new key. Can test using register values and functionality.

Verify that ROM initializes the retention SRAM when needed.

CREATOR_SW_CFG_RET_RAM_RESET_MASK should be 1 << 2 so that ROM initializes the retention SRAM after a SW reset request.

• Verify that reset_reasons reports POR.
• Write a known pattern into all sections of retention SRAM.
• Request a SW reset.
• Verify that reset_reasons reports a SW request.
• Verify that all previously written sections are different.

Verify that the retention SRAM is preserved across resets.

• Verify that reset_reasons reports POR.
• Write a known pattern into all sections of retention SRAM.
• Perform a low power entry & exit.
• Verify that reset_reasons reports a low power exit.
• Verify that all previously written sections are intact.
• Request a SW reset.
• Verify that reset_reasons reports a SW request.
• Verify that all previously written sections are intact.

Verify that ROM initializes various peripherals properly.

• Pinmux: UART pins, SW straps if OWNER_SW_CFG_ROM_BOOTSTRAP_EN == kHardenedBoolTrue
• UART
• Bits 0-5 of the cpuctrl CSR: CREATOR_SW_CFG_CPUCTRL

Verify that ROM correctly configures the ePMP region for debug ROM.

• ePMP Debug ROM region should be enabled in TEST, DEV, and RMA, anddisabled in PROD and PROD_END.

Verify that ROM reconfigures the watchdog timer correctly.

• Should be disabled in TEST and RMA.
• In DEV, PROD, and PROD_END, the threshold should be OWNER_SW_CFG_ROM_WATCHDOG_BITE_THRESHOLD_CYCLES if greater than or equal to kWatchdogMinThreshold, disabled otherwise.

Verify that ROM configures the alert handler correctly.

• Disabled in TEST.
• Read from OTP in DEV, PROD, PROD_END, and RMA. Checksum of config registers must match the OTP value.

Verify that ROM initializes the flash_ctrl correctly.

• Verify that
  • CREATOR_SW_CFG_FLASH_DATA_DEFAULT_CFG controls the default scrambling, ecc, and he settings for the data partitions.
  • CREATOR_SW_CFG_FLASH_INFO_BOOT_DATA_CFG controls the scrambling, ecc, and he settings for the boot partitions kFlashCtrlInfoPageBootData0 and kFlashCtrlInfoPageBootData1.
• Verify that flash_ctrl is initialized.

Verify that ROM initializes the keymgr correctly.

• Verify that keymgr is at the "reset" state.
• Verify that
  • attestation sw binding equals
    • the digest of the ROM_EXT if OWNER_SW_CFG_ROM_KEYMGR_ROM_EXT_MEAS_EN is kHardenedBoolTrue, and
    • the binding_value field of the manifest, otherwise,
  • sealing sw binding equals the binding_value field of the manifest, and
  • max creator key version equals the max_key_version field of the manifest,

Verify that ROM initializes the data structures in the .static_critical section properly.

• Verify that boot_measurements holds the digest of the next stage.
  • Don't specify any usage constraints to be able to compute the actual hash in the second stage.
• Verify that sec_mmio_ctx is valid using sec_mmio_check_values() and sec_mmio_check_counters().
• Verify that a failed sec_mmio check triggers an illegal instruction exception.

Determine which functests can be executed using ROM.

Functests test ROM components (e.g., drivers, libraries, etc.) work as intended on-chip. However, unlike when these components are embedded in the ROM, functests are linked with the OTTF, and run out of flash. Additionally, unlike the ROM E2E tests, functests are booted by the test ROM.

Determine which functests can be executed using ROM to understand which tests can be reused on the silicon.

Verify rstmgr's resets_o is connected to aon_timer's reset port.

Verify rstmgr's resets_o is connected to aon_timer's aon-reset port.

Verify the clock connectivity between AST and clock manager.

Verify the connectivity of power-related signals between AST and power manager.

Verify the reset connectivity between AST and reset manager.

Verify pads that are directly shorted to pads

Verify AST -> pinmux connectivity

Verify pad inputs that are connected to AST

Verify clock connectivity between AST and other blocks in the system, excluding clkmgr connections.

Verify reset connectivity between AST and other blocks in the system, excluding rstmgr connections.

Verify the connectivity of power-related signals between AST and other blocks in the system, excluding power manager.

Verify ast model's dual port configuration bits are connected to the dual port RAMs in the following blocks:

• spi_device
• usbdev

Verify ast model's single port configuration bits are connected to the single port RAMs in the following blocks:

• otbn_imem
• otbn_dmem
• rv_core_ibex_tag0
• rv_core_ibex_tag1
• rv_core_ibex_data0
• rv_core_ibex_data1
• sram_main
• sram_retention
• rom

Verify the connectivity of scanmode to the following IPs:

• clkmgr
• flash_ctrl
• lc_ctrl
• otp_ctrl
• padring
• pinmux
• rstmgr
• rv_core_ibex
• rv_dm
• spi_device
• xbar_main
• xbar_peri

Verify the connectivity of vendor_test IOs between otp_ctrl and lc_ctrl.

Verify clkmgr's cg_en_o.io_peri is connected to alert_handler's lpg_cg_en[7].

Verify clkmgr's cg_en_o.io_div2_peri is connected to alert_handler's lpg_cg_en[8].

Verify clkmgr's cg_en_o.io_div4_infra is connected to:

• alert_handler's lpg_cg_en_i[12]
• alert_handler's lpg_cg_en_i[16]

Verify clkmgr's cg_en_o.io_div4_peri is connected to the following:

• alert_handler's lpg_cg_en_i[4:0]
• alert_handler's lpg_cg_en_i[13]

Verify clkmgr's cg_en_o.io_div4_powerup is connected to the following:

• alert_handler's lpg_cg_en_i[11:10]
• alert_handler's lpg_cg_en_i[14]

Verify clkmgr's cg_en_o.io_div4_secure is connected to the following:

• alert_handler's lpg_cg_en_i[6]
• alert_handler's lpg_cg_en_i[17]

Verify clkmgr's cg_en_o.io_div4_timers is connected to the following:

• alert_handler's lpg_cg_en_i[5]
• alert_handler's lpg_cg_en_i[15]

Verify clkmgr's cg_en_o.main_aes is connected to alert_handler's lpg_cg_en[21].