Earlgrey Chip DV document

Goals

  • DV
    • Verify top_earlgrey features by running dynamic simulations with a SV/UVM based testbench.
    • Verify the integration of all pre-verified IPs instantiated in the chip.
    • Verify the integration and the internal design of non-pre-verified IPs instantiated in the chip.
    • Verify system level scenarios for correctness of our design assumptions and behavior.
    • Verify the full chip configuration and memory address space by running the automated tests.
    • Stress test the XBAR structures in the chip.
  • FPV
    • Verify the connectivity of signals (that are excluded from functional DV above) from point A to point B.
    • Secure verification
      • Check for leakage of secure data into unsecure locations / paths and vice-versa using the Cadence SPV tool.

Current status

Design features

For detailed information on top_earlgrey design features, please see the Earl Grey Top Level Specification.

Testbench architecture

The top_earlgrey chip level testbench has been constructed based on the CIP testbench architecture.

Block diagram

TBD

Top level testbench

Top level testbench is located at hw/ip/top_earlgrey/dv/tb/tb.sv. It instantiates the top_earlgrey DUT module hw/top_earlgrey/rtl/autogen/chip_earlgrey_asic.sv. In addition, it instantiates the following interfaces, connects them to the DUT and sets their handle into uvm_config_db:

  • Clock and reset interface
    • Main clock as well as USB clock
  • TileLink host interface
    • This is connected to the CPU’s data port.
  • JTAG interface
  • SPI interface
  • UART interface
  • SW logger inteface (for test boot ROM as well as the test SW)
  • SW test status monitor
  • Backdoor memory interfaces (for ROM, SRAM and the flask banks)
  • Individual control pins:
    • Bootstrap
    • JTAG/SPI switch
    • SRST_N

Common DV utility components

The following utilities provide generic helper tasks and functions to perform activities that are common across the project:

Global types & methods

All common types and methods defined at the package level can be found in the chip_env_pkg. Some of them in use are:

[list a few parameters, types & methods; no need to mention all]

TL_agent

The full chip testbench instantiates (already handled in CIP base env) the tl_agent which provides the ability to drive and independently monitor random traffic via TL host interface into CHIP device.

UART Agent

[Describe here or add link to its README]

SPI Agent

[Describe here or add link to its README]

JTAG Agent

[Describe here or add link to its README]

I2C Agent

[Describe here or add link to its README]

USB20 Agent

[Describe here or add link to its README]

UVM RAL Model

The CHIP RAL model is created with the ralgen FuseSoC generator script automatically when the simulation is at the build stage.

It can be created manually (separately) by running make in the the hw/ area.

Reference models

Testbench configurations

Stub CPU mode

Bare-metal SW test mode

XBAR integration mode

Stimulus strategy

Test sequences

All test sequences reside in hw/ip/chip/dv/env/seq_lib. The chip_base_vseq virtual sequence is extended from cip_base_vseq and serves as a starting point. All test sequences are extended from chip_base_vseq. It provides commonly used handles, variables, functions and tasks that the test sequences can simple use / call. Some of the most commonly used tasks / functions are as follows:

  • task 1:
  • task 2:

Functional coverage

To ensure high quality constrained random stimulus, it is necessary to develop a functional coverage model. The following covergroups have been developed to prove that the test intent has been adequately met:

  • cg1:
  • cg2:

Self-checking strategy

Scoreboard

The chip_scoreboard is primarily used for end to end checking. It creates the following analysis ports to retrieve the data monitored by corresponding interface agents:

  • analysis port1:
  • analysis port2:

Assertions

  • TLUL assertions: The tb/chip_bind.sv binds the tlul_assert assertions to the IP to ensure TileLink interface protocol compliance.
  • Unknown checks on DUT outputs: The RTL has assertions to ensure all outputs are initialized to known values after coming out of reset.
  • assert prop 1:
  • assert prop 2:

Building and running tests

DV simulations for top_earlgrey are run with the dvsim tool. Please take a look at the link for detailed information on the usage, capabilities, features and known issues. The basic UART transmit and receive test can be run with the following command:

$ ./util/dvsim/dvsim.py hw/top_earlgrey/dv/chip_sim_cfg.hjson -i chip_uart_tx_rx

For a list of available tests to run, please see the ‘Tests’ column in the testplan below.

Regressions

Sanity

SW access

Nightly

Testplan (RTL simulations)

Testpoints

Milestone Name Tests Description
V1 chip_sw_uart_tx_rx 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.

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

V1 chip_sw_uart_rand_baudrate chip_sw_uart_rand_baudrate

Verify UART transmission of data at various speeds.

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

V1 chip_sw_uart_tx_rx_alt_clk_freq chip_sw_uart_tx_rx_alt_clk_freq
chip_sw_uart_tx_rx_alt_clk_freq_low_speed
chip_sw_uart_tx_rx_alt_clk_fast_ip_clk

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.
V1 chip_sw_gpio_out chip_sw_gpio

Verify GPIO outputs.

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

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

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

V1 chip_sw_example_test_from_rom_or_flash chip_sw_example_flash
chip_sw_example_rom

Run examples tests developed for each boot stage.

Our test infrastructure defaults to running tests out flash, at the ROM_EXT stage, but also supports running tests in the ROM stage. We develop example tests to demonstrate these capabilities, and need to run them in DV to ensure the integrity of our infrastructure.

V1 csr_hw_reset 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.
V1 csr_rw 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.
V1 csr_bit_bash 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.
V1 csr_aliasing 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.
V1 csr_mem_rw_with_rand_reset 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.
V1 regwen_csr_and_corresponding_lockable_csr 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.

V1 xbar_smoke xbar_chip_smoke

Sequentially test each host to access any device

V2 chip_sw_spi_device_tx_rx chip_sw_spi_device_tx_rx

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

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

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

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

  • Configure the SPI device and host in pass through mode.
  • Configure and enable both spi_host0 and spi_host1
  • Send a random flash commands over the SPI device interface (chip IOs) from the testbench.
  • Verify the flash commands which pass through spi_host0, are received on chip IOs.
  • Verify spi_host1 doesn't send out any data from spi_device
  • Run with min (6MHz), typical (30-48Mhz) and max(48MHz) 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
V2 chip_sw_spi_device_pass_through_filter

Verify the command filtering mechanism in passthrough mode.

  • Extend the chip_spi_device_pass_through test.
  • Program the cmd_filter_* CSRs to filter out certain commands. a one byte command (such as Chip Erase) and a multi-bytes command (such as Program or Sector/Block Erase) must be added to filter
  • Verify that only the payloads that are not filtered show up on the SPI host interface at chip IOs.
V2 chip_sw_spi_device_pass_through_flash_model

Verify the command filtering mechanism in passthrough mode.

  • Extend the chip_spi_device_pass_through and chip_spi_device_pass_through_filter tests.
  • Connect with a real flash model on spi_host
  • Verify that the flash commands are received and interpreted correctly in the flash model
V2 chip_conn_spi_device_ast

Verify the connectivity between spi_device and AST on scanmode and mbist

This could be done through the connectivity test with FPV

V2 chip_sw_spi_device_pass_through_collision

Verify the collisions on driving spi_host is handled properly

TODO, add detail testplan once we have a conclusion on #5134

V2 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.
  • At the same time, the testbench transfers a known payload from device to host on the SPI host interface.
  • The SPI device monitor in the testbench grabs the host payload and verifies its integrity.
  • The SW verifies the device payload for integrity and services the SPI event interrupt.
  • Run with min and max SPI clk frequencies and with single, dual and quad SPI modes.

Verify all SPI host instances in the chip.

V2 chip_sw_i2c_host_tx_rx

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 and verified by the testbench for correctness.
  • SW validates the reception of FMT watermark and trans complete interrupts.
  • Verify the virtual / true open drain capability.

Verify all instances of I2C in the chip.

V2 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.
  • SW validates the reception of RX watermark and trans complete interrupts.
  • Verify the virtual / true open drain capability.

Verify all instances of I2C in the chip.

V2 chip_sw_usb_fs_tx_rx

Verify the transmission of single-ended data over the USB at full speed. As a part of this test, the enablement of USB pullup is also expected to be verified.

  • Set tx_differential_mode to single-ended and rx_differential_mode to differential. The other modes are not supported in OpenTitan.
  • configure Link state to Active.
  • Send and receive packets to fill the entire buffer. Ensure all the packets are correct.
  • Check interrupts (connected, pkt_received, pkt_sent, av_empty, rx_full) are triggered correcly.
V2 chip_sw_usb_vbus

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.
  • VBUS is controlled by SW, through programming CSRs (override_pwr_sense_en and override_pwr_sense_val) to connect / disconnect the USB.
  • Disconnect the USB to trigger disconnected interrupt.
  • Then reconnect it and check the connected interrupt.
  • Re-enable data transfer and ensure data correctness.
  • Observe valid reference pulse usb_ref_val/pulse_o.
V2 chip_sw_usb_suspend

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

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

  • Configure to enable usb_ref_disable.
  • Send a frame with the same frame number as the USB device to trigger frame interrupt.
  • Ensure usb_ref_pulse_o and usb_ref_val_o behave correctly.
  • Stop sending any frame and check the host_lost interrupt. Ensure use_ref_* behave correctly.
V2 chip_usb_wake_debug

Verify that usb_state_debug_i can be read from the CSR

  • Drive random value on usb_state_debug_i.
  • Ensure the CSR wake_debug returns correctly value.
V2 chip_usb_enumeration

Verify USB enumeration. Details are not clear.

  • TODO
V2 chip_sw_pin_mux

Verify the MIO muxing at input and output sides.

SW programs MIO INSEL and OUTSEL CSRs to connect and verify each muxed source. At the moment, GPIOs are the only mux inputs.

V2 chip_sw_sleep_pin_mio_dio_val

Verify the MIO output values in deep sleep state.

SW programs the MIO OUTSEL CSRs to to ensure that in deep 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.

V2 chip_sw_sleep_pin_wake

Verify pin wake up from deep sleep state.

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.

V2 chip_sw_tap_strap_sampling chip_tap_straps_dev
chip_tap_straps_prod
chip_tap_straps_rma

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.

V2 chip_sw_padctrl_attributes

Verify pad attribute settings for all MIO and DIO pads.

V2 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.
V2 chip_sw_sleep_pwm_pulses 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.
V2 chip_sw_data_integrity

Verify the alert signaling mechanism due to data integrity violation.

An automated SW test which performs the following for each IP:

  • Pick a CSR to write.
  • Corrupt a random control / data / integrity bit at the CPU source using SV force.
  • Verify that the device detects the integrity violation causing an alert.
  • Verify the alert upto the NMI stage.
  • Now pick a CSR to read.
  • Corrupt a random control / data / integrity bit at the device using SV force.
  • Verify that the CPU detects the integrity violation causing an alert.
  • Verify the alert upto the NMI stage.
V2 chip_jtag_csr_rw 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.
V2 chip_jtag_mem_access 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, preload the memory with random data via backdoor.
  • Shuffle the list of memories again.
  • Read the previously written addresses in the memories back again and check the read value for correctness. Pick some random addresses to verify in case of read-only memories.
V2 chip_rv_dm_cpu_debug_mem_not_accessable

Verify that the debug mem can't be accessed from the CPU while not in the debug mode.

TODO, add stimulus and checks

V2 chip_rv_dm_perform_debug
  • X-ref'ed with mask_rom_rv_dm_perform_debug from mask rom testplan
V2 chip_rv_dm_ndm_reset_req 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.
  • 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.
V2 chip_rv_dm_ndm_reset_req_when_ibex_halted

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

  • Configure ibex in halted state (dmstatus.anyhalted/dmstatus.allhalted is asserted).
  • Configure RV_DM to send NDM reset request.
  • Check that halted state is clear (dmstatus.anyhalted/dmstatus.allhalted should be de-asserted).
V2 chip_rv_dm_access_after_wakeup

Verify RV_DM works after wakes up from sleep.

  • Put the chip into sleep mode and then wake up.
  • Access some RV_DM CSRs to ensure that RV_DM doesn't need a full reset to work.
V2 chip_sw_rv_dm_jtag_tap_sel

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.
  • TODO, X-ref'ed with the LC tests.
V2 chip_sw_rv_dm_lc_disabled

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

  • Put life cycle on states other than Test, RMA and DEV.
  • Verify that the rv_dm bus device is inaccessible from the CPU as well as external JTAG.
  • Verify that the JTAG TAP is unavailable.
  • X-ref'ed with chip_tap_strap_sampling
V2 chip_sw_timer chip_sw_rv_timer_irq

Verify the timeout interrupt assertion.

  • Configure the RV_TIMER to generate interrupt after a set timeout.
  • Issue a WFI to wait for the interrupt to trigger.
  • Service the interrupt when it triggers; verify that it came from rv_timer.
  • Verify that the interrupt triggered only after the timeout elapsed.
V2 chip_sw_aon_timer_wakeup_irq 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.
V2 chip_sw_aon_timer_sleep_wakeup 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.
V2 chip_conn_aon_timer_clks_resets

Verify that the correct clocks and resets are connected to the AON timer.

  • The chip_aon_timer_deep_sleep_wakeup achieves this goal.
  • Verify via connectivity assertion checks, the right clocks and resets from clkmgr and rstmgr are connected to AON timer.
V2 chip_sw_aon_timer_wdog_bark_irq 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.
V2 chip_sw_aon_timer_wdog_lc_escalate 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.
V2 chip_sw_aon_timer_wdog_bite_reset 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.
V2 chip_sw_aon_timer_sleep_wdog_bite_reset 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.
V2 chip_sw_aon_timer_sleep_wdog_sleep_pause 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.
V2 chip_sw_plic_all_irqs chip_plic_all_irqs

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.

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

V2 chip_sw_plic_nmi_irq

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

TBD if multiple NMI irqs are OR-ed into the CPU (example - NMI from alert handler and the watchdog bark), then map each test to this testpoint.

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

V2 chip_sw_clkmgr_off_trans 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, and verify the rstmgr crash dump info records the CSR address.

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

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

V2 chip_conn_clkmgr_div chip_sw_clkmgr_external_clk_src_for_sw_fast
chip_sw_clkmgr_external_clk_src_for_sw_slow
chip_sw_clkmgr_external_clk_src_for_lc

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.

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

V2 chip_sw_clkmgr_external_clk_src_for_sw chip_sw_clkmgr_external_clk_src_for_sw_fast
chip_sw_clkmgr_external_clk_src_for_sw_slow

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

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

V2 chip_sw_clkmgr_jitter 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_main_scrambled_access_jitter_en

Verify the clock jitter functionality.

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

X-ref with various specific jitter enable tests.

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

V2 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 randomly enabling clocks. Upon wakeup interrupt the clock measurements should be on, and the recoverable fault status may have faults for only the disabled clocks.

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

V2 chip_sw_clkmgr_escalation_reset

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

Trigger an internal fault (measurement error timeout) 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.

V2 chip_sw_pwrmgr_external_full_reset 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 records POR in reset_info CSR.

V2 chip_sw_pwrmgr_normal_sleep_all_wake_ups 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 low power, optionally disabling the source's clock, have the source issue a wakeup event and verify wake_info indicates the expected wakeup.

V2 chip_sw_pwrmgr_sleep_all_reset_reqs chip_sw_aon_timer_wdog_bite_reset

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

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

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

V2 chip_sw_pwrmgr_deep_sleep_all_reset_reqs chip_sw_pwrmgr_deep_sleep_all_reset_reqs

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

This verifies ALL reset sources.

  • 7 resets are generated randomly with deep sleeps
  • POR (HW PAD) reset, SW POR, sysrst, wdog timer reset, esc rst, SW req
  • esc reset is followd by normal mode because it does not work with sleep mode
V2 chip_sw_pwrmgr_normal_sleep_all_reset_reqs 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
V2 chip_sw_pwrmgr_wdog_reset 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.

V2 chip_sw_pwrmgr_aon_power_glitch_reset 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 records POR in reset_info CSR.

V2 chip_sw_pwrmgr_main_power_glitch_reset 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 reading the reset_info CSR when the test restarts and the POR bit is not set.

V2 chip_sw_pwrmgr_deep_sleep_power_glitch_reset 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 reading the reset_info CSR when the test restarts and the POR bit is not set.

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.
V2 chip_sw_pwrmgr_sleep_power_glitch_reset 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 reading the reset_info CSR when the test restarts and the POR bit is not set.

V2 chip_sw_pwrmgr_random_sleep_all_reset_reqs chip_sw_pwrmgr_random_sleep_all_reset_reqs

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

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

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

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

V2 chip_sw_pwrmgr_debug_sleep

Verify low power entry is prevented when the chip is in "debuggable" state.

This is an open issue: https://github.com/lowRISC/opentitan/issues/7215

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

V2 chip_sw_pwrmgr_escalation_reset

Verify the power manager resets to a clean state after an internal fault causes the system to escalate to reset.

Upon alert escalation reset, the internal status should be clear and the pwrmgr should not attempt to send out more alerts.

V2 chip_sw_rstmgr_non_sys_reset_info chip_sw_pwrmgr_smoketest

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 reset_info CSR is as expected. This and other rstmgr testpoints that require different resets cross-reference the individual IP tests that generate those resets, and this testpoint merely adds reset checks in them. Those IP blocks are pwrmgr, alert_handler, aon_timer, and sysrst_ctrl.

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

V2 chip_sw_rstmgr_sys_reset_info

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 reset_info CSR is as expected. This testpoint cross-reference the rv_dm tests that generate this reset, and this testpoint merely adds reset checks in them.

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

V2 chip_sw_rstmgr_cpu_info 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_*sys_rstmgr_reset_info.

V2 chip_sw_rstmgr_sw_req_reset 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 reset_info CSR should reflect that a software request was the reset cause.

V2 chip_sw_rstmgr_alert_info 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. Refer to chip_*sys_rstmgr_reset_info.

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

V2 chip_sw_rstmgr_escalation_reset

Verify the reset manager resets to a clean state after an internal fault causes the system to escalate to reset.

Upon alert escalation reset, the internal status should be clear and the rstmgr should not attempt to send out more alerts.

V2 chip_sw_alert_handler_alerts 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.
V2 chip_sw_alert_handler_escalations

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 secrets to be wiped - read via SW to confirm.
  • Verify the third results in device being put in scrap state, via the LC JTAG TAP.
  • Verify the fourth results in chip reset.
  • Ensure that all escalation handshakes complete without errors.
V2 chip_sw_alert_handler_irqs chip_plic_all_irqs

Verify all classes of alert handler interrupts to the CPU.

X-ref'ed with the automated PLIC test.

V2 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 4'bff 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.
V2 chip_sw_alert_handler_crashdump

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.

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

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

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.
  • Trigger fatal alerts in an IP then configure clkmgr to turn off the IP clock. Check the IP's fatal alert resumes after clock is turned back on.
V2 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.
V2 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.

V2 chip_sw_lc_ctrl_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
    • Second escalation should cause the lc_escalation_en output to be asserted. Read the LC_STATE CSR to confirm that it is in the escalate state.
      • Verify that the escalate_en and check_bypass_en signals are asserted. X-ref'ed with the respective IP tests that consume these signals.
    • Third escalation should cause the LC ctrl to transition to the virtual scrap state. At this stage, the CPU is not operational. Read the LC_STATE CSR via backdoor and confirm that it is is in the scrap state.
      • Verify that all decoded outputs except for escalate_en and check_bypass_en are disabled. X-ref'ed with the respective IP tests that consume these signals.

X-ref'ed with chip_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.

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

V2 chip_sw_lc_ctrl_jtag_trst

Verify the JTAG test reset input connection to LC ctrl.

V2 chip_sw_lc_ctrl_otp_hw_cfg chip_sw_lc_ctrl_otp_hw_cfg

Verify the device_ID and ID_state CSRs

  • Preload the hw_cfg partition in OTP ctrl with random data.
  • Read the device ID and the ID state CSRs to verify their correctness.
  • Reset the chip and repeat the first 2 steps to verify a different set of values.
V2 chip_sw_lc_ctrl_init 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.
V2 chip_sw_lc_ctrl_transitions 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.

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

V2 chip_sw_lc_ctrl_kmac_reset

Verify the effect of putting the KMAC logic in reset during LC state transition.

  • For a lc state transition, force a reset to KMAC when KMAC is processing lc transition tokens.
  • Verify that LC won't transfer to next state upon KMAC reset glitch.
V2 chip_sw_lc_ctrl_key_div

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.

X-ref'ed with chip_keymgr_lc_key_div_o.

V2 chip_sw_lc_ctrl_broadcast

Verify broadcast signals from lc_ctrl.

  • Preload the LC partition in the OTP ctrl with the following states: RMA, DEV, TEST_LOCKED[N] & SCRAP (tested in chip_lc_ctrl_escalation).
  • Verify that the following broadcast signals are having the right effect in the respective IPs that consume them:
    • lc_dft_en_o: impacts clkmgr, pinmux, OTP ctrl & AST
    • lc_nvm_debug_en_o: impacts flash ctrl
    • lc_hw_debug_en_o: impacts pinmux, SRAM ctrl (main and ret) & the debug module
    • lc_cpu_en_o: impacts the CPU
    • lc_keymgr_en: impacts keymgr
    • lc_escalate_en_o: impacts SRAM ctrl, AES & OTP ctrl
    • lc_clk_byp_req_o: impacts clkmgr (handshake with lc_clk_byp_ack_i)
    • lc_flash_rma_req_o: impacts flash ctrl (handshake with lc_flash_ram_ack_i)
    • lc_flash_rma_seed_o: impacts flash ctrl
    • lc_check_byp_en_o: impacts OTP ctrl
    • lc_creator_seed_sw_rw_en_o: impacts flash ctrl & OTP ctrl
    • lc_owner_seed_sw_rw_en_o: impacts flash ctrl
    • lc_iso_part_sw_rd_en_o: impacts flash ctrl
    • lc_iso_part_sw_wr_en_o: impacts flash ctrl
    • lc_seed_hw_rd_en_o: impacts flash ctrl & OTP ctrl
  • These outputs are enabled per the [life cycle architecture spec]({{< relref "doc/security/specs/device_life_cycle/#architecture" >}}). X-ref'ed with the respective IP tests that consume these signals.
V2 chip_conn_lc_ctrl_scanmode

Verify the connectivity of scanmode to LC ctrl.

V2 chip_conn_ctrl_scanmode_reset

Verify the connectivity of scanmode reset to LC ctrl.

V2 chip_sw_sysrst_ctrl_inputs 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.
V2 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.
V2 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.
  • 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, eack key combination sufccessfully generates an interrupt.
V2 chip_sw_sysrst_ctrl_sleep_wakeup 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.
V2 chip_sw_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.
V2 chip_sw_sysrst_ctrl_sleep_reset 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.
V2 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.
V2 chip_sw_sysrst_ctrl_flash_wp_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.
V2 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.
V2 chip_sw_adc_ctrl_debug_cable_irq

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.
V2 chip_sw_adc_ctrl_sleep_debug_cable_wakeup 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.
V2 chip_sw_aes_enc chip_sw_aes_enc
chip_sw_aes_enc_jitter_en

Verify the AES operation.

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

V2 chip_sw_aes_entropy chip_sw_aes_entropy

Verify the AES entropy input used by the internal PRNGs.

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

Verify the AES sideload mechanism.

Details TBD, design updates pending.

V2 chip_sw_hmac_enc chip_sw_hmac_enc_irq
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.

V2 chip_sw_hmac_idle chip_sw_hmac_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.
V2 chip_sw_kmac_enc 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.

V2 chip_sw_kmac_app_keymgr

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.

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

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

V2 chip_sw_kmac_idle 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).
V2 chip_sw_entropy_src_ast_rng_req chip_sw_entropy_src_ast_rgn_req

Verify the RNG req to ast.

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

Verify the connectivity of rng_fips_o feedback signal to RNG.

Details TBD.

V2 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. Details TBD.

V2 chip_sw_entropy_src_cs_aes_halt

Verify the aes halt handshake with CSRNG.

Details TBD.

V2 chip_sw_entropy_src_fuse_en_fw_read

Verify the fuse input entropy_src.

  • Initialize the OTP with this fuse bit set to 1.
  • Perform an entropy request operation.
  • Read the entropy_data_fifo via SW; verify that it reads valid values.
  • Reset the chip, but this time, initialize the OTP with this fuse bit set to 0.
  • Perform an entropy request operation.
  • Read the internal state via SW; verify that it reads all zeros this time.
V2 chip_sw_entropy_src_known_answer_tests chip_sw_entropy_src_kat_test

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

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

Verify incoming command interface from EDN.

  • Have each EDN instance issue an instantiate command to CSRNG.
  • When done, verify the reception of cmd req done interrupt.
  • Check the data returned to EDN via connectivity assertion checks.
  • TODO: explore the ability to generate predictable data and verify the received value. Details TBD.
V2 chip_sw_csrng_fuse_en_sw_app_read

Verify the fuse input to CSRNG.

  • Initialize the OTP with this fuse bit set to 1.
  • Issue an instantiate command to request entropy.
  • Verify that SW can read the internal states.
  • Reset the chip and repeat the steps above, but this time, with OTP fuse bit set to 0.
  • Verify that the SW reads back all zeros when reading the internal states.
V2 chip_sw_csrng_lc_hw_debug_en

Verify the effect of LC HW debug enable on CSRNG.

TODO: This is pending SCA security review and might be removed.

V2 chip_sw_csrng_known_answer_tests chip_sw_csrng_kat_test

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

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

Verify the entropy requests from all peripherals.

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

V2 chip_sw_keymgr_key_derivation 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 both Attestation CDI and Sealing CDI.

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

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

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

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

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

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

X-ref'ed with kmac test.

V2 chip_sw_keymgr_sideload_kmac

Verify the keymgr sideload interface to KMAC, similar to chip_kmac_app_keymgr.

  • Configure the keymgr and advance to CreatorRootKey.
  • Transmit a sideloaded key to the KMAC.
  • Configure KMAC to use the sideload key to generate digest data.
  • Verify the digest for correctness.
  • Advance to 2 other operational states and repeat the above sequences (optional).

X-ref'ed with chip_kmac_app_keymgr test.

V2 chip_sw_keymgr_sideload_aes

Verify the keymgr sideload interface to AES.

Same as chip_keymgr_sideload_kmac, except, sideload to AES.

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

V2 chip_sw_otbn_op 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.
V2 chip_sw_otbn_rnd_entropy 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 consequtively do not match, and its not all 0s or all 1s, as a basic measure to ensure that the entropy subsystem is returning some data.
V2 chip_sw_otbn_urnd_entropy 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.
V2 chip_sw_otbn_idle 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.
V2 chip_conn_otbn_ast_ram_cfg

Verify that the ram_cfg signal from AST is connected to OTBN.

  • In open source, this is verified by a simple connectivity assertion check.
V2 chip_sw_otbn_mem_scramble chip_sw_otbn_mem_scramble

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

  • Have OTBN fetch a new key and nonce from the OTP_CTRL.
  • Write and read-check OTBN and IMEM for consistency.
  • Fetch a new key from the OTP_CTRL and ensure that previous contents in the IMEM and DMEM cannot be read anymore.
V2 chip_sw_rom_access 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.
V2 chip_conn_rom_ctrl_ast_rom_cfg

Verify that the rom_cfg signal from AST is connected to ROM ctrl.

  • In open source, this is verified by a simple connectivity assertion check.
V2 chip_sw_rom_ctrl_integrity_check 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.
V2 chip_sw_sram_scrambled_access chip_sw_sram_ctrl_ret_scrambled_access
chip_sw_sram_ctrl_main_scrambled_access
chip_sw_sram_ctrl_main_scrambled_access_jitter_en

Verify scrambled memory accesses to both main and retention SRAMs.

  • 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.
V2 chip_sw_sleep_sram_ret_contents chip_sw_sleep_sram_ret_contents

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

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

TODO: how to deal with the scramble keys on low power exit?

V2 chip_sw_sram_execution 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_CFG partition of OTP controller set and not set.
    • A life cycle state that enables (TEST_UNLOCKED, DEV or RMA) and disables (PROD) hardware debug.
    • The execution CSR programmed to be enabled and disabled.
  • For both, main and the retention SRAM in each of these 8 scenarios:

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

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

OTP HW_CFG[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.

V2 chip_sw_sram_lc_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.
V2 chip_otp_ctrl_init 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.
V2 chip_sw_otp_ctrl_keys

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), and OTBN.

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

V2 chip_sw_otp_ctrl_entropy

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.

V2 chip_sw_otp_ctrl_edn_reset

Verify the effect of putting the EDN domain in reset on OTP ctrl.

Verify that the computed nonce for SRAM is reset? Verify all entropy data used for various things are reset.

V2 chip_sw_otp_ctrl_program 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.
V2 chip_sw_otp_ctrl_program_error

Verify the otp program error.

  • Initiate an illegal program request from LC ctrl to OTP ctrl (example: issue program request when the lc_cnt is at max value).
  • Verify that the LC ctrl triggers an alert when the OTP ctrl responds back with a program error.
V2 chip_sw_otp_ctrl_hw_cfg chip_sw_lc_ctrl_otp_hw_cfg

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

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

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

V2 chip_sw_otp_ctrl_lc_signals

Verify the broadcast signals from LC ctrl.

  • lc_escalate_en_i: read the error code CSR and verify that it reflects an FSM error state due to the escalation signal triggering.
  • 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.

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

V2 chip_sw_otp_ctrl_ast

Verify the power sequencing signals to AST, as well as the alert.

Details TBD.

V2 chip_conn_otp_ctrl_external_voltage

Verify the connectivity of the external voltage signal to OTP ctrl.

Details TBD. TODO; This signal is not connected in the design yet.

V2 chip_conn_otp_ctrl_scan

Verify the connectivity of the scan signals to OTP ctrl.

Details TBD. TODO; This signal is not connected in the design yet.

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

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

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

V2 chip_sw_flash_rma_unlocked chip_sw_flash_rma_unlocked

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

  • Provision an RMA_UNLOCK token in OTP.

  • Reset the chip.

  • Enable RMA mode, and verify that the SW can access the flash. Ensure that the previous contents are inaccessible.

  • RMA entry can be on the C side as well. This should be done over C - The JTAG interface to flash ctrl is actually for the closed src.

V2 chip_conn_flash_jtag

Verify that the JTAG interface for the closed source flash macro is connected from chip IOs.

In open source, this JTAG interface is null-terminated, so we can only verify this through a connectivity test.

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

V2 chip_sw_flash_idle_low_power 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.
V2 chip_sw_flash_keymgr_seeds

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.

V2 chip_sw_flash_lc_creator_seed_sw_rw_en 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.
V2 chip_sw_flash_creator_seed_wipe_on_rma chip_sw_flash_rma_unlocked

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

V2 chip_sw_flash_lc_owner_seed_sw_rw_en 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.
V2 chip_sw_flash_lc_iso_part_sw_rd_en chip_sw_flash_ctrl_lc_rw_en

Verify the lc_iso_part_sw_rd_en signal from LC ctrl.

  • Transition from DEV to PROD to ESCALATION/SCRAP state via OTP and verify that this LC signal transitions from 0 to 1 and back to 0. Verify that the SW accessibility of the corresponding partition depending on the signal value.
V2 chip_sw_flash_lc_iso_part_sw_wr_en 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.
V2 chip_sw_flash_lc_seed_hw_rd_en 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.
V2 chip_sw_flash_lc_escalate_en

Verify the lc_escalate_en signal from LC ctrl.

  • Trigger an LC escalatation signal by generating an alert.
  • Verify that all flash accesses are disabled when the escalation kicks in.
  • The CPU cannot read the flash either once escalation kicks in. This is unfortunately not possible because the CPU is also disabled when the escalation is triggered.
  • Use assertion based connectivity check to prove that this signal is connected to the flash ctrl.
V2 chip_sw_flash_prim_tl_access

Verify that the SW can read / write the dummy memory in flash phy.

  • The dummy memory 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.

  • TODO: the existing CSR / mem tests may already handle this.

V2 chip_conn_flash_ast

Verify the connectivity of AST / top level signals.

  • From AST to flash ctrl: flash_power_ready_h_i, flash_power_down_h_i, flash_bist_enable_i, scanmode_i, scan_en_i, scan_rst_ni.

  • From top level (chip IOs): flash_test_mode_a_io, flash_test_voltage_h_io.

  • From flash ctrl to AST: flash_alert_o.

V2 chip_sw_flash_ctrl_clock_freqs 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.
V2 chip_conn_flash_lc_nvm_debug_en

Verify that the lc_nvm_debug_en signal from LC ctrl is connected to the flash ctrl.

  • Use connectivity test in the open source, since this signal is not used..
V2 chip_sw_ast_clk_outputs 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.

V2 chip_sw_ast_clk_rst_inputs

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

Details TBD.

V2 chip_sw_ast_sys_clk_jitter

Verify that the AST sys clk jitter control.

Details TBD.

V2 chip_sw_ast_usb_clk_calib

Verify the USB clk calibration signaling.

Details TBD.

V2 chip_sw_ast_alerts chip_sw_sensor_ctrl_alert

Verify the alerts from AST aggregating into the sensor_ctrl.

X-ref'ed with chip_sensor_ctrl_ast_alerts.

V2 chip_sw_sensor_ctrl_ast_alerts 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 AST events can be triggered from sensor_ctrl and that the resulting AST outputs are observed in both sensor_ctrl and the alert_handler.

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

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

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

V2 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.
  • 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.
V2 chip_sw_rv_core_ibex_address_translation

Verify the simple address translation functionality.

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

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

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.
V2 chip_sw_smoketest 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_otp_ctrl_smoketest
chip_sw_rv_plic_smoketest
chip_sw_pwrmgr_smoketest
chip_sw_rv_timer_smoketest
chip_sw_rstmgr_smoketest
chip_sw_sram_ctrl_smoketest
chip_sw_uart_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.

V2 chip_sw_signed chip_sw_uart_smoketest_signed

Run some chip-level tests with mask ROM.

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

V2 chip_sw_coremark chip_sw_coremark

Run the coremark benchmark on the full chip.

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

V2 chip_sw_secure_boot

Verify the secure boot flow.

Details TBD.

V2 chip_sw_lc_walkthrough 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.
V2 chip_sw_device_ownership

Walk through device ownership stages and flows.

Details TBD.

V2 chip_sw_sram_nmi_wipe

Verify SRAM behavior during an NMI escalation.

  • Trigger an NMI through the alert handler path to cause a system shutdown.
  • SW should trigger a memory "initialization", fully randomizing RAM contents and initiating another key request.
  • Verify that the RAMs are "wiped" once this operation completes.
V2 tl_d_oob_addr_access chip_tl_errors

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

V2 tl_d_illegal_access 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]({{< relref "hw/ip/tlul/doc/_index.md#explicit-error-cases" >}})

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

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

V2 xbar_base_random_sequence xbar_chip_random

Enable all hosts to randomly send transactions to any device

V2 xbar_random_delay xbar_chip_smoke_zero_delays
xbar_chip_smoke_large_delays
xbar_chip_smoke_slow_rsp
xbar_chip_random_zero_delays
xbar_chip_random_large_delays
xbar_chip_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
V2 xbar_unmapped_address xbar_chip_unmapped_addr
xbar_chip_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
V2 xbar_error_cases xbar_chip_error_random
xbar_chip_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
V2 xbar_all_access_same_device xbar_chip_access_same_device
xbar_chip_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
V2 xbar_all_hosts_use_same_source_id xbar_chip_same_source

Test all hosts use same ID at the same same

V2 xbar_stress_all xbar_chip_stress_all
xbar_chip_stress_all_with_error
  • Combine all sequences and run in parallel
  • Add random reset between each iteration
V2 xbar_stress_with_reset xbar_chip_stress_all_with_rand_reset
xbar_chip_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
V2 mask_rom_functests mask_rom_keymgr_functest

Run functests developed for mask ROM.

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

V2 mask_rom_e2e_bootup_no_rom_ext

Verify device fails to boot with no ROM_EXT.

  • Test runner loads the Mask ROM and no ROM_EXT.
  • Attempt to boot.
  • Verify that the chip indicates the correct boot fault.
V2 mask_rom_e2e_bootup_success

Verify device boots with a good ROM_EXT.

  • Generate a ROM_EXT with a sufficiently high version number.
  • Sign the ROM_EXT with a valid key.
  • Test runner loads the Mask ROM and prepared ROM_EXT.
  • Attempt to boot.
  • Verify that the chip successfully boots into the ROM_EXT.
V2 mask_rom_e2e_bootup_bad_rom_ext_signature

Verify device fails to boot with an improperly-signed ROM_EXT.

  • Generate a ROM_EXT with a sufficiently high version number.
  • Sign the ROM_EXT with a valid key.
  • Flip one bit in the signature.
  • Test runner loads the Mask ROM and the improperly-signed ROM_EXT.
  • Attempt to boot.
  • Verify that the chip indicates the correct boot fault.
V2 mask_rom_e2e_bootup_bad_manifest_usage_constraint

Verify device fails to boot with an invalid manifest usage constraints.

  • Generate an otherwise valid ROM_EXT with invalid manifest usage constraints.
  • Sign the ROM_EXT with a valid key.
  • Test runner loads the Mask ROM and the ROM_EXT.
  • Attempt to boot.
  • Verify that the chip indicates the correct boot fault.
V2 mask_rom_e2e_bootup_rom_ext_invalidated_key

Verify device fails to boot with a ROM_EXT signed with an invalidated key.

  • Generate a ROM_EXT with a sufficiently high version number.
  • Sign the ROM_EXT with a test key.
  • Generate an OTP with that test key disabled.
  • Test runner loads the Mask ROM, the signed ROM_EXT, and the OTP image.
  • Verify that the chip indicates the correct boot fault.
V2 mask_rom_e2e_bootup_bad_rom_ext_version

Verify device fails to boot with a bad minimum version.

  • Test runner loads the Mask ROM and a properly-signed ROM_EXT with a version number that is below the minimum version.
  • Attempt to boot.
  • Verify that the chip indicates the correct boot fault.
V2 mask_rom_e2e_bootstrap_success

Verify device enters bootstrap mode when strapping pins are set correctly.

  • Test runner loads an OTP image with bootstrap mode enabled.
  • Test runner sets the strapping pins to the correct levels.
  • Attempt to boot the chip.
  • Verify that the chip entered bootstrap mode.
V2 mask_rom_e2e_bootstrap_bad_pin_config

Verify the device does not enter bootstrap mode when strapping pins are set incorrectly.

  • Test runner loads an OTP image with bootstrap mode enabled.
  • Test runner sets the strapping pins to levels that do not correspond to entering bootstrap mode.
  • Attempt to boot the chip.
  • Verify that the chip does not enter bootstrap mode.
V2 mask_rom_e2e_bootstrap_disabled

Verify device does not enter bootstrap mode when strapping pins are set correctly, but bootstrap is disabled in the OTP.

  • Test runner loads an OTP image that has bootstrapping mode disabled.
  • Set the strapping pins to the correct levels for bootstrapping.
  • Attempt to boot the chip.
  • Verify that the chip does not enter bootstrap mode.
V2 mask_rom_e2e_bootstrap_config

Verify that JEDEC ID and SFDP are configured.

  • Test runner configures chip to enter bootstrap mode.
  • In bootstrap mode, read JEDEC Device ID
  • Verify that it matches the lowRISC JEDEC ID.
  • SW reads SFDP and verifies that it is correct.
V2 mask_rom_e2e_bootstrap_phase1_reset_op

Verify that phase 1 of bootstrap handles RESET ops correctly.

  • Enter bootstrap mode.
  • Test runner issues a RESET opcode.
  • Verify that the bootstrap process aborted.
  • Verify that the flash does not change. Phase 1 only allows the ERASE opcode.
V2 mask_rom_e2e_bootstrap_phase1_read_op

Verify that phase 1 of bootstrap handles READ ops correctly.

  • Enter bootstrap mode.
  • Test runner issues a READ opcode.
  • Verify that the flash returns 0xFF. Phase 1 only allows the ERASE opcode.
  • Abort the bootstrap process.
  • Verify that the flash contents are unchanged.
V2 mask_rom_e2e_bootstrap_phase1_page_program_op

Verify that phase 1 of bootstrap handles PAGE_PROGRAM ops correctly.

  • Enter bootstrap mode.
  • Test runner issues a PAGE_PROGRAM opcode.
  • Abort the bootstrap process.
  • Verify that the flash does not change. Phase 1 only allows the ERASE opcode.
V2 mask_rom_e2e_bootstrap_phase1_erase_op

Verify that phase 1 of bootstrap handles ERASE ops correctly.

  • Enter bootstrap mode.
  • Test runner issues an ERASE opcode.
  • Abort the bootstrap process.
  • Verify that the entire flash DATA segment is erased.
  • Verify that the flash INFO segment is unchanged.
V2 mask_rom_e2e_bootstrap_phase2_reset_op

Verify that phase 2 of bootstrap handles RESET ops correctly.

  • Enter bootstrap mode.
  • Issue ERASE opcode to enter phase 2.
  • Issue RSTEN opcode.
  • Issue RESET opcode.
  • Verify that bootstrap was exited and that the chip was reset.
V2 mask_rom_e2e_phase2_page_program_op

Verify that phase 2 of bootstrap correctly handles the PAGE_PROGRAM opcode.

  • Enter bootstrap mode.
  • Issue ERASE opcode to enter phase 2.
  • Issue PAGE_PROGRAM opcode with an invalid address.
  • Issue PAGE_PROGRAM opcode with a valid address.
  • Issue RESET opcode to exit bootstrap and reset the chip.
  • Verify that the valid address is correctly programmed and that the rest of flash is unchanged.
V2 mask_rom_e2e_phase2_erase_op

Verify that phase 2 of bootstrap correctly handles the ERASE opcode.

  • Enter bootstrap mode.
  • Issue ERASE opcode to enter phase 2.
  • Issue PAGE_PROGRAM opcode to program a target address.
  • Issue ERASE opcode to the same target address.
  • Issue RESET opcode to exit bootstrap and reset the chip.
  • Verify that the target address was erased and that the rest of flash is unchanged.
V2 mask_rom_e2e_phase2_read_op

Verify that phase 2 of bootstrap correctly handles the READ opcode.

  • Enter bootstrap mode.
  • Issue ERASE opcode to enter phase 2.
  • Issue PAGE_PROGRAM opcode to program a target address.
  • Issue READ opcode to read the same target address.
  • Verify that the READ behaves correctly.
V2 mask_rom_e2e_startup_ast_main_sram_init

Verify that the AST and main SRAM are initialized correctly after POR.

For each lifecycle state, perform the following:

  • Load an OTP image corresponding to this state.
  • Boot the chip.
  • Check the SENSOR_CTRL_STATUS_AST_INIT_DONE bit.
    • This bit should be 1 if the AST should be initialized and 0 otherwise.
  • Check the following main SRAM registers in SRAM_CTRL.CTRL:
    • SCR_KEY_VALID = 1
    • SCR_KEY_SEED_VALID = 1
    • INIT_DONE = 1
V2 mask_rom_e2e_startup_retention_sram_init

Verify that the retention SRAM is initialized correctly after POR.

  • Initiate a POR.
  • Check the following retention SRAM registers in SRAM_CTRL.CTRL:
    • SCR_KEY_VALID = 1
    • SCR_KEY_SEED_VALID = 1
    • INIT_DONE = 1
V2 mask_rom_e2e_startup_retention_sram_saved

Verify that retention SRAM saves data across low-power entry/exit.

  • Write known data into silicon_owner section of retention SRAM.
  • Trigger a low-power entry/exit.
  • Read the silicon_owner section of retention SRAM.
  • Verify that the data has been retained.
  • Verify that silicon_creator section has been wiped.
V2 mask_rom_e2e_startup_retention_sram_wiped

Verify that retention SRAM is wiped after a POR.

  • Write known data into all sections of retention SRAM.
  • Trigger a POR.
  • Verify that that all sections of retention SRAM have been cleared.
V2 mask_rom_e2e_shutdown_boot_failure

Verify that all boot failure cases enter shutdown.

  • Ensure that all invocations of shutdown_finalize and SHUTDOWN_IF_ERROR result in a shutdown.
V2 mask_rom_e2e_shutdown_alert_configuration

Verify that alert-handler is configured correctly.

  • Verify alert-handler CSRs are configured as expected per the OTP.
  • Test program forces an alert to trigger full escalation path.
  • Verify that a reset occurs.
V2 mask_rom_e2e_shutdown_mask_rom_alert_shutdown

Verify that alerts during Mask ROM execution lead to shutdown.

  • Trigger an alert while the Mask ROM is executing.
  • Verify that the chip undergoes expected shutdown sequence.
V2 mask_rom_e2e_shutdown_interrupts

Verify that interrupts lead to shutdown.

  • Randomly select a group of interrupts.
  • Force those interrupts during Mask ROM execution.
  • Verify that shutdown occurs when the IRQ is triggered.
V2 mask_rom_e2e_upgradable

Verify that new firmware allows for upgrades.

  • Load new firmware of version N.
  • Attempt to upgrade to version N+1.
V2 mask_rom_e2e_upgrade_min_sec_version

Verify that Mask ROM checks minimum security version before booting.

  • Load ROM_EXT that updates min_security_version past its own version.
  • Attempt to boot again.
  • Verify that the same ROM_EXT cannot be booted again.
V2 mask_rom_e2e_upgrade_power_loss

Verify that losing power during a ROM_EXT upgrade does not brick the chip.

  • Initiate a ROM_EXT update.
  • After the new ROM_EXT is loaded into flash, trigger a reset.
  • Verify that the chip can boot.
V2 mask_rom_rv_dm_perform_debug

Verify that Ibex enters debug mode when triggered through JTAG

This test must be run with mask ROM. Mask ROM is responsible for enabling debug ROM access and must be used to ensure the epmp configurations are done correctly.

  • X-ref'ed with chip_sw_sram_execution and populate a single "return" instruction into main SRAM at a fixed location (bottom of SRAM).
  • Execute a "wait_for_interrupt" in a wrapping function in the test, this causes Ibex to populate the return address and halt execution.
  • Trigger a debug request by programming dmcontrol.haltreq via JTAG.
  • Program the program buffer via JTAG with code to jump Ibex to the SRAM return instruction.
  • Verify that Ibex can fetch and execute the instructions from the SRAM correctly, Ibex should return to the code that originally invoked the wait_for_interrupt routine.
  • Release Ibex from halt via JTAG and allow the test to complete.
  • The test should also ensure that no other interrupts occur in the system.
V2 aon_timer_rst aon_timer_rst

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

V2 aon_timer_rst_aon aon_timer_rst_aon

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

V2 ast_dft_ram_2p_cfg 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
V2 ast_dft_ram_1p_cfg 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
V2 ast_sys_clk_clkmgr ast_sys_clk_clkmgr

Verify ast model's clk_src_sys_o is connected to clkmgr's main clock.

V2 ast_io_clk_clkmgr ast_io_clk_clkmgr

Verify ast model's clk_src_io_o is connected to clkmgr's io clock.

V2 ast_usb_clk_clkmgr ast_usb_clk_clkmgr

Verify ast model's clk_src_usb_o is connected to clkmgr's usb clock.

V2 ast_aon_clk_clkmgr ast_aon_clk_clkmgr

Verify ast model's clk_src_aon_o is connected to clkmgr's aon clock.

V2 clkmgr_jitter_ast clkmgr_jitter_ast

Verify clkmgr's jitter enable is connected to ast.

V2 clkmgr_idle 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
V2 clkmgr_clk_io_div4_infra clkmgr_infra_clk_flash_ctrl_clk
clkmgr_infra_clk_xbar_main_fixed_clk
clkmgr_infra_clk_xbar_peri_peri_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

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

  • flash_ctrl clk_otp_i
  • xbar_main clk_fixed_i
  • xbar_peri clk_peri_i
  • sram_ctrl main clk_otp_i
  • sram_ctrl retention clk_i
  • sram_ctrl retention clk_otp_i
  • sysrst_ctrl clk_i
V2 clkmgr_clk_main_infra 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
V2 clkmgr_clk_aon_infra 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
V2 clkmgr_clk_io_infra 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
V2 clkmgr_clk_io_div2_infra 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
V2 clkmgr_clk_io_div4_peri 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
clkmgr_peri_clk_usbdev_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
  • usbdev clk_i
V2 clkmgr_clk_io_div2_peri 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 clk_scan_i
  • spi_host1 clk_i
V2 clkmgr_clk_io_peri 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
V2 clkmgr_clk_usb_peri clkmgr_peri_clk_usbdev_usb_clk

Verify clkmgr's clk_usb_peri is connected to usbdev's usb clock.

V2 clkmgr_clk_aon_peri clkmgr_peri_clk_adc_ctrl_aon_clk
clkmgr_peri_clk_usbdev_aon_clk

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

  • adc_ctrl clk_aon_i
  • usbdev clk_aon_i
V2 clkmgr_clk_io_div4_powerup clkmgr_powerup_clk_clkmgr_clk
clkmgr_powerup_clk_pinmux_clk
clkmgr_powerup_clk_pwm_clk
clkmgr_powerup_clk_pwrmgr_clk
clkmgr_powerup_clk_rstmgr_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
V2 clkmgr_clk_aon_powerup 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
V2 clkmgr_clk_main_powerup clkmgr_powerup_clk_rstmgr_main_clk

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

  • rstmgr's clock_main_i
V2 clkmgr_clk_io_powerup clkmgr_powerup_clk_rstmgr_io_clk

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

V2 clkmgr_clk_usb_powerup clkmgr_powerup_clk_rstmgr_usb_clk

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

V2 clkmgr_clk_io_div2_powerup clkmgr_powerup_clk_rstmgr_io2_clk

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

V2 clkmgr_clk_io_div4_secure clkmgr_secure_clk_alert_handler_clk
clkmgr_secure_clk_otp_ctrl_clk
clkmgr_secure_clk_pwrmgr_clk
clkmgr_secure_clk_rv_core_ibex_clk
clkmgr_secure_clk_rv_core_ibex_otp_clk
clkmgr_secure_clk_sensor_ctrl_clk
clkmgr_secure_clk_ast_tlul_clk
clkmgr_secure_clk_ast_alert_clk
clkmgr_secure_clk_lc_ctrl_clk

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

  • alert_handler clk_i
  • otp_ctrl clk_i
  • pwrmgr clk_i
  • rv_core_ibex clk_i
  • rv_core_ibex clk_otp_i
  • sensor_ctrl clk_i
  • ast clk_tlul_i
  • ast clk_alert_i
  • lc_ctrl clk_i
V2 clkmgr_clk_main_secure clkmgr_secure_clk_alert_handler_edn_clk
clkmgr_secure_clk_ast_es_clk
clkmgr_secure_clk_ast_rng_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_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
  • ast clk_est_i
  • ast clk_rng_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
  • otp_ctrl clk_edn_i
  • rv_plic clk_i
V2 clkmgr_clk_aon_secure clkmgr_secure_clk_ast_adc_clk
clkmgr_secure_clk_sensor_ctrl_aon_clk

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

  • ast clk_adc_i
  • sensor_ctrl clk_aon_i
V2 clkmgr_clk_usb_secure clkmgr_secure_clk_ast_usb_clk

Verify clkmgr's clk_usb_secure is connected to ast's usb clock.

V2 clkmgr_clk_io_div4_timers 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
V2 clkmgr_clk_aon_timers clkmgr_timers_clk_aon_timer_aon_clk

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

V2 flash_ast_obs_ctrl flash_ast_obs_ctrl

Verify ast's obs_ctrl_o is connected to flash_ctrl's obs_ctrl_i.

V2 lc_escalate_en 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
V2 pwrmgr_rst_lc_req pwrmgr_rst_lc_req

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

V2 pwrmgr_rst_sys_req pwrmgr_rst_sys_req

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

V2 rstmgr_rst_lc_src_n rstmgr_rst_lc_src_n

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

V2 rstmgr_rst_sys_src_n rstmgr_rst_sys_src_n

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

V2S tl_intg_err chip_tl_intg_err
chip_sec_cm

Verify that the data integrity check violation generates an alert.

  • Randomly inject errors on the control, data, or the ECC bits during CSR accesses. Verify that triggers the correct fatal alert.
  • Inject a fault at the onehot check in u_reg.u_prim_reg_we_check and verify the corresponding fatal alert occurs
V3 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. // TODO - error handling is not complete, do not enable wait_timer yet. KMAC should send request to EDN once CmdStart is written, and should send out another request to EDN when either:

  • kmac hash counter hits the configured threshold (assuming it is non-zero)
  • a hash operation is completed, KMAC will refresh its internal entropy state 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.

Covergroups

Name Description
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.
tl_intg_err_cg

Cover all kinds of integrity errors (command, data or both) and cover number of error bits on each integrity check.

Cover the kinds of integrity errors with byte enabled write on memory if applicable: Some memories store the integrity values. When there is a subword write, design re-calculate the integrity with full word data and update integrity in the memory. This coverage ensures that memory byte write has been issued and the related design logic has been verfied.

Testplan (Gate level simulations)

Note that the descriptions of the test below may be replicated from the table above.

Testpoints

Milestone Name Tests Description
V1 chip_sw_uart_tx_rxchip_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.

Covergroups

Name Description
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.
tl_intg_err_cg

Cover all kinds of integrity errors (command, data or both) and cover number of error bits on each integrity check.

Cover the kinds of integrity errors with byte enabled write on memory if applicable: Some memories store the integrity values. When there is a subword write, design re-calculate the integrity with full word data and update integrity in the memory. This coverage ensures that memory byte write has been issued and the related design logic has been verfied.