reset domain crossing

Reset Domain Crossing (RDC) is the digital design challenge of safely propagating asynchronous reset signals across clock domain boundaries — ensuring that reset assertion and de-assertion are correctly sampled by destination flip-flops without causing metastability, partial reset (where some FFs reset and others don't), or glitch-induced reset that corrupts state. RDC is the complement to CDC (Clock Domain Crossing) and is equally critical for functional correctness of multi-clock SoC designs.

Why Reset Domain Crossing Is Difficult

• Asynchronous reset: Independent of clock → can assert/de-assert at any time.
• Assertion (going into reset): Usually safe — all FFs immediately reset (synchronous logic can handle async reset assertion).
• De-assertion (coming out of reset): DANGEROUS — if different FFs sample the release edge at different clock cycles, chip comes out of reset with inconsistent state → functional failure.

De-assertion Metastability

• Source reset released at time T → destination FF clock samples it between T and T + setup_time → metastability.
• Metastable state propagates → some FFs in the clock domain remain in reset, others exit reset.
• Result: Corrupted initial state → undefined behavior until next full reset cycle.

Reset Synchronizer Circuit

Standard 2-FF synchronizer for reset de-assertion:

Reset_n (async) →|FF1|→|FF2|→ Synchronized Reset to logic
                    ↑      ↑
                  CLK_A  CLK_A

- FF1: D=VDD, RESET_n=async reset
- FF2: D=FF1_Q, RESET_n=async reset
- FF1 and FF2 both have async reset tied to original reset signal
- Release: Both FFs are in reset, then after 2 clock cycles they release together

Why 2 FFs Work

• FF1 may be metastable on de-assertion → one full clock period resolves → FF1 output stable before FF2 samples.
• FF2 output is always stable → safe input to downstream logic.
• Probability of metastability surviving 2 FFs at 1 GHz: ~10⁻¹⁵ → acceptable for production.

Reset Synchronizer with Feedback (Toggle)

• For multiple clock domains: Each domain has its own 2-FF synchronizer + feedback acknowledge.
• Handshake: Domain A sends reset, waits for Domain B acknowledge → ensures all domains reset-release together.
• Used in SoC power-on reset (POR) sequencing.

Partial Reset Problem (Glitch Reset)

• Reset pulse too short (glitch) → assertion reaches some FFs, not others → partial reset.
• Minimum reset pulse width: Must be > 2 × destination clock period to guarantee all FFs see the reset.
• Reset qualification: Use synchronized reset generator → assert for N clock cycles before releasing.

RDC vs. CDC

RDC Analysis Tools

• Synopsys SpyGlass RDC: Structural analysis of reset propagation paths → flag unsynchronized crossings.
• Mentor Questa RDC: Formal analysis of reset de-assertion ordering → detects partial reset scenarios.
• Cadence JasperGold RDC: Formal property checking of reset behavior.

SoC Reset Architecture

• Power-on reset (POR): Hardware RC timer → de-asserts after VDD stable.
• Warm reset: Software-triggered reset (watchdog, software register write).
• Domain reset: Individual IP blocks resetable independently (for power management).
• Reset sequencer: Orders de-assertion: first reset PHY → then reset controller → then reset logic → prevents invalid states during power-up.

RDC in Practice

• A missed RDC in a complex SoC can cause a chip to power up randomly in an incorrect state — one of the hardest silicon bugs to reproduce and diagnose since symptoms only appear under specific PVT conditions or boot sequences.
• Industry practice: All reset synchronizers are tagged in the RTL → RDC tool verifies every async reset crossing has a synchronizer → sign-off criterion for tapeout.

Reset domain crossing analysis is the overlooked counterpart to CDC that prevents silicon chips from starting life in an unpredictable state — by ensuring every flip-flop in every clock domain reliably exits reset in the same clock cycle rather than at random intervals, proper RDC design and verification eliminates an entire class of intermittent, hard-to-reproduce boot failures that would otherwise plague system integration and field deployment.