ADC_CTRL DV document
Goals
- DV
- Verify all ADC_CTRL IP features by running dynamic simulations with a SV/UVM based testbench
- Develop and run all tests based on the DV plan 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 ADC_CTRL design features, please see the ADC_CTRL HWIP technical specification.
Testbench architecture
ADC_CTRL testbench has been constructed based on the CIP testbench architecture.
Block diagram
Top level testbench
Top level testbench is located at hw/ip/adc_ctrl/dv/tb/tb.sv
. It instantiates the ADC_CTRL DUT module hw/ip/adc_ctrl/rtl/adc_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
- ADC_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
adc_ctrl_env_pkg
. Some of them in use are:
[list a few parameters, types & methods; no need to mention all]
TL_agent
ADC_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 ADC_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 ADC_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/adc_ctrl/dv/env/seq_lib
.
The adc_ctrl_base_vseq
virtual sequence is extended from cip_base_vseq
and serves as a starting point.
All test sequences are extended from adc_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 adc_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/adc_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/adc_ctrl/dv/adc_ctrl_sim_cfg.hjson -i adc_ctrl_smoke
DV plan
Milestone | Name | Description | Tests |
---|---|---|---|
V1 | smoke | Smoke test accessing a major datapath within the dcd. Stimulus:
Checks:
| adc_ctrl_smoke |
V1 | feature1 | Add more test entries here like above. | |
V1 | csr_hw_reset | Verify the reset values as indicated in the RAL specification.
| adc_ctrl_csr_hw_reset |
V1 | csr_rw | Verify accessibility of CSRs as indicated in the RAL specification.
| adc_ctrl_csr_rw |
V1 | csr_bit_bash | Verify no aliasing within individual bits of a CSR.
| adc_ctrl_csr_bit_bash |
V1 | csr_aliasing | Verify no aliasing within the CSR address space.
| adc_ctrl_csr_aliasing |
V1 | csr_mem_rw_with_rand_reset | Verify random reset during CSR/memory access.
| adc_ctrl_csr_mem_rw_with_rand_reset |
V1 | mem_walk | Verify accessibility of all memories in the design.
| adc_ctrl_mem_walk |
V1 | mem_partial_access | Verify partial-accessibility of all memories in the design.
| adc_ctrl_mem_partial_access |
V2 | intr_test | Verify common intr_test CSRs that allows SW to mock-inject interrupts.
| adc_ctrl_intr_test |
V2 | tl_d_oob_addr_access | Access out of bounds address and verify correctness of response / behavior | adc_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
| adc_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. | adc_ctrl_csr_hw_reset adc_ctrl_csr_rw adc_ctrl_csr_aliasing adc_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 | adc_ctrl_csr_hw_reset adc_ctrl_csr_rw adc_ctrl_csr_aliasing adc_ctrl_same_csr_outstanding |