PWRMGR DV document

Goals

  • DV
    • Verify all PWRMGR 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 PWRMGR design features, please see the PWRMGR HWIP technical specification.

Testbench architecture

PWRMGR testbench has been constructed based on the CIP testbench architecture.

Block diagram

Block diagram

Top level testbench

Top level testbench is located at hw/ip/pwrmgr/dv/tb.sv. It instantiates the PWRMGR DUT module hw/ip/pwrmgr/rtl/pwrmgr.sv. In addition, it instantiates the following interfaces, connects them to the DUT and sets their handle into uvm_config_db:

Common DV utility components

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

Global types & methods

All common types and methods defined at the package level can be found in pwrmgr_env_pkg. Some of them in use are:

  typedef enum int {
    WakeupSysrst,
    WakeupDbgCable,
    WakeupPin,
    WakeupUsb,
    WakeupAonTimer,
    WakeupSensorCtrl
  } wakeup_e;

  typedef struct packed {
    logic main_pd_n;
    logic usb_clk_en_active;
    logic usb_clk_en_lp;
    logic io_clk_en;
    logic core_clk_en;
  } control_enables_t;

  typedef bit [pwrmgr_reg_pkg::NumWkups-1:0] wakeups_t;
  typedef bit [pwrmgr_reg_pkg::NumRstReqs-1:0] resets_t;

  // This is used to send all resets to rstmgr.
  typedef bit [pwrmgr_pkg::HwResetWidth-1:0] resets_out_t;

TL_agent

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

UVM RAL Model

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

Stimulus strategy

The sequences are closely related to the testplan’s testpoints. Testpoints and coverage are described in more detail in the testplan. All test sequences reside in hw/ip/pwrmgr/dv/env/seq_lib, and extend pwrmgr_base_vseq. The pwrmgr_base_vseq virtual sequence is extended from cip_base_vseq and serves as a starting point. It provides commonly used handles, variables, functions and tasks used by the test sequences. Some of the most commonly used tasks and functions are as follows:

  • task wait_for_fast_fsm_active: Waits for the fetch_en_o output to become 1, indicating the fast fsm is active and the cpu can fetch instructions. We wait for this before the tests can start, since any CSR accesses require the CPU to be running. Due to complexities in the UVM sequences this task is called in the virtual post_apply_reset task of dv_base_vseq.
  • task wait_for_csr_to_propagate_to_slow_domain: Waits for cfg_cdc_sync CSR to be clear, indicating the CDC to the slow clock has completed.
  • task wait_for_reset_cause: Waits for the pwr_rst_req.reset_cause output to match an expected cause.
  • task check_wait_info: Checks the wake_info CSR matches expectations.
  • task check_reset_status: Checks the reset_status CSR matches expectations.
  • task check_and_clear_interrupt: Checks the interrupt enable, status, and output pin.

In addition, the base sequence provides two tasks that provide expected inputs based on the pwrmgr outputs. In the absence of these inputs the pwrmgr will be stuck waiting forever. Being based on outputs means the inputs are in accordance to the implicit protocol. The tasks in question are:

  • task slow_responder: Handles required input changes from AST for the slow state machine. For the various <clk>_en outputs it changes the <clk>_val as required, for core, io, main, and usb clocks.
  • task fast_responder: Handles input changes for the fast state machine.
    • Completes the handshake with rstmgr for lc and sys resets: some random cycles after an output reset is requested the corresponding reset src input must go low.
    • Completes the handshake with clkmgr: the various <clk>_status inputs need to match the corresponding <clk>_ip_clk_en output after some cycles, for io, main, and usb clocks.
    • Completes the handshake with lc and otp: both *_done inputs must match the corresponding *_init outputs after some cycles.

These tasks are started by the parent sequence’s pre_start task, and terminated gracefully in the parent sequence’s post_start task.

Test sequences

The test sequences besides the base are as follows:

  • pwrmgr_smoke_vseq tests the pwrmgr through POR, entry and exit from software initiated low power and reset.
  • pwrmgr_wakeup_vseq checks the transitions to low power and the wakeup settings. It randomizes wakeup inputs, wakeup enables, the wakeup info capture enable, and the interrupt enable.
  • pwrmgr_aborted_low_power_vseq creates scenarios that lead to aborting a low power transition. The abort can be due to the processor waking up very soon, or otp, lc, or flash being busy.
  • pwrmgr_reset_vseq checks the pwrmgr response to conditional resets and reset enables, and unconditional escalation and main power glitch resets.
  • pwrmgr_wakeup_reset_vseq aligns reset and wakeup from low power.
  • pwrmgr_lowpower_wakeup_race_vseq aligns a wakeup event coming in proximity to low power entry. Notice the wakeup is not expected to impact low power entry, since it is not sampled at this time.

Functional coverage

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:

  • wakeup_ctrl_cg covers wakeup and capture control.
  • wakeup_intr_cg covers control of the interrupt due to a wakeup.
  • control_cg covers clock controls.
  • hw_reset_0_cg covers external reset via rstreqs_i[0].
  • hw_reset_1_cg covers external reset via rstreqs_i[1].
  • rstmgr_sw_reset_cg covers software initiated resets via rstmgr CSR.
  • main_power_reset_cg covers resets due to a main power glitch.
  • esc_reset_cg covers resets due to an incoming escalation.
  • reset_wakeup_distance_cg covers the distance in clock cycles between a wakeup and a reset request.

More details about these sequences and covergroups can be found at testplan.

Self-checking strategy

Many of the checks are performed via SVA, and are enabled for all test sequences. Refer to the assertions section below for details.

Scoreboard

The pwrmgr_scoreboard is primarily used for end to end checking.

Many inputs must have specific transitions to prevent the pwrmgr fsms from wait forever. When possible the transitions are triggered by pwrmgr output changes. These are described according to the unit that originates or is the recepient of the ports. See also the test plan for specific ways these are driven to trigger different testpoints.

AST
  • Output slow_clk_en is always on.
  • Input slow_clk_val is unused.
  • Outputs core_clk_en, io_clk_en, and usb_clk_en reset low, and go high prior to the slow fsm requesting the fast fsm to wakeup. Notice the usb clock can be programmed to stay low on wakeup via the control CSR. These clock enables are cleared on reset, and should match their corresponding enables in the control CSR on low power transitions. These clock enables are checked via SVAs in hw/ip/pwrmgr/dv/sva/pwrmgr_clock_enables_sva_if.sv. When slow fsm transitions to SlowPwrStateReqPwrUp the clock enables should be on (except usb should match control.usb_clk_en_active). When slow fsm transitions to SlowPwrStatePwrClampOn the clock enables should match their bits in the control CSR.
  • Inputs core_clk_val, io_clk_val, and usb_clk_val track the corresponding enables. They are driven by slow_responder, which turn them off when their enables go off, and turn them back on a few random slow clock cycles after their enables go on. Slow fsm waits for them to go high prior to requesting fast fsm wakeup. Lack of a high transition when needed is detected via timeout. Such timeout would be due to the corresponding enables being set incorrectly. These inputs are checked via SVAs in hw/ip/pwrmgr/dv/sva/pwrmgr_ast_sva_if.sv.
  • Output main_pd_n should go high when slow fsm transitions to SlowPwrStateMainPowerOn, and should match control.main_pd_n CSR when slow fsm transitions to SlowPwrStateMainPowerOff.
  • Input main_pok should turn on for the slow fsm to start power up sequence. This is also driven by slow_responder, which turn this off in response to main_pd_n going low, and turn it back on after a few random slow clock cycles from main_pd_n going high. Lack of a high transition causes a timeout, and would point to main_pd_n being set incorrectly.
  • Output transitions of pwr_clamp_env must always precede transitions of pwr_clamp output. Output transitions of pwr_clamp to active must always precede transitions of main_pd_n output to active. Output transitions of pwr_clamp to inactive must always follow transitions of main_pd_n output to inactive.
RSTMGR
  • Output rst_lc_req resets to 1, also set on reset transition, and on low power transitions that turn off main clock. Cleared early on during the steps to fast fsm active.
  • Input rst_lc_src_n go low in response to rst_lc_req high, go high when rst_lc_req clears (and lc is reset). Driven by fast_responder in response to rst_lc_req, waiting a few random cycles prior to transitions. Fast fsm waits for it to go low before deactivating, and for it to go high before activating. Checked implicitly by lack of timeout: a timeout would be due to rst_lc_req being set incorrectly, and by SVA as described below.
  • Output rst_sys_req resets to 1, also set to on reset, and on low power transitions that turn off main clock. Cleared right before the fast fsm goes active.
  • Input rst_sys_src_n go low in response to rst_sys_req high. Transitions go high when rst_sysd_req clears (and lc is reset). Fast fsm waits for it to go low before deactivating. Also driver by fast_responder. Checked implicitly by lack of timeout, and by SVA.
  • Output rstreqs correspond to the enabled pwrmgr rstreqs inputs plus main power glitch, escalation reset, and software reset request from RSTMGR. Checked in scoreboard and SVA.
  • Output reset_cause indicates a reset is due to low power entry or a reset request. Checked in scoreboard.
CLKMGR
  • Outputs pwr_clk_o.<clk>_ip_clk_en reset low, are driven high by fast fsm when going active, and driven low when going inactive. The <clk> correspond to io, main, and usb.
  • Inputs pwr_clk_i.<clk>_status are expected to track pwr_clk_o.<clk>_ip_clk_en. Fast fsm waits for them going high prior to going active, and going low prior to deactivating. These are controlled by the control CSR. Driven by fast_responder, which turns them off when <clk>_ip_clk_en goes low, and turns them back on a few random cycles after <clk>_ip_clk_en goes high. Checked by lack of a timeout: such timeout would be due to ip_clk_en being set incorrectly. Also checked by SVA.
OTP
  • Output otp_init resets low, goes high when the fast fsm is going active, and low after the otp_done input goes high.
  • Input otp_done is driven by fast_responder. It is initialized low, and goes high some random cycles after otp_init goes high. The sequencer will timeout if otp_init is not driven high.
  • Input otp_idle normally set high, but is set low by the pwrmgr_aborted_low_power_vseq sequence.
LC

The pins connecting to LC behave pretty much the same way as those to OTP.

FLASH
  • Input flash_idle is handled much like lc_idle and otp_idle.
CPU
  • Input core_sleeping is driven by sequences. It is driven low to enable a transition to low power. After the transition is under way it is a don’t care. The pwrmgr_aborted_low_power_vseq sequence sets it carefully to abort a low power entry soon after the attempt because the processor wakes up.
Wakepus and Resets

There are a number of wakeup and reset requests. They are driven by sequences as they need to.

Assertions

The hw/ip/pwrmgr/dv/sva/pwrmgr_bind.sv module binds a few modules containing assertions to the IP as follows:

  • TLUL assertions: the tlul_assert assertions ensures TileLink interface protocol compliance.
  • Clock enables assertions: The pwrmgr_clock_enables_sva_if module contains assertions checking that the various clk_en outputs correspond to the settings in the control CSR.
  • CLKMGR clk_en to status handshake assertions: The clkmgr_pwrmgr_sva_if contains assertions checking the various <clk>_status inputs track the corresponding <clk>_ip_clk_en outputs.
  • AST input/output handshake assertions: The pwrmgr_ast_sva_if module contains assertions checking that the inputs from the AST respond to the pwrmgr outputs.
  • RSTMGR input/output handshake assertions: The pwrmgr_rstmgr_sva_if module contains assertions checking the following:
    • The rst_lc_src_n input from RSTMGR respond to the rst_lc_req pwrmgr output.
    • The rst_sys_src_n input from RSTMGR respond to the rst_sys_req pwrmgr output.
    • The different pwr_rst_o.rstreqs output bits track the corresponding reset causes. These include hardware, power glitch, escalation, and software resets.

In addition, the RTL has assertions to ensure all outputs are initialized to known values after coming out of reset.

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/pwrmgr/dv/pwrmgr_sim_cfg.hjson -i pwrmgr_smoke

Testplan

Testpoints

Milestone Name Tests Description
V1 smoke pwrmgr_smoke

Smoke test exercising the pwrmgr state transitions.

  • Brings pwrmgr out of POR.
  • Enables wakeup.
  • Triggers SW initiated low power transition with reset settings in control CSR.
  • Triggers wakeup.
  • Enables reset.
  • Triggers a reset.
  • Waits for pwrmgr to be out of reset.

Stimulus:

  • CSR writes to wakeup_en, reset_en, and low_power_hint.
  • Needs many input pins to line up correctly in order to prevent the pwrmgr from waiting forever. Most of these are set in response to outputs, and are checked by SVA.

Checks:

  • Checks that fast fsm is active checking the CSR ctrl_cfg_regwen is set.
  • Checks that the wakeup and reset causes are as expected reading CSRs wake_status and reset_status.
  • Checks the output pwr_rst_req.reset_cause matches a low power or reset cause.
  • Checks the output pwr_rst_req.rstreqs matches the enabled resets.
V1 csr_hw_reset pwrmgr_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 pwrmgr_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 pwrmgr_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 pwrmgr_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_resetpwrmgr_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.
V2 wakeup pwrmgr_wakeup

Test random wakeup, wakeup_en, wake_info_capture_dis, and interrupt.

The different wakeup inputs can be disabled via bits in the wakeup_en CSR. Update of wakeup_info can be disabled via the wake_info_capture_dis CSR. Any wakeup causes an interrupt unless interrupts are disabled.

Stimulus:

  • Sets wakeup_en randomly but don't set it to zero, or the test will timeout.
  • Set wake_info_capture_dis randomly on and off.
  • Bring pwrmgr to low power.
  • Set wakeups_i inputs randomly.
  • Set intr_enable randomly.

Checks:

  • Waits for fast fsm to become active reading ctrl_cfg_regwen until it becomes 1.
  • Depending on wakeups_i:
    • If all wakeups are disabled, wait some time checking the state remains inactive.
    • Set wakeups_i so at least one is enabled.
  • Checks wakeup_status CSR during transition to active state since the reset involved will clear the wakeups_i input.
  • Checks the wake_info CSR.
  • Checks the output pwr_rst_req.reset_cause is LowPwrEntry.
  • Check that intr_wakeup_o is set according to intr_enable CSR.
  • Coverage collected by wakeup_cg and wakeup_intr_cg.
V2 control_clks pwrmgr_wakeup

Test CSR control of peripheral clocks during low power.

The peripheral clocks can be configured to remain on or be turned off during low power with bits in the control CSR register. The usb clock can also be configured off in active mode.

Stimulus:

  • Sets these control bits at random.
  • Cause a low power transition and wakeup.

Checks:

  • The clock enable outputs to the AST clocks during a low power transition match the control bits.
  • The usb clock enable is also checked during active mode against the control register.
V2 aborted_low_power pwrmgr_aborted_low_power

Test aborted low power transitions.

Low power transitions can be aborted in two cases:

  • The processor gets an interrupt soon after a low power entry is triggered.
  • OTP, LC, or FLASH are not idle. This test aborts low power transitions, and disables any wakeups, so the test would timeout if low power was entered.

Stimulus:

  • Bring pwrmgr to low power.
  • Either disable pwr_cpu.core_sleeping or keep some of lc_idle, otp_idle, or flash_idle inputs off.
  • Disable all wakeup enables.
  • Randomly set wakeup_info_capture_dis CSR.

Checks:

  • The ctrl_cfg_regwen CSR reads as 1 on the first attempt.
  • Checks the output pwr_rst_req.reset_cause doesn't change for a bounded amount of time.
  • Check that the wakeup_info CSR flags either fall_through or abort events when capture is enabled.
V2 reset pwrmgr_reset

Test random reset and reset_en.

Conditional reset inputs can be disabled via bits in the reset_en CSR, while escalation and main power are unconditional. Resets can be triggered either in active or low power state.

Stimulus:

  • Sets reset_en randomly.
  • Randomly choose whether to put the unit in low power mode.
  • Generate resets randomly in value and time:
    • Conditionals via rstreqs_i,
    • Main power glitch via rst_main_ni.
    • Escalation via esc_rst_tx_i.

Checks:

  • Waits for fast fsm to become active reading ctrl_cfg_regwen until it becomes 1.
  • Checks the reset_status CSRs.
  • Checks ip_clk_en output has a low transition.
  • SVA that when pwr_rst_req.reset_cause is HwReq, and the output pwr_rst_req.rstreqs matches the unconditional and enabled conditional resets inputs.
V2 main_power_glitch_reset pwrmgr_reset

Test reset due to a glitch in main power.

A power glitch causes an unconditional reset.

Stimulus:

  • Set the rst_main_ni input low indicating a main power glitch.

Checks:

  • Waits for fast fsm to become active reading ctrl_cfg_regwen until it becomes 1.
  • Checks the reset_status CSRs.
  • Checks ip_clk_en output has a low transition.
  • Checks the output pwr_rst_req.reset_cause matches HwReq.
  • Checks the output pwr_rst_req.rstreqs matches power glitch.
V2 reset_wakeup_race pwrmgr_wakeup_reset

Test wakeup from low power and reset request almost coinciding.

If a wakeup from low power and a reset occur at nearly the same time the system handles them one at a time.

Stimulus:

  • Trigger reset and wakeup from low power as described for other testpoints.
  • Issue reset and wakeup a random number of cycles after the slow state machine is in LowPower state.
    • This also checks them coinciding.

Check:

  • Similar tests as for the wakeup and reset testpoints, except making sure they happen per the triggering order.
V2 lowpower_wakeup_race pwrmgr_lowpower_wakeup_race

Test wakeups coming close to lowpower entry.

If low power entry and a wakeup are closely aligned the hardware could get confused. Notice this is very unlikely, since wakeup is only sensed when the slow fsm is in LowPower state.

Stimulus:

  • Trigger low power entry as described for other testpoints.
  • Have all wakeups enabled.
  • Assert wakeups_i in the temporal neighborhood of low power entry.

Check:

  • No timeout occurs.
  • Either pwrmgr remains active or a full low power cycle occurs.
V2 intr_test pwrmgr_intr_test

Verify common intr_test CSRs that allows SW to mock-inject interrupts.

  • Enable a random set of interrupts by writing random value(s) to intr_enable CSR(s).
  • Randomly &quot;turn on&quot; interrupts by writing random value(s) to intr_test CSR(s).
  • Read all intr_state CSR(s) back to verify that it reflects the same value as what was written to the corresponding intr_test CSR.
  • Check the cfg.intr_vif pins to verify that only the interrupts that were enabled and turned on are set.
  • Clear a random set of interrupts by writing a randomly value to intr_state CSR(s).
  • Repeat the above steps a bunch of times.
V2 tl_d_oob_addr_access pwrmgr_tl_errors

Access out of bounds address and verify correctness of response / behavior

V2 tl_d_illegal_access pwrmgr_tl_errors

Drive unsupported requests via TL interface and verify correctness of response / behavior. Below error cases are tested bases on the [TLUL spec]({{&lt; relref &quot;hw/ip/tlul/doc/_index.md#explicit-error-cases&quot; &gt;}})

  • 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 = &#x27;b0010
    • mask and address misaligned, e.g. a_address = 0x01, a_mask = &#x27;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 != &#x27;1 when it doesn't support partial accesses
    • read a WO (write-only) memory
    • write a RO (read-only) memory
V2 tl_d_outstanding_access pwrmgr_csr_hw_reset
pwrmgr_csr_rw
pwrmgr_csr_aliasing
pwrmgr_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 pwrmgr_csr_hw_reset
pwrmgr_csr_rw
pwrmgr_csr_aliasing
pwrmgr_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 pwrmgr_tl_intg_err

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.

V3 stress

The standard stress test.

V3 stress_all_with_rand_resetpwrmgr_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
control_cg

Collects coverage on clock and power bits from control CSR during a lowpower transition and active state.

esc_reset_cg

Collects coverage on resets due to escalation.

Covergroup contains a coverpoint for the input esc_rst_tx_i that triggers an escalation reset, and whether this reset is asserted during low power state.

hw_reset_0_cg

Collects coverage related to external reset 0.

Covergroup contains coverpoints for the rstreqs_i[0] external reset input, its corresponding bit in reset_en CSR, and whether this reset is asserted during low power state, and suitable crosses.

hw_reset_1_cg

Collects coverage related to external reset 1.

Covergroup contains coverpoints for the rstreqs_i[1] external reset input, its corresponding bit in reset_en CSR, and whether this reset is asserted during low power state, and suitable crosses.

main_power_reset_cg

Collects coverage on resets due to a main power glitch.

Covergroup contains a coverpoint for the input rst_main_i that triggers a power glitch reset, and whether this reset is asserted during low power state.

reset_wakeup_distance_cg

Covergroup contains a coverpoint for the difference between the cycles when the reset and the wakeup were received in the inputs. The difference is positive when reset happened after wakeup, and zero when the two happened at the same clock cycle.

rstmgr_sw_reset_cg

Collects coverage on the software reset from rstmgr.

Covergroup contains a coverpoint for the input sw_rst_req_i from rstmgr.

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.

wakeup_ctrl_cg

Collects coverage on wakeup enable and capture functionality.

This is collected per individual wakeup bit. Covergroup contains coverpoints for the wakeup_en CSR bit, wakeup_info_capture_dis CSR, wakeups_i input bit, and wakeup_status CSR bit, and their cross.

wakeup_intr_cg

Collects coverage on interrupts for wakeup functionality.

This is collected per individual wakeup bit. Covergroup contains coverpoints for the intr_en CSR, the wakeup_status CSR bit, the intr_status CSR, the output intr_wakeup port, and their cross.