ROM Controller DV document
- Verify all
rom_ctrlIP 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
- Verify all
- Verify TileLink device protocol compliance with an SVA based testbench
For detailed information on
rom_ctrl design features, please see the ROM Controller HWIP technical specification.
rom_ctrl testbench has been constructed based on the CIP testbench architecture.
Top level testbench
The top level testbench is located at
It instantiates the
rom_ctrl DUT module
In addition, it instantiates the following interfaces, connects them to the DUT and sets their handle into
- Clock and reset interface
- TileLink host interface
- Memory backdoor utility
- Alerts (
Common DV utility components
The following utilities provide generic helper tasks and functions to perform activities that are common across the project:
There is only one compile-time configuration, where arbitrary values are chosen for compile-time constants.
rom_ctrl testbench instantiates (already handled in CIP base env) tl_agent.
This provides the ability to drive and independently monitor random traffic via both TL host interfaces into the DUT.
UVM RAL Model
rom_ctrl RAL model is created with the
ralgen FuseSoC generator script automatically when the simulation is at the build stage.
The test sequences reside in
All test sequences are extended from
rom_ctrl_base_vseq, which is extended from
cip_base_vseq and serves as a starting point.
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:
rom_ctrl_mem_init: initialize the rom to random values
do_rand_ops: drive random traffic into the rom TLUL interface
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:
- Collect coverage on the rom_ctrl / kmac interface, specifically around stalling and back-pressure behavior.
- Collect coverage on the two TLUL interfaces, specifically checking that we see requests around the same time as the rom check completes.
- Collect coverage to ensure that a_valid goes high when rom check is in progress. This ensures that the scenario where TL accesses are blocked until the ROM check is done is covered.
- Collect coverage on the outputs sent to the power manager to confirm that we see pass and fail results.
rom_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:
The scoreboard monitors traffic sent to and from the KMAC interface. Data sent to KMAC during rom checking are compared against expected values from the memory model. The data received from the KMAC interface are used to update expected digest values and expected check pass/fail values.
Traffic from the ROM TLUL interface is monitored and compared against memory model to check for correctness.
- TLUL assertions: The
tb/rom_ctrl_bind.svfile binds the
tlul_assertassertions 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.
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/rom_ctrl/dv/rom_ctrl_sim_cfg.hjson -i rom_ctrl_smoke