A typical functional testbench asserts reset at time zero, releases it, and never touches it again. The design under test therefore never experiences the reset events that happen in silicon: a watchdog firing mid-transfer, one domain resetting while its neighbour keeps running, or two resets releasing in the wrong order after a warm reboot.
Scenario | What happens in silicon | What a reset-once testbench sees |
|---|---|---|
Reset asserted mid-operation | In-flight transactions are cut off; buffers, arbiters, and link partners must recover. | Nothing: reset never moves after time zero. |
Partial reset | One domain resets while another keeps running; handshakes stall on one side. | Nothing: all resets move together or not at all. |
Release ordering | Domains come out in sequence; a domain released early samples garbage from one still in reset. | Only one order is ever exercised, usually the easy one. |
Back-to-back resets | A second reset lands before recovery from the first has finished. | Never happens with a single initial reset. |
Reset during low-power entry or exit | Isolation and retention interact with the reset sequence. | Power modes are rarely combined with reset tests. |
Each scenario corrupts state only when the reset lands in a narrow window: a buffer holding data, a handshake mid-cycle, a neighbour running. A testbench that never puts the design in those states while reset moves will pass on broken RTL every time, and the failure then appears as an intermittent field issue that depends on reset timing.
The review asks for each reset when it last moved during simulation, not just whether reset was used. A test plan where every reset moves only at time zero is incomplete by inspection. Reset-aware simulation means at least one directed sequence per scenario in the table above, plus randomised reset timing around real traffic, with checkers that verify recovery rather than just absence of a crash.
Everything except a single simultaneous release: mid-operation assertion, partial resets, any other release order, and back-to-back resets are all untested.
Because corruption needs reset to land in a narrow busy window. Tests that never create that overlap always pass, while silicon hits the window on some sequences and misses it on others.