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**.

Go deeper with CFSGPT

Get AI-powered deep-dives, save terms, and run advanced simulations — free account.

Create Free Account