Reset Domain Crossing Verification
Clock Domain Crossing Verification covered metastability on ordinary data signals crossing clock domains. A reset signal crossing into a domain it wasn't generated in has the same underlying failure mechanism, plus two more failure modes unique to resets specifically — which is why RDC gets its own dedicated check, not just a footnote on CDC.
Metastability on both edges, not just one
An asynchronous reset is deliberately built to assert immediately, with no dependency on any clock — that's the entire point of an async reset, reaching every flop instantly regardless of clock state. But de-assertion is a signal transition like any other, and if it isn't synchronized to the domain it's releasing, it can land inside a receiving flop's setup/hold window exactly like any other unsynchronized crossing — metastability on reset release, at the exact moment logic is coming out of a known, defined state into an unknown one.
reset_src asserts instantly and asynchronously — correct by design. But its de-assertion, passed through raw as reset_dst, lands right on a clk_dst edge instead of a safely stable phase — exactly the CDC problem, applied to reset release.
The standard fix is structurally identical to CDC's: assert asynchronously (immediately, unsynchronized, by design), but synchronize de-assertion to the destination clock through a dedicated reset synchronizer — never through arbitrary combinational logic, which introduces the next problem.
Glitches from combinational reset logic
A reset signal generated by combinational logic — gated with some other condition, derived from an OR of several sources — inherits every hazard combinational logic can produce: a momentary glitch on an input can produce a spurious, momentary pulse on the reset output, asserting reset for a fraction of a cycle no test ever intended. Dedicated reset controller cells or structures, not arbitrary gating logic, are the standard mitigation specifically because they're built and characterized to avoid this.
Reconvergence: two synchronized copies of "the same" reset disagreeing
The failure mode unique to RDC, with no direct CDC equivalent: the same source reset, synchronized independently into two different downstream paths (through two separate synchronizers, or into two different clock domains), can come out of each synchronizer on a different cycle — each synchronizer resolved correctly on its own terms, but the two now-independent copies are no longer guaranteed to agree cycle-for-cycle. If logic downstream assumes both copies represent "the same reset event" and combines them, one part of the design can see reset still asserted while another sees it already released, in the same real cycle — a genuine functional bug, not a timing artifact, and one static timing analysis, CDC tools, and ordinary simulation can all miss, since each of the two synchronized paths is individually correct.
Two configuration mistakes that show up before synchronization even matters
Not every RDC bug is a timing problem. A reset can be structurally synchronized perfectly and still be wrong for a simpler reason: wrong polarity (a reset synchronizer built for active-high driving an active-low reset input, or vice versa — the logic "works," just backwards) or wrong clock (a reset de-assertion synchronized to a clock domain other than the one actually sampling it downstream — structurally identical to skipping synchronization entirely, since the synchronizer is now solving the wrong problem). Both are exactly the kind of mistake a structural check should catch immediately, since neither depends on timing at all — they're wrong by construction, not wrong by chance.
Verification approach: static RDC analysis first
The same static-vs-dynamic split CDC verification introduced applies here, with one difference in emphasis: static RDC analysis — tracing every reset's synchronization structure, polarity, and destination clock directly from the design, no testbench or stimulus required — is the primary, standard way real projects catch reset-domain-crossing bugs, for the same reason static CDC is: it's exhaustive, and it runs before a testbench even exists, well before the first cycle of simulation. Dynamic (simulation-based) and formal checks still have a role — confirming a synchronizer is exercised correctly under real reset sequences, or proving a specific reconvergence scenario is safe — but static analysis is where RDC verification starts, not an afterthought layered on once simulation is already running.
What's next
CDC and RDC both concern signal-level, structural correctness across clock/reset boundaries. The next page covers a different, earlier gate entirely — catching a broad class of structural problems (including some CDC/RDC precursors) before a single cycle of simulation ever runs.