For detailed information on RV_DM design features, please see the RV_DM HWIP technical specification. The internal debug logic is vendored-in from the external PULP RISC-V debug repository.
RV_DM has a standard UVM testbench, which is based on the CIP testbench architecture.
The flow of data into the scoreboard is described below.
The top level testbench is located at hw/ip/rv_dm/dv/tb.sv
. It instantiates the RV_DM DUT module hw/ip/rv_dm/rtl/rv_dm.sv
. In addition, it instantiates the following interfaces, connects them to the DUT and sets their handle into uvm_config_db
:
`DV_ALERT_IF_CONNECT
defined in hw/dv/sv/dv_utils/dv_macros.svh
.lc_hw_debug_en_i
, scanmode_i
, scan_rst_ni
, unavailable_i
ndmreset_req_o
, dmactive_o
& debug_req_o
The following utilities provide generic helper tasks and functions to perform activities that are common across the project:
The RV_DM 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 RV_DM device.
RV_DM testbench instantiates an alert_agent. This is already done in the CIP base environment. It uses a string array of alert names to associate each instance of an alert signal. RV_DM exposes only a single alert signal, so this array is set to [“fatal_fault”]. This alert is wired from the bus integrity logic.
The alert_agents provide the ability to drive and independently monitor the alert handshakes via alert interfaces which are connected to the DUT.
The RVDM testbench instantiates an instance of jtag_agent.
The RV_DM testbench instantiates the sub-components of jtag_dmi_agent - the jtag_dmi_monitor
, sba_access_monitor
and the jtag_dmi_reg_block
.
On OpenTitan, the DV RAL models are typically generated with the ralgen
FuseSoC generator script automatically when the simulations are run. ralgen
invokes the reggen
tool underneath, which takes the design specification hjson
file as input, which contains the register descriptions. This generator is invoked by FuseSoC when it processes the RV_DM environment core file located at hw/ip/rv_dm/dv/env/rv_dm_env.core
.
RV_DM has 4 distinct register spaces that are accessed via different interfaces. The RAL models associated with each of these are created using different methods. They are as follows:
RV_DM regs RAL model: The registers in the space are defined in the design specification hjson
file. They are accessed by software via its ‘main’ TL device interface, referred to in the design as TL regs
interface. This RAL model is auto-generated by ralgen
when running simulations.
RV_DM debug memory RAL model: This region is the core debug memory which contains registers, a program buffer (SRAM) and a ROM section. It is accessed via the second TL device interface, which is referred to in the design as TL rom
interface. The design associated with this space comes from the external PULP RISC-V debug repository. There is hence, no hjson
file associated with it. We manually create and maintain it at hw/ip/rv_dm/data/rv_dm_debug_mem.hjson
, to serve our verification needs. This RAL model is also auto-generated by ralgen
.
JTAG DTM RAL model: This RAL model describes the JTAG data transport module (DTM) registers, and can be accessed only via JTAG. This RAL model is hand-written and checked into our repository in the jtag_agent
area.
JTAG DMI RAL model: The RISC-V debug specification defines registers in the DMI space, which also can be accessed only via JTAG. These registers facilitate CPU debug. The PULP RISC-V debug implementation however only implements a subset of these registers. This RAL model is also checked into our repository in the jtag_agent
area. It is created in the RV_DM environment configuration object.
All four of these RAL models can be referenced (directly or indirectly) using the RV_DM environment configuration object.
The test sequences reside in hw/ip/rv_dm/dv/env/seq_lib
. All test sequences are extended from rv_dm_base_vseq
, which is extended from cip_base_vseq
and serves as a starting point. It provides the following commonly used handles, variables, functions and tasks that the test sequences can simply use / call.
sba_tl_device_seq_start(): This task enables the auto-responding device sequence that is run on the TLUL device agent sequencer that is attached to the SBA TL interface. This task is non-blocking - it spawns off a separate, perpetually running thread which runs the sequence independently. The task provides some arguments to “pattern” the kind of randomized responses that are sent.
sba_tl_device_seq_stop(): This method stops the previously spawned SBA TL device sequence from executing further. If the invocation of this task coincides with a new SBA TL request from RV_DM then the new request is accepted. The task waits for all accepted requests to be serviced (i.e. responded to) before returning back to the caller.
All test sequences extend from rv_dm_base_vseq
.
Please scroll down to the testplan section for a detailed list of covergroups implemented for RV_DM.
All transactions made to or coming from the DUT flow into the scoreboard, which models the design closely to verify the DUT behavior.
cfg
class provides a handle to the virtual interface rv_dm_if
which enables sampling of the DUT IOs (spare pins).cfg
class also provides handles to all four RAL models (two on the TL interfaces, and two on JTAG), which are used to maintain a mirror of what we predict the design would also reflect.sba_access_monitor
.jtag_dmi_monitor
sends raw JTAG transactions that were not made to the JTAG DTM DMI register over its non_dmi_jtag_dtm_analysis_port
.sba_acccess_monitor
sends both, the DMI transactions that were not made to the SBA DMI registers over the non_sba_jtag_dmi_analysis_port
, as well as predicted SBA transactions over its analysis_port
.tb/rv_dm_bind.sv
file 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/ip/rv_dm/dv/rv_dm_sim_cfg.hjson -i rv_dm_smoke