Reset Domain Crossing Rdc

Reset Domain Crossing (RDC) Verification is the systematic analysis of signal transitions between different reset domains in a digital SoC to identify functional hazards caused by asynchronous reset assertion or deassertion sequences that can corrupt data, create metastability, or leave state machines in undefined states — complementing clock domain crossing (CDC) verification as a critical signoff check for complex multi-domain designs.

Reset Domain Architecture:
- Power-On Reset (POR): global chip-level reset generated by voltage supervisors that initializes all logic to known states; typically held active for microseconds after supply voltage reaches stable operating level
- Warm Reset: software-initiated or watchdog-triggered reset that reinitializes selected logic blocks while preserving configuration registers and memory contents; requires careful definition of which flops are reset and which are retained
- Domain-Specific Reset: independent reset signals for individual IP blocks (PCIe, USB, Ethernet) that allow subsystem reinitialization without disturbing other chip functions; creates multiple reset domain boundaries requiring crossing analysis
- Reset Tree Design: dedicated reset distribution network with balanced skew and glitch filtering; reset buffers sized for fan-out with minimum insertion delay to ensure simultaneous arrival across all flops in the domain

RDC Hazard Categories:
- Asynchronous Reset Deassertion: when reset releases asynchronously relative to the clock, recovery and removal timing violations can cause metastability on the first clock edge after reset; reset synchronizers (two-stage synchronizer on the reset deassertion path) resolve this hazard
- Data Corruption at Crossing: signals crossing from a domain in reset to a domain in active operation may carry undefined values; receiving logic must gate or ignore inputs from domains that are still under reset
- Partial Reset Ordering: when multiple resets deassert in sequence, intermediate states may violate protocol assumptions; reset sequencing logic must enforce correct ordering with sufficient margin between domain activations
- Retention Corruption: in power-gated designs, reset deassertion must occur after power is stable and retention flop contents have been restored; premature reset release corrupts saved state

RDC Verification Methodology:
- Structural Analysis: EDA tools (Synopsys SpyGlass RDC, Cadence JasperGold) automatically identify all reset domain crossings by tracing reset and clock connectivity; each crossing is classified by hazard type and severity
- Synchronizer Verification: tools check that every asynchronous reset deassertion path includes a proper two-stage synchronizer to prevent metastability; the synchronizer must be clocked by the receiving domain's clock
- Protocol Checking: assertions and formal properties verify that data crossing reset domain boundaries is valid when sampled; handshake protocols at reset boundaries must complete correctly during both reset entry and exit
- Simulation Coverage: targeted reset sequence tests exercise all reset assertion and deassertion orderings; coverage metrics track that every reset domain transition has been verified under worst-case timing conditions

RDC verification is an essential signoff discipline that prevents silent data corruption and undefined behavior in multi-domain SoCs — ensuring that reset sequences, which occur during every power-on, warm reboot, and error recovery event, execute correctly across all domain boundaries throughout the chip's operational lifetime.