For detailed information on SYSRST_CTRL design features, please see the SYSRST_CTRL HWIP technical specification.
SYSRST_CTRL testbench has been constructed based on the CIP testbench architecture.
The top level testbench is located at hw/ip/sysrst_ctrl/dv/tb.sv
. It instantiates the SYSRST_CTRL DUT module hw/ip/sysrst_ctrl/rtl/sysrst_ctrl.sv
. In addition, it instantiates the following interfaces, connects them to the DUT and sets their handle into uvm_config_db
:
pins_if
)alert_esc_if
)pins_if
)The following utilities provide generic helper tasks and functions to perform activities that are common across the project:
[list compile time configurations, if any and what are they used for]
All common types and methods defined at the package level can be found in sysrst_ctrl_env_pkg
.
The SYSRST_CTRL testbench instantiates (already handled in CIP base env) tl_agent. This provides the ability to drive and independently monitor random traffic via the TL host interface into the SYSRST_CTRL device.
SYSRST_CTRL testbench instantiates (already handled in CIP base env) alert_agents: [list alert names]. The alert_agents provide the ability to drive and independently monitor alert handshakes via alert interfaces in SYSRST_CTRL device.
The SYSRST_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
:
The test sequences reside in hw/ip/sysrst_ctrl/dv/env/seq_lib
. All test sequences are extended from sysrst_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.
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:
The sysrst_ctrl_scoreboard
is primarily used for end to end checking.
sva/sysrst_ctrl_bind.sv
file binds the tlul_assert
assertions to the IP to ensure TileLink interface protocol compliance.tb.sv
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/sysrst_ctrl/dv/sysrst_ctrl_sim_cfg.hjson -i sysrst_ctrl_smoke
{{< incGenFromIpDesc “/hw/ip/sysrst_ctrl/data/sysrst_ctrl_testplan.hjson” “testplan” >}}