OTP_CTRL DV Plan
Goals
- DV
- Verify all OTP_CTRL IP features by running dynamic simulations with a SV/UVM based testbench
- Develop and run all tests based on the testplan below towards closing code and functional coverage on the IP and all of its sub-modules
- FPV
- Verify TileLink device protocol compliance with an SVA based testbench
Current status
Design features
For detailed information on OTP_CTRL design features, please see the OTP_CTRL HWIP technical specification.
Testbench architecture
OTP_CTRL testbench has been constructed based on the CIP testbench architecture.
Block diagram
Top level testbench
Top level testbench is located at hw/ip/otp_ctrl/dv/tb/tb.sv
. It instantiates the OTP_CTRL DUT module hw/ip/otp_ctrl/rtl/otp_ctrl.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
- TileLink host interface
- OTP_CTRL IOs
- Interrupts (
pins_if
- Alerts (
pins_if
- Devmode (
pins_if
Common DV utility components
The following utilities provide generic helper tasks and functions to perform activities that are common across the project:
Compile-time configurations
[list compile time configurations, if any and what are they used for]
Global types & methods
All common types and methods defined at the package level can be found in
otp_ctrl_env_pkg
. Some of them in use are:
[list a few parameters, types & methods; no need to mention all]
TL_agent
OTP_CTRL testbench instantiates (already handled in CIP base env) tl_agent which provides the ability to drive and independently monitor random traffic via TL host interface into OTP_CTRL device.
UVC/agent 1
[Describe here or add link to its README]
UVC/agent 2
[Describe here or add link to its README]
UVM RAL Model
The OTP_CTRL RAL model is created with the ralgen
FuseSoC generator script automatically when the simulation is at the build stage.
It can be created manually by invoking regtool
:
Reference models
[Describe reference models in use if applicable, example: SHA256/HMAC]
Stimulus strategy
Test sequences
All test sequences reside in hw/ip/otp_ctrl/dv/env/seq_lib
.
The otp_ctrl_base_vseq
virtual sequence is extended from cip_base_vseq
and serves as a starting point.
All test sequences are extended from otp_ctrl_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 otp_ctrl_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/otp_ctrl_bind.sv
binds thetlul_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
We are using our in-house developed regression tool for building and running our tests and regressions. Please take a look at the link for detailed information on the usage, capabilities, features and known issues. Here’s how to run a smoke test:
$ $REPO_TOP/util/dvsim/dvsim.py $REPO_TOP/hw/ip/otp_ctrl/dv/otp_ctrl_sim_cfg.hjson -i otp_ctrl_smoke
Testplan
Milestone | Name | Description | Tests |
---|---|---|---|
V1 | wake_up | Wake_up test walks through otp_ctrl's power-on initialization, read, program, and digest functionalities.
| otp_ctrl_wake_up |
V1 | smoke | Otp_ctrl smoke test to provision and lock partitions.
| otp_ctrl_smoke |
V1 | csr_hw_reset | Verify the reset values as indicated in the RAL specification.
| otp_ctrl_csr_hw_reset |
V1 | csr_rw | Verify accessibility of CSRs as indicated in the RAL specification.
| otp_ctrl_csr_rw |
V1 | csr_bit_bash | Verify no aliasing within individual bits of a CSR.
| otp_ctrl_csr_bit_bash |
V1 | csr_aliasing | Verify no aliasing within the CSR address space.
| otp_ctrl_csr_aliasing |
V1 | csr_mem_rw_with_rand_reset | Verify random reset during CSR/memory access.
| otp_ctrl_csr_mem_rw_with_rand_reset |
V1 | mem_walk | Verify accessibility of all memories in the design.
| otp_ctrl_mem_walk |
V1 | mem_partial_access | Verify partial-accessibility of all memories in the design.
| otp_ctrl_mem_partial_access |
V2 | all_partitions | Based on the smoke test, this test ensures every address in each partition can be accessed successfully within its access policy. | |
V2 | partition_check_failure | Randomly program partition check related registers including:
| |
V2 | partition_lock | This test will cover two methods of locking read and write: digest calculation and CSR
write. After locking the partitions, issue read or program sequences and check if the
operations are locked correctly, and check if the | |
V2 | interface_key_check | OTP_CTRL can output keys to key_manager, flash, sram, and OTBN. This test will modify inputs and OTP storage, the check if generated keys are correct. | |
V2 | lc_interactions | This test check otp and life_cycle interactions.
| otp_ctrl_lc |
V2 | otp_macro_errors | This test will randomly run the following OTP errors:
The test will check:
| |
V2 | otp_ctrl_errors | This test will randomly run the following OTP errors:
The test will check:
| |
V2 | test_access | This test checks if the test access to OTP macro is connected correctly.
| |
V2 | stress_all |
| |
V2 | intr_test | Verify common intr_test CSRs that allows SW to mock-inject interrupts.
| otp_ctrl_intr_test |
V2 | alert_test | Verify common
| otp_ctrl_alert_test |
V2 | tl_d_oob_addr_access | Access out of bounds address and verify correctness of response / behavior | otp_ctrl_tl_errors |
V2 | tl_d_illegal_access | Drive unsupported requests via TL interface and verify correctness of response / behavior. Below error cases are tested
| otp_ctrl_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. | otp_ctrl_csr_hw_reset otp_ctrl_csr_rw otp_ctrl_csr_aliasing otp_ctrl_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 | otp_ctrl_csr_hw_reset otp_ctrl_csr_rw otp_ctrl_csr_aliasing otp_ctrl_same_csr_outstanding |