Reset Domain Crossing (RDC) Analysis is the verification discipline that ensures reset signals are properly synchronized when they cross between different clock or reset domains, preventing the same class of metastability and ordering hazards that affect clock domain crossings but applied specifically to reset architecture — an area historically overlooked until dedicated RDC tools became available.
Reset bugs are particularly dangerous because they affect system initialization and recovery — exactly the scenarios where reliable behavior is most critical. A metastable reset release can leave part of the chip in reset while the rest is operational, causing functional failures that disappear on retry.
Reset Architecture Fundamentals: Most designs use asynchronous assert, synchronous deassert reset strategy: a reset signal immediately forces all flip-flops to known state (async assert), but is released synchronously with the destination clock (deassert) to ensure all flip-flops exit reset on the same clock edge. The reset synchronizer (a 2-FF synchronizer on the deassert path) prevents metastability.
RDC Hazard Categories:
| Hazard | Description | Impact |
|--------|-----------|--------|
| Missing reset synchronizer | Async reset deasserts without sync FF | Metastable reset release |
| Reset sequencing | Domains exit reset in wrong order | Protocol violations |
| Reset glitch | Combinational logic on reset path creates glitch | Spurious reset assertion |
| Incomplete reset | Some FFs in a domain miss the reset | Partial initialization |
| Reset-clock interaction | Reset deasserts near clock edge | Setup/hold violation on reset |
Reset Ordering Requirements: Complex SoCs require specific reset sequences — for example, the memory controller must be out of reset before the CPU begins fetching instructions; the PLL must lock before downstream logic exits reset; the power management unit (PMU) must be functional before any switchable domains are activated. RDC verification ensures these ordering constraints are met in all reset scenarios (power-on, watchdog, software-initiated, warm reset).
RDC Verification Tools: Tools like Synopsys SpyGlass RDC and Siemens Questa RDC perform structural analysis to identify: reset signals crossing between asynchronous domains without proper synchronization, reset tree topology errors (fan-out imbalance causing skew), combinational logic in reset paths that may introduce glitches, and reset domains where some flip-flops are connected to different reset sources.
RDC analysis has emerged as a critical signoff check alongside CDC — as SoC complexity has increased to dozens of independent reset domains, the probability of reset architecture bugs has risen from rare corner cases to systematic design risks that require dedicated verification methodology to catch.