Mid-Test Reset Orchestration: Verification Case Study

Mechanism and evidence

See it. Work it through.

Reject old work after reset.

A watercolor reset boundary separates an epoch-11 request from a new epoch-12 request. A late epoch-11 response cannot satisfy the epoch-12 ledger entry. — The reset boundary creates a new lifetime. Reusing an ID does not make an old response belong to the new request.

Request A is outstanding in epoch 11. Reset cancels old work; after the interface is ready, a new request reuses A in epoch 12. Now an old response arrives.

Follow the scoreboard entry
Event	Identity	Expected result
Old request	(11, A)	Add an outstanding expectation.
Reset	Epoch 11 ends	Cancel old expectations under this contract.
New request	(12, A)	Track a new expectation after readiness.
Late response	(11, A)	Report stale work; keep (12, A) pending.

Worked check · equal ID is not enough

expected = (epoch 12, ID A)
received = (epoch 11, ID A)
match = false → new request stays pending

Matching only ID A would incorrectly complete the new transaction. Follow the stale-response trace in the lab and check that the new expectation remains pending.

This fixture supplies epoch provenance. An untagged interface needs a real drain or cancellation contract before reusing IDs; a checker cannot infer an ambiguous response’s origin from its ID alone.

Guided verification lab

The reset boundary changes what is valid.

Track the expectation ledger as a domain resets, restarts, and receives a response from its previous lifetime.

STEP THROUGH

STATE & OBSERVATIONCoordinated reset / 1 of 5

Checkpoint 1 · Epoch 11 has accepted work.

RESET: 0
EPOCH: 11
LEDGER: 11:A
RESPONSE: —

Compare all 5 checkpoints

1 · Epoch 11 has accepted work.
RESET
0
EPOCH
11
LEDGER
11:A
RESPONSE
—
2 · Reset cancels this domain’s work.
RESET
1
EPOCH
11
LEDGER
cancel
RESPONSE
—
3 · Clean up the matching expectations.
RESET
1
EPOCH
11
LEDGER
empty
RESPONSE
—
4 · Epoch 12 starts after readiness.
RESET
0
EPOCH
12
LEDGER
12:A
RESPONSE
—
5 · New work completes in its own epoch.
RESET
0
EPOCH
12
LEDGER
empty
RESPONSE
12:A

Inspect the contract

Epoch 11 has accepted work.

Epoch: 11
Pending: A

Transaction A is outstanding in the domain that will reset. The independent scoreboard carries its ID and epoch.

Evidence to inspect

Preserve the accepted handshake and expectation identity.

Checkpoint 1 / 5

Inspect the checker Selected checkpoint pseudocode

Conceptual checker / selected checkpoint

pending[{11, A}] = expected_A;

Example contract & limitations

Example contract. The fixture provides epoch provenance. On an untagged interface, a real drain/cancellation contract is needed before reusing IDs. Only the reset domain is invalidated; sticky and unaffected-domain state follows its specification. Checkpoints show selected state changes, not equally spaced simulation cycles.

Read the complete walkthrough

Coordinated reset

Epoch 11 has accepted work.. Transaction A is outstanding in the domain that will reset. The independent scoreboard carries its ID and epoch. Evidence: Preserve the accepted handshake and expectation identity.
Reset cancels this domain’s work.. Stop new stimulus and drive the reset-safe interface state. The reset contract explicitly invalidates transaction A. Evidence: Check driver VALID, reset assertion, and the domain cancellation boundary.
Clean up the matching expectations.. Flush invalidated expectations and resynchronize model and register abstraction state. Preserve state the specification marks sticky. Evidence: Verify no epoch-11 expectation remains eligible for a future response.
Epoch 12 starts after readiness.. The domain finishes initialization. New transaction A can now be tracked with epoch-12 provenance. Evidence: Observe readiness before reopening stimulus.
New work completes in its own epoch.. The response belongs to epoch 12 and matches the current expectation. Old work cannot consume it. Evidence: Correlate epoch, ID, and data before retiring the entry.

Late old-epoch response

Epoch 11 has accepted work.. Transaction A is outstanding in the domain that will reset. The independent scoreboard carries its ID and epoch. Evidence: Preserve the accepted handshake and expectation identity.
Reset cancels this domain’s work.. Stop new stimulus and drive the reset-safe interface state. The reset contract explicitly invalidates transaction A. Evidence: Check driver VALID, reset assertion, and the domain cancellation boundary.
Clean up the matching expectations.. Flush invalidated expectations and resynchronize model and register abstraction state. Preserve state the specification marks sticky. Evidence: Verify no epoch-11 expectation remains eligible for a future response.
Epoch 12 starts after readiness.. The domain finishes initialization. New transaction A can now be tracked with epoch-12 provenance. Evidence: Observe readiness before reopening stimulus.
A stale response is a real failure.. A response with epoch-11 provenance arrives after restart. Report the violation and leave epoch-12 transaction A pending. Evidence: Retain the stale response and show that the new expectation was not consumed.

Related implementation: Coordinate scoreboard, sequencer, and RAL cleanup

function void mac_scoreboard::flush();
  exp_fifo.flush();
  actual_fifo.flush();
  m_expected_count = 0;
endfunction

task mac_env::run_phase(uvm_phase phase);
  forever begin
    @(negedge vif.rst_n);

    agt.sqr.stop_sequences();
    scb.flush();
    reg_model.reset();

    wait (vif.rst_n === 1'b1);
    uvm_report_info("ENV", "Reset released: resume", UVM_LOW);
  end
endtask

Cleanup follows the hardware state transition: stop producers, discard predictions that no longer exist, synchronize the register mirror, then wait for reset release.

Coordinated reset, checkpoint 1: Epoch 11 has accepted work.. Inspect the contract.

Understand the failure

Epoch-aware recoveryReset is a coordinated state transition, not a pause button.

A reset observer ends the old comparison epoch, cancels traffic, clears interfaces and models, then releases stimulus only after the DUT advertises readiness.

01Run · epoch 11requests and responses in flight02Reset assertedstop sequences · drop objections03Quiescedrive idle · cancel stale responses04Rebuild · epoch 12reset RAL, predictors, and scoreboards05Resumewait for ready · start fresh traffic

Before resetExpected ID 7 · epoch 11discardAfter readyExpected ID 1 · epoch 12compare

observed transaction epoch = active scoreboard epoch → eligible for comparison

Reset event fanout

One reset edge interrupts stimulus first, then reconciles checking and model state before traffic resumes.

Reset edge: Warm, IP, subsystem, or global reset asserts during traffic.
Reset handler: Broadcasts the event and owns cleanup ordering.
Driver and sequencer: Abort the handshake and kill requests that cannot complete.
Scoreboard: Flushes predictions and actual observations invalidated by reset.
RAL mirror: Applies the correct reset kind while preserving sticky fields.
Restart gate: Waits for release and initialization before stimulus resumes.

Reset edge -> Reset handler
Reset handler -> Driver and sequencer
Reset handler -> Scoreboard
Reset handler -> RAL mirror
Driver and sequencer + Scoreboard + RAL mirror -> Restart gate

Why it matters

Modern SoCs reset more than once at power-on. Warm resets, IP resets, and subsystem resets can occur while the rest of the chip remains live.
A testbench that cannot recover from reset during traffic cannot verify high-availability or error-recovery behavior.
Hardware clears registers and pipelines immediately, while software testbench objects preserve state until they are told what to discard, retain, or restart.

What is difficult

A sequence can block forever waiting for a response that the reset erased.
A scoreboard can retain pre-reset expected items and compare them against unrelated post-reset traffic.
Reset scope is not always global. One agent may need to restart while unrelated interfaces continue running.
UVM phase jumping requires every component and domain to move coherently, which is difficult to debug and scale across a large team.

Failure signatures

A driver completes a stale handshake or leaves valid asserted across reset.
A sequencer keeps requests that can no longer receive responses.
Expected or actual queues leak across the reset boundary and create false mismatches.
The RAL mirror retains pre-reset values even though hardware returned non-sticky fields to defaults.
A DUT buffer fails to clear and releases old data after reset.

Compare approaches

Two viable approaches—and their cost

UVM phase jumping

Force the UVM domain back to reset_phase so components reinitialize through standard phase callbacks.

Strengths

Uses the official UVM phase mechanism.
Can coordinate component reinitialization through existing reset-phase code.

Costs

Difficult to debug when only part of the environment jumps.
Can deadlock when components or domains do not move together.
Provides less granular control for an IP-only reset while other agents continue.

Centralized reset handler

Monitor reset as a dynamic sideband event and explicitly broadcast cleanup and restart work.

Strengths

Keeps reset behavior explicit and independent of the UVM phase controller.
Can reset one agent or subsystem without disturbing unrelated traffic.
Makes each component's flush, kill, preserve, and restart policy reviewable.

Costs

Every stateful component needs a reset cleanup or recovery method.
The environment must define ordering between aborting stimulus, flushing checks, and resetting mirrors.

Explain it in an interview

Interview answer, built from the mechanism

Treat reset as a dynamic event rather than a one-time phase. A dedicated reset handler detects the edge and tells every affected component what to do.
Make the driver interruptible with fork-join_any so the reset watcher can abort a bus handshake immediately. Stop sequencer activity so no blocked request remains behind.
Flush expected and actual scoreboard state that hardware discarded, and call the appropriate RAL reset type so the mirror matches hardware defaults while sticky state is preserved.
Wait for reset release, perform any required reboot or initialization checks, and only then resume stimulus.

Assign responsibilities

Component responsibility contract

Component responsibilities and required verification changes for Mid-Test Reset Orchestration
Component	Responsibility	Required change
Driver	Handshake abort	Wrap sequence-item driving and reset detection in fork-join_any.
Sequencer	Sequence kill	Call stop_sequences() to clear blocked and queued requests.
Scoreboard	Data flush	Clear expected and actual queues plus local counters and state machines.
RAL model	Mirror reset	Call the correct reg_model.reset() type to match hardware defaults.
Reset handler	Event ordering	Broadcast reset, coordinate cleanup, wait for release, and authorize restart.

Build the checker

Implementation patterns

Abort an in-flight driver operationsystemverilog

task mac_driver::run_phase(uvm_phase phase);
  forever begin
    wait (vif.rst_n === 1'b1);

    fork
      begin : drive_process
        forever begin
          seq_item_port.get_next_item(req);
          drive_item(req);
          seq_item_port.item_done();
        end
      end

      begin : reset_watcher
        @(negedge vif.rst_n);
        uvm_report_info("DRV", "Reset detected: abort drive", UVM_LOW);
      end
    join_any

    disable fork;
    cleanup_signals();
  end
endtask

task mac_driver::cleanup_signals();
  vif.valid <= 1'b0;
  vif.data  <= 'z;
  // The reset handler kills the sequence, so this path does not call item_done().
endtask

The drive loop and reset watcher race. Reset wins immediately, disable fork removes stale drive activity, and the interface returns to an idle value before the next boot.

Coordinate scoreboard, sequencer, and RAL cleanupsystemverilog

function void mac_scoreboard::flush();
  exp_fifo.flush();
  actual_fifo.flush();
  m_expected_count = 0;
endfunction

task mac_env::run_phase(uvm_phase phase);
  forever begin
    @(negedge vif.rst_n);

    agt.sqr.stop_sequences();
    scb.flush();
    reg_model.reset();

    wait (vif.rst_n === 1'b1);
    uvm_report_info("ENV", "Reset released: resume", UVM_LOW);
  end
endtask

Cleanup follows the hardware state transition: stop producers, discard predictions that no longer exist, synchronize the register mirror, then wait for reset release.

Stress the design

Stress recipe

Fill request queues, response queues, pipelines, and DUT buffers before asserting reset.
Assert reset during an active valid-ready handshake and confirm the driver drops valid without hanging.
Exercise warm, IP-level, subsystem, and full reset scopes while unrelated agents remain active.
Verify sticky registers retain their value while non-sticky fields and the RAL mirror return to the correct reset type.
Restart traffic immediately after the allowed reboot window and reject any pre-reset data.

Follow-up questions

How do you verify registers that are sticky and are not cleared by a warm reset?

Model distinct RAL reset kinds. On a warm reset, call model.reset("WARM") so only non-sticky fields return to their warm-reset defaults while sticky mirrors retain their values.

What happens to the sequence that reset interrupted?

Usually the environment kills it. If the use case requires a resumable sequence, checkpoint its progress in a configuration object before termination and restart from that state after reset recovery.

How do you expose a DUT buffer that fails to clear on reset?

Run a dirty-reset test: fill every buffer with traffic, assert reset while state is maximally dirty, then check immediately after release that no pre-reset payload leaks out.

Engineering qualifications