Reset Domain Crossing (RDC) in Digital Design

Reset Domain Crossing (RDC) has become a critical verification concern in modern SoC and FPGA designs, where multiple subsystems operate with different clock and reset requirements. As designs grow in complexity, the  reset architecture is no longer a simple global reset distributed across the chip. Instead, designers often use multiple asynchronous resets, each serving power islands, clock domains, low-power states, or IP blocks. Whenever a signal or flop is reset by one reset domain and later interacts with logic controlled by another reset domain, an RDC hazard can occur.

What is Reset Domain Crossing?

RDC happens when a register or logic element controlled by one reset (rst_a) feeds a register controlled by another reset (rst_b). If the release (de-assertion) of the two resets is not coordinated, the destination logic may latch unstable values, leading to metastability or X-propagation during reset release. Unlike CDC (Clock Domain Crossing), RDC issues occur even when both domains use the same clock, because the instability arises due to asynchronous reset release, not the clock.

Why RDC is Dangerous

1. Metastability During Reset Release:
When one flop is coming out of reset earlier than another, the downstream flop may
capture an undefined state.
2. Unpredictable Boot-up behavior:
The design may behave differently after each power cycle because reset arrival times
vary with routing delays.
3. Fails even with Clean Clock Domain:
Designers often assume same-clock domains are safe—but RDC issues arise purely
from reset sequencing, not clock interaction.
4. Difficult to Debug in Silicon:
Boot-up failures, intermittent wake-up errors, or random lock-ups are common
symptoms of unaddressed RDC bugs.

Common Sources of RDC

1. Asynchronous resets used across multiple blocks without coordination.
2. Partial resets where only a portion of the logic is reset, leaving other flops
unchanged.
3. Low-power mode resets used independently of functional resets.
4. Different IP blocks with locally generated resets (PLL lock reset, POR reset,
software reset).
5. Glitchy reset paths due to combinational logic feeding reset signals.

How to Prevent RDC Issues

1. Use Reset Synchronizers
For asynchronous reset de-assertion, always synchronize the de-asserted reset to the destination
clock to avoid metastability.
A typical 2-flop reset synchronizer:
always @(posedge clk or negedge rst_n) begin
if (!rst_n)
sync <= 2'b00;
else
sync <= {sync[0], 1'b1};
end
assign rst_sync_n = sync[1];

2. Ensure Reset Release Ordering
Use reset controllers or reset sequencers to guarantee a safe order, such as:

• Power-on reset → PLL lock reset → system reset → peripheral resets.

3. Avoid Combinational Logic on Reset Paths
Gating resets through arbitrary logic can create glitches. Always use dedicated reset
controllers/cells.
4. Use RDC Static Verification Tools
Modern EDA tools (Synopsys VC-RDC, Siemens Questa RDC, Cadence Jaspergold) detect:

• Reset domain crossing paths
• Unsafe reset release
• Fan-out of asynchronous resets
• Missing reset synchronizers

Conclusion

Reset Domain Crossing is a critical reliability concern in today’s multi-reset SoCs. Mismanaged resets can lead to metastability, unpredictable boot behaviour, and silicon bugs that are extremely difficult to detect. A robust reset strategy built around reset synchronization, proper sequencing, and static RDC analysis is essential for a clean and reliable design. As SoCs integrate more power modes, clock domains, and IP blocks, RDC closure is now as important as CDC closure for sign-off.