RV_DM DV document
Goals
- DV
- Verify all RV_DM IP 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
- FPV
- Verify TileLink device protocol compliance with an SVA based testbench
Current status
Design features
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.
Testbench architecture
RV_DM has a standard UVM testbench, which is based on the CIP testbench architecture.
Block diagram
The flow of data into the scoreboard is described below.
Testbench
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
:
- Clock and reset interface
- TileLink host interface for the config space (which only contains the alert register).
- TileLink host interface for the debug memory space (which only contains the alert register).
- TileLink device interface for the SBA interface that is used by the JTAG debugger to access the whole chip.
- JTAG interface to act as an external JTAG host.
- Alert and escalation interface for the alert interface.
- The instantiation and hookup of this interface is done using the standardized common macro
`DV_ALERT_IF_CONNECT
defined inhw/dv/sv/dv_utils/dv_macros.svh
.
- The instantiation and hookup of this interface is done using the standardized common macro
- RV_DM interface for driving / sampling the remaining DUT IOs
- Inputs driven / sampled:
lc_hw_debug_en_i
,scanmode_i
,scan_rst_ni
,unavailable_i
- Outputs sampled:
ndmreset_req_o
,dmactive_o
&debug_req_o
- Inputs driven / sampled:
Common DV utility components
The following utilities provide generic helper tasks and functions to perform activities that are common across the project:
- dv_utils_pkg
- dv_lib_pkg
- cip_lib_pkg
- dv_base_reg_pkg
- csr_utils_pkg
TL_agent
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.
Alert_agent
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.
JTAG Agent
The RVDM testbench instantiates an instance of jtag_agent.
JTAG DMI 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
.
UVM RAL Model
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 TLregs
interface. This RAL model is auto-generated byralgen
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, nohjson
file associated with it. We manually create and maintain it athw/ip/rv_dm/data/rv_dm_debug_mem.hjson
, to serve our verification needs. This RAL model is also auto-generated byralgen
. -
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.
Stimulus strategy
Test sequences
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
.
Functional coverage
Please scroll down to the testplan section for a detailed list of covergroups implemented for RV_DM.
Self-checking strategy
Scoreboard
All transactions made to or coming from the DUT flow into the scoreboard, which models the design closely to verify the DUT behavior.
- The
cfg
class provides a handle to the virtual interfacerv_dm_if
which enables sampling of the DUT IOs (spare pins).- The scoreboard can sample the changes to input and output pins of the DUT and perform the necessary checks at the right instants.
- The
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. - The TL device agents monitor transactions on the TL interfaces and send accesses seen on the “main” CSR and debug memory spaces.
- The SBA TL host agent monitors transactions on the SBA TL host interface to compare against the SBA transactions predicted by the
sba_access_monitor
. - The
jtag_dmi_monitor
sends raw JTAG transactions that were not made to the JTAG DTM DMI register over itsnon_dmi_jtag_dtm_analysis_port
. - Finally, the
sba_acccess_monitor
sends both, the DMI transactions that were not made to the SBA DMI registers over thenon_sba_jtag_dmi_analysis_port
, as well as predicted SBA transactions over itsanalysis_port
.
Assertions
- TLUL assertions: The
tb/rv_dm_bind.sv
file 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/rv_dm/dv/rv_dm_sim_cfg.hjson -i rv_dm_smoke
Testplan
Testpoints
Stage | Name | Tests | Description |
---|---|---|---|
V1 | smoke | rv_dm_smoke | A basic smoke test.
|
V1 | jtag_dtm_csr_hw_reset | rv_dm_jtag_dtm_csr_hw_reset | Verify the reset values of JTAG DTM CSRs as indicated in the RAL specification. See hw/dv/tools/dvsim/testplans/csr_testplan.hjson for more description, This follows the same approach, but applies to the JTAG DTM regisers. In these set of tests, the lc_hw_debug_en is set to true, scanmode & scan_rst_n inputs to false. |
V1 | jtag_dtm_csr_rw | rv_dm_jtag_dtm_csr_rw | Verify accessibility of JTAG DTM CSRs as indicated in the RAL specification. See hw/dv/tools/dvsim/testplans/csr_testplan.hjson for more description, This follows the same approach, but applies to the JTAG DTM regisers. |
V1 | jtag_dtm_csr_bit_bash | rv_dm_jtag_dtm_csr_bit_bash | Verify no aliasing within individual bits of JTAG DTM CSR. See hw/dv/tools/dvsim/testplans/csr_testplan.hjson for more description, This follows the same approach, but applies to the JTAG DTM regisers. |
V1 | jtag_dtm_csr_aliasing | rv_dm_jtag_dtm_csr_aliasing | Verify no aliasing within the JTAG DTM CSR address space. See hw/dv/tools/dvsim/testplans/csr_testplan.hjson for more description, This follows the same approach, but applies to the JTAG DTM regisers. |
V1 | jtag_dmi_csr_hw_reset | rv_dm_jtag_dmi_csr_hw_reset | Verify the reset values of JTAG DMI CSRs as indicated in the RAL specification. See hw/dv/tools/dvsim/testplans/csr_testplan.hjson for more description, This follows the same approach, but applies to the JTAG DMI regisers. In these set of tests, the lc_hw_debug_en is set to true, scanmode & scan_rst_n inputs to false. Also, the dmcontrol[dmactive] field is set to 1 at the start, to ensure CSR accesses to all other registers go through. |
V1 | jtag_dmi_csr_rw | rv_dm_jtag_dmi_csr_rw | Verify accessibility of JTAG DMI CSRs as indicated in the RAL specification. See hw/dv/tools/dvsim/testplans/csr_testplan.hjson for more description, This follows the same approach, but applies to the JTAG DMI regisers. |
V1 | jtag_dmi_csr_bit_bash | rv_dm_jtag_dmi_csr_bit_bash | Verify no aliasing within individual bits of JTAG DMI CSR. See hw/dv/tools/dvsim/testplans/csr_testplan.hjson for more description, This follows the same approach, but applies to the JTAG DMI regisers. |
V1 | jtag_dmi_csr_aliasing | rv_dm_jtag_dmi_csr_aliasing | Verify no aliasing within the JTAG DMI CSR address space. See hw/dv/tools/dvsim/testplans/csr_testplan.hjson for more description, This follows the same approach, but applies to the JTAG DMI regisers. |
V1 | csr_hw_reset | rv_dm_csr_hw_reset | Verify the reset values as indicated in the RAL specification.
|
V1 | csr_rw | rv_dm_csr_rw | Verify accessibility of CSRs as indicated in the RAL specification.
|
V1 | csr_bit_bash | rv_dm_csr_bit_bash | Verify no aliasing within individual bits of a CSR.
|
V1 | csr_aliasing | rv_dm_csr_aliasing | Verify no aliasing within the CSR address space.
|
V1 | csr_mem_rw_with_rand_reset | rv_dm_csr_mem_rw_with_rand_reset | Verify random reset during CSR/memory access.
|
V1 | regwen_csr_and_corresponding_lockable_csr | rv_dm_csr_rw rv_dm_csr_aliasing | Verify regwen CSR and its corresponding lockable CSRs.
Note:
This is only applicable if the block contains regwen and locakable CSRs. |
V1 | mem_walk | rv_dm_mem_walk | Verify accessibility of all memories in the design.
|
V1 | mem_partial_access | rv_dm_mem_partial_access | Verify partial-accessibility of all memories in the design.
|
V2 | idcode | rv_dm_smoke | Verify that the JTAG IDCODE reads the correct value.
|
V2 | jtag_dtm_hard_reset | Verify that the debugger can camcel an on-going DMI transaction with a hard reset.
| |
V2 | jtag_dtm_idle_hint | Verify that the JTAG debugger does not need to stay any longer than the advertized idle time indicated in dtmcs register.
| |
V2 | jtag_dmi_failed_op | Verify that a failed DMI op is reflected properly in dtmcs register.
| |
V2 | jtag_dmi_dm_inactive | Verify that writes to DMI registers other than dmcontrol[dmactive] and ignored and they all retain the reset values on reads.
| |
V2 | sba | rv_dm_sba_tl_access rv_dm_delayed_resp_sba_tl_access | Verify all types of accesses from JTAG to SBA.
|
V2 | bad_sba | rv_dm_bad_sba_tl_access | Verify attempts to make bad SBA accesses results in the error sticky bits getting set.
Note: The following error scenarios are not supported by the design:
|
V2 | sba_autoincrement | rv_dm_autoincr_sba_tl_access | Verify the address autoincrement functionality of SBA.
|
V2 | jtag_dmi_debug_disabled | Verify that the JTAG DMI register space cannot be accessed if pinmux_hw_debug_en is a non strict true value.
| |
V2 | sba_debug_disabled | Verify that access to SBA interface is disabled if lc_hw_debug_en is set to not strict true value.
| |
V2 | ndmreset_req | Verify that the debugger can issue a non-debug reset to the rest of the system.
| |
V2 | hart_unavail | Verify that the debugger can read the status of unavailable hart
| |
V2 | tap_ctrl_transitions | Verify all JTAG TAP controller FSM transitions This test should verify that the standardized JTAG TAP FSM is working correctly. | |
V2 | stress_all | rv_dm_stress_all | A 'bug hunt' test that stresses the DUT to its limits.
|
V2 | alert_test | rv_dm_alert_test | Verify common
|
V2 | tl_d_oob_addr_access | rv_dm_tl_errors | Access out of bounds address and verify correctness of response / behavior |
V2 | tl_d_illegal_access | rv_dm_tl_errors | Drive unsupported requests via TL interface and verify correctness of response / behavior. Below error cases are tested bases on the [TLUL spec]({{< relref "hw/ip/tlul/doc/_index.md#explicit-error-cases" >}})
|
V2 | tl_d_outstanding_access | rv_dm_csr_hw_reset rv_dm_csr_rw rv_dm_csr_aliasing rv_dm_same_csr_outstanding | 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. |
V2 | tl_d_partial_access | rv_dm_csr_hw_reset rv_dm_csr_rw rv_dm_csr_aliasing rv_dm_same_csr_outstanding | 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. |
V2S | tl_intg_err | rv_dm_tl_intg_err rv_dm_sec_cm | Verify that the data integrity check violation generates an alert.
|
V2S | sec_cm_bus_integrity | Verify the countermeasure(s) BUS.INTEGRITY. | |
V2S | sec_cm_lc_hw_debug_en_intersig_mubi | Verify the countermeasure(s) LC_HW_DEBUG_EN.INTERSIG.MUBI. | |
V2S | sec_cm_dm_en_ctrl_lc_gated | Verify the countermeasure(s) DM_EN.CTRL.LC_GATED. | |
V2S | sec_cm_sba_tl_lc_gate_fsm_sparse | Verify the countermeasure(s) SBA_TL_LC_GATE.FSM.SPARSE. | |
V2S | sec_cm_mem_tl_lc_gate_fsm_sparse | Verify the countermeasure(s) MEM_TL_LC_GATE.FSM.SPARSE. | |
V2S | sec_cm_exec_ctrl_mubi | Verify the countermeasure(s) EXEC.CTRL.MUBI. | |
V3 | stress_all_with_rand_reset | rv_dm_stress_all_with_rand_reset | This test runs 3 parallel threads - stress_all, tl_errors and random reset. After reset is asserted, the test will read and check all valid CSR registers. |
Covergroups
Name | Description |
---|---|
regwen_val_when_new_value_written_cg | Cover each lockable reg field with these 2 cases:
This is only applicable if the block contains regwen and locakable CSRs. |
sba_access_cg | Cover all possible types of accesses over SBA.
|
tl_errors_cg | Cover the following error cases on TL-UL bus:
|
tl_intg_err_cg | Cover all kinds of integrity errors (command, data or both) and cover number of error bits on each integrity check. Cover the kinds of integrity errors with byte enabled write on memory if applicable: Some memories store the integrity values. When there is a subword write, design re-calculate the integrity with full word data and update integrity in the memory. This coverage ensures that memory byte write has been issued and the related design logic has been verfied. |