Testplan

Testpoints

Stage N.A. Testpoints

`crypto_lib_hash_stress`

No Tests Implemented

Check that the hash algorithms are correct.

Run the hash algorithms Sha256, Sha384 and Sha512 and compare the digist against the NIST test vector.

`crypto_lib_ecc_stress`

No Tests Implemented

Check that the ECC implementation is correct.

Run the follow operations and compare the result against the NIST test vector:

ECDSA signature.
ECDSA signature verification.
ECDH key exchange.

`crypto_lib_rsa_key_gen_stress`

No Tests Implemented

Check that the implementation of RSA key generation is correct.

Generate RSA key pairs with sizes 2048, 3072 and 4096 bits. The key generation should take an appropriate time based on the key size and the platform (FPGA or Silicon). For each key pair:

Sign a message with the private key.
Verify the signature with the public key.

`crypto_lib_rsa_stress`

No Tests Implemented

Check that the RSA implementation is correct.

Run the follow operations and compare the result against the NIST test vector:

RSA signature.
RSA signature verification. With the keys sizes 2048, 3072 and 4096 bits.

`crypto_lib_aes_stress`

No Tests Implemented

Check that the aes implementation is correct.

Run the following operations and compare the result against the NIST test vector:

AES-CBC encryption.
AES-CBC decryption.
AES-GCM encryption.
AES-GCM decryption.

`crypto_lib_symmetric_keygen`

No Tests Implemented

Check that the crypto lib can generate symmetric keys using hardware entropy.

Generate symmetric keys using entropy from the CSRNG and check it quality using a statistical test.

`crypto_lib_entropy`

No Tests Implemented

Check the correctness of the PRNGs.

Initialize the PRNG with a known seed and compare the entropy generated against a test vector.

Stage V1 Testpoints

`chip_sw_example_tests`

Tests:

chip_sw_example_rom
chip_sw_example_flash
chip_sw_example_manufacturer
chip_sw_example_concurrency

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:

Implement test in the ROM stage itself
Implement test in the flash stage, using test ROM
Implement test in the flash stage, using production ROM
Enable external maufacturer hooks in existing tests developed in the open source
Enable concurrent threads in tests

`csr_hw_reset`

Test: chip_csr_hw_reset

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.

`csr_rw`

Test: chip_csr_rw

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.

`csr_bit_bash`

Test: chip_csr_bit_bash

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.

`csr_aliasing`

Test: chip_csr_aliasing

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.

`csr_mem_rw_with_rand_reset`

Test: chip_csr_mem_rw_with_rand_reset

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.

`regwen_csr_and_corresponding_lockable_csr`

Tests:

chip_csr_rw
chip_csr_aliasing

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.

`xbar_smoke`

Test: xbar_smoke

Sequentially test each host to access any device

`chip_sw_gpio_out`

Test: chip_sw_gpio

Verify GPIO outputs.

SW test configures the GPIOs to be in the output mode. Configure pinmux such as gpio output signal loopback to gpio input. 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.

`chip_sw_gpio_in`

Test: chip_sw_gpio

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.

`chip_sw_gpio_irq`

Test: chip_sw_gpio

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.

`chip_sw_uart_tx_rx`

Test: chip_sw_uart_tx_rx

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.

`chip_sw_uart_rx_overflow`

Tests:

chip_sw_uart_tx_rx
chip_sw_uart_tx_rx_idx1
chip_sw_uart_tx_rx_idx2
chip_sw_uart_tx_rx_idx3

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.

`chip_sw_uart_baud_rate`

Test: chip_sw_uart_rand_baudrate

Verify UART transmission of data at various speeds.

Test data transfer in both directions for each UART instance configured for each of these baud rates: 9600Bd, 115200Bd, 230400Bd, 128kBd, 256kBd, 1MBd, 1.5MBd.

`chip_sw_uart_tx_rx_alt_clk_freq`

Tests:

chip_sw_uart_tx_rx_alt_clk_freq
chip_sw_uart_tx_rx_alt_clk_freq_low_speed

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.

Notes for silicon targets:

This testpoint currently has an empty list of associated features, because the choice of clock is really a clkmgr/chip-level feature, rather than a feature of the UART block.

Stage V2 Testpoints

`chip_pin_mux`

Test: chip_padctrl_attributes

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.

`chip_padctrl_attributes`

Test: chip_padctrl_attributes

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.

`chip_sw_sleep_pin_mio_dio_val`

Test: chip_sw_sleep_pin_mio_dio_val

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.

`chip_sw_sleep_pin_wake`

Test: chip_sw_sleep_pin_wake

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.

For V3, enhance this test to configure all wakeup detectors rather than configure only one, then have the host randomly pick one of the IOs configured for wakeup in one of those detectors. Also, randomize and test all wakeup modes and enable debounce filter.

`chip_sw_sleep_pin_retention`

Test: chip_sw_sleep_pin_retention

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.

`chip_sw_tap_strap_sampling`

Tests:

chip_tap_straps_dev
chip_tap_straps_prod
chip_tap_straps_rma
chip_tap_straps_testunlock0

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. Verify loss of DFT functionality when DFT straps are deasserted on the next POR cycle.

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.

`chip_sw_pattgen_ios`

Test: chip_sw_pattgen_ios

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.

Notes for silicon targets:

Repeat the above test for different patterns and lengths.
Repeat the above test for different clock divider.
Repeat the above test for different repeat values.
Repeat the above test with the clock inverted.
Repeat the above test while using both channels at the same time.
Monitor the clock and data pins on the silicon test setup.

`chip_sw_sleep_pwm_pulses`

Test: chip_sw_sleep_pwm_pulses

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.

Notes for silicon targets:

Instead of using the PWM monitor, the PWM signals should be tested by measuring the actual output pins.
The sampling frequency should be high enough to measure the duty cycle accurately.
Repeat this test with:
- At least two different values of the duty cycle.
- All channels set to blinking.
- All channels set to heartbeat.
- All channels set to reverse polarity.
- At least two different values of the clock divider.
- Each odd PWM channel set to be 180 degrees out of phase of the even ones.

`chip_sw_data_integrity`

Test: chip_sw_data_integrity_escalation

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.

`chip_sw_instruction_integrity`

Test: chip_sw_data_integrity_escalation

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.

`chip_sw_ast_clk_outputs`

Test: chip_sw_ast_clk_outputs

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.

`chip_sw_ast_clk_rst_inputs`

Test: chip_sw_ast_clk_rst_inputs

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

Create different scenarios that affect the clocks and resets and see that the AST features (RNG, entropy, alert, ADC) that use those clocks/resets behave correctly. sequence:

Check that AST RNG generates data and fills the entropy source fifo
Create AST alerts
Activate ADC conversion
EDN entropy supply to AST Enter sleep/deep sleep/ stop IO/USB clocks Repeat 1-4 to check it is ok.

`chip_sw_ast_sys_clk_jitter`

Tests:

chip_sw_clkmgr_jitter
chip_sw_flash_ctrl_ops_jitter_en
chip_sw_flash_ctrl_access_jitter_en
chip_sw_otbn_ecdsa_op_irq_jitter_en
chip_sw_aes_enc_jitter_en
chip_sw_hmac_enc_jitter_en
chip_sw_keymgr_key_derivation_jitter_en
chip_sw_kmac_mode_kmac_jitter_en
chip_sw_sram_ctrl_scrambled_access_jitter_en
chip_sw_edn_entropy_reqs_jitter

Verify that the AST sys clk jitter control.

X-ref with chip_sw_clkmgr_jitter

`chip_sw_ast_usb_clk_calib`

Test: chip_sw_usb_ast_clk_calib

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.

`chip_sw_sensor_ctrl_ast_alerts`

Tests:

chip_sw_pwrmgr_sleep_sensor_ctrl_alert_wakeup
chip_sw_sensor_ctrl_alert

Verify the alerts from AST aggregating into the sensor_ctrl.

Check that each AST event can be triggered from sensor_ctrl. Configure alert handler to reset for both fatal and recoverable alerts. Configure each alert source as fatal or recoverable, and as enabled or disabled checking against resets.

`chip_sw_sensor_ctrl_ast_status`

Test: chip_sw_sensor_ctrl_status

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.

`chip_sw_pwrmgr_sleep_sensor_ctrl_alert_wakeup`

Test: chip_sw_pwrmgr_sleep_sensor_ctrl_alert_wakeup

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.

`chip_sw_smoketest`

Tests:

chip_sw_aes_smoketest
chip_sw_aon_timer_smoketest
chip_sw_clkmgr_smoketest
chip_sw_csrng_smoketest
chip_sw_entropy_src_smoketest
chip_sw_gpio_smoketest
chip_sw_hmac_smoketest
chip_sw_kmac_smoketest
chip_sw_otbn_smoketest
chip_sw_pwrmgr_smoketest
chip_sw_pwrmgr_usbdev_smoketest
chip_sw_rv_plic_smoketest
chip_sw_rv_timer_smoketest
chip_sw_rstmgr_smoketest
chip_sw_sram_ctrl_smoketest
chip_sw_uart_smoketest
chip_sw_flash_scrambling_smoketest

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.

`chip_sw_otp_smoketest`

Test: chip_sw_otp_ctrl_smoketest

Run smoke tests developed for OTP.

This smoketest is separated from the chip_sw_smoketest since it cannot be executed in silicon owner stage.

`chip_sw_rom_functests`

Test: rom_keymgr_functest

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.

`chip_sw_boot`

Test: chip_sw_uart_tx_rx_bootstrap

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

`chip_sw_secure_boot`

Test: rom_e2e_smoke

Verify the secure boot flow.

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

`chip_sw_rom_raw_unlock`

Test: rom_raw_unlock

Configure RAW_UNLOCK via LC TAP interface and enable CPU execution.

This test characterizes the DUT initial state before RAW unlock operation, and switches to external clock via clkmgr to ensure the system clock can be switched right after transition into test_unlcoked0 state. The test also verifies that AST is not initialized while CPU is executing code.

Pre-load OTP image with RAW lc_state.
Initiate the LC transition to test_unlocked0 state using the RAW_UNLOCK mode of operation.
Switch TAP interface to rv_dm and configure the ROM_EXEC_EN OTP to enable ROM execution.
If running with the production ROM, enable signature verification via OTBN to improve simulation time.
Perform POR to apply OTP changes.
With rv_dm TAP still selected, switch to external clock via clkmgr using extclk slow mode configuration.
Wait for ROM to start executing code.
Check AST init done equal to 0 via sensor_ctrl.

`chip_sw_power_idle_load`

Test: chip_sw_power_idle_load

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

`chip_sw_power_sleep_load`

Test: chip_sw_power_sleep_load

Concurrency test modeling load conditions in idle state

This concurrency test models average sleep scenarios.

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.

`chip_sw_exit_test_unlocked_bootstrap`

Test: chip_sw_exit_test_unlocked_bootstrap

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

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.

`chip_sw_inject_scramble_seed`

Test: chip_sw_inject_scramble_seed

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.

`tl_d_oob_addr_access`

Test: chip_tl_errors

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

`tl_d_illegal_access`

Test: chip_tl_errors

Drive unsupported requests via TL interface and verify correctness of response / behavior. Below error cases are tested bases on the TLUL spec

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
- 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

`tl_d_outstanding_access`

Tests:

chip_csr_hw_reset
chip_csr_rw
chip_csr_aliasing
chip_same_csr_outstanding

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.

`tl_d_partial_access`

Tests:

chip_csr_hw_reset
chip_csr_rw
chip_csr_aliasing
chip_same_csr_outstanding

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.

`xbar_base_random_sequence`

Test: xbar_random

Enable all hosts to randomly send transactions to any device

`xbar_random_delay`

Tests:

xbar_smoke_zero_delays
xbar_smoke_large_delays
xbar_smoke_slow_rsp
xbar_random_zero_delays
xbar_random_large_delays
xbar_random_slow_rsp

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

`xbar_unmapped_address`

Tests:

xbar_unmapped_addr
xbar_error_and_unmapped_addr
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

`xbar_error_cases`

Tests:

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

`xbar_all_access_same_device`

Tests:

xbar_access_same_device
xbar_access_same_device_slow_rsp
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

`xbar_all_hosts_use_same_source_id`

Test: xbar_same_source

Test all hosts use same ID at the same same

`xbar_stress_all`

Tests:

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

`xbar_stress_with_reset`

Tests:

xbar_stress_all_with_rand_reset
xbar_stress_all_with_reset_error
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

`rom_e2e_smoke`

Test: rom_e2e_smoke

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.

`rom_e2e_default_otp_bootup`

No Tests Implemented

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

Create an OTP with all zeros except:
- 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.

`rom_e2e_shutdown_output`

Test: rom_e2e_shutdown_output

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.

LC State	LCV	OTP LIFE_CYCLE state	OTP LIFE_CYCLE count
TEST	0x02108421	“TEST_UNLOCKED0”	5
DEV	0x21084210	“DEV”	5
PROD	0x2318c631	“PROD”	5
PROD_END	0x25294a52	“PROD_END”	5
RMA	0x2739ce73	“RMA”	5

`rom_e2e_shutdown_redact`

No Tests Implemented

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.

OTP ROM_ERROR_REPORTING	BFV
0xe2290aa5 (None)	0142500d
0x3367d3d4 (Error)	0042500d
0x1e791123 (Module)	0000000d
0x48eb4bd9 (All)	ffffffff

`rom_e2e_shutdown_watchdog`

Test: rom_e2e_shutdown_watchdog

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 0x00030d40 (1 s).
- Verify that watchdog is disabled when WATCHDOG_BITE_THRESHOLD_CYCLES is 0.

`rom_e2e_shutdown_exception_asm`

No Tests Implemented

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.

`rom_e2e_shutdown_exception_c`

Test: rom_e2e_shutdown_exception_c

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.

`rom_e2e_shutdown_alert_config`

No Tests Implemented

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.

`rom_e2e_bootstrap_enabled_requested`

No Tests Implemented

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

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_enabled_not_requested`

No Tests Implemented

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

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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).

`rom_e2e_bootstrap_disabled_requested`

No Tests Implemented

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

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_disabled_not_requested`

No Tests Implemented

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

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_read_status`

No Tests Implemented

Verify that bootstrap handles READ_STATUS correctly.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_watchdog_disabled`

Test: e2e_bootstrap_entry

Verify that watchdog is disabled upon entering bootstrap.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_read_id`

No Tests Implemented

Verify the JEDEC ID used during bootstrap.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_read_sfdp`

No Tests Implemented

Verify the SFDP table used during bootstrap.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_write_enable_disable`

No Tests Implemented

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

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_phase1_reset`

No Tests Implemented

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

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_phase1_page_program`

No Tests Implemented

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

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_phase1_erase`

No Tests Implemented

Verify that bootstrap phase 1 handles erase commands correctly.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_phase1_read`

No Tests Implemented

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

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_phase2_reset`

No Tests Implemented

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

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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).

`rom_e2e_bootstrap_phase2_page_program`

No Tests Implemented

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

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_phase2_erase`

No Tests Implemented

Verify that bootstrap phase 2 handles erase commands correctly.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_phase2_read`

No Tests Implemented

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

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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.

`rom_e2e_bootstrap_shutdown`

No Tests Implemented

Verify that invalid addresses trigger shutdown.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not 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)

`rom_e2e_boot_policy_no_rom_ext`

No Tests Implemented

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.

`rom_e2e_boot_policy_newer`

No Tests Implemented

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.

Slot a security version	Slot b security version	Chosen
0	0	a
0	1	b
1	0	a
1	1	a

`rom_e2e_boot_policy_bad_manifest`

No Tests Implemented

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.

Case	`BFV`
`identitfier = 0`	`kErrorBootPolicyBadIdentifier`
`length < CHIP_ROM_EXT_SIZE_MIN`	`kErrorBootPolicyBadLength`
`length > CHIP_ROM_EXT_SIZE_MAX`	No Error; image should boot.
`length > ROM_EXT_RESIZABLE_SIZE_MAX`	`kErrorBootPolicyBadLength`
`code_start = code_end`	`kErrorManifestBadCodeRegion`
`code_start < CHIP_MANIFEST_SIZE`	`kErrorManifestBadCodeRegion`
`code_end > length`	`kErrorManifestBadCodeRegion`
`code_start` in range, unaligned	`kErrorManifestBadCodeRegion`
`code_end` in range, unaligned	`kErrorManifestBadCodeRegion`
`entry_point < code_start`	`kErrorManifestBadCodeRegion`
`entry_point >= code_end`	`kErrorManifestBadCodeRegion`
`entry_point` in range, unaligned	`kErrorManifestBadCodeRegion`
`security_version = 0`	`kErrorBootPolicyRollback`

`rom_e2e_boot_policy_big_image`

No Tests Implemented

Verify that ROM can boot flash images that are larger than the ROM_EXT slot.

Provisioning flash images may take up more space than the dedicated ROM_EXT slot, and potentially, up to the size of the entire slot A/B (since there is no need to have multiple boot stages for provisioning firmware).

Write image of size CHIP_ROM_EXT_SIZE_MAX + 1 or greater to slot_a.
- The other slot remains empty (since it could be consumed by the single image).
- Image should be less than (CHIP_ROM_EXT_RESIZABLE_SIZE_MAX + 1).
Verify that the chip boots the image successfully.
Repeat for all life cycle states: TEST, DEV, PROD, PROD_END, and RMA.

`rom_e2e_boot_policy_valid`

Tests:

rom_e2e_boot_policy_valid_a_good_b_good_test_unlocked0
rom_e2e_boot_policy_valid_a_good_b_good_dev
rom_e2e_boot_policy_valid_a_good_b_good_prod
rom_e2e_boot_policy_valid_a_good_b_good_prod_end
rom_e2e_boot_policy_valid_a_good_b_good_rma
rom_e2e_boot_policy_valid_a_good_b_bad_test_unlocked0
rom_e2e_boot_policy_valid_a_good_b_bad_dev
rom_e2e_boot_policy_valid_a_good_b_bad_prod
rom_e2e_boot_policy_valid_a_good_b_bad_prod_end
rom_e2e_boot_policy_valid_a_good_b_bad_rma
rom_e2e_boot_policy_valid_a_bad_b_good_test_unlocked0
rom_e2e_boot_policy_valid_a_bad_b_good_dev
rom_e2e_boot_policy_valid_a_bad_b_good_prod
rom_e2e_boot_policy_valid_a_bad_b_good_prod_end
rom_e2e_boot_policy_valid_a_bad_b_good_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.

Slot a	Slot b	Chosen
Bad	Bad	None
Bad	Good	b
Good	Bad	a
Good	Good	a

`rom_e2e_boot_policy_rollback`

No Tests Implemented

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.

Slot a	Slot b	Chosen
0	0	None
0	1	b
2	0	a
1	1	a

`rom_e2e_boot_data_recovery`

No Tests Implemented

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.

LC State	CREATOR_SW_CFG_MIN_SEC_VER_ROM_EXT	CREATOR_SW_CFG_DEFAULT_BOOT_DATA_IN_PROD
TEST	0	`kHardenedBoolFalse`
DEV	1	`kHardenedBoolFalse`
PROD	1	`kHardenedBoolTrue`
PROD	0	`kHardenedBoolFalse` (error)
PROD_END	0	`kHardenedBoolTrue`
PROD_END	1	`kHardenedBoolFalse` (error)
RMA	0	`kHardenedBoolFalse`

`rom_e2e_sigverify_always`

Tests:

rom_e2e_sigverify_always_a_bad_b_bad_test_unlocked0
rom_e2e_sigverify_always_a_bad_b_bad_dev
rom_e2e_sigverify_always_a_bad_b_bad_prod
rom_e2e_sigverify_always_a_bad_b_bad_prod_end
rom_e2e_sigverify_always_a_bad_b_bad_rma
rom_e2e_sigverify_always_a_bad_b_nothing_test_unlocked0
rom_e2e_sigverify_always_a_bad_b_nothing_dev
rom_e2e_sigverify_always_a_bad_b_nothing_prod
rom_e2e_sigverify_always_a_bad_b_nothing_prod_end
rom_e2e_sigverify_always_a_bad_b_nothing_rma
rom_e2e_sigverify_always_a_nothing_b_bad_test_unlocked0
rom_e2e_sigverify_always_a_nothing_b_bad_dev
rom_e2e_sigverify_always_a_nothing_b_bad_prod
rom_e2e_sigverify_always_a_nothing_b_bad_prod_end
rom_e2e_sigverify_always_a_nothing_b_bad_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: kErrorSigverifyBadEcdsaSignature.
Repeat the steps above for TEST, DEV, PROD, PROD_END, and RMA.

See rom_e2e_boot_policy_valid.

`rom_e2e_sigverify_key_auth`

No Tests Implemented

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.

`rom_e2e_sigverify_key_validity`

No Tests Implemented

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

For each key entry in the ROT_CREATOR_AUTH_STATE partition,
- Invalidate the key by setting the entry to a value other than PROVISIONED.
- Prepare a ROM_EXT image with a valid signature generated using the invalidated key.
- Verify that boot fails with BFV:kErrorSigverifyBadEcdsaKey or BFV:kErrorSigverifyBadSpxKey depending on whether the failure is due to a bad ECDSA or SPX key.

LC State	Allowed key types
DEV	Prod, Dev
PROD	Prod
PROD_END	Prod
RMA	Test, Prod

`rom_e2e_sigverify_key_type`

No Tests Implemented

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.

LC State	Allowed key types
TEST	Test, Prod
DEV	Prod, Dev
PROD	Prod
PROD_END	Prod
RMA	Test, Prod

`rom_e2e_sigverify_usage_constraints`

No Tests Implemented

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.

`rom_e2e_address_translation`

No Tests Implemented

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.

Address translation	Image addr	Slot used	Error
Off	A	A	No
Off	B	B	No
Off	A	B	Yes
Off	B	A	Yes
On	Virtual	A	No
On	Virtual	B	No
Invalid	A	A	Yes

`rom_e2e_debug_disallowed_in_prod`

No Tests Implemented

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.

`rom_e2e_rom_ext_upgrade`

No Tests Implemented

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.

`rom_e2e_rom_ext_upgrade_interrupt`

No Tests Implemented

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.

`rom_e2e_asm_interrupt_handler`

No Tests Implemented

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.

`rom_e2e_asm_watchdog`

No Tests Implemented

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.

`rom_e2e_asm_c_interrupt_handler`

No Tests Implemented

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.

`rom_e2e_asm_init`

Tests:

rom_e2e_asm_init_test_unlocked0
rom_e2e_asm_init_dev
rom_e2e_asm_init_prod
rom_e2e_asm_init_prod_end
rom_e2e_asm_init_rma

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.

`rom_e2e_ret_ram_init`

No Tests Implemented

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.

`rom_e2e_ret_ram_keep`

No Tests Implemented

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.

`rom_e2e_c_init`

No Tests Implemented

Verify that ROM initializes various peripherals properly.

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

`rom_e2e_epmp_init`

No Tests Implemented

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.

`rom_e2e_watchdog_reconfig`

No Tests Implemented

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.

`rom_e2e_alert_config`

No Tests Implemented

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.

`rom_e2e_flash_ctrl_init`

No Tests Implemented

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.

`rom_e2e_keymgr_init`

Tests:

rom_e2e_keymgr_init_rom_ext_meas
rom_e2e_keymgr_init_rom_ext_no_meas
rom_e2e_keymgr_init_rom_ext_invalid_meas

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 software readable OTP partitions if OWNER_SW_CFG_ROM_KEYMGR_OTP_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,

`rom_e2e_static_critical`

Test: rom_e2e_static_critical

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.

`rom_functests`

No Tests Implemented

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.

`aon_timer_rst`

Test: aon_timer_rst

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

`aon_timer_rst_aon`

Test: aon_timer_rst_aon

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

`ast_clockmgr_clocks`

Tests:

ast_clk_sys_out
ast_clk_aon_out
ast_clk_usb_out
ast_clk_io_out
ast_all_byp_ack_out
ast_io_byp_ack_out
ast_clk_adc_in
ast_clk_alert_in
ast_clk_es_in
ast_clk_rng_in
ast_clk_tlul_in
ast_clk_usb_in
ast_clk_sns_in
ast_clk_jen_in
ast_all_byp_ack_in
ast_io_byp_ack_in
ast_hispeed_sel_in

Verify the clock connectivity between AST and clock manager.

`ast_pwrmgr_pok`

Tests:

ast_clk_sys_val_out
ast_clk_aon_val_out
ast_clk_usb_val_out
ast_clk_io_val_out
ast_main_pok_out
ast_clk_sys_en_in
ast_clk_usb_en_in
ast_clk_io_en_in

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

`ast_rstmgr_resets`

Tests:

ast_rst_adc_in
ast_rst_alert_in
ast_rst_es_in
ast_rst_rng_in
ast_rst_tlul_in
ast_rst_usb_in
ast_rst_sns_in

Verify the reset connectivity between AST and reset manager.

`ast_pad_shorts`

Tests:

ast_pad0
ast_pad1

Verify pads that are directly shorted to pads

`ast_pinmux`

Test: ast_pinmux

Verify AST -> pinmux connectivity

`ast_pad_inputs`

Test: pad_ast

Verify pad inputs that are connected to AST

`ast_other_clocks`

Tests:

ast_clk_ext_in
ast_clk_spi_sns_in

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

`ast_other_resets`

Test: ast_rst_por_in

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

`ast_other_pok`

Tests:

ast_usb_ref_in
ast_usb_ref_val_in
ast_otp_pwr_seq_in
ast_main_pd_in
ast_main_iso_en_in
ast_otp_pwr_seq_out

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

`ast_dft_ram_2p_cfg`

Tests:

ast_dft_spi_device_ram_2p_cfg
ast_dft_usbdev_ram_2p_cfg

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

spi_device
usbdev

`ast_dft_ram_1p_cfg`

Tests:

ast_dft_otbn_imem_ram_1p_cfg
ast_dft_otbn_dmem_ram_1p_cfg
ast_dft_rv_core_ibex_tag0_ram_1p_cfg
ast_dft_rv_core_ibex_tag1_ram_1p_cfg
ast_dft_rv_core_ibex_data0_ram_1p_cfg
ast_dft_rv_core_ibex_data1_ram_1p_cfg
ast_dft_sram_main_ram_1p_cfg
ast_dft_sram_ret_ram_1p_cfg
ast_dft_rom_cfg

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

`scanmode_connections`

Tests:

ast_scanmode_padring
ast_scanmode_clkmgr
ast_scanmode_flash_ctrl
ast_scanmode_lc_ctrl
ast_scanmode_otp_ctrl
ast_scanmode_pinmux
ast_scanmode_rstmgr
ast_scanmode_rv_core_ibex
ast_scanmode_rv_dm
ast_scanmode_spi_device
ast_scanmode_xbar_main
ast_scanmode_xbar_peri

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

`vendor_test_connections`

Tests:

lc_otp_vendor_test_ctrl
lc_otp_vendor_test_status

Verify the connectivity of vendor_test IOs between otp_ctrl and lc_ctrl.

`cg_en_io_peri`

Test: clkmgr_io_peri_alert_7_cg_en

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

`cg_en_io_div2_peri`

Test: clkmgr_io_div2_peri_alert_8_cg_en

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

`cg_en_io_div4_infra`

Tests:

clkmgr_io_div2_infra_alert_12_cg_en
clkmgr_io_div4_infra_alert_16_cg_en

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]

`cg_en_io_div4_peri`

Tests:

clkmgr_io_div4_peri_alert_0_cg_en
clkmgr_io_div4_peri_alert_1_cg_en
clkmgr_io_div4_peri_alert_2_cg_en
clkmgr_io_div4_peri_alert_3_cg_en
clkmgr_io_div4_peri_alert_4_cg_en
clkmgr_io_div4_peri_alert_13_cg_en

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]

`cg_en_io_div4_powerup`

Tests:

clkmgr_io_div4_powerup_alert_10_cg_en
clkmgr_io_div4_powerup_alert_11_cg_en
clkmgr_io_div4_powerup_alert_14_cg_en

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]

`cg_en_io_div4_secure`

Tests:

clkmgr_io_div4_secure_alert_6_cg_en
clkmgr_io_div4_secure_alert_17_cg_en

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]

`cg_en_io_div4_timers`

Tests:

clkmgr_io_div4_timers_alert_5_cg_en
clkmgr_io_div4_timers_alert_15_cg_en

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]

`cg_en_main_aes`

Test: clkmgr_main_aes_alert_21_cg_en

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

`cg_en_main_infra`

Tests:

clkmgr_main_infra_alert_18_cg_en
clkmgr_main_infra_alert_19_cg_en

Verify clkmgr’s cg_en_o.main_infra is connected to alert_handler’s lpg_cg_en[19:18].

`cg_en_main_secure`

Test: clkmgr_main_secure_alert_20_cg_en

Verify clkmgr’s cg_en_o.main_secure is connected to alert_handler’s lpg_cg_en[20].

`cg_en_usb_peri`

Test: clkmgr_usb_peri_alert_9_cg_en

Verify clkmgr’s cg_en_o.usb_peri is connected to alert_handler’s lpg_cg_en[9].

`clkmgr_idle`

Tests:

clkmgr_idle0
clkmgr_idle1
clkmgr_idle2
clkmgr_idle3

Verify clkmgr’s idle_i bits are connected to the following ports:

index 0 to aes’s idle_o
index 1 to hmac’s idle_o
index 2 to kmac’s idle_o
index 3 to otbn’s idle_o

`clkmgr_clk_io_div4_infra`

Tests:

clkmgr_infra_clk_flash_ctrl_otp_clk
clkmgr_infra_clk_sram_ctrl_main_otp_clk
clkmgr_infra_clk_sram_ctrl_ret_clk
clkmgr_infra_clk_sram_ctrl_ret_otp_clk
clkmgr_infra_clk_sysrst_ctrl_clk
clkmgr_infra_clk_xbar_main_fixed_clk
clkmgr_infra_clk_xbar_peri_peri_clk

Verify clkmgr’s clk_io_div4_infra is connected to the following block’s clock input:

flash_ctrl clk_otp_i
sram_ctrl main clk_otp_i
sram_ctrl retention clk_i
sram_ctrl retention clk_otp_i
sysrst_ctrl clk_i
xbar_main clk_fixed_i
xbar_peri clk_peri_i

`clkmgr_clk_main_infra`

Tests:

clkmgr_infra_clk_flash_ctrl_clk
clkmgr_infra_clk_rv_dm_clk
clkmgr_infra_clk_rom_clk
clkmgr_infra_clk_rv_core_ibex_clk
clkmgr_infra_clk_rv_core_ibex_edn_clk
clkmgr_infra_clk_sram_ctrl_main_clk
clkmgr_infra_clk_xbar_main_main_clk

Verify clkmgr’s clk_main_infra is connected to the following blocks’ clock input:

flash_ctrl clk_i
rv_dm clk_i
rom_ctrl clk_i
rv_core_ibex clk_i
rv_core_ibex clk_edn_i
sram_ctrl main clk_i
xbar_main clk_main_i

`clkmgr_clk_aon_infra`

Test: clkmgr_infra_clk_sysrst_ctrl_aon_clk

Verify clkmgr’s clk_aon_infra is connected to the following block’s clock input:

sysrst_ctrl clk_aon_i

`clkmgr_clk_io_infra`

Test: clkmgr_infra_clk_xbar_main_spi_host0_clk

Verify clkmgr’s clk_io_infra is connected to the following block’s clock input:

xbar_main’s clk_spi_host0_i

`clkmgr_clk_io_div2_infra`

Test: clkmgr_infra_clk_xbar_main_spi_host1_clk

Verify clkmgr’s clk_io_div2_infra is connected to the following block’s clock input:

xbar_main clk_spi_host1_i

`clkmgr_clk_io_div4_peri`

Tests:

clkmgr_peri_clk_adc_ctrl_aon_clk
clkmgr_peri_clk_gpio_clk
clkmgr_peri_clk_spi_device_clk
clkmgr_peri_clk_i2c0_clk
clkmgr_peri_clk_i2c1_clk
clkmgr_peri_clk_i2c2_clk
clkmgr_peri_clk_pattgen_clk
clkmgr_peri_clk_uart0_clk
clkmgr_peri_clk_uart1_clk
clkmgr_peri_clk_uart2_clk
clkmgr_peri_clk_uart3_clk

Verify clkmgr’s clk_io_div4_peri is connected to the following blocks’ clock input:

adc_ctrl clk_i
gpio clk_i
spi_device clk_i
i2c0 clk_i
i2c1 clk_i
i2c2 clk_i
pattgen clk_i
uart0 clk_i
uart1 clk_i
uart2 clk_i
uart3 clk_i

`clkmgr_clk_io_div2_peri`

Tests:

clkmgr_peri_clk_spi_device_scan_clk
clkmgr_peri_clk_spi_host1_clk

Verify clkmgr’s clk_io_div2_peri is connected to the following blocks’ clock input:

spi_device’s scan_clk_i
spi_host1 clk_i

`clkmgr_clk_io_peri`

Test: clkmgr_peri_clk_spi_host0_clk

Verify clkmgr’s clk_io_peri is connected to the following block’s clock input:

spi_host0’s clk_i

`clkmgr_clk_usb_peri`

Test: clkmgr_peri_clk_usbdev_usb_clk

Verify clkmgr’s clk_usb_peri is connected to the following:

usbdev’s clk_i

`clkmgr_clk_aon_peri`

Test: clkmgr_peri_clk_usbdev_aon_clk

Verify clkmgr’s clk_aon_peri is connected to the following blocks’ clock input:

usbdev clk_aon_i

`clkmgr_clk_io_div4_powerup`

Tests:

clkmgr_powerup_clk_clkmgr_clk
clkmgr_powerup_clk_pinmux_clk
clkmgr_powerup_clk_pwm_clk
clkmgr_powerup_clk_pwrmgr_clk
clkmgr_powerup_clk_pwrmgr_lc_clk
clkmgr_powerup_clk_rstmgr_por_clk
clkmgr_powerup_clk_rstmgr_io4_clk

Verify clkmgr’s clk_io_div4_powerup is connected to the following blocks’ clock input:

clkmgr clk_i
pinmux clk_i
pwm clk_i
pwrmgr clk_i
rstmgr clk_i
rstmgr clk_io_div4_i

`clkmgr_clk_aon_powerup`

Tests:

clkmgr_powerup_clk_pinmux_aon_clk
clkmgr_powerup_clk_pwm_core_clk
clkmgr_powerup_clk_pwrmgr_slow_clk
clkmgr_powerup_clk_rstmgr_aon_clk

Verify clkmgr’s clk_aon_powerup is connected to the following blocks’ clock input:

pinmux’s clk_aon_i
pwm clk_core_i
pwrmgr clk_slow_i
rstmgr clk_aon_i

`clkmgr_clk_main_powerup`

Test: clkmgr_powerup_clk_rstmgr_main_clk

Verify clkmgr’s clk_main_powerup is connected to the following block’s clock input:

rstmgr’s clk_main_i

`clkmgr_clk_io_powerup`

Test: clkmgr_powerup_clk_rstmgr_io_clk

Verify clkmgr’s clk_io_powerup is connected to rstmgr’s io clock.

`clkmgr_clk_usb_powerup`

Test: clkmgr_powerup_clk_rstmgr_usb_clk

Verify clkmgr’s clk_usb_powerup is connected to rstmgr’s usb clock.

`clkmgr_clk_io_div2_powerup`

Test: clkmgr_powerup_clk_rstmgr_io2_clk

Verify clkmgr’s clk_io_div2_powerup is connected to rstmgr’s io_div2 clock.

`clkmgr_clk_io_div4_secure`

Tests:

clkmgr_secure_clk_alert_handler_clk
clkmgr_secure_clk_lc_ctrl_clk
clkmgr_secure_clk_otbn_otp_clk
clkmgr_secure_clk_otp_ctrl_clk
clkmgr_secure_clk_rv_core_ibex_clk
clkmgr_secure_clk_rv_core_ibex_otp_clk
clkmgr_secure_clk_sensor_ctrl_clk

Verify clkmgr’s clk_io_div4_secure is connected to the following blocks’ clock input:

alert_handler clk_i
lc_ctrl clk_i
otbn clk_otp_i
otp_ctrl clk_i
pwrmgr clk_lc_i
rv_core_ibex clk_esc_i
rv_core_ibex clk_otp_i
sensor_ctrl clk_i

`clkmgr_clk_main_secure`

Tests:

clkmgr_secure_clk_alert_handler_edn_clk
clkmgr_secure_clk_csrng_clk
clkmgr_secure_clk_edn0_clk
clkmgr_secure_clk_edn1_clk
clkmgr_secure_clk_entropy_src_clk
clkmgr_secure_clk_keymgr_clk
clkmgr_secure_clk_keymgr_edn_clk
clkmgr_secure_clk_lc_ctrl_kmac_clk
clkmgr_secure_clk_otbn_edn_clk
clkmgr_secure_clk_otp_ctrl_edn_clk
clkmgr_secure_clk_rv_plic_clk

Verify clkmgr’s clk_main_secure is connected to the following blocks’ clock input:

alert_handler’s clk_edn_i
csrgn clk_i
edn0 clk_i
edn1 clk_i
entropy_src clk_i
keymgr clk_i
keymgr clk_edn_i
lc_ctrl clk_kmac_i
otbn clk_edn_i
otp_ctrl clk_edn_i
rv_plic clk_i

`clkmgr_clk_aon_secure`

Test: clkmgr_secure_clk_sensor_ctrl_aon_clk

Verify clkmgr’s clk_aon_secure is connected to the following blocks’ clock input:

sensor_ctrl clk_aon_i

`clkmgr_clk_io_div4_timers`

Tests:

clkmgr_timers_clk_aon_timer_clk
clkmgr_timers_clk_rv_timer_clk

Verify clkmgr’s clk_io_div4_timers is connected to the following blocks’ clock input:

aon_timer clk_i
rv_timer clk_i

`clkmgr_clk_aon_timers`

Test: clkmgr_timers_clk_aon_timer_aon_clk

Verify clkmgr’s clk_aon_timers is connected to aon_timer’s aon clock.

`clk_main_aes`

Tests:

clkmgr_trans_aes
clkmgr_trans_aes_edn

Verify clkmgr’s clk_main_aes is connected to the following block’s clocks:

aes clk_i
aes clk_edn_i

`clk_main_hmac`

Test: clkmgr_trans_hmac

Verify clkmgr’s clk_main_hmac is connected to hmac’s clk_i.

`clk_main_kmac`

Tests:

clkmgr_trans_kmac
clkmgr_trans_kmac_edn

Verify clkmgr’s clk_main_kmac is connected to kmac’s clk_i and clk_edn_i.

`clk_main_otbn`

Test: clkmgr_trans_otbn

Verify clkmgr’s clk_main_otbn is connected to otbn’s clk_i.

`ast_flash_ctrl`

Tests:

ast_flash_obs_ctrl
ast_flash_pwr_dwn_out
ast_flash_pwr_rdy_out
ast_flash_bist_en_out

Verify ast’s flash signals are connected to the flash controller.

`chip_sw_entropy_src_ast_fips`

Tests:

ast_entropy_src_rng_val
ast_entropy_src_rng_b
ast_entropy_src_rng_fips
ast_entropy_src_rng_en

Verify the connectivity of rng_fips_o feedback signal to RNG.

`flash_jtag`

Tests:

pinmux_flash_ctrl_tck
pinmux_flash_ctrl_tms
pinmux_flash_ctrl_tdi
pinmux_flash_ctrl_tdo
pinmux_flash_ctrl_tdo_en

Verify jtag interface is connected to flash_phy_req interface.

`lc_jtag_trst`

Tests:

pinmux_lc_ctrl_jtag_req
pinmux_lc_ctrl_jtag_rsp

Verify jtag rst pin is connected to lc_ctrl interface.

`lc_escalate_en`

Tests:

lc_escalate_en_otp
lc_escalate_en_aon_timer
lc_escalate_en_sram_main
lc_escalate_en_sram_ret
lc_escalate_en_flash
lc_escalate_en_aes
lc_escalate_en_kmac
lc_escalate_en_otbn

Verify lc_ctrl’s lc_escalate_en_o is connected to the following blocks’ lc_escalate_en_i:

otp_ctrl
aon_timer
sram_ctrl main
sram_ctrl retention
flash_ctrl
aes
kmac
otbn

`lc_keymgr_en`

Tests:

lc_keymgr_en_keymgr
lc_keymgr_div_keymgr

Verify that lc_ctrl’s keymanager enable signal and diversification value are correctly connected to the keymgr.

`lc_nvm_debug_en`

Test: lc_nvm_debug_en_flash_ctrl

Verify lc_ctrl’s lc_nvm_debug_en is connected correctly to flash_ctrl.

`lc_cpu_en`

Test: lc_cpu_en_rv_core_ibex

Verify that the lc_ctrl’s lc_cpu_en_o signal is correctly connected to rv_core_ibex.

`lc_hw_debug_en`

Tests:

lc_hw_debug_en_pwrmgr
lc_hw_debug_en_clkmgr
lc_hw_debug_en_pinmux
lc_hw_debug_en_sram_ctrl_main
lc_hw_debug_en_rv_dm
lc_hw_debug_en_csrng

Verify that lc_ctrl’s lc_hw_debug_en_o signal is correctly connected to IPs.

`lc_hw_dft_en`

Tests:

lc_dft_en_otp
lc_dft_en_pwrmgr
lc_dft_en_pinmux
lc_dft_en_ast

Verify that lc_ctrl’s lc_dft_en_o signal is correctly connected to IPs.

`lc_flash_otbn_rma`

Tests:

lc_rma_seed_flash_ctrl
lc_rma_req_flash_ctrl
flash_ctrl_rma_ack_otbn
otbn_rma_ack_lc

Verify lc_ctrl’s RMA request connections.

`lc_clk_byp`

Tests:

lc_clk_byp_req_clkmgr
clkmgr_clk_byp_ack_lc

Verify lc_ctrl’s clock bypass request connections.

`lc_otp_check_byp`

Test: lc_check_byp_en_otp

Verify lc_ctrl’s check bypass signal is correctly connected to OTP (used when programming a life cycle transition).

`lc_access_control`

Tests:

lc_creator_seed_sw_rw_en_otp
lc_seed_hw_rd_en_otp
lc_creator_seed_sw_rw_en_flash
lc_seed_hw_rd_en_flash
lc_owner_seed_sw_rw_en_flash
lc_iso_part_sw_rd_en_flash
lc_iso_part_sw_wr_en_flash

Verify lc_ctrl’s access control modulation signals are correctly connected to flash and OTP.

`pwrmgr_rst_lc_req`

Test: pwrmgr_rst_lc_req

Verify pwrmgr’s rst_lc_req is connected to rstmgr’s rst_lc_req.

`pwrmgr_rst_sys_req`

Test: pwrmgr_rst_sys_req

Verify pwrmgr’s rst_sys_req is connected to rstmgr’s rst_sys_req.

`rstmgr_rst_lc_src_n`

Test: rstmgr_rst_lc_src_n

Verify rstmgr’s rst_lc_src_n is connected to pwrmgr’s rst_lc_src_n.

`rstmgr_rst_sys_src_n`

Test: rstmgr_rst_sys_src_n

Verify rstmgr’s rst_sys_src_n is connected to rstmgr’s rst_sys_src_n.

`rst_i2c0_n_d0`

Test: rstmgr_i2c0_d0_i2c0_rst_ni

Verify rstmgr’s rst_i2c0_n[1] is connected to i2c0’s rst_ni.

`rst_i2c1_n_d0`

Test: rstmgr_i2c0_d0_i2c1_rst_ni

Verify rstmgr’s rst_i2c1_n[1] is connected to i2c1’s rst_ni.

`rst_i2c2_n_d0`

Test: rstmgr_i2c2_d0_i2c2_rst_ni

Verify rstmgr’s rst_i2c2_n[1] is connected to i2c2’s rst_ni.

`rst_lc_aon_aon`

Tests:

rstmgr_lc_aon_aon_aon_timer_rst_aon_ni
rstmgr_lc_aon_aon_clkmgr_rst_aon_ni
rstmgr_lc_aon_aon_pinmux_rst_aon_ni

Verify rstmgr’s rst_lc_aon_n[0] is connected to the following:

aon_timer’s rst_aon_ni
clkmgr’s rst_aon_ni
pinmux’s rst_aon_ni

`rst_lc_io_div2_n_aon`

Test: rstmgr_lc_io_div2_aon_clkmgr_rst_io_div2_ni

Verify rstmgr’s rst_i2c2_n[1] is connected to clkmgr’s rst_io_div2_ni.

`rst_lc_io_div4_aon`

Tests:

rstmgr_lc_io_div4_aon_aon_timer_rst_ni
rstmgr_lc_io_div4_aon_clkmgr_rst_ni
rstmgr_lc_io_div4_aon_clkmgr_rst_io_div4_ni
rstmgr_lc_io_div4_aon_pwrmgr_rst_lc_ni
rstmgr_lc_io_div4_aon_pinmux_rst_ni
rstmgr_lc_io_div4_aon_sram_ctrl_ret_rst_otp_ni
rstmgr_lc_io_div4_aon_rstmgr_rst_ni

Verify rstmgr’s rst_lc_io_div4_n[0] is connected to the following:

aon_timer’s rst_ni
clkmgr’s rst_ni
clkmgr’s rst_io_div4_ni
pinmux’s rst_ni
sram_ctrl_ret’s rst_otp_ni
rstmgr’s rst_ni

`rst_lc_io_div4_d0`

Tests:

rstmgr_lc_io_div4_d0_alert_handler_rst_ni
rstmgr_lc_io_div4_d0_lc_ctrl_rst_ni
rstmgr_lc_io_div4_d0_otbn_rst_otp_ni
rstmgr_lc_io_div4_d0_otp_ctrl_rst_ni
rstmgr_lc_io_div4_d0_rv_core_ibex_rst_esc_ni
rstmgr_lc_io_div4_d0_rv_core_ibex_rst_otp_ni
rstmgr_lc_io_div4_d0_sram_ctrl_main_rst_otp_ni

Verify rstmgr’s rst_lc_io_div4_n[1] is connected to the following:

alert_handler’s rst_ni
lc_ctrl’s rst_ni
otbn’s rst_otp_ni
otp_ctrl’s rst_ni
pwrmgr’s rst_lc_ni
rv_core_ibex’s rst_esc_ni
rv_core_ibex’s rst_otp_ni
sram_ctrl_main’s rst_otp_ni

`rst_lc_io_div4_shadowed_aon`

Test: rstmgr_lc_io_div4_shadowed_aon_clkmgr_rst_shadowed_ni

Verify rstmgr’s rst_lc_io_div4_shadowed_n[0] is connected to clkmgr’s rst_shadowed_ni.

`rst_lc_io_div4_shadowed_d0`

Test: rstmgr_lc_io_div4_shadowed_d0_alert_handler_rst_shadowed_ni

Verify rstmgr’s rst_lc_io_div4_shadowed_n[1] is connected to alert_handler’s rst_shadowed_ni.

`rst_lc_aon`

Test: rstmgr_lc_aon_clkmgr_rst_main_ni

Verify rstmgr’s rst_lc_n[0] is connected to clkmgr’s rst_main_ni.

`rst_lc_io_aon`

Test: rstmgr_lc_io_aon_clkmgr_rst_io_ni

Verify rstmgr’s rst_lc_io_n[0] is connected to clkmgr’s rst_io_ni.

`rst_lc_usb_aon`

Test: rstmgr_lc_usb_aon_clkmgr_rst_usb_ni

Verify rstmgr’s rst_lc_usb_n[0] is connected to clkmgr’s rst_usb_ni.

`rst_por_aon_aon`

Test: rstmgr_por_aon_aon_pwrmgr_rst_slow_ni

Verify rstmgr’s rst_por_aon_n[0] is connected to pwrmgr’s rst_slow_ni.

`rst_por_aon_d0`

Test: rstmgr_por_aon_d0_pwrmgr_rst_main_ni

Verify rstmgr’s rst_por_aon_n[1] is connected to pwrmgr’s rst_main_ni.

`rst_por_aon`

Test: rstmgr_por_aon_clkmgr_rst_root_main_ni

Verify rstmgr’s rst_por_n[0] is connected to clkmgr’s rst_root_main_ni.

`rst_por_io_aon`

Test: rstmgr_por_io_aon_clkmgr_rst_root_io_ni

Verify rstmgr’s rst_por_io_n[0] is connected to clkmgr’s rst_root_io_ni.

`rst_por_io_div2_aon`

Test: rstmgr_por_io_div2_aon_clkmgr_rst_root_io_div2_ni

Verify rstmgr’s rst_por_io_div2_n[0] is connected to clkmgr’s rst_root_io_div2_ni.

`rst_por_io_div4_aon`

Tests:

rstmgr_por_io_div4_aon_clkmgr_rst_root_io_div4_ni
rstmgr_por_io_div4_aon_clkmgr_rst_root_ni
rstmgr_por_io_div4_aon_pwrmgr_rst_ni
rstmgr_por_io_div4_aon_rstmgr_rst_ni

Verify rstmgr’s rst_por_io_div4_n[0] is connected to the following:

clkmgr’s rst_root_io_div4_ni
clkmgr’s rst_root_ni
pwrmgr’s rst_ni
rstmgr’s rst_por_ni

`rst_por_usb_aon`

Test: rstmgr_por_usb_aon_clkmgr_rst_root_usb_ni

Verify rstmgr’s rst_por_usb_n[0] is connected to clkmgr’s rst_root_usb_ni.

`rst_spi_device_d0`

Test: rstmgr_spi_device_d0_spi_device_rst_ni

Verify rstmgr’s rst_spi_device_n[1] is connected to spi_device’s rst_ni.

`rst_spi_host0_d0`

Test: rstmgr_spi_host0_d0_spi_host0_rst_ni

Verify rstmgr’s rst_spi_host0_n[1] is connected to spi_host0’s rst_ni.

`rst_spi_host1_d0`

Test: rstmgr_spi_host1_d0_spi_host1_rst_ni

Verify rstmgr’s rst_spi_host1_n[1] is connected to spi_host1’s rst_ni.

`rst_sys_aon_aon`

Tests:

rstmgr_sys_aon_aon_adc_ctrl_rst_aon_ni
rstmgr_sys_aon_aon_pwm_rst_aon_ni
rstmgr_sys_aon_aon_sensor_ctrl_rst_aon_ni
rstmgr_sys_aon_aon_sysrst_ctrl_rst_aon_ni

Verify rstmgr’s rst_sys_aon_n[0] is connected to the following:

adc_ctrl’s rst_aon_ni
pwm’s rst_core_ni
sensor_ctrl’s rst_aon_ni
sysrst_ctrl’s rst_aon_ni

`rst_sys_io_d0`

Test: rstmgr_sys_io_d0_xbar_main_rst_spi_host0_ni

Verify rstmgr’s rst_sys_io_n[1] is connected to xbar_main’s rst_spi_host0_ni.

`rst_sys_io_div2_d0`

Test: rstmgr_sys_io_div2_d0_xbar_main_rst_spi_host1_ni

Verify rstmgr’s rst_sys_io_div2_n[1] is connected to xbar_main’s rst_spi_host1_ni.

`rst_sys_io_div4_aon`

Tests:

rstmgr_sys_io_div4_aon_adc_ctrl_rst_ni
rstmgr_sys_io_div4_aon_pwm_rst_ni
rstmgr_sys_io_div4_aon_sensor_ctrl_rst_ni
rstmgr_sys_io_div4_aon_sram_ctrl_ret_rst_ni
rstmgr_sys_io_div4_aon_sysrst_ctrl_rst_ni

Verify rstmgr’s rst_sys_io_div4_n[0] is connected to the following:

adc_ctrl’s rst_ni
pwm’s rst_ni
sensor_ctrl’s rst_ni
sram_ctrl_ret’s rst_ni
sysrst_ctrl’s rst_ni

`rst_sys_io_div4_d0`

Tests:

rstmgr_sys_io_div4_d0_flash_ctrl_rst_otp_ni
rstmgr_sys_io_div4_d0_gpio_rst_ni
rstmgr_sys_io_div4_d0_pattgen_rst_ni
rstmgr_sys_io_div4_d0_rv_timer_rst_ni
rstmgr_sys_io_div4_d0_uart0_rst_ni
rstmgr_sys_io_div4_d0_uart1_rst_ni
rstmgr_sys_io_div4_d0_uart2_rst_ni
rstmgr_sys_io_div4_d0_uart3_rst_ni
rstmgr_sys_io_div4_d0_xbar_main_rst_fixed_ni
rstmgr_sys_io_div4_d0_xbar_peri_rst_peri_ni

Verify rstmgr’s rst_sys_io_div4_n[1] is connected to the following:

flash_ctrl’s rst_otp_ni
gpio’s rst_ni
pattgen’s rst_ni
rv_timer’s rst_ni
uart0’s rst_ni
uart1’s rst_ni
uart2’s rst_ni
uart3’s rst_ni
xbar_main’s rst_fixed_ni
xbar_peri’s rst_peri_ni

`rst_sys_d0`

Tests:

rstmgr_sys_d0_aes_rst_edn_ni
rstmgr_sys_d0_aes_rst_ni
rstmgr_sys_d0_alert_handler_rst_edn_ni
rstmgr_sys_d0_csrng_rst_ni
rstmgr_sys_d0_edn0_rst_ni
rstmgr_sys_d0_edn1_rst_ni
rstmgr_sys_d0_entropy_src_rst_ni
rstmgr_sys_d0_flash_ctrl_rst_ni
rstmgr_sys_d0_hmac_rst_ni
rstmgr_sys_d0_keymgr_rst_edn_ni
rstmgr_sys_d0_keymgr_rst_ni
rstmgr_sys_d0_kmac_rst_edn_ni
rstmgr_sys_d0_kmac_rst_ni
rstmgr_sys_d0_otbn_rst_edn_ni
rstmgr_sys_d0_otbn_rst_ni
rstmgr_sys_d0_lc_ctrl_rst_kmac_ni
rstmgr_sys_d0_otp_ctrl_rst_edn_ni
rstmgr_sys_d0_rv_core_ibex_rst_edn_ni
rstmgr_sys_d0_rv_core_ibex_rst_ni
rstmgr_sys_d0_rv_plic_rst_ni
rstmgr_sys_d0_sram_ctrl_main_rst_ni
rstmgr_sys_d0_xbar_main_rst_main_ni

Verify rstmgr’s rst_sys_n[1] is connected to the following:

aes’s rst_edn_ni
aes’s rst_ni
alert_handler’s rst_edn_ni
csrng’s rst_ni
edn0’s rst_ni
edn1’s rst_ni
entropy_src’s rst_ni
flash_ctrl’s rst_ni
hmac’s rst_ni
keymgr’s rst_edn_ni
keymgr’s rst_ni
kmac’s rst_edn_ni
kmac’s rst_ni
otbn’s rst_edn_ni
otbn’s rst_ni
lc_ctrl’s rst_kmac_ni
otp_ctrl’s rst_edn_ni
rv_core_ibex’s rst_edn_ni
rv_core_ibex’s rst_ni
rv_plic’s rst_ni
sram_ctrl_main’s rst_ni
xbar_main’s rst_main_ni

`rst_sys_shadowed_d0`

Tests:

rstmgr_sys_shadowed_d0_aes_rst_shadowed_ni
rstmgr_sys_shadowed_d0_flash_ctrl_rst_shadowed_ni
rstmgr_sys_shadowed_d0_keymgr_rst_shadowed_ni
rstmgr_sys_shadowed_d0_kmac_rst_shadowed_ni

Verify rstmgr’s rst_sys_shadowed_n[1] is connected to the following:

aes’s rst_shadowed_ni
flash_ctrl’s rst_shadowed_ni
keymgr’s rst_shadowed_ni
kmac’s rst_shadowed_ni

`rst_sys_usb_d0`

Test: rstmgr_sys_usb_d0_xbar_main_rst_usb_ni

Verify rstmgr’s rst_sys_usb_n[1] is connected to xbar_main’s rst_usb_ni.

`rst_usb_aon_d0`

Test: rstmgr_usb_aon_d0_usbdev_rst_aon_ni

Verify rstmgr’s rst_usb_aon_n[1] is connected to usbdev’s rst_aon_ni

`rst_usb_d0`

Test: rstmgr_usb_d0_usbdev_rst_ni

Verify rstmgr’s rst_usb_n[1] is connected to the following:

usbdev’s rst_ni

`rst_en_i2c0_d0`

Test: rstmgr_i2c0_d0_alert_2_rst_en

Verify rstmgr’s rst_en_o.i2c0[1] connects to alert_handler’s lpg_rst_en[2].

`rst_en_i2c1_d0`

Test: rstmgr_i2c1_d0_alert_3_rst_en

Verify rstmgr’s rst_en_o.i2c1[1] connects to alert_handler’s lpg_rst_en[3].

`rst_en_i2c2_d0`

Test: rstmgr_i2c2_d0_alert_4_rst_en

Verify rstmgr’s rst_en_o.i2c2[1] connects to alert_handler’s lpg_rst_en[4].

`rst_en_lc_d0`

Test: rstmgr_lc_d0_alert_19_rst_en

Verify rstmgr’s rst_en_o.lc[1] connects to alert_handler’s lpg_rst_en[19].

`rst_en_lc_io_div4_aon`

Tests:

rstmgr_lc_io_div4_aon_alert_11_rst_en
rstmgr_lc_io_div4_aon_alert_15_rst_en

Verify rstmgr’s rst_en_o.lc_io_div4[0] connects to the following:

alert_handler’s lpg_rst_en[11]
alert_handler’s lpg_rst_en[15]

`rst_en_lc_io_div4_d0`

Test: rstmgr_lc_io_div4_d0_alert_6_rst_en

Verify rstmgr’s rst_en_o.lc_io_div4[1] connects to alert_handler’s lpg_rst_en[6].

`rst_en_por_io_div4_d0`

Test: rstmgr_por_io_div4_d0_alert_10_rst_en

Verify rstmgr’s rst_en_o.por_io_div4[1] connects to alert_handler’s lpg_rst_en[10].

`rst_en_spi_host0_d0`

Test: rstmgr_spi_host0_d0_alert_7_rst_en

Verify rstmgr’s rst_en_o.spi_host0[1] connects to alert_handler’s lpg_rst_en[7].

`rst_en_spi_host1_d0`

Test: rstmgr_spi_host1_d0_alert_8_rst_en

Verify rstmgr’s rst_en_o.spi_host1[1] connects to alert_handler’s lpg_rst_en[8].

`rst_en_spi_device_d0`

Test: rstmgr_spi_device_d0_alert_1_rst_en

Verify rstmgr’s rst_en_o.spi_device[1] connects to alert_handler’s lpg_rst_en[1].

`rst_en_sys_d0`

Tests:

rstmgr_sys_d0_alert_18_rst_en
rstmgr_sys_d0_alert_20_rst_en
rstmgr_sys_d0_alert_21_rst_en

Verify rstmgr’s rst_en_o.sys[1] connects to the following:

alert_handler’s lpg_rst_en[18]
alert_handler’s lpg_rst_en[20]
alert_handler’s lpg_rst_en[21]

`rst_en_sys_io_div4_aon`

Tests:

rstmgr_sys_io_div4_aon_alert_12_rst_en
rstmgr_sys_io_div4_aon_alert_13_rst_en
rstmgr_sys_io_div4_aon_alert_14_rst_en
rstmgr_sys_io_div4_aon_alert_17_rst_en

Verify rstmgr’s rst_en_o.sys_io_div4[0] connects to the following:

alert_handler’s lpg_rst_en[12]
alert_handler’s lpg_rst_en[13]
alert_handler’s lpg_rst_en[14]
alert_handler’s lpg_rst_en[17]

`rst_en_sys_io_div4_d0`

Tests:

rstmgr_sys_io_div4_d0_alert_0_rst_en
rstmgr_sys_io_div4_d0_alert_5_rst_en
rstmgr_sys_io_div4_d0_alert_16_rst_en

Verify rstmgr’s rst_en_o.sys_io_div4[1] connects to the following:

alert_handler’s lpg_rst_en[0]
alert_handler’s lpg_rst_en[5]
alert_handler’s lpg_rst_en[16]

`rst_en_usb_d0`

Test: rstmgr_usb_d0_alert_9_rst_en

Verify rstmgr’s rst_en_o.usb[1] connects to alert_handler’s lpg_rst_en[9].

`rstmgr_crashdump`

Tests:

alert_handler_rstmgr_crashdump
rv_core_ibex_rstmgr_crashdump

Verify that the Ibex and alert_handler crashdump outputs are correctly connected to the rstmgr.

`otp_ctrl_external_voltage`

Test: otp_ext_volt

Verify the connectivity between the external voltage pad and otp_ctrl.

`flash_ctrl_test_voltage`

Test: flash_test_volt

Verify the connectivity between the test voltage pad and flash_ctrl.

`flash_ctrl_test_mode`

Tests:

flash_test_mode0
flash_test_mode1

Verify the connectivity between the test mode pads and flash_ctrl.

`ast_adc`

Tests:

ast_cc1
ast_cc2

Verify the connectivity between the CC pads and the ast ADC input.

`chip_sw_adc_ctrl_debug_cable_irq`

Test: chip_sw_adc_ctrl_sleep_debug_cable_wakeup

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.

`chip_sw_adc_ctrl_sleep_debug_cable_wakeup`

Test: chip_sw_adc_ctrl_sleep_debug_cable_wakeup

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.

`chip_sw_aes_enc`

Tests:

chip_sw_aes_enc
chip_sw_aes_enc_jitter_en

Verify the AES operation.

Procedure: -Set up the desired operation, ECB mode, 256b key length, and set the engine to manual operation. Set mask_reseeding to 1 per block. -Trigger the encryption by loading the plaintext. -Wait for the AES operation to complete by polling the status register and read the result.

-The above procedure should be performed twice. First for encryption. Second for decryption of the result using the same key. -Check that the decryption result matches the original plaintext.

`chip_sw_aes_multi_block`

No Tests Implemented

Verify the AES operations on multi-block messages. This test should be performed for all supported modes (ECB, CBC, CFB-128, OFB and CTR) and all supported key lengths (128/192/256).

Note: The number of message blocks has to be at least 4.

Note: AES should start this test using the automatic (default) operation. This means that the MANUAL_OPERATION bit in CTRL_SHADOWED register is set to 0.

Procedure: -Configure the desired operation, mode, key length, and set the engine to automatic operation. Configure the IV for modes that require it. -Using dif_aes_start() and dif_aes_process_data(), encrypt the message. -Check the output for correctness against the expected value.

-The above procedure should be performed twice. First for encryption. Second for decryption of the result using the same key (and same IV if needed). -Check that the decryption result matches the original plaintext.

`chip_sw_aes_interrupt_encryption`

No Tests Implemented

Verify that a multi-block encryption can be interrupted and continued.

This test should:

start the encryption of a four-block message.
interrupt it after two blocks by reading back the IV register.
perform an encryption of a different message using a different key.
re-store and complete the original encryption

Note: AES should start this test using the automatic (default) operation. This means that the MANUAL_OPERATION bit in CTRL_SHADOWED register is set to 0.

Procedure: -Configure encryption using the desired mode, key length, IV, and set the engine to automatic operation. -Using dif_aes_process_data, encrypt the first two blocks. -Using dif_aes_read_iv read the IV. Note that AES has automatically updated the content of this register. This IV will be needed later to continue this encryption. -De-initialize automatic operation. This step is necessary to clear all registers. -Perform an encryption using a different data and key. Message size, key size and mode can be chosen arbitrarily. -Continue the original encryption: -Configure the operation using the previously read IV -Process the remaining plaintext blocks using dif_aes_process_data -Decrypt the result (using the original key and IV) -Check that the decryption result matches the original plaintext.

`chip_sw_aes_entropy`

Test: chip_sw_aes_entropy

Verify the AES entropy input used by the internal PRNGs.

Configure encryption using the CBC mode, key length 256, and set the engine to manual operation.
Write the initial key share, IV and data in CSRs (known combinations).
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 ciphertext 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.

`chip_sw_aes_prng_reseed`

No Tests Implemented

Verify that the AES module halts when a PRNG reseed is required but the entropy complex is disabled, and resumes encryption once the entropy complex is re-enabled.

Procedure:

After proper initialization of the AES and entropy modules, configure the AES encryption operation to process a number of blocks with:
- Operation: Encrypt
- Mode: ECB
- Key Length: 128 bits
- Key Provider: Software-provided key
- Manual Operation: Disabled (Automatic operation)
- Mask Reseeding: Reseed per 64 blocks (kDifAesReseedPer64Block)
- Reseed on Key Change: Enabled
- Force Masks: Disabled
Generate AES key.
Initialize the AES module and start the AES operation using dif_aes_start().
Process blocks using the following steps:
- Disable entropy for a block fewer than 64.
- For each block,
  - Continue encrypting blocks (fewer than 64 blocks)
  - Once processing reaches the block where the entropy complex is disabled
    - Disable the entire entropy complex using entropy_testutils_stop_all().
    - This will halt the AES module when a PRNG reseed is required (i.e after 64 blocks).
  - Re-enable the entropy complex to resume encryption:
    - Verify that the AES module is halted by checking that kDifAesStatusOutputValid is not set for the 63rd block
    - Re-enable the entropy complex using entropy_testutils_auto_mode_init().
    - Wait for some time for the entropy complex to stabilize.
    - Wait for the AES module to produce output valid (kDifAesStatusOutputValid).
    - Read the encrypted output data using dif_aes_read_output().
Finish the AES encryption operation by calling dif_aes_end().
Verify that the AES module is idle at the end of the encryption operation (kDifAesStatusIdle).
Repeat the test for a reseed rate kDifAesReseedPer8kBlock and a message longer than 8K blocks.

Expected Outcome:

The AES module halts when a PRNG reseed is required but the entropy complex is disabled.
After re-enabling the entropy complex, the AES module resumes encryption and produces the expected output.
The test verifies that the AES module correctly handles halting and resuming based on the availability of entropy and the configured mask reseeding rate.

`chip_sw_aes_force_prng_reseed`

No Tests Implemented

Verify that the AES module stalls/halts when the entropy complex is disabled before starting encryption and enables output of encryption once the entropy complex is re-enabled.

Procedure:

After proper initialization of AES and entropy modules, disable the entire entropy complex using entropy_testutils_stop_all().
- Configure the AES encryption operation to process some number of blocks with:
  - Operation: Encrypt
  - Mode: ECB
  - Key Length: 128 bits
  - Key Provider: Software-provided key
  - Manual Operation: Enabled
  - Mask Reseeding: Reseed per block
  - Reseed on Key Change: Enabled (When KEY_TOUCH_FORCES_RESEED is set, the PRNG reseed is triggered every time a key changes)
  - Force Masks: Enabled
- Generate AES key.
- At this point dif_aes_start() will write the key register which will trigger reseed request.
- This request will stall the output of the encrypted data until entropy is re-enabled.
- Verify that the AES module is halted by checking that kDifAesStatusOutputValid is not set.
- Re-enable the entropy complex using entropy_testutils_auto_mode_init().
- Wait for some time for the entropy complex to stabilize.
- Wait for the AES module to produce output valid (kDifAesStatusOutputValid).
- Read the encrypted output data using dif_aes_read_output().
- Process all the blocks and ensure AES completes encryption operation.
  - Verify that the AES module is idle at the end of encryption operation (kDifAesStatusIdle).
Expected Outcome:
- The AES module halts output when the entropy complex is disabled before starting encryption.
- After re-enabling the entropy complex, the AES module resumes encryption and produces the expected output.
- The test verifies that the AES module correctly handles halting and resuming based on the availability of entropy.

`chip_sw_aes_idle`

Test: chip_sw_aes_idle

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.

`chip_sw_aes_sideload`

Test: chip_sw_keymgr_sideload_aes

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.

`chip_sw_alert_handler_alerts`

Test: chip_sw_alert_test

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.

Note for silicon validation:

Ensure this test makes no alterations to OTP (use NMI escalation path).

`chip_sw_alert_handler_escalations`

Test: chip_sw_alert_handler_escalation

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.
- This cannot be checked in sival as the handshake signals cannot be directly observed.

`chip_sw_alert_handler_escalation_nmi_reset`

No Tests Implemented

Verify NMI and reset alert escalation paths.

Program the alert classes to only use escalation signals 0 and 3 (NMI interrupt and chip reset)
Verify the first escalation of an alert results in NMI interrupt serviced by the CPU.
Verify the second escalation of an alert results in a chip reset.
It is critical this test does not trigger escalation signals 1 and 2 as these result in an OTP mutate that puts the chips in an unrecoverable SCRAP state.
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.

`chip_sw_alert_handler_escalation_methods`

No Tests Implemented

Verify the different escalation trigger methods

For each escalation class, verify the escalation occurs (just the first stage, NMI escalation) with all of the possible trigger methods.

Escalation triggered when the number of alerts seen in the class is greater than the threshold
Escalation triggered when initial interrupt isn’t acknowledged within the timeout

`chip_sw_all_escalation_resets`

Test: chip_sw_all_escalation_resets

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. SiVal: It is not possible to trigger internal integrity errors.

`chip_sw_alert_handler_irqs`

Tests:

chip_plic_all_irqs_0
chip_plic_all_irqs_10
chip_plic_all_irqs_20

Verify all classes of alert handler interrupts to the CPU.

X-ref’ed with the automated PLIC test.

`chip_sw_alert_handler_entropy`

Test: chip_sw_alert_handler_entropy

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. SiVal: This test is not necessary:
We cannot explicitly detect an EDN request.
There are plenty of tests checking ping behavior.

`chip_sw_alert_handler_crashdump`

Test: chip_sw_rstmgr_alert_info

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.

`chip_sw_alert_handler_ping_timeout`

Test: chip_sw_alert_handler_ping_timeout

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.

`chip_sw_alert_handler_lpg_sleep_mode_alerts`

Test: chip_sw_alert_handler_lpg_sleep_mode_alerts

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.
Fatal alerts from flash_ctrl, otp_ctrl, sram_ctrl, and lc_ctrl are omitted because they disable the CPU and require a reset for the system to continue to function.

`chip_sw_alert_handler_lpg_sleep_mode_pings`

Test: chip_sw_alert_handler_lpg_sleep_mode_pings

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.

`chip_sw_alert_handler_lpg_clock_off`

Test: chip_sw_alert_handler_lpg_clkoff

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.

`chip_sw_alert_handler_lpg_reset_toggle`

Test: chip_sw_alert_handler_lpg_reset_toggle

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.

`chip_sw_alert_handler_ping_ok`

Test: chip_sw_alert_handler_ping_ok

Verify alert ping mechanism doesn’t trigger spurious alerts.

Check that the alert handler ping mechanism doesn’t trigger any unexpected NMI interrupts once enabled.

Ping timeout calculation See timout calcuations described in the chip_sw_alert_handler_reverse_ping_in_deep_sleep test.

Procedure

On POR reset:
- Enable an alert and assign it to to ClassA.
- Set escalation configuration to trigger before test wake up time.
- Set ping timeout to 0x100
- Lock alert configuration and enable ping mechanism.
- Wait for polling counters to cycle through by busy polling on Ibex for 5 milliseconds.
- Check there are no alert_handler NMI interrupts triggered.

`chip_sw_alert_handler_reverse_ping_in_deep_sleep`

Test: chip_sw_alert_handler_reverse_ping_in_deep_sleep

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.

`chip_sw_aon_timer_wakeup_irq`

Test: chip_sw_aon_timer_irq

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.

`chip_sw_aon_timer_sleep_wakeup`

Test: chip_sw_pwrmgr_smoketest

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.

`chip_sw_aon_timer_wdog_bark_irq`

Test: chip_sw_aon_timer_irq

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.

`chip_sw_aon_timer_wdog_bite_reset`

Test: chip_sw_aon_timer_wdog_bite_reset

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.

`chip_sw_aon_timer_sleep_wdog_bite_reset`

Test: chip_sw_aon_timer_wdog_bite_reset

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.

`chip_sw_aon_timer_sleep_wdog_sleep_pause`

Test: chip_sw_aon_timer_sleep_wdog_sleep_pause

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.

`chip_sw_aon_timer_wdog_lc_escalate`

Test: chip_sw_aon_timer_wdog_lc_escalate

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.

`chip_sw_clkmgr_idle_trans`

Tests:

chip_sw_aes_idle
chip_sw_hmac_enc_idle
chip_sw_kmac_idle
chip_sw_otbn_randomness

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.

SiVal: CPU must be enabled, but no other OTP or lifecycle dependencies. This tests already run in CW310.

`chip_sw_clkmgr_off_trans`

Tests:

chip_sw_clkmgr_off_aes_trans
chip_sw_clkmgr_off_hmac_trans
chip_sw_clkmgr_off_kmac_trans
chip_sw_clkmgr_off_otbn_trans

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, verify the rstmgr crash dump info records the CSR address, and the execution pc is close enough to the address that performs the hung access.

SiVal: CPU must be enabled, but no other OTP or lifecycle dependencies. This tests already run in CW310.

`chip_sw_clkmgr_off_peri`

Test: chip_sw_clkmgr_off_peri

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, and the execution pc is close enough to the address that performs the hung access.

SiVal: CPU must be enabled, but no other OTP or lifecycle dependencies. This tests already run in CW310.

`chip_sw_clkmgr_div`

Tests:

chip_sw_ast_clk_outputs
chip_sw_clkmgr_external_clk_src_for_sw_fast_test_unlocked0
chip_sw_clkmgr_external_clk_src_for_sw_slow_test_unlocked0
chip_sw_clkmgr_external_clk_src_for_sw_fast_dev
chip_sw_clkmgr_external_clk_src_for_sw_slow_dev
chip_sw_clkmgr_external_clk_src_for_sw_fast_rma
chip_sw_clkmgr_external_clk_src_for_sw_slow_rma

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.

SiVal: These tests should be run after clock calibration is completed. Any LC cycle stage after calibration is done.

`chip_sw_clkmgr_external_clk_src_for_lc`

Test: chip_sw_clkmgr_external_clk_src_for_lc

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. SiVal: This is implicitly tested by the success of OTP updates for calibration.

`chip_sw_clkmgr_external_clk_src_for_sw`

Tests:

chip_sw_clkmgr_external_clk_src_for_sw_fast_dev
chip_sw_clkmgr_external_clk_src_for_sw_slow_dev

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

In DEV, TEST_UNLOCKED, and RMA 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.

Disable external clock source and verify the AST reliably falls back to the internal clock. Ensure the chip operates normally. X-ref with chip_sw_uart_tx_rx_alt_clk_freq, which needs to deal with this as well. SiVal: The only necessary test is that the internal clocks are running with the right frequency after calibration. There are a few such tests already.

`chip_sw_clkmgr_jitter`

Tests:

chip_sw_clkmgr_jitter
chip_sw_flash_ctrl_ops_jitter_en
chip_sw_flash_ctrl_access_jitter_en
chip_sw_otbn_ecdsa_op_irq_jitter_en
chip_sw_aes_enc_jitter_en
chip_sw_hmac_enc_jitter_en
chip_sw_keymgr_key_derivation_jitter_en
chip_sw_kmac_mode_kmac_jitter_en
chip_sw_sram_ctrl_scrambled_access_jitter_en
chip_sw_edn_entropy_reqs_jitter

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.

If jitter_regwen is enabled check that jitter_enable can be toggled. If jitter_regwen is disabled check that jitter_enable cannot be changed. X-ref with various specific jitter enable tests. SiVal: CPU must be enabled, but no other OTP or lifecycle dependencies.

`chip_sw_clkmgr_extended_range`

Tests:

chip_sw_clkmgr_jitter_reduced_freq
chip_sw_flash_ctrl_ops_jitter_en_reduced_freq
chip_sw_flash_ctrl_access_jitter_en_reduced_freq
chip_sw_otbn_ecdsa_op_irq_jitter_en_reduced_freq
chip_sw_aes_enc_jitter_en_reduced_freq
chip_sw_hmac_enc_jitter_en_reduced_freq
chip_sw_keymgr_key_derivation_jitter_en_reduced_freq
chip_sw_kmac_mode_kmac_jitter_en_reduced_freq
chip_sw_sram_ctrl_scrambled_access_jitter_en_reduced_freq
chip_sw_flash_init_reduced_freq
chip_sw_csrng_edn_concurrency_reduced_freq

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 SiVal: This can be executed if we detect problems running at nominal frequencies. It may be implemented as the system running specific tests with an external cLock. No specific work may be needed other than configuring external clocks.

`chip_sw_clkmgr_deep_sleep_frequency`

Test: chip_sw_ast_clk_outputs

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.

`chip_sw_clkmgr_sleep_frequency`

Test: chip_sw_clkmgr_sleep_frequency

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. SiVal: CPU must be enabled, but no other OTP or lifecycle dependencies. This tests already run in CW310.

`chip_sw_clkmgr_reset_frequency`

Test: chip_sw_clkmgr_reset_frequency

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. SiVal: CPU must be enabled and clocks must be calibrated, but no other OTP or lifecycle dependencies. This tests already run in CW310.

`chip_sw_clkmgr_escalation_reset`

Test: chip_sw_all_escalation_resets

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. SiVal: This is tested by other unit’s escalation tests. They will need to add extra checks for specific units having been reset.

`chip_sw_clkmgr_alert_handler_clock_enables`

Test: chip_sw_alert_handler_lpg_clkoff

Verify the clock manager sends the correct information to the alert handler regarding individual clocks being active so it can ignore missing ping responses from them and avoid triggering spurious escalation. This scenario is caused by peripheral and transactional clocks being disabled among others. The check is that spurious escalation is not triggered. SiVal: CPU must be enabled, but no other OTP or lifecycle dependencies. This tests already run in CW310.

`chip_sw_csrng_edn_cmd`

Test: chip_sw_entropy_src_csrng

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.

Notes for silicon targets:

In silicon, the connectivity cannot be checked using assertions. However, checking that the OTBN randomness test finishes allows to quickly assess if both EDNs deliver any entropy which is very fundamental.

`chip_sw_csrng_fuse_en_sw_app_read`

Test: chip_sw_csrng_fuse_en_sw_app_read_test

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.

Notes for silicon targets:

The current understanding is that the en_csrng_sw_app_read OTP switch controlling the CSRNG.READ_INT_STATE feature will need to be enabled also in the PROD life-cycle state for validation and known-answer testing. Thus, burning the en_csrng_sw_app_read OTP fuses is not advisable for silicon validation.

`chip_sw_csrng_lc_hw_debug_en`

Test: chip_sw_csrng_lc_hw_debug_en_test

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 in non-deterministic mode and have it load the known entropy from ENTROPY_SRC while in the TEST_UNLOCKED or DEV life-cycle 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 PROD_END life-cycle state (HW_DEBUG_EN = 0).
Again configure ENTROPY_SRC to bypass the conditioner and use direct injection.
Again instantiate CSRNG in non-deterministic mode and have it load the known entropy from ENTROPY_SRCw while in the new state.
The newly fetched entropy and the old entropy stored in flash should not match.

Notes for silicon targets:

This test goes through life-cycle stages that will permanently change the characteristic of the chip.
These tests will need to be done in secure environments where there is access to chips in the TEST_UNLOCKED or DEV life-cycle states.

`chip_sw_csrng_known_answer_tests`

Test: chip_sw_csrng_kat_test

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

Configure the software instance in deterministic mode with the expected seed (as per the NIST-specified test for CTR_DRBG operation). Read the DRBG internal K and V state using INT_STATE_VAL register and compare the obtained values against the test vector expected values.
Perform generate operations as required by the test vector.
Compare the results to test expectations.

Notes for silicon targets:

For the INT_STATE_VAL register to provide read access to the internal K and V state, the en_csrng_sw_app_read OTP switch needs to be in the kMultiBitBool8True position. The current understanding is that this will need to be enabled also in the PROD life-cycle state for validation and known-answer testing. Thus, the test doesn’t need to be run in a secure environment.

`chip_sw_edn_entropy_reqs`

Tests:

chip_sw_edn_entropy_reqs
chip_sw_csrng_edn_concurrency
chip_sw_entropy_src_ast_rng_req

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 requests entropy from EDN.

`chip_sw_entropy_src_ast_rng_req`

Test: chip_sw_entropy_src_ast_rng_req

Verify the RNG req to AST.

Enable ENTROPY_SRC in FIPS mode.
Enable Firmware Override - Extract & Insert to route entropy received from AST to the observe FIFO.
Verify that the observe 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.

Notes for silicon targets:

This test requires access to the ENTROPY_SRC.FW_OV.EXTRACT_AND_INSERT feature, which is gated by OTP. This test might thus need to be done in a secure facility.
In silicon, it’s not possible to check whether the values match. However, checking that the observe FIFO actually fills up is a very fundamental test prior to the validation testing.

`chip_sw_entropy_src_csrng`

Test: chip_sw_entropy_src_csrng

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.

`chip_sw_entropy_src_fuse_en_fw_read`

Test: chip_sw_entropy_src_fuse_en_fw_read_test

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 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.

Notes for silicon targets:

The current understanding is that the en_entropy_src_fw_read OTP switch controlling the ENTROPY_SRC.ROUTE_TO_FIRMWARE feature will need to be enabled also in the PROD life-cycle state for validation and known-answer testing. Thus, burning the en_entropy_src_fw_read OTP fuses is not advisable for silicon validation. This particular test may be skipped in favor of chip_sw_entropy_src_known_answer_tests which also tests the ENTROPY_SRC.ROUTE_TO_FIRMWARE feature.

`chip_sw_entropy_src_known_answer_tests`

Test: chip_sw_entropy_src_kat_test

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

Enable ENTROPY_SRC in FIPS mode.
Enable Firmware Override - Extract & Insert.
Feed NIST test-defined entropy sequences into ENTROPY_SRC via the FW_OV_WR_DATA register.
Trigger the hardware conditioner.
Read the conditioned entropy from ENTROPY_SRC via the ENTROPY_DATA register; verify that it reads the expected values.

Notes for silicon targets:

This test requires access to the ENTROPY_SRC.ROUTE_TO_FIRMWARE and ENTROPY_SRC.FW_OV.EXTRACT_AND_INSERT features, which are gated by OTP. This test might thus need to be done in a secure facility.

`chip_sw_entropy_src_fw_observe_many_contiguous`

No Tests Implemented

Verify that the software can observe samples fast enough to extract many contiguous samples.

Procedure:

Disable the entropy complex.
Disable health checks.
Enable ENTROPY_SRC in FIPS mode
Enable Firmware Override - Observe.
Repeat several times:
- Collect 1000 contiguous samples from the observe FIFO:
  - Verify after reading each sample that the observe FIFO overflow status has not been set.
- Let the observe FIFO overflow.
- Drain the observe FIFO.

Tests:

The procedure must be run once with ENTROPY_SRC.RNG_BIT_ENABLE disabled (4-bit / sample) and four times with the ENTROPY_SRC.RNG_BIT_ENABLE feature being enabled (once for every channel).

Notes for silicon targets:

This test requires access to the ENTROPY_SRC.FW_OV.OBSERVE feature, which is gated by OTP. This test might thus need to be done in a secure facility.

`chip_sw_entropy_src_fw_extract_and_insert`

No Tests Implemented

Verify that the software can observe samples fast enough to extract many contiguous samples.

Procedure:

Disable the entropy complex.
Disable health checks.
Enable ENTROPY_SRC in FIPS mode.
Configure OBSERVE_FIFO_THRESH to a sensible value.
Enable Firmware Override - Extract & Insert.
Enable CSRNG.
Enable both EDNs in auto request mode.
Trigger the execution of various cryptographic hardware blocks consuming entropy to stress test the entropy complex.
Repeat until all entropy consuming endpoints have finished their operations:
- Read 1000 samples from the observe FIFO.
- Verify that the observe FIFO overflow status has not been set.
- Insert the samples back into the entropy flow.
- Let the observe FIFO overflow.
- Empty the observe FIFO and discard any values read.

Tests:

The procedure must be run once with ENTROPY_SRC.RNG_BIT_ENABLE disabled (4-bit / sample) and four times with the ENTROPY_SRC.RNG_BIT_ENABLE feature being enabled (once for every channel).
The procedure must be tested with and without the conditioner (bypass mode).
The procedure must be tested with a significant delay added between extracting and inserting the entropy.
The procedure must be tested with a diablement and a re-enablement of ENTROPY_SRC.
- To this end, ENTROPY_SRC must be disabled after it has produced entropy.
- Whenever CSRNG has an outstanding entropy request ENTROPY_SRC can be enabled again.

Notes for silicon targets:

This test requires access to the ENTROPY_SRC.ROUTE_TO_FIRMWARE and ENTROPY_SRC.FW_OV.EXTRACT_AND_INSERT features, which are gated by OTP. This test might thus need to be done in a secure facility.

`chip_sw_flash_init`

Test: chip_sw_flash_init

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.
In silicon, this will be covered by manuf_ft_provision_rma_token_and_personalization.

`chip_sw_flash_host_access`

Tests:

chip_sw_flash_ctrl_access
chip_sw_flash_ctrl_access_jitter_en

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.

`chip_sw_flash_ctrl_ops`

Tests:

chip_sw_flash_ctrl_ops
chip_sw_flash_ctrl_ops_jitter_en

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.

`chip_sw_flash_rma_unlocked`

Test: chip_sw_flash_rma_unlocked

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.

`chip_sw_flash_scramble`

Test: chip_sw_flash_init

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.

`chip_sw_flash_idle_low_power`

Test: chip_sw_flash_ctrl_idle_low_power

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.

`chip_sw_flash_keymgr_seeds`

Test: chip_sw_keymgr_key_derivation

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.

`chip_sw_flash_lc_creator_seed_sw_rw_en`

Test: chip_sw_flash_ctrl_lc_rw_en

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.

In silicon, we cannot transition the chip or check this signal. The accessibility of the partition should still be checked in each of the relevant LC states.

`chip_sw_flash_creator_seed_wipe_on_rma`

Test: chip_sw_flash_rma_unlocked

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

`chip_sw_flash_lc_owner_seed_sw_rw_en`

Test: chip_sw_flash_ctrl_lc_rw_en

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.

In silicon, we cannot transition the chip or check this signal. The accessibility of the partition should still be checked in each of the relevant LC states.

`chip_sw_flash_lc_iso_part_sw_rd_en`

Test: chip_sw_flash_ctrl_lc_rw_en

Verify the lc_iso_part_sw_rd_en signal from LC ctrl.

Transition from DEV or 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.

In silicon, we cannot transition the chip or check this signal. The accessibility of the partition should still be checked in each of the relevant LC states.

`chip_sw_flash_lc_iso_part_sw_wr_en`

Test: chip_sw_flash_ctrl_lc_rw_en

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.

In silicon, we cannot transition the chip or check this signal. The accessibility of the partition should still be checked in each of the relevant LC states.

`chip_sw_flash_lc_seed_hw_rd_en`

Test: chip_sw_flash_ctrl_lc_rw_en

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.
In silicon, this will be covered by manuf_ft_provision_rma_token_and_personalization.

`chip_sw_flash_lc_escalate_en`

Test: chip_sw_all_escalation_resets

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.

`chip_sw_flash_prim_tl_access`

Test: chip_prim_tl_access

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.

`chip_sw_flash_ctrl_clock_freqs`

Test: chip_sw_flash_ctrl_clock_freqs

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.

`chip_sw_flash_ctrl_escalation_reset`

Test: chip_sw_flash_crash_alert

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.

`chip_sw_flash_ctrl_write_clear`

Test: chip_sw_flash_crash_alert

Verify the flash is able to process a second write to clear all bits when ECC is enabled.

Configure memory protected entries to override the default flash configuration as follows:

ECC enabled, scrambling and high endurance disabled.
ECC and high endurance enabled, scrambling disabled.

Test the following sequence:

Set one of the configuration options above.
Erase target page.
Write and verify intermediate value, different than all 1s or 0s.
Write and verify all 0s.

The flash should not throw any errors on the second write.

Note: The hardware does not support this behavior when scrambling is enabled.

`chip_sw_hmac_enc`

Tests:

chip_sw_hmac_enc
chip_sw_hmac_enc_jitter_en

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.

`chip_sw_hmac_idle`

Test: chip_sw_hmac_enc_idle

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.

`chip_sw_hmac_all_configurations`

Test: chip_sw_hmac_oneshot

Verify HMAC 256/384 and 512 modes of operation.

Verify the following security configurations for 6 hardcoded vectors:
- SHA2-256
- SHA2-384
- SHA2-512
- HMAC-SHA2-256
- HMAC-SHA2-384
- HMAC-SHA2-512
Use endianness configuration used in the crypto library.

`chip_sw_hmac_multistream_mode`

Test: chip_sw_hmac_multistream

Verify HMAC context save/restore functionality.

Verify that HMAC block can stream 6 SHA-2/HMAC operations in parallel:
- One test vector for each configuration:
  - SHA2-256
  - SHA2-384
  - SHA2-512
  - HMAC-SHA2-256
  - HMAC-SHA2-384
  - HMAC-SHA2-512
- For each vector, message input is split into two chunks, and each operation is completed with 2 update calls.
  - Initiate all 6 operations.
  - Feed the first message chunk to each stream, by resuming, updating and removing context for each operation.
  - Once all streams receive their first chunk, then feed their second message chunk similarly.
  - Once all streams receive all their message inputs, then finalize them in a loop and check their result.

`chip_sw_i2c_host_tx_rx`

Tests:

chip_sw_i2c_host_tx_rx
chip_sw_i2c_host_tx_rx_idx1
chip_sw_i2c_host_tx_rx_idx2

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 SW reads back the payload from the testbench 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.

Notes for silicon targets:

The testbench in this case will be a device that physically toggles/inspects the appropriate SCL and SDA lines.

`chip_sw_i2c_device_tx_rx`

Test: chip_sw_i2c_device_tx_rx

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.

Notes for silicon targets:

The testbench in this case will be a device that physically toggles/inspects the appropriate SCL and SDA lines.

`chip_sw_keymgr_key_derivation`

Tests:

chip_sw_keymgr_key_derivation
chip_sw_keymgr_key_derivation_jitter_en

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. (Adopt this approach.)

X-ref’ed with kmac test.

`chip_sw_keymgr_sideload_kmac`

Test: chip_sw_keymgr_sideload_kmac

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 keymgr’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.
In simulation environments, verify the digest for correctness (should match the DV-side result again).

Notes for silicon targets:

The device needs to be personalized before the test can be executed. See manuf_ft_provision_rma_token_and_personalization for more details.
Sideload is expected to work in the following keymgr states: CreatorRootKey, OwnerIntKey and OwnerKey. The test program should try to cover as many states as possible given the initial device state.
Key derivations must be reproducible across boot cycles during regular operating conditions.

X-ref’ed with chip_kmac_app_keymgr test.

For SV2 X-ref’ed with chip_sw_kmac_kmac_key_sideload.

`chip_sw_keymgr_sideload_aes`

Test: chip_sw_keymgr_sideload_aes

Verify the keymgr sideload interface to AES.

Same as chip_keymgr_sideload_kmac, except, sideload to AES.

`chip_sw_keymgr_sideload_otbn`

Test: chip_sw_keymgr_sideload_otbn

Verify the keymgr sideload interface to OTBN.

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

Clear the sideload key once done.

`chip_sw_kmac_enc`

Tests:

chip_sw_kmac_mode_cshake
chip_sw_kmac_mode_kmac
chip_sw_kmac_mode_kmac_jitter_en

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.

`chip_sw_kmac_app_keymgr`

Test: chip_sw_keymgr_key_derivation

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.

`chip_sw_kmac_app_lc`

Test: chip_sw_lc_ctrl_transition

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.

`chip_sw_kmac_app_rom`

Test: chip_sw_kmac_app_rom

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.

`chip_sw_kmac_entropy`

Test: chip_sw_kmac_entropy

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.

`chip_sw_kmac_idle`

Test: chip_sw_kmac_idle

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).

`chip_sw_lc_ctrl_alert_handler_escalation`

Test: chip_sw_alert_handler_escalation

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.

In silicon and FPGA test targets, verify that the device debug interfaces are not accessible when testing in TEST_UNLOCKED, DEV or RMA states.

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.

`chip_sw_lc_ctrl_jtag_access`

Tests:

chip_tap_straps_dev
chip_tap_straps_prod
chip_tap_straps_rma

Verify enable to access LC ctrl via JTAG.

Using the JTAG agent, write and read LC ctrl CSRs, verify the read value for correctness. Repeat test with clk_ext configuration.

`chip_sw_lc_ctrl_otp_hw_cfg0`

Test: chip_sw_lc_ctrl_otp_hw_cfg0

Verify the device_ID and ID_state CSRs.

Preload the hw_cfg0 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.

In silicon and FPGA targets, verify that the DeviceID read via JTAG matches the value read from Ibex.

`chip_sw_lc_ctrl_init`

Test: chip_sw_lc_ctrl_transition

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.

`chip_sw_lc_ctrl_transitions`

Test: chip_sw_lc_ctrl_transition

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. X-ref’ed manuf_cp_unlock_raw X-ref’ed manuf_cp_test_lock X-ref’ed manuf_ft_exit_token

`chip_sw_lc_ctrl_kmac_req`

Test: chip_sw_lc_ctrl_transition

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. X-ref’ed manuf_cp_unlock_raw X-ref’ed manuf_cp_test_lock X-ref’ed manuf_ft_exit_token X-ref’ed manuf_rma_entry

`chip_sw_lc_ctrl_key_div`

Test: chip_sw_keymgr_key_derivation_prod

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.

`chip_sw_lc_ctrl_broadcast`

Tests:

chip_prim_tl_access
chip_tap_straps_dev
chip_tap_straps_prod
chip_tap_straps_rma
chip_sw_rom_ctrl_integrity_check
chip_sw_clkmgr_external_clk_src_for_sw_fast_test_unlocked0
chip_sw_clkmgr_external_clk_src_for_sw_slow_test_unlocked0
chip_sw_clkmgr_external_clk_src_for_sw_fast_dev
chip_sw_clkmgr_external_clk_src_for_sw_slow_dev
chip_sw_clkmgr_external_clk_src_for_sw_fast_rma
chip_sw_clkmgr_external_clk_src_for_sw_slow_rma
chip_sw_sram_ctrl_execution_main
chip_rv_dm_lc_disabled
chip_sw_keymgr_key_derivation
chip_sw_clkmgr_external_clk_src_for_lc
chip_sw_flash_rma_unlocked
chip_sw_lc_ctrl_transition
chip_sw_flash_ctrl_lc_rw_en
chip_sw_otp_ctrl_lc_signals_test_unlocked0
chip_sw_otp_ctrl_lc_signals_dev
chip_sw_otp_ctrl_lc_signals_prod
chip_sw_otp_ctrl_lc_signals_rma

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.

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)

`chip_lc_scrap`

Tests:

chip_sw_lc_ctrl_rand_to_scrap
chip_sw_lc_ctrl_raw_to_scrap
chip_sw_lc_ctrl_rma_to_scrap
chip_sw_lc_ctrl_test_locked0_to_scrap

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

`chip_lc_test_locked`

Tests:

chip_sw_lc_walkthrough_testunlocks
chip_rv_dm_lc_disabled

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

`chip_sw_lc_walkthrough`

Tests:

chip_sw_lc_walkthrough_dev
chip_sw_lc_walkthrough_prod
chip_sw_lc_walkthrough_prodend
chip_sw_lc_walkthrough_rma
chip_sw_lc_walkthrough_testunlocks

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.

`chip_sw_lc_ctrl_volatile_raw_unlock`

Tests:

chip_sw_lc_ctrl_volatile_raw_unlock
chip_sw_lc_ctrl_volatile_raw_unlock_ext_clk_48mhz
rom_volatile_raw_unlock

Configure VOLATILE_RAW_UNLOCK via LC TAP interface and enable CPU execution.

Pre-load OTP image with RAW lc_state.
Initiate the LC transition to test_unlocked0 state using the VOLATILE_RAW_UNLOCK mode of operation.

If this top-level is expected to support VOLATILE_RAW_UNLOCK:

As part of the transition to test_unlocked0, switch the TAP interface to rv_dm.
Enable ROM execution via rv_dm, and perform POR.
Initiate a second transition to test_unlocked0 using VOLATILE_RAW_UNLOCK.
Verify that the CPU is able to execute.
Test ext_clk injection before enabling ROM execution.

If this top-level is NOT expected to support VOLATILE_RAW_UNLOCK:

Check that the VOLATILE_RAW_UNLOCK bit in the transition control register stays 0 when it is programmed to 1.
Check that the transition results in a token error (the real RAW unlock transition expects the unhashed token instead of the hashed token supplied for volatile RAW unlock).

`chip_sw_otbn_isa`

No Tests Implemented

Run every OTBN instruction and check final state.

Utilizing the existing OTBN smoke test which uses every instruction
(hw/ip/otbn/dv/smoke/smoke_test.s). Check the final register state matches the
expected values (in hw/ip/otbn/dv/smoke/smoke_expected.txt). Check OTBN completed
successfully without errors. This will require a modified version of the smoke test
which dumps register state to memory.

Following the smoke test run a new program just to dump out the register state to
dmem, check the values do not match the previous values from the smoke test run to
ensure the internal state secure wipe has worked.

`chip_sw_otbn_op`

Tests:

chip_sw_otbn_ecdsa_op_irq
chip_sw_otbn_ecdsa_op_irq_jitter_en

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.

`chip_sw_otbn_rnd_entropy`

Test: chip_sw_otbn_randomness

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 consecutively do not match, and that no value is all 0s or all 1s, as a basic measure to ensure that the entropy subsystem is returning some data.

`chip_sw_otbn_urnd_entropy`

Test: chip_sw_otbn_randomness

Verify OTBN can fetch URND numbers from the entropy src.

Similar to chip_otbn_rnd_entropy, but verifies the URND bits.

`chip_sw_otbn_idle`

Test: chip_sw_otbn_randomness

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.

`chip_sw_otbn_mem_scramble`

Test: chip_sw_otbn_mem_scramble

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).

`chip_sw_otbn_keymgr`

No Tests Implemented

Check the OTBN keymgr connection is functional.

Setup the keymgr and any other blocks required to provide OTBN with a valid sideload key. Run an OTBN program to read the key via the KEY_S[0|1]_[H|L] WSRs and write it to dmem. Sanity check the returned value (e.g. != 0) and check OTBN completed successfully with no errors.

`chip_otp_ctrl_init`

Test: chip_sw_lc_ctrl_transition

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.

`chip_sw_otp_ctrl_keys`

Tests:

chip_sw_sram_ctrl_scrambled_access
chip_sw_flash_init
chip_sw_keymgr_key_derivation
chip_sw_otbn_mem_scramble
chip_sw_rv_core_ibex_icache_invalidate

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).
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 For sival, this test can be done by
manuf_ft_sku_individualization
manuf_ft_provision_rma_token_and_personalization

`chip_sw_otp_ctrl_entropy`

Tests:

chip_sw_sram_ctrl_scrambled_access
chip_sw_flash_init
chip_sw_keymgr_key_derivation
chip_sw_otbn_mem_scramble
chip_sw_rv_core_ibex_icache_invalidate

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. For sival, this test can be done by

manuf_ft_sku_individualization
manuf_ft_provision_rma_token_and_personalization

`chip_sw_otp_ctrl_program`

Test: chip_sw_lc_ctrl_transition

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. For sival, this test can be done by
manuf_ft_sku_individualization_preop

`chip_sw_otp_ctrl_program_error`

Test: chip_sw_lc_ctrl_program_error

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 and escalation when the OTP ctrl responds back with the correct fatal program error as expected.
Allow escalation to go through reset.
Use the rstmgr alert info and the fault CSRs to check the alert cause is right.
Keep state across resets in flash to check that no NMI or regular ISR interrupt run for kTopEarlgreyAlertIdLcCtrlFatalProgError.
Verify that, after escalation reset, the alert handler cause and the fault register are cleared.
Verify after the escalation reset that the alert info captured the correct alert. SiVal: Forcing this illegal condition is not feasible in sival.

`chip_sw_otp_ctrl_hw_cfg0`

Test: chip_sw_lc_ctrl_otp_hw_cfg0

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

Preload the OTP ctrl’s hw_cfg0 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. For sival, this test can be done by

manuf_ft_sku_individualization_preop

`chip_sw_otp_ctrl_lc_signals`

Tests:

chip_prim_tl_access
chip_sw_lc_ctrl_transition
chip_sw_otp_ctrl_lc_signals_test_unlocked0
chip_sw_otp_ctrl_lc_signals_dev
chip_sw_otp_ctrl_lc_signals_prod
chip_sw_otp_ctrl_lc_signals_rma

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.

`chip_sw_otp_prim_tl_access`

Test: chip_prim_tl_access

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.
For sival, this test can only run on opensource rtl in test_unlocked or rma state. Do random csr write and read back for RW type registers.

`chip_sw_otp_ctrl_dai_lock`

Test: chip_sw_otp_ctrl_dai_lock

Verify DAI lock functionality.

Try write/read through DAI accessible partitions.
Disable DAI by clearing the DIRECT_ACCESS_REGWEN register.
OTP data must not be accessible to software through DAI when it is disabled.

`chip_sw_pwrmgr_external_full_reset`

Test: chip_sw_pwrmgr_full_aon_reset

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. SiVal: This will be exercised without any special test, since all tests trigger POR when they start.

`chip_sw_pwrmgr_random_sleep_all_wake_ups`

Test: chip_sw_pwrmgr_random_sleep_all_wake_ups

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. SiVal: This test can do controllable variants of wakeup testing, provided we run enough cycles with suitable randomization. This can run in any lifecycle state with the corresponding OTP. This test will need the host side to trigger wakeups that use external pins. Note:

The sensor_ctrl wakeup is not necessarily controllable, or the ones that are will not trigger in sleep mode.

`chip_sw_pwrmgr_normal_sleep_all_wake_ups`

Test: chip_sw_pwrmgr_normal_sleep_all_wake_ups

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. SiVal: No need to run this, run chip_sw_pwrmgr_random_sleep_all_wake_ups instead.

`chip_sw_pwrmgr_deep_sleep_por_reset`

Test: chip_sw_pwrmgr_deep_sleep_por_reset

Verify POR in deep sleep mode.

This verifies that the pwrmgr can handle POR in deep sleep. The chip is placed in deep sleep, a POR is sent, and the wakeup cause is checked to be POR. This test is broken out of the all_reset_reqs tests since the retention sram is wiped on POR, so there is no state indicating the two PORs are any different. SiVal: The CPU must be running to configure lop power entry.

`chip_sw_pwrmgr_normal_sleep_por_reset`

Test: chip_sw_pwrmgr_normal_sleep_por_reset

Verify POR in normal sleep mode.

This verifies that the pwrmgr can handle POR in normal sleep. The chip is placed in normal sleep, a POR is sent, and the wakeup cause is checked to be POR. This test is broken out of the all_reset_reqs tests since the retention sram is wiped on POR, so there is no state indicating the two PORs are any different. SiVal: The CPU must be running to configure lop power entry.

`chip_sw_pwrmgr_deep_sleep_all_wake_ups`

Test: chip_sw_pwrmgr_deep_sleep_all_wake_ups

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. SiVal: No need to run this, run chip_sw_pwrmgr_random_sleep_all_wake_ups instead.

`chip_sw_pwrmgr_deep_sleep_all_reset_reqs`

Tests:

chip_sw_aon_timer_wdog_bite_reset
chip_sw_pwrmgr_deep_sleep_all_reset_reqs

Verify resets by relevant reset sources in deep sleep mode.

4 resets are generated with deep sleep mode
sysrst, wdog timer reset, rstmgr sw reset, and escalation reset Notice rstmgr sw reset cannot be triggered in sleep mode. Esc reset is triggered by pwrmgr ALERT_TEST.FATAL_FAULT CSR, configuring the alert handler so that the reset triggers after setting sleep mode. This verifies ALL programable or external 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 indicates the expected reset. SiVal: The CPU must be enabled to enter sleep mode. No need to run this, run chip_sw_pwrmgr_random_sleep_all_reset_reqs instead.

`chip_sw_pwrmgr_normal_sleep_all_reset_reqs`

Test: chip_sw_pwrmgr_normal_sleep_all_reset_reqs

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 SiVal: No need to run this, run chip_sw_pwrmgr_random_sleep_all_reset_reqs instead.

`chip_sw_pwrmgr_wdog_reset`

Test: chip_sw_pwrmgr_wdog_reset

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.

SiVal: CPU must be enabled, but no other OTP or lifecycle dependencies.

`chip_sw_pwrmgr_aon_power_glitch_reset`

Test: chip_sw_pwrmgr_full_aon_reset

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. SiVal: AON power glitch cannot be triggered at will.

`chip_sw_pwrmgr_main_power_glitch_reset`

Test: chip_sw_pwrmgr_main_power_glitch_reset

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. SiVal: Main power glitch cannot be triggered at will.

`chip_sw_pwrmgr_random_sleep_power_glitch_reset`

Test: chip_sw_pwrmgr_random_sleep_power_glitch_reset

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. SiVal: Main power glitch cannot be triggered at will.

`chip_sw_pwrmgr_deep_sleep_power_glitch_reset`

Test: chip_sw_pwrmgr_deep_sleep_power_glitch_reset

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. SiVal: Main power glitch cannot be triggered at will.

`chip_sw_pwrmgr_sleep_power_glitch_reset`

Test: chip_sw_pwrmgr_sleep_power_glitch_reset

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. SiVal: Main power glitch cannot be triggered at will.

`chip_sw_pwrmgr_random_sleep_all_reset_reqs`

Test: chip_sw_pwrmgr_random_sleep_all_reset_reqs

Verify resets by relevant reset sources in sleep modes.

4 resets are generated with normal and deep sleep mode each
sysrst, wdog timer reset, rstmgr sw reset, and escalation reset Notice rstmgr sw reset cannot be triggered in sleep mode. Esc reset is triggered by pwrmgr ALERT_TEST.FATAL_FAULT CSR, configuring the alert handler so that the reset triggers after setting sleep mode. This verifies ALL programable or external 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 indicates the expected reset. SiVal: The CPU must be enabled to enter sleep mode.

`chip_sw_pwrmgr_sysrst_ctrl_reset`

Tests:

chip_sw_pwrmgr_sysrst_ctrl_reset
chip_sw_pwrmgr_all_reset_reqs

Verify sysrst_ctrl and watchdog reset.

Read the reset cause register in rstmgr to confirm that the SW is in the POR reset phase.
Generate sysrst by driving input PAD.
After reset read the rstmgr reset_info CSR to confirm it indicates a sysrst reset.
Program the AON timer wdog to ‘bark’ after some time.
Let the bark escalate to bite, which should cause a reset.
After reset, read the rstmgr reset_info CSR to confirm it indicates a watchdog reset. SiVal: The pin that causes sysrst to reset needs to be pulsed from the host side. The chip_sw_all_resets is a superset of this testpoint.

`chip_sw_pwrmgr_b2b_sleep_reset_req`

Test: chip_sw_pwrmgr_b2b_sleep_reset_req

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.

`chip_sw_pwrmgr_sleep_disabled`

Test: chip_sw_pwrmgr_sleep_disabled

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.

SiVal: CPU must be enabled, but no other OTP or lifecycle dependencies.

`chip_sw_pwrmgr_escalation_reset`

Test: chip_sw_all_escalation_resets

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. SiVal: This is not suitable for sival, and the various reset tests that work in sival platforms cover escalation resets via writing to the alert_test, and setting the alert_handler to immediately trip escalation reset.

`chip_sw_rom_access`

Test: chip_sw_rom_ctrl_integrity_check

Verify that the CPU can access the rom contents.

Verify that the CPU can fetch instructions from the ROM.

`chip_sw_rom_ctrl_integrity_check`

Test: chip_sw_rom_ctrl_integrity_check

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.

Notes for silicon targets:

The only thing that this test can do at the SiVal stage is to ensure that the expected and measured digests are readable and have the values we expect.
That (simpler) check is done in the separate chip_sw_rom_ctrl_digests test, so this test doesn’t have any SiVal stage.

`chip_sw_rstmgr_non_sys_reset_info`

Tests:

chip_sw_pwrmgr_smoketest
chip_sw_pwrmgr_random_sleep_all_reset_reqs
chip_sw_pwrmgr_all_reset_reqs
chip_sw_pwrmgr_wdog_reset

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.

SiVal: This testpoint is exercised by a large number of existing reset cases, yet it would be best to develop a single test that issues all resets realizable by software, not on error injection. The requirement for this testpoint is to check the reset info is checked. CPU must be enabled, but no other OTP or lifecycle dependencies.

`chip_sw_rstmgr_sys_reset_info`

Test: chip_rv_dm_ndm_reset_req

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.

SiVal: CPU and debug must be enabled, so it only works in TEST_UNLOCKED, DEV, and RMA. The rv_dm is an important tool for SiVal, so the stage is set to SV2.

`chip_sw_rstmgr_cpu_info`

Test: chip_sw_rstmgr_cpu_info

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_sw_rstmgr_*sys_reset_info.

SiVal: CPU must be enabled, but no other OTP or lifecycle dependencies. This can be an important diagnostic tool, so setting it to SV1. This test already runs in CW310.

`chip_sw_rstmgr_sw_req_reset`

Test: chip_sw_rstmgr_sw_req

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.

SiVal: CPU must be enabled, but no other OTP or lifecycle dependencies. For early SiV we could rely on the external reset, so this seems SV3. This test already runs in CW310.

`chip_sw_rstmgr_alert_info`

Test: chip_sw_rstmgr_alert_info

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. Disable capture for some cases and make sure the alert info remains unchanged. Refer to chip_sw_rstmgr_*sys_reset_info.

SiVal: CPU must be enabled, but no other OTP or lifecycle dependencies. This can be an important diagnostic tool, so setting it to SV1.

`chip_sw_rstmgr_sw_rst`

Test: chip_sw_rstmgr_sw_rst

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*.

SiVal: CPU must be enabled, but no other OTP or lifecycle dependencies. This test already runs in CW310.

`chip_sw_rstmgr_escalation_reset`

Test: chip_sw_all_escalation_resets

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. In addition, set some CSR to its non-reset value and check it returns to its reset value after reset.

SiVal: Rather than relying on injecting fatal faults, escalation reset can be triggered by not responding to software induced alerts interrupts, and properly configuring the alert handler. CPU must be enabled, but no other OTP or lifecycle dependencies.

`chip_sw_rstmgr_alert_handler_reset_enables`

Test: chip_sw_alert_handler_lpg_reset_toggle

Verify the reset manager sends the correct information to the alert handler regarding individual resets being active so it can ignore missing ping responses from them and avoid triggering spurious escalation. This scenario is caused by software induced peripheral resets among others. The check is that spurious escalation is not triggered.

SiVal: CPU must be enabled, but no other OTP or lifecycle dependencies. This test already runs in CW310.

`chip_sw_nmi_irq`

Test: chip_sw_rv_core_ibex_nmi_irq

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.

`chip_sw_rv_core_ibex_rnd`

Test: chip_sw_rv_core_ibex_rnd

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.

`chip_sw_rv_core_ibex_address_translation`

Test: chip_sw_rv_core_ibex_address_translation

Verify the simple address translation functionality.

Setup address translation for both slots on 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.

`chip_sw_rv_core_ibex_icache_scrambled_access`

Test: chip_sw_rv_core_ibex_icache_invalidate

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.
In simultation: verify using probes, that this resulted in a new scrambling key fetched from the OTP ctrl.
In SiVal: loop reading the value of the Ibex CSR cpustrlsts.ic_scr_key_valid until it indciates a valid scrambling key, then continue executing some code to demonstrate continued functioning of the instruction cache.

`chip_sw_rv_core_ibex_fault_dump`

Test: chip_sw_rstmgr_cpu_info

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.

`chip_sw_rv_core_ibex_double_fault`

Test: chip_sw_rstmgr_cpu_info

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.

`chip_sw_rv_core_ibex_smoke`

No Tests Implemented

Execute each instruction implemented by Ibex at least once. Then check the register state against expected values.

The core of this test will be written in assembler and at least partially
auto-generated. It should be constructed such that a failure of any of the
instructions should (but is not guaranteed) to have some impact on the final
register state

`chip_sw_rv_core_ibex_epmp_smoke`

No Tests Implemented

Setup and test a few epmp regions

Check a range of ePMP access modes, ensure these include:
  - Shared execute, read and write
  - U-mode only execute, read and write
  - M-mode only execute, read and write

Also trial usage of the MML, MMWP and RLB bits in mseccfg.

Note that to fully implement this test it will need to injected into SRAM via JTAG
and run before the boot ROM executes in DEV/TEST_UNLOCKED, however a more limited
version can run in all lifecycle states using the standard load/execute mechanism
for all tests.

`chip_sw_rv_core_ibex_mem_smoke`

No Tests Implemented

Check access to each kind of memory from Ibex

Read a known value from each of the following and check it
matches the expected value:

- ROM
- Flash

Write values to each of the following and then read it back to
ensure it's as expected:

- SRAM
- A device register (choose one that can have at least an 8-bit value written to and
  you can expect to read it back un-changed). Preferably cover multiple devices

Execute code from each of the following:

- ROM
- Flash
- SRAM

First with the ICache disabled and then with the ICache enabled.  (Note that SRAM
execution may be unavailable in some lifecycle states).

`chip_jtag_csr_rw`

Test: chip_jtag_csr_rw

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.

For silicon validation, instead of randomised testing to all CSRs, one CSR for each IP is tested.

`chip_jtag_mem_access`

Test: chip_jtag_mem_access

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:
- In simulation preload the memory with random data via backdoor.
- For silicon choose some known values and addresses in these memories and shuffle these to choose one from each for the test.
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.

`chip_rv_dm_ndm_reset_req`

Test: chip_rv_dm_ndm_reset_req

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.

`chip_sw_rv_dm_ndm_reset_req_when_cpu_halted`

Test: chip_sw_rv_dm_ndm_reset_req_when_cpu_halted

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.
Verify that the debug logic is fully accessible during this time, while the NDM reset is being processed and the chip is rebooted, by continuously accessing the DMI register space in rv_dm over JTAG.
De-assert the NDM reset request and wait for the CPU to reboot and finish the post-NDM reset phase of the test.

`chip_rv_dm_access_after_wakeup`

Test: chip_sw_rv_dm_access_after_wakeup

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.

`chip_sw_rv_dm_jtag_tap_sel`

Test: chip_tap_straps_rma

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.

`chip_rv_dm_lc_disabled`

Test: chip_rv_dm_lc_disabled

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

Procedure

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

Late debug enable

In DEV life cycle stage test the following scenarios:
- rv_dm is accessible via CPU and JTAG when OTP DIS_RV_DM_LATE_DEBUG is set to true.
- rv_dm is accessible via CPU only when OTP DIS_RV_DM_LATE_DEBUG is set to false and the late_debug_enable register is set to false.
- rv_dm is accessible via CPU and JTAG when OTP DIS_RV_DM_LATE_DEBUG is set to false and the late_debug_enable register is set to true.

Silicon validation

For post silicon validation the test cannot change lifecycle mode. Instead it must discover the lifecycle of the device it is being run against and act appropriately (noting in particular it will not be able to execute code on Ibex in some life cycle states).

`chip_rv_dm_jtag`

No Tests Implemented

Verify basic JTAG functionality - Read IDCODE, check it is the expected value - Attempt to write IDCODE, check the expected value remains after a read - Check functionality of BYPASS - Read DTMCS ensure value is as expected

`chip_rv_dm_dtm`

No Tests Implemented

Verify basic DTM functionality - Select Ibex CPU with write to hartsel - Read hartinfo and check value is as expected - Write random values to data0 and data1 - Read back the values from data0 and data1 and check it matches the written value

`chip_rv_dm_control_status`

No Tests Implemented

Verify the functionality of dmcontrol/dmstatus - Write 0 to hartsel (select Ibex) - Check dmstatus indicates havereset for Ibex (power-on reset) - Write 1 to ackhavereset - Check dmstatus does not indicate havereset for Ibex - Write all 1s to hartsel - Read back hartsel and check value is 0 (hartsel is WARL) - Halt Ibex with a write to haltreq - Check dmstatus reflects halted status - Resume Ibex for a write to resumereq - Check dmstatus reflects halted status

NDM reset behaviour covered by chip_rv_dm_ndm_reset_req

`chip_sw_plic_all_irqs`

Tests:

chip_plic_all_irqs_0
chip_plic_all_irqs_10
chip_plic_all_irqs_20

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.

`chip_sw_plic_sw_irq`

Test: chip_sw_plic_sw_irq

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.

`chip_sw_timer`

Test: chip_sw_rv_timer_irq

Verify the timeout interrupt assertion.

Configure RV_TIMER to generate an 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.

`chip_sw_spi_device_flash_mode`

Test: rom_e2e_smoke

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 LAST_READ_ADDR.

`chip_sw_spi_device_pass_through`

Test: chip_sw_spi_device_pass_through

Verify the passthrough mode from an end-to-end perspective.

Configure the SPI device and host in passthrough mode.
Program the cmd_filter_* CSRs to filter out random commands.
Configure and enable both spi_host0 and spi_host1.
Send 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

`chip_sw_spi_device_pass_through_collision`

Test: chip_sw_spi_device_pass_through_collision

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. Upstream SPI host agent.
- Send a flash program/erase, then keep 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.
1. A SW process.
- Receives an upload interrupt, then reads the command in the upload fifo to check.
- Configures the SPI host that shows the same downstream port to send the uploaded command to the downstream SPI port.
- Clears the busy bit to allow the upstream SPI host to proceed to the next command.

`chip_sw_spi_device_tpm`

Test: chip_sw_spi_device_tpm

Verify the basic operation of the spi_device in TPM mode.

The testbench sends a known payload to the 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.

`chip_sw_spi_host_tx_rx`

Test: chip_sw_spi_host_tx_rx

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.

Notes for silicon targets:

The testbench that mimics a physical SPI device should measure the clock to verify that the frequencies for each speed mode is correct. This can be done by checking timing of the beginning and the end of the packet.

`chip_sw_sram_scrambled_access`

Tests:

chip_sw_sram_ctrl_scrambled_access
chip_sw_sram_ctrl_scrambled_access_jitter_en

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).

Note: In simulation, this uses a backdoor interface. However, most of the test should be possible on a silicon target (with no EDN assertions, and no backdoor accesses to check operations).

`chip_sw_sleep_sram_ret_contents`

Tests:

chip_sw_sleep_sram_ret_contents_no_scramble
chip_sw_sleep_sram_ret_contents_scramble

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

Ensure that the data within the retention SRAM survives as described in this table.

Mode	Scrambled	Data Preserved
Normal sleep	No	Yes
Deep sleep	No	Yes
Reset due to a reset request	No	Yes
Normal sleep	Yes	Yes
Deep sleep	Yes	Yes
Reset due to a reset request	Yes	No

Notes for silicon targets:

This test has an empty list of associated “features” because those list block-level features and this is really testing a chip-level property.

`chip_sw_sram_execution`

Test: chip_sw_sram_ctrl_execution_main

Verify that CPU can fetch instructions from SRAM if enabled.

Create the following combinations of 8 scenarios:
- The fetch enable bit in the HW_CFG1 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.

OTP HW_CFG1[IFETCH]	HW_DEBUG_EN via LC state	EXEC CSR	MAIN SRAM	RET SRAM
0	0	0	disabled	disabled
0	0	1	disabled	disabled
0	1	0	enabled	disabled
0	1	1	enabled	disabled
1	0	0	disabled	disabled
1	0	1	enabled	disabled
1	1	0	disabled	disabled
1	1	1	enabled	disabled

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

Notes for silicon targets:

This test will be reasonably trivial for silicon validation, because the behaviour depends on lifecycle state and we’re expecting to do these tests on PROD silicon, where execution from SRAM is disallowed.

`chip_sw_sram_lc_escalation`

Tests:

chip_sw_all_escalation_resets
chip_sw_data_integrity_escalation

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.

`chip_sw_sysrst_ctrl_reset`

Tests:

chip_sw_pwrmgr_sysrst_ctrl_reset
chip_sw_sysrst_ctrl_reset

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.

`chip_sw_sysrst_ctrl_inputs`

Test: chip_sw_sysrst_ctrl_inputs

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.

`chip_sw_sysrst_ctrl_outputs`

Test: chip_sw_sysrst_ctrl_outputs

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.

`chip_sw_sysrst_ctrl_in_irq`

Test: chip_sw_sysrst_ctrl_in_irq

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.

`chip_sw_sysrst_ctrl_sleep_wakeup`

Test: chip_sw_sysrst_ctrl_reset

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.

`chip_sw_sysrst_ctrl_sleep_reset`

Test: chip_sw_sysrst_ctrl_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.

`chip_sw_sysrst_ctrl_ec_rst_l`

Test: chip_sw_sysrst_ctrl_ec_rst_l

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.

`chip_sw_sysrst_ctrl_flash_wp_l`

Test: chip_sw_sysrst_ctrl_ec_rst_l

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.

`chip_sw_sysrst_ctrl_ulp_z3_wakeup`

Tests:

chip_sw_adc_ctrl_sleep_debug_cable_wakeup
chip_sw_sysrst_ctrl_ulp_z3_wakeup

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.

`chip_sw_usbdev_mem`

No Tests Implemented

Verify that the USB device packet memory works reliably from the CPU side.

With the USB device powered but not connected (pull up not enabled), check that the packet buffer memory works reliably from the CPU side.
Exercise and check 32-bit reads/writes to all addresses within the packet buffer RAM.

`chip_sw_usbdev_vbus`

Test: chip_sw_usbdev_vbus

Verify that the USB device can detect the presence of VBUS from the USB host.

Set up the pinmux to ensure that the SENSE/VBUS input can reach usbdev
Check that VBUS is asserted indicating the presence of a connection to the USB host or DPI model.

`chip_sw_usbdev_pullup`

Test: chip_sw_usbdev_pullup

Verify that the USB device can assert the pull up to indicate its presence.

This test extends from chip_sw_usbdev_vbus by checking that the DP line of the USB is deasserted after VBUS detection.
Enable the interface by asserting the pull up.
Check that the DP line rises by reading from the phy_pins_sense register.
Host/DPI model detects the presence of a Full Speed device.
Deassert the pull up.
Check that the DP line falls again.
For those targets which can apply a pull up to either line, repeat the above for the DN line using the usbdev pin-flipping feature.
No other communication with the host, so indicating Low Speed is harmless.

`chip_sw_usbdev_aon_pullup`

Test: chip_sw_usbdev_aon_pullup

Verify that the AON Wake module can assume control of the pull ups.

This test extends from chip_sw_usbdev_pullup by additionally exercising the ability of the ‘usbdev_aon_wake’ module to assume control of the DP/DN pull up resistors and maintain the state of the USB during suspend.
Drive the DP signal into a known state, enable the AON Wake module and attempt to change the DP pull up from the usbdev.
Check that the DP line is unaffected and that it retains the state at the point of usbdev_aon_wake taking control.
Repeat the above test with the DP line in the opposite state.
For those targets which support pinflipping, repeat the above for the DN line too.

`chip_sw_usbdev_sof`

No Tests Implemented

Verify that the USB device can detect SOF and respond with usb_ref_pulse_o and usb_ref_val_o.

This test extends from chip_sw_usbdev_pullup by connecting to the host/DPI model and awaiting the Start Of Frame token packets that signal the bus frames.
SOF packets serve as a ‘heartbeat’ from the host and allow the device to keep its clock frequency calibrated.
Configure the device to enable the usb_ref_val_o and usb_ref_pulse_o outputs.
Monitor the bus to check that the host/DPI SOF signal is not lost for a number of bus frames.
Ascertain that the reference pulse is being used to adjust the usb clock frequency appropriately.

`chip_sw_usbdev_setup_rx`

Test: chip_sw_usbdev_setuprx

Verify that the USB device can receive the SETUP stage of a Control Transfer from the host/DPI model.

This test extends from chip_sw_usbdev_pullup by checking that the device can receive packets from the host/DPI model.
Set tx_differential_mode to single-ended and rx_differential_mode to differential. The other modes are not supported in OpenTitan Earl Grey.
Upon detection of the usbdev asserting its pull up on the DP line, indicating the presence of a Full Speed device, the first communication attempt from the host/DPI model will be a SETUP token packet.
Software shall receive the SETUP DATA packet following the token packet.
The properties but not contents of this packet shall be verified; This makes the test robust against alternative host behaviors, since the first Control Transfer to be sent upon connection is unspecified.

`chip_sw_usbdev_config_host`

Test: chip_sw_usbdev_config_host

Verify that the USB device can be configured by the host/DPI.

This test extends from chip_sw_usbdev_setup_rx by using the usb_testutils software layer to receive, decode and respond to Control Transfers.
Software/usbdev receives GET_DESCRIPTOR requests and SET_ADDRESS control transfer from the host controller/USB device driver software, assigning an address on the USB and configuring the device via a SET_CONFIGURATION control transfer.
The device should present two serial ports (as /dev/ttyUSBn on a Linux host).

`chip_sw_usbdev_pincfg`

Test: chip_sw_usbdev_pincfg

Verify that the USB device can operate in all pin configurations.

This test extends from chip_sw_usbdev_config_host by testing all pin configurations.
Cycles the device through each of the supported bus modes/pin configurations.
Checks that the host/DPI model can set up the device with a given pin configuration, before resetting the device and advancing to the next pin configuration.
Exercises all available permutations of (i) pinflipping on/off, (ii) single-ended transmission on/off, and (iii) external differential receiver yes/no.
Targets differ in which modes/pin configurations are supported.

`chip_sw_usbdev_tx_rx`

Test: chip_sw_usbdev_dpi

Verify operation of simple Bulk Transfers to/from host/DPI model.

DPI model provides a simulation of a simple USB host; asserts VBUS
SW sets up the USB device, and enables the interface.
Host/DPI detects presence of pull up and VBUS, and initiates communications.
SW receives device address and configuration from host/DPI model.
A small data packet is transmitted from the device to the host/DPI model.
Host/DPI model returns a small data packet to the device and SW.
SW checks the content of the received data packet.
With a physical host this just requires character echo in response to a serial connection (eg. cat /dev/ttyUSB0).

`chip_sw_usbdev_toggle_restore`

Test: chip_sw_usbdev_toggle_restore

Verify that the USB device is able to save and restore arbitrary permutations of the Data Toggle flags on both the IN and OUT sides.

With the USB device powered and recently connected (pull up enabled), wait until the link comes out of reset. Do NOT enable any endpoints because USB traffic will interfere with testing of the Data Toggle bits.
Set the IN and OUT Data Toggle flags for all endpoints to a known state.
Verify that the IN and OUT Data Toggle flags may be read back correctly.
Check that each Data Toggle bit may be set and reset independently.
This functionality is required when Resuming from Deep Sleep.
Note that this test does not exercise any low power states or Suspend/Resume.
Note: This test requires the RTL changes for the production part; it will not pass on ES.

Stage V2S Testpoints

`chip_sw_aes_masking_off`

Test: chip_sw_aes_masking_off

Verify the AES masking off feature for ES.

Perform known-answer test using CSRNG SW application interface.
Verify CSRNG produces the deterministic seed leading to an all-zero output of the AES masking PRNG.
Configure EDN to perform a CSRNG instantiate followed by repeated generate and reseed commands using the maximum amount of additional data and no entropy input in automatic mode.
Let CSRNG produce and forward to EDN the deterministic seed leading to an all-zero output of the AES masking PRNG.
Initialize AES and set the force_masks configuration bit.
Configure an AES key of which the second share is zero.
Trigger a reseed operation of the masking PRNG inside AES to load the deterministic seed produced by CSRNG and distributed by EDN.
Verify that the masking PRNG outputs an all-zero vector. (Note: This may not be possible to verify in silicon.)
Encrypt a message of multiple blocks using AES.
Verify that the second share of the initial, intermediate and output state is zero.
Verify that the second share of the SubBytes input and output is zero. (Note: This may not possible to verify in silicon.)
Verify that the produced cipher text is correct.
Repeat the entire procedure with PRNG_RESEED_RATE set to PER_1. Verify that the second share of intermediate and output state is not zero.

Notes for silicon targets:

The AES.PRNG.FORCE_MASKS feature is relevant for penetration testing only and a SCA evaluation setup is required for its verification. This is done using other routines as part of the experimental setup for penetration testing. The only thing that can be tested on silicon / FPGA for SiVal is the known-answer test using the CSRNG SW application interface for which a dedicated SiVal test exists. For this reason, the chip_sw_aes_masking_off test is run in simulation only.

`chip_sw_rv_core_ibex_lockstep_glitch`

Test: chip_sw_rv_core_ibex_lockstep_glitch

Verify lockstep checking of the Ibex core.

Ensure suitable alerts are triggered when:

Outputs from the lockstep or the main core are corrupted.
Inputs into the lockstep core are corrupted.

Stage V3 Testpoints

`chip_sw_usb_suspend`

No Tests Implemented

Verify that the USB device can detect the presence of VBUS from the USB host.

This test extends from chip_usb_fs_df_tx_rx, add below at the end of the sequence.
Configure USB device to enter Suspend state and ensure link_suspend interrupt is triggered.
Test these 2 power modes.
- Normal sleep:
  - Configure pwrmgr to enter normal sleep mode, then clocks are disable while powers are kept on.
  - Resume the device through pinmux and check the link_resume interrupt.
  - Ensure that previously enumerated information is kept.
- Deep sleep:
  - Before entering deep sleep, store previously enumerated information in retention RAM. (optional)
  - Configure pwrmgr to enter deep sleep mode, and powers are turned off.
  - Resume the device through pinmux and check the link_resume interrupt.
  - Ensure that previously enumerated information and configuration (non-default values) are wiped, as USB has been reset before wakeup.
  - Restore previously enumerated information (if it’s stored) or re-enumerate the USB.
Re-enable data transfer and ensure data correctness.

`chip_sw_coremark`

Test: chip_sw_coremark

Run the coremark benchmark on the full chip.

`chip_sw_power_max_load`

Test: chip_sw_power_virus

Concurrency test modeling maximum load conditions.

This concurrency test runs multiple blocks at the same time, to simulate maximum load (“power virus test”). Should be combined with low power entry and exit scenarios.

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

Blocks / functionality to run simulatenously in this test:

The ADC is continuously sampling new data
Staggered activation of OTBN, aes, KMAC/HMAC.
KMAC / aes would need to take turns being fed data
KMAC activation should be a combination of otp background, key manager background and software
for OTBN, any signature verification / signing event is sufficient
Entropy complex ongoing
reseed / update operation ongoing
Flash scramble ongoing (ideally both instruction and data, but data should be sufficient for now)
instruction scrambling gated by script availability
Simultaneous IO toggling as defined below
ideally for digital activity, 3xUART / I2C modules should be activated
for first pass simplicity can activate IO portion only for now through GPIO
for dedicated pins, focus on SPI device quad activity
USB activity should be activated
for first pass simplicity activate IO portion only for now via pin forcing in usbdev.
Ongoing cpu activity (icache / SRAM scrambling both activated)
servicing ongoing threads and random read/write data to memory
icache needs to be activated, otherwise the system may spend most of its time fetching code
Background checks enabled wherever possible
rstmgr background checks
alert_handler ping checks
OTP background checks
The test should be run both with / without external clock

`rom_e2e_debug`

Tests:

rom_e2e_jtag_debug_test_unlocked0
rom_e2e_jtag_debug_dev
rom_e2e_jtag_debug_rma

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 can be debugged in TEST, DEV, and RMA life cycle states.
- Test debugging with commands to GDB connected via OpenOCD and JTAG (or the SystemVerilog based JTAG debugger model in case of DV simulations).
- Read back GDB responses to check they match expected behaviour
- Connect a debugger and verify that ROM halts very early in rom_start.S.
- Trial the following activities within GDB, ensuring the correct behaviour is seen:
  - Halting execution and resetting
  - Setting, hitting and deleting breakpoints using all available hardware breakpoints
  - Single stepping
    - In particular single step over wfi
  - Reading and writing all registers
  - Reading all CSRs and writing some (write set TBD)
  - Reading and writing memory (both SRAM and device)
  - Setting the PC to jump to some location
  - Executing code from GDB (using the call command)
- Verify that ROM fails to boot with BFV:0142500d.

`rom_e2e_jtag_inject`

Tests:

rom_e2e_jtag_inject_test_unlocked0
rom_e2e_jtag_inject_dev
rom_e2e_jtag_inject_rma

Verify that a program can be injected into SRAM via JTAG and executed.

CREATOR_SW_CFG_ROM_EXEC_EN should be set to 0.

For TEST, DEV, and RMA:
- Connect a debugger.
- Follow the steps here and execute //sw/device/examples/sram_program binary from SRAM.
- Verify that chip sends the expected message over UART.

See this doc for detils.

`rom_bootstrap_rma`

No Tests Implemented

End to end test to ensure RMA mode can be activated by halting ROM execution.

This test must be run with the real ROM.
Pre-load the device into PROD or PROD_END state.
Backdoor load CREATOR_SW_CONFIG_RMA_SPIN_CYCLES and SPIN_EN.
The value for CREATOR_SW_CONFIG_RMA_SPIN_CYCLES should be small, just enough for the DV agent to activate the life cycle JTAG interface.
Drive software strap to the RMA bootstrap value.
The test contains two iterations.
In iteration 1, do not issue the life cycle rma command. ROM should timeout on spin cycles and automatically reset the device. Check to ensure device has reset via backdoor CSR.
In iteration 2, issue the life cycle RMA command and ensure RMA transition can be successfully completed.

`rom_e2e_weak_straps`

No Tests Implemented

Verify that ROM can differentiate strong pull-ups/-downs from weak pull-ups/-downs.

For strap in {all 64 strap values}
Verify that ROM boots as usual unless strap == bootstrap or strap == rma_entry.

Each iteration should be pretty fast since the next stage is empty. If the above test takes a long time to run in DV, consider the following (or a subset of):

For strap in {bootstrap, rma_entry}
Apply all combinations of strap where pin values are the same but at least one pin uses weak pull-down.
Verify that ROM boots as usual.

`rom_e2e_self_hash`

Test: rom_e2e_self_hash

Verify that the expected ROM has been properly baked into the nelist.

Hash the contents of the ROM using SHA256.
Verify the hash against golden hash baked into the test.
Print out hash over console.
Run in TEST_UNLOCKED0 LC state.

`manuf_cp_unlock_raw`

No Tests Implemented

Verify transition from RAW to TEST_UNLOCKED lc_state.

Pre-load OTP with RAW lc_state.
Bring device out of reset selecting the Life Cycle (LC) TAP interface using strap pins.

Perfom the following steps via LC TAP interface:

Switch to external clock via TRANSITION_CTRL.EXT_CLOCK_EN.
Provide RAW_UNLOCK.
Poll for lc_ctrl STATUS register for TRANSITION_SUCCESSFUL. Check for errors or timeout.
Perform reset by toggling the POR pin.
Verify the lc_state is TEST_UNLOCKED0.

The manufacturing environment is required to support test reruns whenever possible:

Verify that the RAW_UNLOCK process can be re-tried after failed or interrupted attempts.

`manuf_scrap`

No Tests Implemented

Verify transition from any state to SCRAP lc_state.

Manufacturing tests should be able to move the device from any lc_state into SCRAP state.

For each manufacturing lc_state s:

Pre-load OTP with s lc_state image.
Bring device out of reset selecting the Life Cycle (LC) TAP interface using strap pins.
Request transition to SCRAP state via LC TAP interface.
Perform reset by togglig the POR pin.
Check we are in SCRAP state via LC TAP interface.

The manufacturing environment is required to support test reruns whenever possible:

Verify that the transition to SCRAP mode can be re-tried after failed or interrupted attempts.

`manuf_cp_yield_test`

No Tests Implemented

Verify that it is possible to switch TAP interfaces while injecting external clock.

Verify that it is possible to access TAP interfaces while injecting an external clock. This test case is valid only in test life cycle states.

Pre-load OTP with TEST_UNLOCKED lc_state in pre-silicon environments. Advance to state in silicon.
Enable external clock injection.
Connect to CPU JTAG and perform register read/writes to memory/registers.
Switch to LC TAP by manipulating the strap pins.
Verify that read/writes to lc_ctrl work as expected.

`manuf_cp_ast_test_execution`

No Tests Implemented

Verify that the tester is able to load/exec test sequences into/from SRAM.

An expected pattern during manufacturing involves loading small program sequences into SRAM, and use them to run higher level operations such as configuring OTP values in the OTP hardware partition.

Pre-load OTP with TEST_UNLOCKED lc_state in pre-silicon environments. Advance to state in silicon.
Select CPU JTAG via strap pins.
Load program into SRAM to execute OTP word write sequences.
Trigger OTP writes to HW partition (e.g. device ID).
Perform reset by toggling POR pin.
Select CPU JTAG via strap pins.
Verify that OTP write was successful.

`manuf_cp_device_info_flash_wr`

No Tests Implemented

Verify that the tester is able to write to flash info pages.

During early manufacturing stages, the tester writes information for later use into flash info pages.

Pre-load OTP with TEST_UNLOCKED lc_state in pre-silicon environments. Advance to state in silicon.
Select CPU JTAG via strap pins.
Load program into SRAM to execute flash write sequences.
Write 32B to the isolated flash info partition. Verify unable to read back.

In silicon, a separate test program must perform the following additional operations. In pre-silicon, they can be part of the same program.

Switch to LC TAP at runtime.
Request transition to PROD or PROD_END state (test both cases).
Perform reset by toggling POR pin.
Verify isolated flash info partition expected data.

`manuf_cp_test_lock`

No Tests Implemented

Verify provisioning and use of unlock tokens.

In transit devices will need to be switched into TEST_LOCKED states to disable debug access and code execution. This test verifies that a TEST_UNLOCKED token can be provisioned as part of this process.

Pre-load OTP with TEST_UNLOCKED lc_state in pre-silicon environments. Advance to state in silicon.
Select CPU JTAG via strap pins.
Program TEST_UNLOCK_TOKEN in OTP transition via JTAG.
Select LC TAP via strap pins (at runtime).
Request transition into TEST_LOCKED state.
Perform reset by toggling POR pin.
Select LC TAP via strap pins.
Verify lc state.

Implement the following steps in a way in which it could be executed at a later time in silicon targets:

Load OTP state generted by previous steps.
Select LC TAP via strap pins.
Request transition to TEST_UNLOCKED by providing the TEST_UNLOCK_TOKEN provisioned in previous steps.
Perform reset by toggling POR pin.
Select LC TAP via strap pins.
Verify lc_state.

Repeat the same flow for the number of supported TEST_LOCK/UNLOCKED states.

`manuf_ft_exit_token`

No Tests Implemented

Verify provisioning and use of test exit token.

The test exit token is used to move the device from test mode into DEV, PROD or PROD_END state. This test also incorporates enabling of ROM execution before triggering the lc_state change.

Pre-load OTP with TEST_UNLOCKED lc_state in pre-silicon environments. Advance to state in silicon.
Select CPU JTAG via strap pins.
Program TEST_EXIT_TOKEN in OTP transition via JTAG.
Reset device by toggling POR pin.
Select CPU JTAG via strap pins.
Program CREATOR_SW_CFG_ROM_EXEC_EN in OTP via JTAG.
Select LC TAP via strap pins (at runtime).
Request transition into {pick one: DEV, PROD, PROD_END} state providing TEST_EXIT_TOKEN.
Perform reset by toggling POR pin.
Select LC TAP via strap pins.
Verify lc state.

After this test most of the following manuf_ft_* test cases can be loaded into flash via boostrap in silicon.

`manuf_ft_sku_individualization_preop`

No Tests Implemented

Configure device fuses before switching the device to an operational lc_state.

This includes configuration of the CREATOR_SW and OWNER_SW partition.

The test steps are expected to be executed from flash. In silicon, the program is loaded using the ROM bootstrap protocol. It is recommended to use the same approach on the FPGA, and enable it as a configuration option in DV.

Pre-load OTP with a TEST_UNLOCKED* lc_state in pre-silicon environments. Advance to state in silicon.
Load test program into flash and start execution.
Configure CREATOR_SW_CFG OTP words according to device SKU configuration.
Configure OWNER_SW_CFG OTP words according to device SKU configuration.
Perform reset triggered by software.
Load test program again into flash and start execution.
Send response to host with test result serialized in JSON format.
Check status response on the host side.

Note: Tests are easier to integrate with Automated Test Equipment (ATE) if all device-host interfaces are unidirectional. This influences the type of physical interface selection (e.g. SPI versus UART). Make sure the interface design takes this constraint into consideration.

`manuf_ft_sku_individualization`

No Tests Implemented

Configure device fuses.

This includes configuration for most countermeasures and hardware options. It does not include configuration of the device identity and RMA token, which is done in the personalization step.

Pre-load OTP with {pick one: DEV, PROD, PROD_END} lc_state in pre-silicon environments. Advance to state in silicon.
Load test program into flash and start execution.
Check device lc_state. Return error to the host if device in invalid state.
Configure the following OTP fuses to enable access to entropy:
- EN_CSRNG_SW_APP_READ
Configure remaining HW_CFG0 OTP fields:
- DEVICE_ID
- MANUF_STATE
Lock HW_CFG0 OPT partition.
Perform reset trigered by software.
Initialize entropy_src in FIPS mode. Check health status after setting appropriate health test parameters. Configure SW csrng instance to generate enough data to configure the following OTP fields:
- FLASH_ADDR_KEY_SEED
- FLASH_DATA_KEY_SEED
- SRAM_DATA_KEY_SEED
Lock SECRET1 partition.
Perform reset triggered by software.
Load test program again into flash and start execution.
Send response to host with test result serialized in JSON format.
Check status response on the host side.

`manuf_ft_provision_rma_token_and_personalization`

No Tests Implemented

Provision RMA unlock token.

Provisioning of RMA_UNLOCK_TOKEN

The RMA_UNLOCK_TOKEN is used to take a device from a production ls_state (i.e. DEV, PROD) in to RMA state. RMA entry is conditional to flash erase, and it also triggers a diversification change in the key manager to ensure that user assets are not exposed to the manufacturer.

Since RMA enables debug interfaces in the chip, it is important to maintain the confidentiality of the RMA_UNLOCK_TOKEN. For this reason, asymmetric encryption is used to export the token.

The manufactuer is expected to maintain the RMA_UNLOCK_TOKEN decryption key in an offline HSM.

Personalization

The device is configured with a unique set of secrets, which once provisioned, are hidden from software. These secrets are used as the root of the key derivation function in the key manager.

Test steps

Prep steps

Pre-load the OTP state with an image of an individualized device. See manuf_ft_sku_individualization for more details.
Check expected ls_state and OTP locked partitions (SECRET1, HW_CFG0).
Check the device lifecyle to be set in DEV, PROD or PROD_END state.
Initialize entropy source in FIPS mode. Check health status after setting appropriate health test parameters.

Device secrets

Instantiate the SW CSRNG, and configure it to generate data.
Configure the Silicon Creator secret info flash partition.
Uninstantiate the SW CSRNG.
Instantiate the SW CSRNG, and configure it to generate data.
Configure the following OTP entries with data extracted from the CSRNG:
- CREATOR_ROOT_KEY_SHARE0
- CREATOR_ROOT_KEY_SHARE1
Uninstantiate the SW CSRNG.
Lock SECRET2 OTP partition.
Perform reset triggered by software.

RMA provisioning

Instantiate the SW CSRNG, and configure it to generate data.
Configure RMA_TOKEN in the OTP partition with data extracted from the CSRNG.
Encrypt RMA_TOKEN with asymmetric algorithm (e.g RSA-3072). The encrypted blob will be sent to the host in the result status.
Uninstantiate the sw CSRNG.

Device Identity

The OWNER_SW_CFG_ROM_KEYMGR_OTP_MEAS_EN OTP must be configured so that the attestation measurement can be provided in the manifest of the test program. This way the provisioning program is able to generate the key manager derivation matching the production OTP configurations.

TODO: Left details vague on purpose until we get the attestation flow reviewed.

Advance the keymgr to CREATOR_ROOT_KEY state.
Derive CREATOR attestation key pair.
Calculate SHA2 hash of the public key with the device secret provisionined in the manuf_cp_device_info_flash_wr test. The device secret is known by the provisioning appliance.
Disable the key manager.
Configure OWNER_SW_CFG_ROM_KEYMGR_OTP_MEAS_EN OTP to switch to attestation mode associated with the device SKU.

Result status

Send response to host with test result serialized in JSON format. The result must include the encrypted RMA_UNLOCK_TOKEN, the DEVICE_ID, the public attestation key and its hash.

`manuf_ft_load_transport_image`

No Tests Implemented

Load transport stack into flash.

Ensure the ROM is able to bootstrap the transport image. The transport image supports functionality such as full device attestation, and ownership transfer, which are required to enable device integration into a system.

Pre-load the OTP with an image of a personalized device. See manuf_ft_provision_rma_token_and_personalization for more details.
Bootstrap transport image.
Reset device by toggling POR pin.
Check device firmware version.

`manuf_ft_load_certificates`

No Tests Implemented

Load endorsed certificates.

Load device certificate endorsing the creator public key. The certificate is signed by the silicon creator.

TODO: This assumes the ROM_EXT supports a mechanism to update the certificate. TODO: Should the transport image contain silicon creator pubilc keys to be able to verify the certificate before install?

Pre-load the OTP with an image of a personalized device. See manuf_ft_provision_rma_token_and_personalization for more details.
The device flash should be loaded with the transprot image. See manuf_ft_load_transport_image for details.
The host sends a command to the device including the device certificate.
The device verifies that the certificate corresponds to its device key.
The certificate is then stored into a flash page (info versus regular flash TBD).
Send response to the host with test result.

`manuf_ft_eom`

No Tests Implemented

End of manufacturing.

This test requires the device to have completed the manuf_ft_load_certificates test.

The host sends a command to the device to trigger the end of manufacturing.
Final OTP configuration options are set.
Manufacturing functionality supported by the ROM_EXT and transport image will be disabled after reset.
Trigger software reset.
The host sends a command to ensure device is in post-manufacturing state.

`manuf_rma_entry`

No Tests Implemented

Verifies RMA entry.

In silicon, the entire process is executed in a secure environment in adherence to certification requirements.

Initialize device to reflect eom state. See manuf_ft_eom for more details.
Select LC TAP via strap pins.
Read DEVICE_ID via LC TAP interface.
Powerdown the device.

The Silicon Creator is expected to lookup the RMA_UNLOCK_TOKEN in a manufacturing database using the DEVICE_ID and decrypt it at an offline location. The token cannot leave the secure environment in unencrypted form at any time, implying that there is a way for the secure environment to handle the decryption operation.

Select LC TAP via strap pins.
Power on the device.

The following steps are performed via the LC TAP interface:

Read DEVICE_ID. Confirm expected response.
Load RMA_UNLOCK_TOKEN and request transition to RMA state.
Poll for status completion.
Reset device by toggling POR pin.

RMA entry will trigger a rotation of scrambling keys. It is recommended to either connect to the CPU JTAG to continue debug, or bootstrap the device with new a firmware image. Otherwise the ROM will fail to boot.

`manuf_sram_program_crc_functest`

No Tests Implemented

Verifies SRAM CRC mechanism.

SRAM programs are loaded via JTAG which has no data integrity mechanism. To make sure that the program is not corrupted, the SRAM CRT computes the CRC of the entire program at runtime and compares it to the host provided data. This test verifies the CRC check is correctly done by running two tests:

load a SRAM program and make sure that it works as expected (print a message),
corrupt a byte in memory (where the program was loaded), try to re-run it and confirm that the CRT now reports a CRC mismatch error.

`chip_sw_adc_ctrl_normal`

No Tests Implemented

Verifiy that ADC can sample from channel 0 and 1 in normal mode.

`chip_sw_adc_ctrl_oneshot`

No Tests Implemented

Verifiy that ADC can sample from channel 0 and 1 in normal mode with oneshot filter config.

`chip_sw_aes_stall_test`

No Tests Implemented

Verify that the AES module’s stall bit assertion when multiple input blocks are loaded without reading output data, and resumes encryption once the output data is read.

Procedure:

Initialize the AES.
Configure the AES encryption operation with the following settings:
- Operation: Encrypt
- Mode: ECB
- Key Length: 128 bits
- Key Provider: Software-provided key
- Mask Reseeding: Reseed per block
- Manual Operation: Auto
- Reseed on Key Change: Enabled
- Force Masks: Enabled
Generate an AES key and load it for encryption.
Prepare input blocks with random plaintext data.
Load multiple blocks into AES without reading output data to simulate a stall condition.
- Verify that kDifAesStatusStall is set.
Once the AES is stalled, read the output blocks one by one.
- Verify that reading the output clears the stall condition.
Ensure the AES encryption operation completes successfully and that the AES module reaches the idle state at the end of the test.

Expected Outcome:

AES enters a stall condition when multiple input blocks are loaded without reading output.
Reading the output clears the stall condition, allowing AES to resume encryption.
The test verifies correct handling of the stall condition and that the AES operation completes as expected.

`chip_sw_clkmgr_jitter_cycle_measurements`

Test: chip_sw_clkmgr_jitter_frequency

Verify jitter via clock cycle measurements after calibration. The clock count thresholds for main clk need to be set wider than when jitter is disabled.

Check when jitter is enabled:

using jitter thresholds no errors are detected
using normal thresholds results in recoverable errors
don’t test normal thresholds for FPGAs since they don’t support jitter and no errors will occur Check when jitter is disabled:
using either sets of thresholds result in no errors

The test flow should depend on jitter enable lock:

if it is locked only tests for the given jitter configuration
if it is unlocked test for both jitter enabled and disabled

SiVal: This is only useful on real silicon since FPGAs don’t support jitter. Should be done after clock calibration.

`chip_sw_edn_boot_mode`

Test: chip_sw_edn_boot_mode

Verify EDN operation in boot-time request mode.

Verify that EDN delivers entropy in boot-time request mode and that the edn_fips bit correctly signals to endpoints whether the delivered entropy is derived from a FIPS/CC compliant seed or not.

Procedure:

Disable the entropy complex.
Enable ENTROPY_SRC in boot-time mode, e.g., by setting CONF.FIPS_ENABLE to kMultiBitBool4False.
Enable CSRNG.
Enable EDN1 (the one connected to OTBN RND) in boot-time request mode.
Disable ENTROPY_SRC.
Since EDN1 provides entropy only to the OTBN, CSRNG will be idle.
Enable ENTROPY_SRC in FIPS mode.
Enable EDN0 (the one connected to OTBN URND and other endpoints) in auto request mode.
Launch an OTBN program consuming entropy via both the RND and the URND interface.
Verify that the OTBN program completes (entropy available) and that OTBN sets ERR_BITS.RND_FIPS_CHK_FAIL to indicate the reception of non-FIPS/CC-compliant entropy over the RND interface.
Consume entropy through rv_core_ibex.RND_DATA and verify, using rv_core_ibex.RND_STATUS, that the received bits are FIPS compliant.
Disable the entropy complex.
Enable ENTROPY_SRC in FIPS mode.
Enable CSRNG.
Enable EDN1 (the one connected to OTBN RND) in auto request mode.
Disable ENTROPY_SRC.
Enable ENTROPY_SRC in boot-time mode.
Enable EDN0 (the one connected to OTBN URND and other endpoints) in boot-time request mode.
Launch an OTBN program consuming entropy via both the RND and the URND interface.
Verify that the OTBN program completes (entropy available) and that OTBN does not set ERR_BITS.RND_FIPS_CHK_FAIL.
Consume entropy through rv_core_ibex.RND_DATA and verify, using rv_core_ibex.RND_STATUS, that the received bits are FIPS NON-compliant.
Disable the entropy complex.
Enable ENTROPY_SRC in FIPS mode.
Enable CSRNG.
Enable EDN1 and EDN0 in auto request mode and with non-deterministic seeds (flag0 = kMultiBitBool4False for Instantiate and Reseed commands).
Re-launch the OTBN program.
Verify that the OTBN program completes (entropy available) and that OTBN does not set ERR_BITS.RND_FIPS_CHK_FAIL.
Consume entropy through rv_core_ibex.RND_DATA and verify, using rv_core_ibex.RND_STATUS, that the received bits are FIPS compliant.

`chip_sw_edn_auto_mode`

Test: chip_sw_edn_auto_mode

Verify EDN operation in auto request mode.

Verify that EDN delivers entropy in auto request mode.

Procedure:

Disable the entropy complex.
Enable ENTROPY_SRC in FIPS mode.
Enable CSRNG.
Enable EDN0 and EDN1 in auto request mode and with non-deterministic seeds (flag0 = kMultiBitBool4False for Instantiate and Reseed commands).
Trigger the execution of various cryptographic hardware blocks consuming entropy to stress test the EDNs.
Verify that all entropy consuming endpoints can finish their operations and do not hang.
Repeat the procedure with different EDN configurations. In particular, modify:
- The command length or amount of optional additional data.
- The generate length parameter.
- The MAX_NUM_REQS_BETWEEN_RESEEDS register.

`chip_sw_edn_sw_mode`

Test: chip_sw_edn_sw_mode

Verify EDN operation in software port mode.

Verify that EDN delivers entropy in software port mode.

Procedure:

Disable the entropy complex.
Enable ENTROPY_SRC in FIPS mode.
Enable CSRNG.
Enable EDN1 in auto request mode.
Enable EDN0 in software port mode.
Trigger the execution of a cryptographic hardware block consuming entropy (e.g., AES) to test EDN0.
Verify that the entropy consuming endpoint hangs.
Provide the required commands to EDN0 via SW_CMD_REQ register to start generating and delivering entropy to consumers.
Verify that the entropy consuming endpoint can finish its operations and does not hang.

`chip_sw_edn_kat`

Test: chip_sw_edn_kat

Perform a Known-Answer Test with EDN.

Verify that EDN delivers the expected entropy bits when running CSRNG in fully deterministic mode.

Procedure:

Disable the entropy complex.
Enable ENTROPY_SRC in FIPS mode.
Enable CSRNG.
Enable EDN1 in auto request mode.
Enable EDN0 in auto request mode with the following configuration:
- Use deterministic seeds (set flag0 = kMultiBitBool4True in all instantiate/reseed application command headers sent to CSRNG). This causes CSRNG to ignore the seed provided by ENTROPY_SRC and exclusively use the optional additional data provided by EDN.
- Set the command length or amount of optional additional data for the Instantiate and Reseed commands to 12 words.
- Set the generate length parameter for the Generate command to 4 blocks.
- Provide the correct seed material for the Instantiate and Reseed commands.
- For an example, refer to chip_sw_csrng_kat_test.
Verify that EDN0 delivers the expected entropy bits using the rv_core_ibex.RND_DATA and rv_core_ibex.RND_STATUS registers.
Disable the entropy complex.
Enable ENTROPY_SRC in FIPS mode.
Enable CSRNG.
Enable EDN1 in auto request mode.
Enable EDN0 in auto request mode with the following configuration:
- Use deterministic seeds (set flag0 = kMultiBitBool4True in all instantiate/reseed application command headers sent to CSRNG).
- Set the command length or amount of optional additional data for the Instantiate and Reseed commands to 12 words.
- Set the generate length parameter for the Generate command to 1 block.
- Set the max_num_reqs_between_reseeds parameter for the Generate command to 1.
- Provide the correct seed material for the Instantiate and Reseed commands.
- For an example, refer to chip_sw_aes_masking_off_test.
Verify that EDN0 triggers a recoverable alert and sets the RECOV_ALERT_STS.EDN_BUS_CMP_ALERT bit as more entropy is consumed via rv_core_ibex.RND_DATA and CSRNG continues to provide the same entropy bits to EDN0.

`chip_sw_entropy_src_bypass_mode_health_tests`

No Tests Implemented

Verify that ENTROPY_SRC:

provides one initial seed in boot-time / bypass mode only,
signals a recoverable alert if the total failure counter hits the threshold in boot-time / bypass mode.

Procedure:

Disable the entropy complex.
Configure loose health test threshold values for boot-time / bypass mode.
Enable ENTROPY_SRC in boot-time / bypass mode.
Enable CSRNG.
Enable both EDNs in boot-time request mode.
Trigger the execution of a cryptographic hardware block consuming entropy (e.g. AES) to test EDN0.
Verify the entropy consuming endpoint finishes its operation.
Trigger the execution of an OTBN program requiring entropy from both EDN1 and EDN0.
Verify the OTBN program hangs.
Disable the entropy complex.
Configure unrealistically stringent health test threshold values for boot-time / bypass mode.
Configure an alert threshold value of 1 in the ALERT_THRESHOLD register.
Enable ENTROPY_SRC in boot-time / bypass mode.
Enable CSRNG.
Enable both EDNs in boot-time request mode.
Verify that ENTROPY_SRC triggers a recoverable alert and sets the RECOV_ALERT_STS.ES_MAIN_SM_ALERT bit.

`chip_sw_entropy_src_fips_mode_health_tests`

No Tests Implemented

Verify that ENTROPY_SRC:

provides continuous entropy in FIPS/CC compliant mode,
works with different health test window sizes in FIPS mode,
signals a recoverable alert and stops serving entropy if the total failure counter hits the threshold in FIPS mode.

Procedure:

Disable the entropy complex.
Configure realistic health test threshold values for FIPS/CC compliant mode.
Enable ENTROPY_SRC in FIPS mode.
Enable CSRNG.
Enable both EDNs in auto request mode.
Trigger the execution of various cryptographic hardware blocks consuming entropy to stress test the entropy complex.
Verify that all entropy consuming endpoints can finish their operations and do not hang.
Repeat the procedure with different health test window sizes for FIPS mode.
Disable the entropy complex.
Configure unrealistically stringent health test threshold values for FIPS mode.
Configure a low alert threshold value in the ALERT_THRESHOLD register.
Enable ENTROPY_SRC in FIPS mode.
Enable CSRNG.
Enable both EDNs in auto request mode and with low values for the generate length parameter to request fresh entropy more often.
Trigger the execution of various cryptographic hardware blocks consuming entropy to stress test the entropy complex.
Verify that ENTROPY_SRC triggers a recoverable alert and sets the RECOV_ALERT_STS.ES_MAIN_SM_ALERT bit.
Verify that various entropy consuming endpoints hang as ENTROPY_SRC stops generating entropy after triggering the recoverable alert.

`chip_sw_entropy_src_validation`

No Tests Implemented

Enable validation of the four channels of the digital noise source / physical true random number generator (PTRNG) at the ENTROPY_SRC input, and verify that ENTROPY_SRC allows observing raw entropy through the observe FIFO while serving entropy to consumers.

Procedure:

Disable the entropy complex.
Configure realistic health test threshold values for FIPS/CC compliant mode.
Enable ENTROPY_SRC in FIPS mode.
Enable Firmware Override - Observe.
Enable CSRNG.
Enable both EDNs in auto request mode.
Trigger the execution of various cryptographic hardware blocks consuming entropy to stress test the entropy complex.
Verify that all entropy consuming endpoints can finish their operations and do not hang.
Verify that the observe FIFO depth is non-zero and read out post-health test entropy for validation testing.
Repeat the procedure four times with the ENTROPY_SRC.RNG_BIT_ENABLE feature being enabled (once for every channel).

Notes for silicon targets:

This test requires access to the ENTROPY_SRC.FW_OV.OBSERVE feature, which is gated by OTP. This test might thus need to be done in a secure facility.

`chip_sw_flash_memory_protection`

Test: chip_sw_flash_ctrl_mem_protection

Extend chip_sw_flash_ctrl_access test to over following features. Perform READ/ PROGRAM/ ERASE operations over protected regions and pages of data and info partitions. Use set and reset values of corresponding read, program and erase enable bits. Test boundary values of regions. Test overlap of regions in which lower region wins arbitration.

`chip_sw_hmac_sha2_stress`

No Tests Implemented

Verify SHA2 mode of operation.

Verify the following digest sizes: 256, 384, 512
Verify input message size of 0 bytes.
Verify multiple input message sizes as defined in NIST test vectors.
Use endianness configuration used in the crypto library.

`chip_sw_hmac_stress`

No Tests Implemented

Verify HMAC mode of operation.

Verify all HMAC modes of operation:
- HMAC-SHA2-256
- HMAC-SHA2-384
- HMAC-SHA2-512
Verify input message size of 0 bytes.
Verify multiple input message sizes as defined in NIST test vectors.
Use endianness configuration used in the crypto library.

`chip_sw_hmac_endianness`

No Tests Implemented

Verify all HMAC endianness options

This is a low priority test P3.

Test the permutation of all endianness configuration options for message and digest registers.

`chip_sw_hmac_secure_wipe`

No Tests Implemented

Verify HMAC secure wipe

Perform HMAC operation with known key and message.
Store MAC digest in memory after finalizing HMAC operation.
Perform secure wipe operation.
Read digest registers. They should not match the previously calculated digest.
Process HMAC operation with initial known message.
Compare MAC disgest against original result. The result must not match.

`chip_sw_hmac_error_conditions`

No Tests Implemented

Verify reporting of HMAC errors

This is a negative test case covering the following error conditions:

SwPushMsgWhenShaDisabled: Push message when SHA is disabled.
SwHashStartWhenShaDisabled: Start hash operation when SHA is disabled.
SwUpdateSecretKeyInProcess: Update secret key when hash is in progress.
SwHashStartWhenActive: Issue hash start when hash is in progress.
SwPushMsgWhenDisallowed: Push message when HMAC is not idle.
SwInvalidConfig: Issue when HMAC configured with incorrect digest-size or key-length

`chip_sw_i2c_speed`

No Tests Implemented

Verify the transmission speed of data over the chip’s I2C interfaces.

Run the following for standard, fast and fast plus speeds:

Program the I2C to be in the appropriate mode (host/target).
For hosts, the SW test writes a known payload over the chip’s I2C host interface. It should then receive back that payload plus one. The test checks whether the payload is sent at the appropriate throughput with 3% of tolerance.
For targets, the test sends data at the appropriate speed mode and checks whether an ack is received. The test should also do a read request.

Verify all instances of I2C in the chip.

Notes for silicon targets:

The testbench in this case will be a device that physically toggles/inspects the appropriate SCL and SDA lines.
To check the baud rate the test bench should time the packets and average this time out over multiple runs. Then check whether these timings match the appropriate throughput within 3% of tolerance: Fast-mode should be faster than standard-mode and fast-mode plus should be faster than fast-mode.

`chip_sw_i2c_override`

No Tests Implemented

Verify overriding SDA and SCL on I2C interfaces.

For all I2C host mode instances:

Software cycles through all SDA/SCL combinations with long delays.
Test monitors the SDA/SCL lines and checks whether it receives the values in the expected order and delay.

Verify all instances of I2C in the chip.

Notes for silicon targets:

The testbench in this case will be a device that physically toggles/inspects the appropriate SCL and SDA lines.

`chip_sw_i2c_clockstretching`

No Tests Implemented

Verify clock stretching on I2C interfaces.

For all I2C host mode instances:

Do a read and make target stretch after reading an address.
Do a write and make the target stretch during that write.
Do a read and make the target stretch during that read.

For all I2C target mode instances:

Have a queue of 10 I2C transactions where the data increments by one.
The test bench host tries to send these transactions one after the other without pausing.
On the chip, the Ibex waits to receive the first transaction, then it goes to sleep for 1 second and refuses to pull transactions out of the ACQ FIFO, which should cause clock stretching to happen.
Afterwards Ibex repeats the reading transaction and sleeping for 1 second.
The Ibex checks that it receives 10 transactions total and that the data in each of the transactions are incremented by one. After that, it sends back a transactions with the data value of the final transaction.
The test bench checks that the transaction received from the chip has the same data value as the final packet sent.

Notes for silicon targets:

The testbench in this case will be a device that physically toggles/inspects the appropriate SCL and SDA lines.

`chip_sw_i2c_nack`

No Tests Implemented

Verify correct behavior of nack detection.

For all I2C host mode instances:

Program the I2C to be in host mode.
Fail to send an acknowledgement after the address.
Fail to send an acknowledgment after a random data byte.

The host mode should successfully detect this nack and raise the appropriate interrupt.

Notes for silicon targets:

The testbench in this case will be a device that physically toggles/inspects the appropriate SCL and SDA lines.

`chip_sw_i2c_repeatedstart`

No Tests Implemented

Verify correct behavior of repeated start.

For all I2C target mode instances:

Program the I2C to be in target mode.
Start a transaction, but fail to send a stop.
Send a repeated start with a specific data value and stop the transaction as usual.
Perform a read from the I2C device and check that the target sends back the data val

Notes for silicon targets:

The testbench in this case will be a device that physically toggles/inspects the appropriate SCL and SDA lines.

`chip_sw_keymgr_sideload_kmac_error`

No Tests Implemented

Verify the effect of KMAC returning an error during a keymgr operation.

Configure keymgr to enter any of the 3 working states.
Issue a keymgr operation.
While the KMAC is actively computing the digest, glitch the KMAC app sparse FSM to trigger a fault.
Verify that KMAC returns an error signal to the keymgr via checking keymgr CSRs, when the operation is done:
- Check op_status is set to DONE_ERROR.
- Check fault_status.kmac_done is set to 1.

`chip_sw_keymgr_derive_attestation`

Test: chip_sw_keymgr_derive_attestation

Verify the Attestation CDI.

For each keymgr operational state: CreatorRootKey, OwnerIntKey and OwnerKey:
- Generate identity SW output for the Attestation CDI.
- Generate OTBN sideload output for the Attestation CDI.
Ensure that the key output changes after calculating the previous steps after a keymgr advance operation.
The keymgr shall be able to reproduce the same keys for a give device configuration and known set of inputs.
The software binding registers must be locked after configuration until a keymgr advance operation.

Notes:

The device initial state needs to be equivalent to the end state of the manuf_ft_provision_rma_token_and_personalization testpoint, otherwise the keymgr will fail to advance into operational states.
Ensure the entropy complex is running in continuous mode, and that KMAC is configured to extract entropy from EDN.
The test should check for any error or fault code status, to ensure all operations executed successfully.

`chip_sw_keymgr_derive_sealing`

Test: chip_sw_keymgr_derive_sealing

Verify the Sealing CDI.

Same as chip_sw_keymgr_derive_attestation, except using Sealing CDI outputs.

To test key versioning:

Configure the max version register for each keymgr operational state.
Test a valid and an invalid key version when generating SW and sideload keys.

`chip_sw_kmac_sha3_stress`

No Tests Implemented

Verify all SHA3 modes of operation.

Verify the following digest sizes: 224, 256, 384, 512
Verify input message size of 0 bytes.
Verify multiple input message sizes as defined in NIST test vectors.
Use endianess configuration used in the crypto library.

`chip_sw_kmac_shake_stress`

No Tests Implemented

Verify all SHAKE modes of operation.

Verify the following security configurations: 128, 256
Verify input message size of 0 bytes.
Verify multiple input message sizes as defined in NIST test vectors.
Use endianess configuration used in the crypto library.
Verify multiple XOF configurations.

`chip_sw_kmac_cshake_stress`

No Tests Implemented

Verify all cSHAKE modes of operation.

Verify the following security configurations: 128, 256
Verify input message size of 0 bytes.
Verify multiple input message sizes as defined in NIST test vectors.
Use endianess configuration used in the crypto library.
Verify multiple XOF configurations.

`chip_sw_kmac_kmac_stress`

No Tests Implemented

Verify all KMAC modes of operation.

Verify the following security configurations: 128, 256
Verify input message size of 0 bytes.
Verify multiple input message sizes as defined in NIST test vectors.
Use endianess configuration used in the crypto library.

`chip_sw_kmac_kmac_key_sideload`

No Tests Implemented

Verify all KMAC key sideload.

Procedure:

Configure the keymgr to sideload a key to KMAC.
Generate a KMAC output and store it in retention RAM.
Clear sideload key from keymgr.
Create a new sideload key with a different salt using keymgr.
Verify that KMAC can no longer reproduce the same KMAC output.
Perform software initiated reset.
Configure the keymgr again to sideload a key to KMAC.
Verify digest against value stored in retention RAM.

Additional test configurations:

Verify the following security configurations: 128, 256
Use endianess configuration used in the crypto library.

`chip_sw_kmac_endianess`

No Tests Implemented

Verify all KMAC endinaness options

This is a low priority test P3.

Test the permutation of all endinaness configuration options for message and digest registers.

`chip_sw_kmac_entropy_stress`

No Tests Implemented

Verify all KMAC entropy configuration options.

Verify all entropy modes of operation (e.g. software, EDN). Depending on the mode of operation, exercise relevant functionality, for example:

Entropy period
Entropy refresh hash count
Entropy seed

Process many message blocks in KMAC configuration for all entropy modes, and verify that there are no error conditions.

`chip_sw_kmac_error_conditions`

No Tests Implemented

Verify reporting of KMAC errors

This is a negative test case covering the following error conditions:

ErrKeyNotValid: covers that secret key is invalid when KeyMgr initiates App operation
ErrSwPushedMsgFifo: covers that SW writes the msgfifo while App interface is active
ErrSwIssuedCmdInAppActive: covers that SW writes all possible commands to the KMAC while App interface is active
ErrWaitTimerExpired: covers that the KMAC timed out while waiting for EDN entropy
ErrIncorrectEntropyMode: covers that incorrect entropy modes are detected by the KMAC
ErrUnexpectedModeStrength: covers that 128-bit strength is seen for SHA3, and all but 128/256 bit strengths are seen for XOF functions
ErrIncorrectFunctionName: covers that the function name is configured incorrectly when KMAC mode is enabled
ErrSwCmdSequence: covers that SW issues commands to the KMAC out of order
Shadow register update alert: covers that the an recoverable alert is triggered on active shadow register update error
ErrSwHashingWithoutEntropyReady: covers that starting a hash operation when the entropy is not ready triggers an error

Some of the error conditions may be difficult to reproduce in silicon. In such cases, update the test description to capture any limitations.

`chip_sw_lc_ctrl_kmac_error`

No Tests Implemented

Verify the effect of KMAC returning an error during the hash generation of LC tokens.

Follow the steps in chip_sw_lc_ctrl_kmac_req test.
While the KMAC is actively computing the digest, glitch the KMAC app sparse FSM to trigger a fault.
Verify that KMAC returns an error signal to the LC controller.
TBD

`chip_sw_lc_ctrl_debug_access`

No Tests Implemented

Verify debug access for each lifecycle state.

For each lifecycle state verify the debug and CPU access to make sure it matches the specification.

`chip_sw_otp_ctrl_vendor_test_csr_access`

Test: chip_sw_otp_ctrl_vendor_test_csr_access

Verify the vendor test control access in raw, test_*, dev, prod, and rma LC states.

Boot the chip successively in raw, test_*, dev, prod and rma LC states.
Verify that the SW is able to access the vendor test control and status registers in raw, test_* and rma LC states. In open source environment, this check is implemented by probing the OTP_CTRL’s lc_otp_vendor_test_i port.
Verify that in dev / prod LC states, the vendor status always reads back 0s regardless of what is programmed into the vendor test control register.
Once VENDOR_TEST_READ_LOCK is 0, Try to read / write to see it triggered access error.
For sival, real vendor test will be done by a silicon vendor and nothing need to be done in the open source side.

`chip_sw_otp_ctrl_escalation`

Test: chip_sw_otp_ctrl_escalation

Verify escalation from otp_ctrl macro fatal error.

Inject ECC fatal error into OTP macro’s HW cfg partition, and read back this macro via DAI interface.
Because this fatal error will immediately turn off CPU, so the DV sequence will probe the alert interface to make sure alert and escalation is triggered.

X’ref with chip_sw_all_escalation_resets. SiVal: It is not feasible to inject ECC fatal errors in OTP macro.

`otp_ctrl_calibration`

No Tests Implemented

Verify all calibrated parameters are programmed during manufacturing stage calibration test phase. For sival this test can be done by

manuf_cp_ast_test_execution

`otp_ctrl_partition_access_locked`

No Tests Implemented

Verify accessibily of all partition except life_cycle partition.

Without locking state, try random write and read back test over all sw accessible partitions.
Per each partition, enable write lock and try to do subsequent write then readback.
Dut should generate recoverable error (access error) and 2nd write won’t go through.
Per each partition, enable read lock and try to read.
Dut should generate recoverable error (access error).

`otp_ctrl_check_timeout`

No Tests Implemented

Verify check_tiemout feature.

Program otp_ctrl.check_timeout value small value (e.g. 1000 cycles).
Write 1 to otp_ctrl.check_trigger.integrity.
After timeout cycle, check otp_ctrl.status.timeout_error = 1.
Write 1 to otp_ctrl.check_trigger.consistency.
After timeout cycle, check otp_ctrl.status.timeout_error = 1.

`chip_sw_pwm_smoketest`

No Tests Implemented

Verify that the PWM outputs correct wave.

Program the PWM to output waves of 24hz, 48, 98hz.
Program the duty cycle to 11%, 36%, 50%, 71%, and 91%.
The test harness should check that the frequency and duty cycle is correct within a tolerance of 2%.

`chip_sw_sensor_ctrl_deep_sleep_wake_up`

Test: chip_sw_pwrmgr_sensor_ctrl_deep_sleep_wake_up

Verify that the chip will wake up from deep sleep by sensor_ctrl.

This forces the sensor_ctrl alert input from AST to trigger wake up. It does this while the chip is in deep sleep, so clocks are off. SiVal: This test can only run in sim_dv.

`chip_sw_pwrmgr_usb_clk_disabled_when_active`

Test: chip_sw_pwrmgr_usb_clk_disabled_when_active

Verify that the USB stops responding when its clock is disabled in active state.

Configure the pwrmgr CONTROL CSR with USB_CLK_EN_ACTIVE off, and issue a CSR read to the USB. This CSR read should cause the CPU to hung. Prior to this read, configure the watchdog to bite, and the test passes if there is a watchdog reset.

SiVal: CPU must be enabled, but no other OTP or lifecycle dependencies.

`chip_sw_all_resets`

Test: chip_sw_pwrmgr_all_reset_reqs

Verify resets by relevant reset sources when active.

POR (HW PAD) reset, SW POR, sysrst, wdog timer reset, esc rst.
rstmgr sw reset is in rstmgr testplan.
ndm reset is in rv_dm testplan. This test is like the pwrmgr_*_sleep_all_reset_reqs tests, except the CPU will just spin_wait for a reset, so the pwrmgr will be in active state. SiVal: The CPU must be enabled to configure the test.

`chip_sw_rom_ctrl_kmac_error`

No Tests Implemented

Verify the effect of KMAC reporting an error during ROM digest computation.

Backdoor load a valid test ROM image and bring the DUT out of reset.
During the ROM checker pwrmgr FSM state, while the ROM controller is actively sending data to KMAC for the digest computation, glitch the KMAC app sparse FSM to trigger a fault.
Verify that KMAC returns an error signal to the ROM controller.
Verify that the ROM controller itself transitions to invalid state and the chip is effectively dead. SiVal: Creating a glitch is not feasible, so this is not a sival test.

`chip_sw_rom_ctrl_digests`

No Tests Implemented

Check that the (real and expected) ROM digests are accessible through CSRs.

Read the DIGEST_* and EXP_DIGEST_* CSRs and check they match (if they differed, we wouldn’t be running!)
Check that they also match the digest words that we expect.

`chip_sw_rv_core_ibex_alerts`

No Tests Implemented

Inject and verify all available faults in rv_core_ibex / ibex_top.

Inject faults in the following areas and verify the alert is fired leading to an escalation.

Bus integrity error on the data and instruction TL interface (on the response channel)
PC mismatch fault
ECC error in the register file

`chip_rv_dm_perform_debug`

Tests:

rom_e2e_jtag_debug_test_unlocked0
rom_e2e_jtag_debug_dev
rom_e2e_jtag_debug_rma
X-ref’ed with rom_e2e_jtag_debug from rom testplan.

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 can be debugged in TEST, DEV, and RMA life cycle states.
- Test debugging with commands to GDB connected via OpenOCD and JTAG (or the SystemVerilog based JTAG debugger model in case of DV simulations).
- Read back GDB responses to check they match expected behaviour
- Connect a debugger and verify that ROM halts very early in rom_start.S.
- Trial the following activities within GDB, ensuring the correct behaviour is seen:
  - Halting execution and resetting
  - Setting, hitting and deleting breakpoints using all available hardware breakpoints
  - Single stepping
    - In particular single step over wfi
  - Reading and writing all registers
  - Reading all CSRs and writing some (write set TBD)
  - Reading and writing memory (both SRAM and device)
  - Setting the PC to jump to some location
  - Executing code from GDB (using the call command)
- Verify that ROM fails to boot with BFV:0142500d.

`chip_sw_rv_dm_access_after_hw_reset`

Test: chip_sw_rv_dm_access_after_escalation_reset

Verify RV_DM works after a watchdog or escalated reset.

Access some RV_DM CSRs both before and after resets.
An activation would be required, as the tap strap would also be sampled again.

`chip_sw_plic_alerts`

Test: chip_sw_all_escalation_resets

Verify alerts from PLIC due to both, TL intg and reg WE onehot check faults.

Since PLIC is not pre-verified in a DV environment, we need to ensure these are tested separately.

`tick_configuration`

Test: chip_sw_rv_timer_systick_test

Verify that the timer can be configured to generate a system tick.

Configure the timer to generate a tick of T microseconds long.
Enable the timer.
Start a busy loop of 5 milliseconds based on the mcycleh CSR.
Read the number of ticks n.
Verify that n * T ~= 5 milliseconds within 3% of tolerance.
Repeat for T in: [1, 5, 25, 100, 125]

`counter_wrap`

Test: chip_sw_rv_timer_systick_test

Verify that the timer counter will wrap to zero when the limit is reached.

Enable interrupts.
Set the counter to UINT64_MAX - 5 milliseconds.
Set the compare register to UINT64_MAX.
Enable the timer.
Start a busy loop of 5 milliseconds based on the mcycleh CSR.
Verify that the counter has wrapped around by reading mtime.
Verify that the interrupt has fired.

`chip_sw_spi_device_pass_through_flash_model`

No Tests Implemented

Verify the command filtering mechanism in passthrough mode.

Extend the chip_spi_device_pass_through test.
Connect with a real flash model on spi_host.
Verify that the flash commands are received and interpreted correctly in the flash model.

`chip_sw_spi_device_output_when_disabled_or_sleeping`

Test: chip_sw_spi_device_pinmux_sleep_retention

Verify spi_device output values when spi_device is disabled or the chip is sleeping.

SW needs to be able to set the SPI output value when spi_device is disabled or the chip is sleeping, to either all-zeros or all-ones, depending on integration requirements. The following scenarios have to be verified:

After power-on reset:

SW to configure pinmux retention logic so that the chip pins connected to spi_device outputs are (a) always zero or (b) always one (SW needs to be able to choose between a and b).
DV environment to check that SPI outputs match configuration by SW.

Going to sleep:

SW to disable spi_device, wait until CSb is high, configure pinmux retention logic as it would after POR, and put chip to sleep.
DV environment to check that SPI outputs match configuration by SW.

Wake up from sleep:

DV environment to wake chip from sleep.
SW to enable spi_device and disable retention logic.
DV environment to check that SPI transactions work as usual.

Notes for silicon targets: This test currently does not exercise any features of the spi_device block itself, which is why the “features” list is empty. It may be reclassifed in the future.

`chip_sw_spi_host_pass_through`

No Tests Implemented

Verify that the SPI host can be configured in pass through mode. Essentially the configuration is as follows: (real) host -> OT -> flash device

Connect one of the OpenTitan SPI hosts to a SPI device on a serial NOR flash.
Configure an OpenTitan SPI device and the above mentioned OpenTitan SPI host in pass through mode.
Use the testbench’s (external) SPI host to write a word to the flash through the passthrough SPI host and device in OpenTitan.
Let the testbench read that word back, again through the pass through of the SPI host and device on OpenTitan.
The testbench should check that the word read back is the same as the one written.

`chip_sw_spi_host_configuration`

No Tests Implemented

Verifiy that the polarity configurations work appropriately.

Send four packets from the host to the device, each one with a different configuration for cpol and cpha.
The device should receive the packets and be able to decode them with the appropriated configuration.

`chip_sw_spi_host_events`

No Tests Implemented

Verify that various events are correctly triggered by the SPI host.

For the transmit empty and watermark events:
- Fill the transmit queue on the Ibex side.
- Clear and enable the respective interrupt.
- Testbench should check that it receives the same data as Ibex has sent.
- Ibex should check whether it has received the transmit empty or watermark interrupt within a reasonable amount of time.
For the receive full and watermark events:
- Empty the receive queue.
- Clear and enable the respective interrupt.
- Testbench sends as much data as the receive queue can hold for the full interrupt or the amount necessary to hit the watermark.
- Ibex checks that the receive full or watermark interrupt is raised.

`chip_sw_sram_memset`

No Tests Implemented

Use the LFSR-based initialisation mechanism to wipe the contents of SRAM.

Write some known data to the main SRAM and read it back to make sure the write worked as expected.
Use the INIT CSR for the relevant sram_ctrl to request that the memory is filled with pseudo-random data.
Read the location from the SRAM and check that the data has been wiped.
Repeat the steps above for the retention SRAM.

`chip_sw_sram_readback`

No Tests Implemented

Enable the SRAM readback feature and write and read data from and to the SRAM.

Enable the SRAM readback feature.
Write some known data to the ret. SRAM and read it back to make sure the write worked as expected.
Use the INIT CSR for the relevant sram_ctrl to request that the memory is filled with pseudo-random data.
Read the location from the SRAM and check that the data has been wiped.
Repeat the steps above with the disabled SRAM readback feature.
Lock the SRAM readback configuration register and try to set it.

`chip_sw_sram_subword_access`

No Tests Implemented

Check that subword access works for each SRAM.

Initialise a region of the SRAM with known patterns.
Read subwords (each length from one byte upwards; each address modulo 8) and check they have the expected values.
Write subwords (same list as above) and read back the whole word that we touch in each case. Check that only the expected bytes have been changed.

`chip_sw_uart_parity`

No Tests Implemented

Verify transmission of data in both directions with parity enabled.

This is very similar to chip_sw_uart_tx_rx except that parity (generation and checking) should be enabled. Control expected word parity by configuring CTRL.PARITY_ODD register.

Test the rx_parity_err interrupt by sending a word with incorrect parity.

`chip_sw_uart_line_loopback`

No Tests Implemented

Verify UART line loopback feature.

Configure the UART to enable RX, TX and line loopback. Send it some data and check that the bits appear on its TX side.

`chip_sw_uart_system_loopback`

No Tests Implemented

Verify UART system loopback feature.

Configure the UART to enable RX, TX and system loopback. Transmit some data and check that the data that was transmitted also appears on the RX side.

`chip_sw_uart_line_break`

No Tests Implemented

Check that the UART can detect line breaks.

Enable RX and configure the line break threshold. On the host side, send data but hold the signal low for enough characters that this should be detected as a line break. Check that the rx_break_err interrupt was asserted.

Repeat with parity enabled and with different line break thresholds (controlled by CTRL.RXBLVL).

`chip_sw_uart_watermarks`

Test: chip_sw_uart_tx_rx

Observe UART watermark interrupts.

Transmit data from the host and receive it on the OT side by servicing the rx_watermark interrupt. Check that the data matches the sequence that the host was expected to send.

Send the data back from OT to the host, refilling the TX FIFO on reception of the tx_watermark interrupt. On the host side, check that the data that came back matches the sequence that was sent in the first place.

`chip_sw_usbdev_stream`

Test: chip_sw_usbdev_stream

Verify the transmission of randomized Bulk Transfer stream data to/from host/DPI model.

This test extends from chip_sw_usbdev_tx_rx.
All endpoints in use simultaneously.
Randomized packet contents and length; LFSR-generated data at device is combined with host LFSR-generated byte stream.
Checking of both byte streams when returned to the device.
Randomized retrying when using the DPI model.
With a physical host this requires the usbdev/stream_test host- side test application.

`chip_sw_usbdev_iso`

No Tests Implemented

Verify the transmission of randomized Isochronous Transfer stream data to/from host/DPI model.

This test extends from chip_sw_usbdev_stream.
Maximal endpoints in use simultaneously (limited by bandwidth).
Randomized packet contents and length; LFSR-generated data at device is combined with host LFSR-generated byte stream.
Checking of both byte streams when returned to the device.
Expectation of and recovery from packet-dropping, prioritizing guaranteed service over reliability.
With a physical host this requires the usbdev/stream_test host- side test application.

`chip_sw_usbdev_mixed`

No Tests Implemented

Verify the transmission of randomized Control, Interrupt, Bulk and Isochronous Transfer stream data to/from host/DPI model.

This test extends from chip_sw_usbdev_iso by adding Control Endpoints and Interrupt endpoints alongside the Isochronous and Bulk Endpoints.
Streaming occurs simultaneously to all endpoints of all types.
With a physical host this requires the usbdev/stream_test host- side test application.

`chip_sw_usbdev_suspend_resume`

No Tests Implemented

Verify that the USB device can detect Suspend and Resume Signaling from the host.

Host configures the USB device as normal.
Host requests that the USB device enter a Suspended state, by ceasing activity and leaving the USB Idle for more than 3.0ms.
Check that the usbdev link state becomes Suspended.
Host performs Resume Signaling.
Check that SOF has resumed and usbdev enters the Resuming state and subsequently the Active state.
With a physical host this requires the usbdev/suspend_test host-side test application to perform Suspend/Resume Signaling.
Note: this test does not engage the AON Wake module or enter a low power state.

`chip_sw_usbdev_aon_wake_reset`

No Tests Implemented

Verify that the USB AON Wake module can detect Bus Resets from the host.

Host configures the USB device as normal and subsequently performs Suspend signaling.
Device software requests that the AON Wake module take control of the USB.
Host issues a Bus Reset to the USB device.
Check that the AON Wake module reports a Bus Reset.
Check that, in response to software request, the AON Wake module returns control of the USB pull ups to usbdev.
With a physical host this requires the usbdev/suspend_test host-side test application to perform Suspend Signaling and to issue a Bus Reset to the USB device.
Note: this test does not exercise power manager-related functionality and does not enter any low power mode.

`chip_sw_usbdev_aon_wake_disconnect`

No Tests Implemented

Verify that the USB AON Wake module can detect USB Disconnects.

Host configures the USB device as normal and subsequently performs Suspend signaling.
Device software requests that the AON Wake module take control of the USB.
Host or HyperDebug Disconnects the USB device from the USB.
Check that the AON Wake module reports a Disconnect.
Check that, in response to software request, the AON Wake module returns control of the USB pull ups to usbdev.
With a physical host this requires the usbdev/suspend_test host-side test application to perform Suspend Signaling.
This test requires either HyperDebug-based control of the VBUS connection on the SiVal test board or host-side code and a hub that is capable of power control.
Note: this test does not exercise power manager-related functionality and does not enter any low power mode.

Covergroups

regwen_val_when_new_value_written_cg

Cover each lockable reg field with these 2 cases:

When regwen = 1, a different value is written to the lockable CSR field, and a read occurs after that.
When regwen = 0, a different value is written to the lockable CSR field, and a read occurs after that.

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

tl_errors_cg

Cover the following error cases on TL-UL bus:

TL-UL protocol error cases.
OpenTitan defined error cases, refer to testpoint tl_d_illegal_access.