Finding the gaps in a reset verification plan

The verification challenge

Consider a hypothetical peripheral with software-visible registers, an interrupt output and a transaction interface. Normal read and write tests pass, but the product must also recover from resets during activity. The review asks what happens to an accepted transaction, a partially completed operation and an interrupt that is pending when reset arrives.

The example is deliberately about verification planning. It does not assert that a real design has a defect or that a particular simulation campaign has been completed. The same method can be adapted to a timer, serial controller or data mover, but each block’s actual specification determines the legal behaviour.

Separate the kinds of reset

A power-on reset, a software-requested reset and a subsystem reset may have different effects. Build a matrix of reset sources against registers, queues, interrupt state and externally visible outputs. Identify retained state and values that are unspecified until initialization. If a reset is only legal after a quiesce handshake, that prerequisite belongs in the plan.

Review assertion and release separately. Clarify which clock must be running, how long reset remains active and when software may access the block afterward. Reset-domain crossing and clock-domain crossing checks are distinct activities; a testbench that exercises reset does not replace structural or implementation analysis.

Build checkers before increasing stimulus

A test can toggle reset repeatedly without detecting a lost transaction. Define what the scoreboard does with work that was accepted before reset and what the specification says should happen next. If reset cancels work, flush only the affected expectations and verify the cancellation’s visible consequences. If work must survive, preserve those expectations and check completion.

Register-model predictions also need an explicit reset treatment. A retained register should not be predicted to its power-on value during a warm reset. Interrupt checkers should distinguish a cleared pending condition from an output that remains asserted because its underlying event is still active. Independent checking turns reset activity into evidence.

Target difficult intersections

Useful scenarios combine reset with a meaningful state: FIFO full, transaction stalled, interrupt pending, configuration changing or an error response in progress. Exercise different offsets relative to clock edges within the limitations of the verification environment. For each scenario, define a bounded recovery sequence and the first operation that must succeed afterward.

Use functional coverage to track the specified intersections. Avoid creating a huge cross-product that cannot be interpreted or closed. A missing bin may represent a test gap, an unreachable state or a specification conflict; it needs investigation, not automatic exclusion. Keep the reason and reviewer for every justified exclusion.

Debug from the first divergence

When a failure appears, identify the earliest difference between the contract and the observed behaviour. A late timeout may be caused by a dropped request much earlier. Save the seed, configuration, build revision, relevant waveform interval and checker message. Reduce the sequence while preserving the behaviour that triggers the failure.

Classify whether the issue belongs to the design, the testbench, an assumption or the integration environment. A testbench bug should be repaired and its affected results rerun. A specification change should update both the checker and the tests. Closing a ticket without reconciling those artifacts leaves the same misunderstanding available to return later.

An example review worksheet

Create one row for each meaningful reset scenario and include the starting state, reset source, expected retained state, expected canceled work and first legal operation afterward. For example, a pending interrupt combined with a partially filled receive queue may have a different outcome under a peripheral reset than under a whole-system reset. Ask the specification owner to confirm the expected behaviour before the test author encodes it.

Add columns for the checker, stimulus method and observed evidence. This keeps a scenario from being marked complete merely because a test name exists. If the scenario is not legal, record the system mechanism that prevents it and decide where that mechanism is verified. An assumption such as software never does this should be connected to a real interface contract or enforcement mechanism.

Finally, ask whether the scenario leaves any outstanding transaction in another block. Reset correctness is often a relationship between components. A local scoreboard can be internally consistent while the upstream system waits for a response that will never arrive. Use the worksheet to identify which scenarios need subsystem tests and which can be resolved at block level. This gives the integration team a specific plan instead of a vague request to test reset again.

Review readiness as a set of evidence

A proposed handoff contains the reset matrix, requirement-linked test plan, checker descriptions, coverage review and unresolved integration assumptions. It should distinguish simulated behaviour from formal or structural analysis. A single green dashboard cannot convey the limitations of all those methods.

The review ends with an agreed list of supported reset sequences and responsibilities for system integration. Firmware and platform teams need to know when access is legal, what state survives and how to recover from an interrupted operation. This makes the verification package useful beyond the team that wrote the tests.

What to bring. What to review.

Questions before you begin.