For detailed information on ALERT_HANDLER design features, please see the ALERT_HANDLER HWIP technical specification.
ALERT_HANDLER testbench has been constructed based on the CIP testbench architecture.
Top level testbench is located at hw/ip/alert_handler/dv/tb/tb.sv
. It instantiates the ALERT_HANDLER DUT module hw/ip/alert_handler/rtl/alert_handler.sv
. In addition, it instantiates the following interfaces, connects them to the DUT and sets their handle into uvm_config_db
:
alert_esc_if
)pins_if
)pins_if
)The alert_handler testbench environment can be reused in chip level testing.
The following utilities provide generic helper tasks and functions to perform activities that are common across the project:
All common types and methods defined at the package level can be found in alert_handler_env_pkg
. Some of them in use are:
parameter uint NUM_MAX_ESC_SEV = 8;
ALERT_HANDLER 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 ALERT_HANDLER device.
ALERT_ESC agent is used to drive and monitor transmitter and receiver pairs for the alerts and escalators. Alert_handler DUT includes alert_receivers and esc_senders, so the alert_esc agent will drive output signals of the alert_senders and esc_receivers.
The ALERT_HANDLER 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
.
All test sequences reside in hw/ip/alert_handler/dv/env/seq_lib
. The alert_handler_base_vseq
virtual sequence is extended from cip_base_vseq
and serves as a starting point. All test sequences are extended from alert_handler_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:
intr_en
, alert_en_shadowed_*
, alert_class_shadowed_*
, loc_alert_en_shadowed_*
, loc_alert_class_shadowed_*
registers.alert_sender_driver
.esc_receiver_driver
.classa/b/c/d_accum_cnt
, classa/b/c/d_esc_cnt
, and classa/b/c/d_state
.class*_state
registers and check esc_rx/tx signals.lpg_cg_en
or lpg_rst_en
to Mubi4True.esc_tx
when received escalation or escalation-ping requests.alert_rx
when received alert-ping requests.To ensure high quality constrained random stimulus, it is necessary to develop a functional coverage model. The detailed covergroups are documented under alert_handler testplan.
The alert_handler_scoreboard
is primarily used for end to end checking. It creates the following analysis ports to retrieve the data monitored by corresponding interface agents:
alert_fifo
that connects to corresponding alert_monitorsesc_fifo
that connects to corresponding esc_monitorsAlert_handler scoreboard monitors all valid CSR registers, alert handshakes, and escalation handshakes. To ensure certain alert, interrupt, or escalation signals are triggered at the expected time, the alert_handler scoreboard implemented a few counters:
timeout_cyc
registers, the corresponding escalation is expected to be triggeredaccum_threshold
registers, the corresponding escalation is expected to be triggeredphase_cyc
registersThe alert_handler scoreboard is parameterized to support different number of classes, alert pairs, and escalation pairs.
tb/alert_handler_bind.sv
binds the tlul_assert
assertions to the IP to ensure TileLink interface protocol compliance.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/$CHIP/ip_autogen/alert_handler/dv/alert_handler_sim_cfg.hjson -i alert_handler_smoke
In this run command, $CHIP can be top_earlgrey, etc.