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 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 DV plan below.

Regressions

Sanity

SW access

Nightly

DV plan

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

chip_uart_tx_rx
V1 chip_uart_rx_overflow

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.

chip_uart_tx_rx
V1 chip_gpio_out

Verify GPIO outputs.

SW test configures the GPIO to be in the output mode. The test walks a 1 through the pins. The testbench checks the value for correctness.
V1 chip_gpio_in

Verify GPIO inputs.

The SW test configures the GPIO 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 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.
chip_tl_csr_hw_reset
chip_jtag_csr_hw_reset
V1 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.
chip_tl_csr_rw
chip_jtag_csr_rw
V1 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.
chip_tl_csr_bit_bash
chip_jtag_csr_bit_bash
V1 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.
chip_tl_csr_aliasing
chip_jtag_csr_aliasing
V1 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.
chip_tl_csr_mem_rw_with_rand_reset
chip_jtag_csr_mem_rw_with_rand_reset
V1 shadow_reg_errors

Verify shadow registers' update and storage errors.

  • Issue reset at random to clear all the internal stored values and phases trackers in shadow registers.
  • Select all the shadow registers and a random amount of the rest of the non-excluded registers. Shuffle and write random values to the selected registers. For shadow registers, the second write is not enabled. There is a 50% possibility that the shadow register's write value is identical to its previous write value. If shadow register's second write value does not match the first write value, ensure that the update error alert is triggered.
  • Randomly inject storage errors by modifying the shadow register's staged or committed values via backdoor method. Ensure that the storage error alert is triggered.
  • Randomly decide to read all the non-excluded registers or fields. Then check the read values against predicted values. A read on a shadow register will clear its phase tracker.
  • Repeat the above steps a bunch of times.
chip_shadow_reg_errors
V1 mem_walk

Verify accessibility of all memories in the design.

  • Run the standard UVM mem walk sequence on all memories in the RAL model.
  • It is mandatory to run this test from all available interfaces the memories are accessible from.
chip_tl_mem_walk
chip_jtag_mem_walk
V1 mem_partial_access

Verify partial-accessibility of all memories in the design.

  • Do partial reads and writes into the memories and verify the outcome for correctness.
  • Also test outstanding access on memories
chip_tl_mem_partial_access
chip_jtag_mem_partial_access
V1 xbar_smoke

Sequentially test each host to access any device

xbar_chip_smoke
V2 chip_spi_device_tx_rx

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

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 and max SPI clk frequencies. Also, run with single, dual and quad SPI modes. Also, ensure that the spi_device does not recieve transactions when the csb is high.
V2 chip_spi_device_eeprom

Verify the SPI device in EEPROM mode.

SW puts the SPI device in EEPROM mode and allows a firmware image (a.k.a. a known payload) to be downloaded into the in-built EEPROM. SW verifies the integrity of the payload upon reception by reading the EEPROM. Details TBD since the feature is NA yet.
V2 chip_spi_host_tx_rx

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

Details TBD. Run with min and max SPI clk frequencies. Also, run with single, dual, and quad SPI modes.
V2 chip_spi_pass_through

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

SW configures the SPI device and host in pass through mode. The testbench sends a random payload over the SPI device interface and verifies its integrity on the SPI host interface. Run with min and max SPI clk frequencies. Also, run with single, dual, and quad SPI modes. Details TBD.
V2 chip_i2c_host_tx_rx

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

The SW test writes a known data over the chip's I2C host interface, which is verified by the testbench (which acts as the I2C device). Likewise, SW test then reads and verifies a known data. SW validates the reception of RX watermark, FMT overflow, RX overflow, NAK, FMT watermark and trans complete interrupts (the SW test / testbench work together to create those scenarios). Verify all instances of I2C in the chip independently.
V2 chip_i2c_device_tx_rx

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

The testbench writes a known data over the chip's I2C device interface, which is verified by the SW test for correctness. Testbench then reads and verifies a known data. SW validates the reception of TBD interrupts (the SW test / testbench create those scenarios). Verify all instances of I2C in the chip independently.
V2 chip_usb_fs_se_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.

Details TBD.
V2 chip_usb_fs_df_tx_rx

Verify the transmission of data over the USB at full speed. As a part of this test, the enablement of USB pullup is also expected to be verified. In this test, the USB is configured in differential mode.

Details TBD.
V2 chip_usb_vbus

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

TBD.
V2 chip_usb_suspend

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

TBD.
V2 chip_sleep_usb_suspend

Same as the above, but tested with low power entry/exit.

TBD.
V2 chip_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_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_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_padctrl_attributes

Verify pad attribute settings for all MIO and DIO pads.
V2 chip_rv_dm_cpu_debug_mem

Verify access to the debug mem from the CPU.
V2 chip_rv_dm_jtag_debug_mem

Verify access to the debug mem from the external JTAG interface.
V2 chip_rv_dm_cpu_debug_req

Verify debug request to Ibex while it is actively executing.
V2 chip_rv_dm_ndm_reset_req

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

Read CSRs / mem within all IPs in the chip to ensure that they are reset to the original values. Read CSRs / mem in the debug domain to ensure that the values survive the reset.
V2 chip_sleep_rv_dm_ndm_reset_req

Verify non-debug reset req initiated from RV_DM when the chip is in deep sleep.

Read CSRs / mem within all IPs in the chip to ensure that they are reset to the original values. Read CSRs / mem in the debug domain to ensure that the values survive the reset. There are also other modules such as clk, pwr, rstmgr which survive this reset. Verify those as well.

TODO: rv_dm currently is not on the AON domain, so this feature does not exist ATM. Need discussion with SW/Nuvoton.
V2 chip_rv_dm_jtag_tap_sel

Verify ability to select all available TAPs.

Details TBD.
V2 chip_rv_dm_lc_disabled

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

Verify that the debug mem is inaccessible from the CPU as well as external JTAG. Details TBD. X-ref'ed with the LC tests.
V2 chip_pattgen_ios

Verify pattern generation to chip output pads.

SW programs pattgen to generate distinct patterns on both groups. SW programs pinmux to select pattgen outputs to be routed. SW validates the reception of patt_done interrupts. Testbench verifies the correctness of the pattern seen on the IO pins.
V2 chip_sleep_pwm_ios_val

Verify PWM signaling to chip output pads during deep sleep

PWM is in the AON domain. During deep sleep, we should be able to signal the 3 external LEDs that are connected to the PWM signals. Details TBD.
V2 chip_timer

Verify the timeout interrupt from all timer instances.

The SW test configures the RV_TIMER to generate interrupt after a set timeout. The SW test validates the received interrupt. The testbench verifies that the interrupt was fired only after the timeout elapsed. Verify all instances of the RV_Timer.
V2 chip_sleep_aon_timer_wake

Verify the timer in the AON domain can wake up the chip from sleep.
V2 chip_wdog_bark

Verify the watchdog bark reception in awake state.
V2 chip_wdog_bite

Verify the watchdog bite causing reset in awake state.
V2 chip_sleep_wdog_bark_wake

Verify the watchdog bark wake up from sleep state.
V2 chip_sleep_wdog_bite_wake

Verify the watchdog bite reset from sleep state.
V2 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_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_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_clk_off_trans

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

Ensure that activity in any of the IPs running on this clock prevents the clock from actually being turned off. Verify that turning off this clock does not affect the other derived clocks.
V2 chip_sw_clk_off_peri

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

Verify clk division logic is working correctly.
V2 chip_pwrmgr_cold_boot

Verify the cold boot sequence through the wiggling of por_rst_n.

This mainly ensures that both FSMs are properly reset on the POR signal. Details TBD.
V2 chip_pwrmgr_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.
V2 chip_pwrmgr_sleep_all_reset_reqs

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.
V2 chip_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.
V2 chip_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. This also verifies that the pwrmgr sequencing is working correctly as expected. X-ref'ed with all individual IP tests.
V2 chip_pwrmgr_all_reset_reqs

Verify that the chip can be reset by ALL available reset 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.
V2 chip_pwrmgr_bad_main_pok

Verify the effect of main_pok de-assertion in the middle of low power entry / exit FSM transition.

The main_pok from AST is randomly forced to flip while in the middle of a FSM transition. This is done on all normal / deep sleep / reset request tests.
V2 chip_pwrmgr_b2b_sleep_reset_req

Verify that the pwrmge sequences sleep_req and reset req coming in almost at the same time, one after the other.
V2 chip_pwrmgr_debug_sleep

Verify that when the chip being in "debuggable" state prevent the low power entry.
V2 chip_pwrmgr_sleep_wake_req_disabled

Verify that the chip cannot be woken up from sleep from a wake up source that is disabled.
V2 chip_pwrmgr_reset_req_disabled

Verify that the chip cannot be reset from a reset source that is disabled.
V2 chip_pwrmgr_sleep_reset_req_disabled

Verify that the chip cannot be woken up from sleep from a reset source that is disabled.
V2 chip_pwrmgr_sleep_disabled

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

Verify that the chip sleep falls through when an interrupt arrives just in time before the pwrmgr iniitates the low power entry.
V2 chip_pwrmgr_sleep_abort

Verify that the chip sleep transition aborts due to an active flash / lifecycle / OTP transaction.
V2 chip_alert_handler_alerts

Verify all alerts coming into the alert_handler.

X-ref'ed with all IP tests.
V2 chip_alert_handler_irqs

Verify all classes of alert handler interrupts to the CPU.

Program each alert to cause an interrupt in each class. SW validates the reception of the interrupt. X-ref'ed with all IP tests.
V2 chip_alert_handler_esc_irqs

Verify all alert handler escalation irqs.

Details TBD.
V2 chip_alert_handler_entropy

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

Details TBD.
V2 chip_alert_handler_crashdump

Verify the alert handler crashdump signal.

Details TBD.
V2 chip_alert_handler_ping_fail

Verify the alert ping failure results in an escalation.

Details TBD.
V2 chip_aes_enc

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 (or interrupt if available). Check the digest registers for correctness against the expected digest value.
V2 chip_aes_shadow_reg_alert

Verify shadow reg alert from AES.

Inject a storage error via backdoor to generate this alert signal while the SW is actively executing some piece of code. Verify alert propagation to an NMI.
V2 chip_aes_idle

Verify AES idle signaling to clkmgr.

Details TBD.
V2 chip_hmac_enc

Verify HMAC / SHA256 operation.

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

Verify alert from HMAC.

Details TBD.
V2 chip_hmac_idle

Verify HMAC idle signaling to clkmgr.

Details TBD.
V2 chip_kmac_enc

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_kmac_sram_uncorrectable_alert

Verify the SRAM uncorrectable alert from KMAC.

Inject 2 bit errors within the SRAM inside KMAC via backdoor and ensure that this alert propagates to an NMI.
V2 chip_kmac_sram_data_parity_alert

Verify the data parity alert from KMAC.

Details TBD.
V2 chip_kmac_keymgr_key_data

Verify the keymgr interface to KMAC.

X-ref'ed with keymgr test.
V2 chip_kmac_idle

Verify KMAC idle signaling to clkmgr.

Details TBD.
V2 chip_csrng_cmd

Verify the cmd interface to CSRNG.

Details TBD. SW test validates the reception of cmd req done interrupt.
V2 chip_csrng_entropy_src

Verify the interface to entropy_src.

Details TBD.
V2 chip_csrng_fuse

Verify the fuse input to CSRNG.

Details TBD.
V2 chip_entropy_src_ast_rng_req

Verify the RNG req to ast.

Details TBD. SW test validates the reception of the entropy valid interrupt.
V2 chip_entropy_src_fuse

Verify the fuse input entropy_src.

Details TBD.
V2 chip_otbn_op

Verify an OTBN operation.

SW test directs the BIGNUM engine to perform an operation. The BIGNUM SW image is backdoor loaded into OTBN IMEM. SW validates the reception of the otbn done interrupt. SW also verifies the correctness of the OTBN operation using a reference model. Details TBD.
V2 chip_otbn_imem_uncorrectable_alert

Verify the imem uncorrectable alert from OTBN.

Inject 2 bit errors within the IMEM SRAM inside OTBN via backdoor and ensure that this alert propagates to an NMI.
V2 chip_otbn_dmem_uncorrectable_alert

Verify the dmem uncorrectable alert from OTBN.

Inject 2 bit errors within the DMEM SRAM inside OTBN via backdoor and ensure that this alert propagates to an NMI.
V2 chip_otbn_reg_uncorrectable_alert

Verify the reg uncorrectable alert from OTBN.

Details TBD. Ensure that this alert propagates to an NMI.
V2 chip_otbn_mem_encr

Verify the encryption of the mem within OTBN using the key provided by the OTP.

Details TBD.
V2 chip_otbn_idle

Verify OTBN idle signaling to clkmgr.

Details TBD.
V2 chip_rom_access

Verify access to the rom.

Verify that the CPU can fetch instructions from the ROM. Nothing extra needs to be done here - all SW tests do this anyway.
V2 chip_rom_security_features

Verify ROM security / ECC features if available.

Details TBD.
V2 chip_sram_access

Verify access to the SRAM.

Verify that the CPU can fetch data from the SRAM. Nothing extra needs to be done here - all SW tests do this anyway.
V2 chip_sram_scramble

Verify scrambling of the SRAM data.

SW enables scrambling within the SRAM. Ensure that the data written to the SRAM is scrambled and likewise, when read from the SRAM is de-scrambled correctly via backdoor. The key and nonce for the scrambling is supplied by the OTP.
V2 chip_sram_ret_access

Verify access to the retention SRAM.

Verify that the CPU can fetch data from the retention SRAM.
V2 chip_sram_ret_scramble

Verify scrambling of the retention SRAM data.

SW enables scrambling within the retention SRAM. Ensure that the data written to the SRAM is scrambled and likewise, when read from the SRAM is de-scrambled correctly via backdoor. The key and nonce for the scrambling is supplied by the OTP.
V2 chip_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_otp_init

Verify the OPT initialization on chip power up.

Details TBD.
V2 chip_otp_keys

Verify the proliferation of keys to security peripherals.

Ensure that the correct set of keys are provided to sram, sram_ret, flash, keymgr and the OTBN. X-ref'ed with those individual IP tests.
V2 chip_otp_lc_program

Verify the OTP program req from LC.

Ensure that the correct set of keys are provided to sram, sram_ret, flash, keymgr and the OTBN. X-ref'ed with those individual IP tests.
V2 chip_flash_host_access

Verify access to the flash mem.

Verify that the CPU can read the flash mem contents.
V2 chip_flash_ctrl_ops

Verify flash ctrl ops.

Verify that the CPU can read / program and erase the flash mem. Pick an operation on both 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_flash_ctrl_scramble

Verify flash scrambling via the controller.

Verify that the CPU can program and read back data via the flash ctrl with scrambling enabled.
V2 chip_flash_scramble

Verify flash scrambling via the host interface.

Verify that the CPU read data from the flash with scrambling enabled.
V2 chip_flash_ast_pwr_dwn

Verify that power down signaling from AST to flash.

Details TBD.
V2 chip_flash_test_mode

Verify that flash test mode and flash volt signaling from chip IOs.

Details TBD.
V2 chip_rbox_key_pass_through

Verify pass through of key in to key out.

Details TBD.
V2 chip_rbox_pwrb_pass_through

Verify pass through of power button signal in to out.

Details TBD.
V2 chip_rbox_ac_present_in

Verify the RBOX can detect AC present input.

Details TBD.
V2 chip_rbox_batt_en_out

Verify the RBOX can signal battery enabled output.

Details TBD.
V2 chip_rbox_ec_entering_rw_in

Verify the RBOX can detect EC entering RW mode input.

Details TBD.
V2 chip_rbox_ec_in_rw_out

Verify the RBOX can signal EC in RW mode output.

Details TBD.
V2 chip_rbox_ec_reset_l_out

Verify the RBOX can signal EC reset output.

Verify EC reset pulse duration. Verify open drain when not active. Details TBD.
V2 chip_sleep_rbox_ios_val

Verify the RBOX can signal EC reset output.

Verify EC reset pulse duration. Verify open drain when not active. Details TBD.
V2 chip_sleep_adc_ctrl_ast_adc_pd

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

Details TBD.
V2 chip_sleep_adc_ctrl_debug_cable_wake

Verify that the debug cable detection logic can wake up the chip from sleep.

Details TBD.
V2 chip_adc_ctrl_ast_adc

Verify that the DCD can use the ADC within AST to know the voltage level.

Details TBD. SW test validates the reception of debug cable update interrupt.
V2 chip_adc_ctrl_por_l

Verify the POR reset input to DCD.

This sort of also tracks the testing of DCD surviving low power entry/exit. Details TBD.
V2 chip_ast_clk_outputs

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

Verify the clock frequencies are reasonably accurate. Verify that when the clkmgr deasserts the enable (on account of low power entry), the clocks are turned off. Verify that when turned on (low power exit), the clocks are glitch free.
V2 chip_ast_clk_rst_inputs

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

Details TBD.
V2 chip_ast_sys_clk_jitter

Verify that the AST sys clk jitter control.

Details TBD.
V2 chip_ast_usb_clk_calib

Verify the USB clk calibration signaling.

Details TBD.
V2 chip_ast_alerts

Verify the alerts from AST aggregating into the sensor_ctrl.

X-ref'ed with chip_sensor_ctrl_ast_alerts.
V2 chip_sensor_ctrl_ast_alerts

Verify the alerts from AST aggregating into the sensor_ctrl.

Details TBD.
V2 chip_sensor_ctrl_ast_status

Verify the io power ok status from AST.

Details TBD.
V2 chip_sw_boot

Verify the full flash image download with bootstrap signal set.

Details TBD.
V2 chip_secure_boot

Verify the secure boot flow.

Details TBD.
V2 chip_prod_os

Run the OpenTitan TockOS that will be deployed in production.

Run the TockOS image in DV. The advantage of doing so is running Tock with the full suite of design assertions and other checks in place in the DV environment.

chip_opentitan_tock
V2 chip_lc_walkthrough

Walk through the life cycle stages reseting the chip each time.

Verify that the features that should indeed be disabled are indeed disabled.
V2 chip_device_ownership

Walk through device ownership stages and flows.

Details TBD.
V2 enable_reg

The CSR test sequences will read and write accessible CSRs including the enable registers and their locked registers. The RAL model supports predicting the correct value of the locked registers based on their enable registers.

chip_tl_csr_rw
chip_jtag_csr_rw
chip_tl_csr_bit_bash
chip_jtag_csr_bit_bash
chip_tl_csr_aliasing
chip_jtag_csr_aliasing
V2 intr_test

Verify common intr_test CSRs that allows SW to mock-inject interrupts.

  • Enable a random set of interrupts by writing random value(s) to intr_enable CSR(s).
  • Randomly "turn on" interrupts by writing random value(s) to intr_test CSR(s).
  • Read all intr_state CSR(s) back to verify that it reflects the same value as what was written to the corresponding intr_test CSR.
  • Check the cfg.intr_vif pins to verify that only the interrupts that were enabled and turned on are set.
  • Clear a random set of interrupts by writing a randomly value to intr_state CSR(s).
  • Repeat the above steps a bunch of times.
chip_tl_intr_test
chip_jtag_intr_test
V2 tl_d_oob_addr_access

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

chip_tl_errors
V2 tl_d_illegal_access

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

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

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.

chip_csr_hw_reset
chip_csr_rw
chip_csr_aliasing
chip_same_csr_outstanding
V2 tl_d_partial_access

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

chip_csr_hw_reset
chip_csr_rw
chip_csr_aliasing
chip_same_csr_outstanding
V2 xbar_base_random_sequence

Enable all hosts to randomly send transactions to any device

xbar_chip_random
V2 xbar_random_delay

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

  • Zero delay for sending a/d_valid and a/d_ready
  • Large delay from 0 ~ 1000 cycles
  • Small delay (0-10 cycles) for a_channel, large delay (0-1000 cycles) for d_channel
xbar_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
V2 xbar_unmapped_address
  • Host randomly drives transactions with mapped and unmapped address
  • Ensure DUT returns d_error=1 if address is unmapped and transaction isn't passed down to any device
xbar_chip_unmapped_addr
xbar_chip_error_and_unmapped_addr
V2 xbar_error_cases
  • Drive any random value on size, mask, opcode in both channels
  • Ensure everything just pass through host to device or device to host
xbar_chip_error_random
xbar_chip_error_and_unmapped_addr
V2 xbar_all_access_same_device
  • Randomly pick a device, make all hosts to access this device
  • If the device isn't accessible for the host, let the host randomly access the other devices
xbar_chip_access_same_device
xbar_chip_access_same_device_slow_rsp
V2 xbar_all_hosts_use_same_source_id

Test all hosts use same ID at the same same

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