A crossing is safe while both sides follow the protocol. Reset domain crossing covers a reset hitting one side while the other keeps running.
5 lessons, about 22 min
The consumer loses its protocol state and its data; the producer may keep waiting for an acknowledge, or the consumer may process a stale request again after reset (a duplicate). The crossing needs a defined behaviour for one-sided resets.
The whole topic on one page, taken from each lesson's Remember box. Read it before an interview, or print it.
RDC Is CDC Plus Reset Asymmetry
Reset-value leakage: a flop in reset drives its reset value across, and the other side takes it for data.
Protocol mismatch: one side forgets the handshake state while the other remembers it, which gives duplicates.
The asynchronous reset edge itself can change even a single-bit control signal inside the receiver's window.
Rule of thumb: do not reset data buses that cross; reset control, and mark data invalid while in reset.
Reset Isolation Pattern
Do not reset data that crosses. A destination that is not armed acknowledges an old request without capturing it.
Block acceptance until recovery completes, using link_ready_s from an always-on controller.
Isolate asserts before the block resets and releases after it is stable. The isolate control must come from a domain that is not being reset.
Rule of thumb: use both: isolation at block boundaries and tolerance inside the crossing.
Quiescent State Before Reset Release
Quiescent means no transfer in flight, handshake wires idle, FIFOs empty, and both sides knowing the other's state.
Before a planned reset, stop sending and drain what is in flight. Then reset.
A synchronised alive flag may stay high for several cycles after a remote reset. It does not detect an unexpected reset.
Rule of thumb: the receiver announces readiness and the sender waits; do not rely on a fixed release delay.
RDC Signoff Checklist
Same reset pin does not mean same release time. Protocol tolerance or sequencing is still needed.
The cheapest RDC test is a randomised reset test on every crossing: reset either side at random times, then check traffic resumes with no duplicate or corrupted word.
Every tool waiver needs a reason, and someone other than the RTL author reviews the list after each reset-structure change.
Rule of thumb: structure, crossings, ordering, timing, and a randomised reset test.
Recovery, Removal and Verification Focus
Removal is the hold-like window: reset must stay asserted for a short time after the edge. Recovery is the setup-like window: reset must release before the next edge.
The two windows are narrow, here about 4.5 % of a 10 ns cycle together. The synchroniser moves the release clear of removal.
STA checks both windows for every flop with an asynchronous reset, across the required corners.
Rule of thumb: a raw asynchronous release may meet the windows by chance; it cannot guarantee it.
Mini project: a two-clock block with a handshake, an async FIFO and a hostile test
Practice question: Debugging metastability from asynchronous reset deassertion
Code lab: Reset domain crossing
Interview: run a mock interview on this topic