Reset Domain Crossing (RDC) Explained: Complete Guide for ASIC Verification Engineers
Modern System-on-Chip (SoC) designs contain multiple clock domains and multiple reset domains. While engineers spend significant effort verifying Clock Domain Crossing (CDC), another equally critical challenge often goes unnoticed—Reset Domain Crossing (RDC).
Improper handling of reset signals can introduce hidden bugs that escape simulation and only appear in silicon, making them extremely expensive to debug. This article explains RDC from the ground up, covering its concepts, problems, synchronization techniques, design guidelines, and verification methodology.
What is Reset Domain Crossing (RDC)?
Reset Domain Crossing (RDC) occurs when a reset signal generated in one reset domain affects logic operating in another reset domain.
Unlike CDC, which deals with transferring data across clock domains, RDC focuses on the safe transfer and release of reset signals across independently controlled reset domains.
A design may contain several reset sources:
- Power-On Reset (POR)
- Watchdog Reset
- Software Reset
- Debug Reset
- Peripheral Reset
Whenever logic driven by one reset interacts with logic controlled by another reset, RDC analysis becomes necessary.
Why is RDC Important?
Reset signals determine the initial state of digital circuits.
If reset is not released correctly:
- Flip-flops may exit reset at different times.
- Unknown values (X) may propagate.
- State machines may start from illegal states.
- Metastability can occur.
- Functional failures may appear only after manufacturing.
Many silicon bugs are traced back to improper reset synchronization rather than logic design errors.
Understanding RDC with an Example
Consider two reset domains.
-
reset_acontrols logic in Domain A. -
reset_bcontrols logic in Domain B. - The reset signal crosses between independent reset domains.
If reset_b is released asynchronously while Domain B is running, some flip-flops may leave reset before others, causing unpredictable behavior.
Common Problems Caused by RDC
1. Metastability During Reset Release
The assertion of reset is usually safe because every register is immediately forced into a known state.
The real danger occurs during reset deassertion.
If reset is removed close to the active clock edge, a flip-flop may enter a metastable state.
Clock ─┐ ─┐ ─┐ │ │ │ ──┘────┘────┘── Reset ──────────┐ │ └──── Release occurs near clock edge ↓ Metastability
2. Partial Reset
Some registers leave reset earlier than others.
Example:
Register A : Released Register B : Still in Reset Register C : Released
This creates inconsistent logic states.
3. Different Reset Release Times
Suppose an FSM contains five flip-flops.
If three registers release during one clock cycle and two registers release one cycle later, the state machine may begin in an illegal state.
4. Unknown State Propagation
Improper reset sequencing can generate unknown (X) values.
Reset Released ↓ Unknown State ↓ Combinational Logic ↓ Incorrect Outputs
5. Functional Failures
Improper RDC may cause:
- Boot failures
- Peripheral initialization errors
- Deadlocks
- Random system hangs
- Silicon bring-up failures
Types of Reset
Golden Rule of Reset Design
The most widely accepted guideline is:
Assert reset asynchronously (if required), but always deassert it synchronously.
This combines the advantages of fast reset assertion with safe reset release.
Reset Synchronizer (2-Flip-Flop Synchronizer)
The most common solution for RDC is the 2-FF reset synchronizer.
How It Works
- Reset may deassert at any time.
- First flip-flop samples the reset.
- If metastability occurs, it is confined to FF1.
- Second flip-flop allows the signal an additional clock cycle to settle.
- The synchronized reset is then safely distributed throughout the domain.
Reset Synchronizer Variants
2-FF Synchronizer
Most widely used.
Suitable for:
- General ASIC designs
- FPGA designs
- Medium-speed systems
3-FF Synchronizer
Adds another synchronization stage.
Benefits include:
- Lower metastability probability
- Better reliability
- Preferred for safety-critical designs
Synchronizer with Feedback
Some designs include feedback logic that filters glitches before reset reaches the destination domain.
These are commonly used in:
- Automotive chips
- Aerospace systems
- High-reliability ASICs
RDC Safe Design Practices
Good reset design follows several important rules.
Synchronize Reset Release
Never allow asynchronous reset release across domains.
Use Proper Synchronizers
Use dedicated reset synchronizer circuits rather than directly connecting resets.
Keep Reset Local
Distribute reset freely only inside a single reset domain.
Synchronize it only at the domain boundary.
Release All Flip-Flops Together
Registers belonging to the same functional block should exit reset simultaneously.
Avoid Combinational Logic
RDC Design Guidelines
A robust reset architecture generally follows these recommendations:
- Use reset synchronizers whenever resets cross domains.
- Keep reset synchronization local to each clock domain.
- Avoid directly fanning out asynchronous reset across multiple domains.
- Minimize combinational logic in reset paths.
- Verify reset trees carefully.
- Consider Power-On Reset (POR) separately from functional resets.
- Review reset sequencing during architecture design.
RDC Verification
Verification is essential because reset bugs are often difficult to reproduce.
Typical RDC verification flow includes:
Identify Reset Domains
Determine every independent reset source in the design.
Find RDC Paths
Locate signals crossing between reset domains.
Check Synchronizers
Ensure every asynchronous reset crossing uses an approved synchronizer.
Verify Reset Deassertion
Confirm that reset is released synchronously within the destination clock domain.
Analyze Reset Tree
Review:
- Reset fanout
- Reset distribution
- Reset buffering
- Reset latency
Run Static RDC Analysis
EDA tools automatically detect unsafe reset crossings and synchronization issues.
Common tools include:
- Siemens Questa RDC
- Synopsys VC SpyGlass RDC
- Cadence Jasper RDC
Perform Reset Simulations
Functional simulation should include scenarios such as:
- Power-on reset
- Warm reset
- Software reset
- Partial reset
- Reset during active transactions
- Random reset assertion/deassertion
These tests help expose corner-case issues before tape-out.
Bad vs Good RDC Design
Benefits:
- Synchronous reset release
- Reliable startup
- Stable operation
- Improved silicon robustness
Common RDC Issues
Some of the most frequently encountered reset-related problems include:
- Using asynchronous resets across domains without synchronization
- Missing reset synchronizers
- Combinational logic in reset paths
- Registers releasing reset at different clock cycles
- Improper reset sequencing
- Reset tree imbalance
- Incomplete reset coverage
- Reset glitches caused by gating logic
Best Practices for ASIC Designers and Verification Engineers
- Plan reset architecture during the early design phase.
- Minimize the number of independent reset domains.
- Use dedicated reset synchronizers for every reset crossing.
- Synchronize reset deassertion to the destination clock.
- Keep reset distribution simple and well-balanced.
- Verify reset behavior using both simulation and static RDC analysis.
-
Include reset scenarios in regression suites to improve verification coverage.
Key Takeaways
Reset Domain Crossing (RDC) is a critical aspect of modern ASIC and SoC design that ensures reset signals are transferred safely between independent reset domains. While reset assertion can often be asynchronous, reset deassertion should always be synchronized to the destination clock to prevent metastability and inconsistent initialization. Proper use of reset synchronizers, disciplined reset architecture, and thorough RDC verification significantly reduce the risk of silicon failures and improve overall system reliability.
As SoCs continue to grow in complexity with multiple power, clock, and reset domains, RDC verification has become just as important as Clock Domain Crossing (CDC) verification. A well-designed reset strategy is fundamental to building stable, reliable, and production-ready digital systems.
- Get link
- X
- Other Apps
Labels
SoC Verification- Get link
- X
- Other Apps


Comments
Post a Comment