[dv/pwrmgr] Add feedback from testplan review
Also fix minor glitches in the documentation.
Signed-off-by: Guillermo Maturana <maturana@google.com>
diff --git a/hw/ip/pwrmgr/data/pwrmgr_testplan.hjson b/hw/ip/pwrmgr/data/pwrmgr_testplan.hjson
index 85dfd92..b80af9f 100644
--- a/hw/ip/pwrmgr/data/pwrmgr_testplan.hjson
+++ b/hw/ip/pwrmgr/data/pwrmgr_testplan.hjson
@@ -177,13 +177,13 @@
{
name: reset_wakeup_race
desc: '''
- Test low power entry and reset request almost coinciding.
+ Test wakeup from low power and reset request almost coinciding.
- If a low power entry and a reset occur at nearly the same time
+ 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 low power entry as described for other
+ - Trigger reset and wakeup from low power as described for other
testpoints.
- Make sure to test them coinciding also.
@@ -200,7 +200,8 @@
Test wakeups coming close to lowpower entry.
If low power entry and a wakeup are closely aligned the hardware
- could get confused.
+ 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.
diff --git a/hw/ip/pwrmgr/doc/_index.md b/hw/ip/pwrmgr/doc/_index.md
index 28181ac..2995387 100644
--- a/hw/ip/pwrmgr/doc/_index.md
+++ b/hw/ip/pwrmgr/doc/_index.md
@@ -69,7 +69,7 @@
* Slow FSM `Idle` and fast FSM `Active`
* Slow FSM `Low Power` and fast FSM `Low Power`
-The slow FSM `Low Power` and fast FSM `Active` states specifically are concepts useful when examining [reset handling](#Reset-Request-Handling).
+The slow FSM `Low Power` and fast FSM `Active` states specifically are concepts useful when examining [reset handling](#reset-request-handling).
## Slow Clock Domain FSM
@@ -93,7 +93,7 @@
The fast clock domain FSM (referred to as fast FSM from here on) resets to `Low Power` state and waits for a power-up request from the slow FSM.
-Once received, the fast FSM releases the life cycle reset stage (see [reset controller](https://docs.google.com/document/d/1oprdDwbm-_opDwMuu-kmmaFVwt4-f1EGqCf0nkO8VpM/edit?usp=sharing) for more details).
+Once received, the fast FSM releases the life cycle reset stage (see [reset controller]({{< relref "hw/ip/rstmgr/doc" >}}) for more details).
This allows the [OTP]({{< relref "hw/ip/otp_ctrl/doc" >}}) to begin sensing.
Once OTP sensing completes , the life cycle controller is initialized.
The initialization of the life cycle controller puts the device into its allowed operating state (see [life cycle controller]({{< relref "hw/ip/lc_ctrl/doc" >}}) for more details).
@@ -101,7 +101,7 @@
Once life cycle initialization is done, the fast FSM enables all second level clock gating (see [clock controller]({{< relref "hw/ip/clkmgr/doc" >}}) for more details) and initiates strap sampling.
For more details on what exactly the strap samples, please see [here](https://docs.google.com/spreadsheets/d/1pH8T1MhQ7TXtP_bFNT85T9jSVIHlxHAfbMnPbsMdjc0/edit?usp=sharing).
-Once strap sampling is complete, the system is ready to begin normal operations (note flash initialization is explicitly not done here, please see [sections below](#Flash-Handling) for more details).
+Once strap sampling is complete, the system is ready to begin normal operations (note flash initialization is explicitly not done here, please see [sections below](#flash-handling) for more details).
The fast FSM acknowledges the slow FSM (which made the original power up request) and releases the system reset stage - this enables the processor to begin operation.
Afterwards, the fast FSM transitions to `Active` state and waits for a software low power entry request.
@@ -118,7 +118,7 @@
## Reset Request Handling
There are 3 reset requests in the system - peripheral requested reset such as watchdog, alert escalation reset and non-debug module reset.
-Flash brownout is handled separately and described in [flash handling section](#Flash-Handling) below.
+Flash brownout is handled separately and described in [flash handling section](#flash-handling) below.
Watchdog and alert escalation resets are handled directly by the power manager, while the non-debug module reset is handled by the reset controller.
This separation is because the non-debug reset does not affect the life cycle controller, non-volatile storage controllers and alert states.
@@ -128,7 +128,7 @@
When a reset request is received during slow FSM `Low Power` state, the system begins its usual power up sequence even if a wakeup has not been received.
When a reset request is received during fast FSM `Active` state, the fast FSM asserts resets and transitions back to its `Low Power` state.
-The normal power-up process described [above](#Fast-Clock-Domain-FSM) is then followed to release the resets.
+The normal power-up process described [above](#fast-clock-domain-fsm) is then followed to release the resets.
Note in this case, the slow FSM is "not activated" and remains in its `Idle` state.
@@ -173,7 +173,7 @@
## Wakeup Recording
-Similar to [reset handling](#Reset-Request-Handling), wakeup signals are only observed during slow FSM `Low Power`; however their recording is continuous until explicitly disabled by software.
+Similar to [reset handling](#reset-request-handling), wakeup signals are only observed during slow FSM `Low Power`; however their recording is continuous until explicitly disabled by software.
Wakeup recording begins when the fast FSM transitions out of `Active` state and continues until explicitly disabled by software.
This ensures wakeup events are not missed until software has set up the appropriate peripherals.
diff --git a/hw/ip/pwrmgr/doc/dv/index.md b/hw/ip/pwrmgr/doc/dv/index.md
index 30cef2c..3d22469 100644
--- a/hw/ip/pwrmgr/doc/dv/index.md
+++ b/hw/ip/pwrmgr/doc/dv/index.md
@@ -41,14 +41,13 @@
### 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:
+`pwrmgr_env_pkg`.
+Some of them in use are:
```systemverilog
[list a few parameters, types & methods; no need to mention all]
```
### TL_agent
-PWRMGR testbench instantiates (already handled in CIP base env) [tl_agent]({{< relref "hw/dv/sv/tl_agent/README.md" >}})
-which provides the ability to drive and independently monitor random traffic via
-TL host interface into PWRMGR device.
+PWRMGR testbench instantiates (already handled in CIP base env) [tl_agent]({{< relref "hw/dv/sv/tl_agent/README.md" >}}) 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`]({{< relref "hw/dv/tools/ralgen/README.md" >}}) FuseSoC generator script automatically when the simulation is at the build stage.
@@ -85,17 +84,17 @@
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 `clk_status` input needs to match the `ip_clk_en` output after some cycles.
- * Completes the handshake with lc and otp: either *_done input must match the corresponding *_init output after some cycles.
+ * Completes the handshake with lc and otp: both *_done input must match the corresponding *_init output 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.
-Notice we plan to implement these responders in drivers instead of the base sequence.
The `pwrmgr_smoke_vseq` sequence tests the pwrmgr through POR, entry and exit from software initiated low power and reset.
The `pwrmgr_wakeup_vseq` sequence 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.
-The `pwrmgr_clks_en_vseq` sequence checks that the peripheral clock enables match the settings of the `control` CSR during low power. It uses a subset of the wakeup sequence.
+The `pwrmgr_clks_en_vseq` sequence checks that the peripheral clock enables match the settings of the `control` CSR during low power.
+It uses a subset of the wakeup sequence.
The `pwrmgr_aborted_lowpower_vseq` sequence creates scenarios that lead to aborting a lowpower transition.
The abort can be due to the processor waking up very soon, or otp, lc, or flash being busy.
@@ -104,7 +103,10 @@
The `pwrmgr_escalation_reset_vseq` sequence checks the response to an escalation reset.
-The `pwrmgr_reset_wakeup_vseq` sequence aligns reset and low power entry
+The `pwrmgr_reset_wakeup_vseq` sequence aligns reset and wakeup from low power.
+
+The `pwrmgr_lowpower_wakeup_race_vseq` sequence 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.
@@ -148,6 +150,12 @@
- Input `main_pok` should turn on for the slow fsm to start power up sequence.
Sequences will 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.
@@ -162,8 +170,10 @@
Transitions go high when `rst_sysd_req` clears (and lc is reset).
Fast fsm waits for it to go low before deactivating.
Checked implicitly by lack of timeout.
-- Output `rstreqs` correspond to the enabled pwrmgr rstreqs inputs plus escalation reset. Checked in scoreboard.
-- Output `reset_cause` indicates a reset is due to low power entry or a reset request. Checked in scoreboard.
+- Output `rstreqs` correspond to the enabled pwrmgr rstreqs inputs plus escalation reset.
+ Checked in scoreboard.
+- Output `reset_cause` indicates a reset is due to low power entry or a reset request.
+ Checked in scoreboard.
##### CLKMGR
- Output `ip_clk_en` resets low, is driven high by fast fsm when going active, and driven low when going inactive.
