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

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 in hw/dv/sv/dv_utils/dv_macros.svh.
  • 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

Common DV utility components

The following utilities provide generic helper tasks and functions to perform activities that are common across the project:

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 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.

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 interface rv_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 its non_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 the non_sba_jtag_dmi_analysis_port, as well as predicted SBA transactions over its analysis_port.

Assertions

  • TLUL assertions: The tb/rv_dm_bind.sv file binds the tlul_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.

  • Read the DTM register idcode and verify that it reflects the correct value.
  • Enable debug by setting lc_hw_debug_en to true.
  • Write to the DMI register field dmcontrol[dmactive] via JTAG and verify that the dmactive output pin reflects the same value.
  • Write to the DMI register field dmcontrol[haltreq] via JTAG and verify that the debug_req output pin reflects the same value.
  • Write to the DMI register field dmcontrol[ndmreset] via JTAG and verify that the ndmreset output pin reflects the same value.
  • Wiggle the unavailable input and read the DTM register field dmstatus[allunavail] to verify that it reflects the same value as the input signal.
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.

  • Write all CSRs with a random value.
  • Apply reset to the DUT as well as the RAL model.
  • Read each CSR and compare it against the reset value. it is mandatory to replicate this test for each reset that affects all or a subset of the CSRs.
  • It is mandatory to run this test for all available interfaces the CSRs are accessible from.
  • Shuffle the list of CSRs first to remove the effect of ordering.
V1 csr_rw rv_dm_csr_rw

Verify accessibility of CSRs as indicated in the RAL specification.

  • Loop through each CSR to write it with a random value.
  • Read the CSR back and check for correctness while adhering to its access policies.
  • It is mandatory to run this test for all available interfaces the CSRs are accessible from.
  • Shuffle the list of CSRs first to remove the effect of ordering.
V1 csr_bit_bash rv_dm_csr_bit_bash

Verify no aliasing within individual bits of a CSR.

  • Walk a 1 through each CSR by flipping 1 bit at a time.
  • Read the CSR back and check for correctness while adhering to its access policies.
  • This verify that writing a specific bit within the CSR did not affect any of the other bits.
  • It is mandatory to run this test for all available interfaces the CSRs are accessible from.
  • Shuffle the list of CSRs first to remove the effect of ordering.
V1 csr_aliasing rv_dm_csr_aliasing

Verify no aliasing within the CSR address space.

  • Loop through each CSR to write it with a random value
  • Shuffle and read ALL CSRs back.
  • All CSRs except for the one that was written in this iteration should read back the previous value.
  • The CSR that was written in this iteration is checked for correctness while adhering to its access policies.
  • It is mandatory to run this test for all available interfaces the CSRs are accessible from.
  • Shuffle the list of CSRs first to remove the effect of ordering.
V1 csr_mem_rw_with_rand_reset rv_dm_csr_mem_rw_with_rand_reset

Verify random reset during CSR/memory access.

  • Run csr_rw sequence to randomly access CSRs
  • If memory exists, run mem_partial_access in parallel with csr_rw
  • Randomly issue reset and then use hw_reset sequence to check all CSRs are reset to default value
  • It is mandatory to run this test for all available interfaces the CSRs are accessible from.
V1 regwen_csr_and_corresponding_lockable_csrrv_dm_csr_rw
rv_dm_csr_aliasing

Verify regwen CSR and its corresponding lockable CSRs.

  • Randomly access all CSRs
  • Test when regwen CSR is set, its corresponding lockable CSRs become read-only registers

Note:

  • If regwen CSR is HW read-only, this feature can be fully tested by common CSR tests - csr_rw and csr_aliasing.
  • If regwen CSR is HW updated, a separate test should be created to test it.

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.

  • Run the standard UVM mem walk sequence on all memories in the RAL model.
  • It is mandatory to run this test from all available interfaces the memories are accessible from.
V1 mem_partial_access rv_dm_mem_partial_access

Verify partial-accessibility of all memories in the design.

  • Do partial reads and writes into the memories and verify the outcome for correctness.
  • Also test outstanding access on memories
V2 idcode rv_dm_smoke

Verify that the JTAG IDCODE reads the correct value.

  • Set a different JTAG ID code an rv_dm design parameter.
  • Read the IDCODE register in JTAG DTM register space, via JTAG.
  • Verify it reads back what was set.
V2 jtag_dtm_hard_reset

Verify that the debugger can camcel an on-going DMI transaction with a hard reset.

  • Perform a random legal DMI write to a chosen DMI register and immediately write to dtmcs[dmihardreset] bit.
  • Read the target DMI register to verify the write did not succeed.
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.

  • Read the dtmcs[idle] value and configure the JTAG DMI register adapter to insert that many delay between transactions.
  • Issue random legal DMI accesses back to back and ensure that all of them complete successfully, without dmistat reflecting an error.
V2 jtag_dmi_failed_op

Verify that the a failed DMI op is reflected properly in dtmcs register.

  • Issue a random legal DMI write to a chosen DMI register.
  • Before that access completes, issue another random legal DMI access.
  • Read the dtmcs[dmistat] register to verify busy error.
  • Clear it by writing to dtmcs[dmireset] register.
  • Poll the DMI access for completion and verify that the first write completed successfully by doing a read-check.
  • TBO - unclear how to generate other types of failed DMI transactions.
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.

  • Perform random writes to DMI registers while dmcontrol[dmactive] is 0 (exclude it).
  • Read all DMI registers back and verify they reflect POR values.
V2 sba rv_dm_sba_tl_access

Verify all types of accesses from JTAG to SBA.

  • Enable debug by setting lc_hw_debug_en to true and activate the dm
  • Write to SBA registers to inject randomized 8/16/32bit writes and reads.
  • Randomize readonaddr and readondata settings and ensure those have the intended effect.
  • Inject a new SBA traffic before the previous one completes - verify that the sbbusyerror asserts.
  • Randomly inject TL intg error and bus access error on the response channel and ensure no deadlocks. The SBA host interface does not support signaling of errors, so this has no effect.
  • Randomly also enable abautoincrement.
  • The TL intg error on SBA TL interface is intentionally not wired to an alert - verify no alerts occur.
  • Hav.
V2 bad_sba rv_dm_bad_sba_tl_access

Verify attempts to make bad SBA accesses results in sberror sticky bit getting set.

  • Enable debug by setting lc_hw_debug_en to true and activate the dm.
  • Inject a randomized SBA access that is not aligned to the size of the transfer and verify that the sberror bit is set to 3.
  • Inject a randomized SBA access that is greater that the supported transfer size and verify that the sberror bit is set to 4.

Note: The following error scenarios are not supported by the design:

  • pulp-platform/riscv-dbg#128: response timeout (sberror = 1) is not implemented.
  • pulp-platform/riscv-dbg#86: bad address (sberror = 2) is not defined or implemented.
  • 'Other' error cases (sberror = 7) is not defined.
V2 sba_autoincrement rv_dm_autoincr_sba_tl_access

Verify the address autoincrement functionality of SBA.

  • Enable debug by setting lc_hw_debug_en to true and activate the dm.
  • Write to the SBCS register to inject randomized 8/16/32bit writes. Set the autoincrement bit.
  • Pick a random address and write to sbaddress0 register.
  • Write a random value to sbdata0, repeating a randomized number of times.
  • Each write should trigger a new SBA TL write access with the address incremented with the transfer size. Verify that the SBA TL access shows up.
  • Repeat the same procedure for reads. For reads, set the readondata register and read the sbdata0 a randomized number of times - each read should trigger a new SBA TL read access.
V2 jtag_dmi_debug_disabled

Verify that the JTAG DMI register space cannot be accessed if lc_hw_debug_en is a non strict true value.

  • Set lc_hw_debug_en to true and activate the dm.
  • Write a known value to a randomly picked DMI CSR.
  • Set lc_hw_debug_en to non-true value.
  • Write a different value to the same DMI CSR.
  • Attempt to read that DMI CSR - it should read all 0s.
  • Note that the above steps are rendered moot becuase the JTAG DTM itself will not receive any incoming JTAG transactions.
  • Set lc_hw_debug_en to true and again, read the DMI CSR - it should reflect the originally written 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.

  • Set lc_hw_debug_en to true and activate the dm.
  • Attempt to inject a legal randomized SBA access - verify that it comes through.
  • Set lc_hw_debug_en to non-true value and activate the dm.
  • Attempt to inject a legal randomized SBA access - verify that no SBA TL accesses appear on the TL interface.
  • Reapeat, a random number of times.
  • Verify via assertion checks, no transactions were seen on the SBA TL interface.
V2 debug_mem_debug_disabled

Verify that access to the debug mem via TL host interface results in error response.

  • Set lc_hw_debug_en to true and activate the dm.
  • Write a known value to a randomly picked debug mem CSR.
  • Set lc_hw_debug_en to non-true value.
  • Attempt to write a different value to the same CSR - verify error response.
  • Attempt to read that CSR - verify error response.
  • Attempt a number of legal accesses to any of the CSRs or memories in this space - they all should result in error response.
  • Set lc_hw_debug_en to true and again, read the debug mem CSR - it should reflect the originally written value.
V2 debug_req

Verify that the debugger can issue a debug request to the CPU.

  • Set lc_hw_debug_en to non-true value and activate the dm.
  • Set unavailable input to 0 to reflect that the hart is available.
  • Write dmcontrol[haltreq] to 1 via JTAG and poll for dmstatus[allhalted] to be set.
  • Verify that the debug_req output asserts.
  • On the debug mem TL interface, after some random delay, write 1 to the halted register in the debub memory.
  • Ensure that the polling in the loop above completes.
V2 ndmreset_req

Verify that the debugger can issue a non-debug reset to the rest of the system.

  • Set lc_hw_debug_en to true value and activate the dm.
  • Pick a random set of write/readable CSRs in all 3 RALs (JTAG DMI, regs RAL and debug mem RAL). Write known values to them.
  • Write the dmcontrol register to assert ndmreset - verify that the ndmreset output stays asserted.
  • Mimic the CPU going into reset by asserting unavailable input.
  • Read the dmstatus register to verify allunavail is asserted.
  • De-assert the ndmreset by writing 0 to the dmcontrol register field, verify the ndmreset output deasserted as well.
  • Mimic the CPU coing out of reset reset by de-asserting unavailable input after some delay.
  • Read the previously written registers back and verify that they reflect the previously written value, proving that ndmreset assertion had no effect on them.
V2 hart_unavail

Verify that the debugger can read the status of unavailable hart

  • Set lc_hw_debug_en to true value and activate the dm.
  • Randomly assert and de-assert the unavailable input (indicates the CPU is under reset). This ideally happens when ndmreset is issued by the debugger.
  • Periodically issue reads to dmstatus register to verify allunavail matches the unavailable input value
V2 prog_buf

Verify that a halted hart can execute arbitrary set of instructions via program buffer.

  • TBD.
V2 abstract_cmd

Verify the quick-access abstract command feature.

  • TBD
V2 abstract_cmd_err

Verify the abstract command error scenarios.

  • TBD
V2 stress_all rv_dm_stress_all

A 'bug hunt' test that stresses the DUT to its limits.

  • Combine above sequences in one test and run as many of them as possible in parallel. Run the rest sequentially.
  • Randomly inject a full device reset intermittently.
V2 alert_test rv_dm_alert_test

Verify common alert_test CSR that allows SW to mock-inject alert requests.

  • Enable a random set of alert requests by writing random value to alert_test CSR.
  • Check each alert_tx.alert_p pin to verify that only the requested alerts are triggered.
  • During alert_handshakes, write alert_test CSR again to verify that: If alert_test writes to current ongoing alert handshake, the alert_test request will be ignored. If alert_test writes to current idle alert handshake, a new alert_handshake should be triggered.
  • Wait for the alert handshakes to finish and verify alert_tx.alert_p pins all sets back to 0.
  • Repeat the above steps a bunch of times.
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" >}})

  • TL-UL protocol error cases
    • invalid opcode
    • some mask bits not set when opcode is PutFullData
    • mask does not match the transfer size, e.g. a_address = 0x00, a_size = 0, a_mask = 'b0010
    • mask and address misaligned, e.g. a_address = 0x01, a_mask = 'b0001
    • address and size aren't aligned, e.g. a_address = 0x01, a_size != 0
    • size is greater than 2
  • OpenTitan defined error cases
    • access unmapped address, expect d_error = 1 when devmode_i == 1
    • write a CSR with unaligned address, e.g. a_address[1:0] != 0
    • write a CSR less than its width, e.g. when CSR is 2 bytes wide, only write 1 byte
    • write a memory with a_mask != '1 when it doesn't support partial accesses
    • read a WO (write-only) memory
    • write a RO (read-only) memory
    • write with instr_type = True
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.

  • Randomly inject errors on the control, data, or the ECC bits during CSR accesses. Verify that triggers the correct fatal alert.
  • Inject a fault at the onehot check in u_reg.u_prim_reg_we_check and verify the corresponding fatal alert occurs
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_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:

  • When regwen = 1, a different value is written to the lockable CSR field, and a read occurs after that.
  • When regwen = 0, a different value is written to the lockable CSR field, and a read occurs after that.

This is only applicable if the block contains regwen and locakable CSRs.

sba_access_cg

Cover all possible types of accesses over SBA.

  • cp: reads and write accesses
  • cp: supported transfer sizes
  • cp: auto-increment address with back-to-back acesses
  • cp: for reads, cover readonaddr and readondata settings
  • cp: sberror cases with unaligned address and unsupported size
  • cp: sbbusyerror case - attempt new access before the previous one completed
  • cr: cross all of the above
tl_errors_cg

Cover the following error cases on TL-UL bus:

  • TL-UL protocol error cases.
  • OpenTitan defined error cases, refer to testpoint tl_d_illegal_access.
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.