[dv/rstmgr] Update DV docs for V1
Signed-off-by: Guillermo Maturana <maturana@google.com>
diff --git a/hw/ip/rstmgr/data/rstmgr_testplan.hjson b/hw/ip/rstmgr/data/rstmgr_testplan.hjson
index 4aba2c9..3d3afe8 100644
--- a/hw/ip/rstmgr/data/rstmgr_testplan.hjson
+++ b/hw/ip/rstmgr/data/rstmgr_testplan.hjson
@@ -20,32 +20,36 @@
- Send a peripheral reset request.
- Send a debug reset.
- Configure a software request for peripheral reset.
+ - Set alert and cpu dump inputs to random values.
**Checks**:
- Checks the reset_info matches expected values.
- - Checks the cpu_info CSR correctly captures the input info.
+ - Checks the `alert_info` CSR correctly captures the input info.
+ - Checks the `cpu_info` CSR correctly captures the input info.
- Checks the output reset pins corresponding to sw resettable
units match `sw_rst_ctrl_n` CSR.
'''
milestone: V1
- tests: ["rstmgr_smoke"]
+ tests: []
}
{
name: reset_stretcher
- desc: '''Test the reset signal is stretched when stable.
+ desc: '''Test the POR reset signal must be stable for multiple cycles.
- The reset signal is stretched by 32 cycles when reset is stable.
+ The POR reset signal must remain active for at least 32 consecutive
+ cycles before going inactive for the rest of the reset tree to go
+ inactive.
**Stimulus**:
- - Send a reset active signal, and de-activate it at a random width
- less than 32 cycles between de-activations for N de-activations.
+ - Activate POR, and de-activate it at a random width less than 32
+ cycles between de-activations for N de-activations.
**Checks**:
- - The output reset is only set if the input reset has had at least
- 32 cycles of steady input reset active.
+ - With SVA check the output reset is only set if the input reset
+ has had at least 32 cycles of steady input reset active.
'''
milestone: V2
- tests: []
+ tests: ["rstmgr_smoke"]
}
{
name: sw_rst_regen_clear_once
diff --git a/hw/ip/rstmgr/doc/checklist.md b/hw/ip/rstmgr/doc/checklist.md
index 094a33b..1203a00 100644
--- a/hw/ip/rstmgr/doc/checklist.md
+++ b/hw/ip/rstmgr/doc/checklist.md
@@ -113,7 +113,7 @@
Documentation | [DV_DOC_DRAFT_COMPLETED][] | Done | [RSTMGR DV document]({{< relref "dv/index.md" >}})
Documentation | [TESTPLAN_COMPLETED][] | Done | [RSTMGR Testplan]({{< relref "dv/index.md#testplan" >}})
Testbench | [TB_TOP_CREATED][] | Done |
-Testbench | [PRELIMINARY_ASSERTION_CHECKS_ADDED][]| Not Started |
+Testbench | [PRELIMINARY_ASSERTION_CHECKS_ADDED][]| Done |
Testbench | [SIM_TB_ENV_CREATED][] | Done |
Testbench | [SIM_RAL_MODEL_GEN_AUTOMATED][] | Done |
Testbench | [CSR_CHECK_GEN_AUTOMATED][] | Done |
@@ -127,11 +127,11 @@
Regression | [FPV_REGRESSION_SETUP][] | N/A |
Coverage | [SIM_COVERAGE_MODEL_ADDED][] | Done |
Code Quality | [TB_LINT_SETUP][] | Done |
-Integration | [PRE_VERIFIED_SUB_MODULES_V1][] | Not Started |
-Review | [DESIGN_SPEC_REVIEWED][] | Not Started |
+Integration | [PRE_VERIFIED_SUB_MODULES_V1][] | Done |
+Review | [DESIGN_SPEC_REVIEWED][] | Done |
Review | [TESTPLAN_REVIEWED][] | Not Started |
-Review | [STD_TEST_CATEGORIES_PLANNED][] | Not Started | Exception (?)
-Review | [V2_CHECKLIST_SCOPED][] | Not Started |
+Review | [STD_TEST_CATEGORIES_PLANNED][] | Done | Exception: power, performance
+Review | [V2_CHECKLIST_SCOPED][] | Done |
[DV_DOC_DRAFT_COMPLETED]: {{<relref "/doc/project/checklist.md#dv_doc_draft_completed" >}}
[TESTPLAN_COMPLETED]: {{<relref "/doc/project/checklist.md#testplan_completed" >}}
diff --git a/hw/ip/rstmgr/doc/dv/index.md b/hw/ip/rstmgr/doc/dv/index.md
index 7f72b88..84439af 100644
--- a/hw/ip/rstmgr/doc/dv/index.md
+++ b/hw/ip/rstmgr/doc/dv/index.md
@@ -2,15 +2,6 @@
title: "RSTMGR DV document"
---
-<!-- Copy this file to hw/ip/rstmgr/doc/dv/index.md and make changes as needed.
-For convenience 'rstmgr' in the document can be searched and replaced easily with the
-desired IP (with case sensitivity!). Also, use the testbench block diagram
-located at OpenTitan team drive / 'design verification'
-as a starting point and modify it to reflect your rstmgr testbench and save it
-to hw/ip/rstmgr/doc/dv/tb.svg. It should get linked and rendered under the block
-diagram section below. Please update / modify / remove sections below as
-applicable. Once done, remove this comment before making a PR. -->
-
## Goals
* **DV**
* Verify all RSTMGR IP features by running dynamic simulations with a SV/UVM based testbench
@@ -51,7 +42,8 @@
All common types and methods defined at the package level can be found in
`rstmgr_env_pkg`. Some of them in use are:
```systemverilog
-[list a few parameters, types & methods; no need to mention all]
+virtual rstmgr_if rstmgr_vif;
+virtual pwrmgr_rstmgr_sva_if pwrmgr_rstmgr_sva_vif;
```
### TL_agent
The RSTMGR testbench instantiates (already handled in CIP base env) [tl_agent]({{< relref "hw/dv/sv/tl_agent/README.md" >}}).
@@ -65,36 +57,36 @@
### UVM RAL Model
The RSTMGR RAL model is created with the [`ralgen`]({{< relref "hw/dv/tools/ralgen/README.md" >}}) FuseSoC generator script automatically when the simulation is at the build stage.
-It can be created manually by invoking [`regtool`]({{< relref "util/reggen/README.md" >}}):
+It can be created manually by invoking [`regtool`]({{< relref "util/reggen/README.md" >}}).
### Stimulus strategy
The following test sequences and covergroups are described in more detail in the testplan at `hw/ip/pwrmgr/data/rstmgr_testplan.hjson`, and also included [below](#testplan).
+This IP is only reset via the `por_n_i` input, and by `scan_rst_ni` qualified by `scanmode_i` being active.
+The regular `rst_ni` input is connected to its own `resets_o.rst_por_io_div4_n[0]` output, so the reset output from `clk_rst_if` is not connected.
+Similarly, all reset outputs from other `clk_rst_if` instances are ignored, and only their clock output is used.
+This is consistent with this IP being in charge of all derived resets in the chip.
+
#### Test sequences
The test sequences reside in `hw/ip/rstmgr/dv/env/seq_lib`.
All test sequences are extended from `rstmgr_base_vseq`, which is extended from `cip_base_vseq` and serves as a starting point.
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:
* task `wait_for_cpu_out_of_reset`:
- Waits for the `resets_o.rst_sys_n[1]` to go high, indicating the CPU is out of reset and CSRs can be accessed.
+ Waits for the `resets_o.rst_sys_n[1]` output to go high, indicating the CPU is out of reset and CSRs can be accessed.
* task `check_cpu_dump_info`:
Reads and compares each field in the `cpu_info` CSR against the given cpu dump.
* task `check_software_reset_csr_and_pins`:
Reads and compares the `sw_rst_ctrl_n` CSR and the output reset ports against the given value.
-The `rstmgr_smoke_vseq` sequence tests the rstmgr through software initiated low power, peripheral reset, ndm reset, and software initiated resets.
-
-The `rstmgr_reset_stretcher_vseq` sequence tests the `resets_o.rst_por_aon_n[0]` output is asserted after 32 stable cycles of `ast_i.aon_pok`.
-
-The `rstmgr_sw_rst_regen_clear_once_vseq` sequence tests that the `sw_rst_regen` CSR is such that a bit cannot be flipped back to 1.
-
-The `rstmgr_sw_rst_vseq` sequence tests the functionality provided by the `sw_rst_regen` and `sw_rst_ctrl_n`.
-
-The `rstmgr_reset_info_vseq` tests the `reset_info` CSR contents correspond to the different resets.
-
-The `rstmgr_cpu_info_vseq` tests the `cpu_info` CSR contents capture to the `cpu_dump_i` present at the time of a reset.
-
-The `rstmgr_alert_info_vseq` tests the `alert_info` CSR contents capture to the `alert_dump_i` present at the time of a reset.
+Other sequences follow:
+* `rstmgr_smoke_vseq` tests the rstmgr through software initiated low power, peripheral reset, ndm reset, and software initiated resets.
+* `rstmgr_reset_stretcher_vseq` tests the `resets_o.rst_por_aon_n[0]` output is asserted after 32 stable cycles of `ast_i.aon_pok`.
+* `rstmgr_sw_rst_regen_clear_once_vseq` tests that the `sw_rst_regen` CSR is such that a bit cannot be flipped back to 1.
+* `rstmgr_sw_rst_vseq` tests the functionality provided by the `sw_rst_regen` and `sw_rst_ctrl_n`.
+* `rstmgr_reset_info_vseq` tests the `reset_info` CSR contents correspond to the different resets.
+* `rstmgr_cpu_info_vseq` tests the `cpu_info` CSR contents capture to the `cpu_dump_i` present at the time of a reset.
+* `rstmgr_alert_info_vseq` tests the `alert_info` CSR contents capture to the `alert_dump_i` present at the time of a reset.
#### Functional coverage
To ensure high quality constrained random stimulus, it is necessary to develop a functional coverage model.
@@ -105,27 +97,29 @@
* `alert_info_capture_cg`
* `cpu_info_capture_cg`
-More details about these sequences and covergroups can be found at `hw/ip/rstmgr/data/rstmgr_testplan.hjson`.
-
### Self-checking strategy
The partition between checks done in the scoreboard is not fixed.
#### Scoreboard
The `rstmgr_scoreboard` is primarily used for end to end checking.
The following checks are performed:
-* Resets cascade hierarchically per [Reset Topology]({{< relref "hw/ip/rstmgr/doc" >}}:#reset-topology)
* The software controlled peripheral resets are asserted based on both `sw_rst_regen` and `sw_rst_ctrl_n` CSRs when not set by `rst_lc_reg`, `rst_sys_req`, or por.
* The `cpu_info` CSRs record the expected values based on the inputs on a system reset.
* The `alert_info` CSRs record the expected values based on the inputs on a system reset.
* The `reset_info` CSR records the expected reset cause.
-* When `scan_rst_ni` and `scanmode_i` inputs are active all output resets become active.
#### Assertions
* TLUL assertions: The `tb/rstmgr_bind.sv` file binds the `tlul_assert` [assertions]({{< relref "hw/ip/tlul/doc/TlulProtocolChecker.md" >}}) 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.
* Response to pwrmgr's `rst_lc_req` and `rst_sys_req` inputs: these trigger transitions in `rst_lc_src_n` and `rst_sys_rst_n` outputs.
- Checked via SVAs.
+ Checked via SVAs in `hw/ip/pwrmgr/dv/sva/pwrmgr_rstmgr_sva_if.sv`.
* Response to `cpu_i.ndmreset_req` input: after it is asserted, rstmgr's `rst_sys_src_n` should go active.
- Checked via SVA.
+ Checked via SVA in `hw/ip/pwrmgr/dv/sva/pwrmgr_rstmgr_sva_if.sv`.
+* Resets cascade hierarchically per [Reset Topology]({{< relref "hw/ip/rstmgr/doc" >}}:#reset-topology).
+ Checked via SVA in `hw/ip/rstmgr/dv/sva/rstmgr_cascading_sva_if.sv`.
+* POR must be active for at least 32 consecutive cycles before going inactive before output resets go inactive.
+ Checked via SVA in `hw/ip/rstmgr/dv/sva/rstmgr_cascading_sva_if.sv`.
+* The scan reset `scan_rst_ni` qualified by `scanmode_i` triggers all cascaded resets that `por_n_i` does.
+ Checked via SVA in `hw/ip/rstmgr/dv/sva/rstmgr_cascading_sva_if.sv`.
## Building and running tests
We are using our in-house developed [regression tool]({{< relref "hw/dv/tools/README.md" >}}) for building and running our tests and regressions.
