Reset Domain Crossing (RDC)
CDC checks clock domains. RDC checks reset domains. If a signal is launched by a flip-flop that resets at one time, and captured by a flip-flop that resets at a different time, you have an RDC hazard.
The RDC Hazard
When a reset is asserted, it doesn't happen instantly across the whole chip. If Domain A resets first, its output might go to an unknown state (X) while Domain B is still running. Domain B then captures that X value, corrupting its state.
The Synchronizer Solution
The safest way to handle RDC is to use a Reset Synchronizer. This is a 2-stage flip-flop chain that synchronizes the de-assertion (release) of the reset to the destination clock domain.
How RTL Bench Checks RDC
Similar to CDC, RTL Bench's backend traverses the Yosys netlist. It finds every flip-flop, traces its reset pin back to the source, and checks if the launch and capture flops share the same reset source.
- Safe: Both flops share the same reset net.
- Unsafe: The capture flop has no reset, or a completely different reset source.
Click the RDC badge in the Studio bottom bar to view the full report.
Frequently asked questions
While Clock Domain Crossing (CDC) deals with signals crossing between asynchronous clocks, Reset Domain Crossing (RDC) occurs when a reset signal asynchronously resets a source flip-flop while the destination flip-flop remains active (or vice versa), causing transient glitches or race conditions.
If a submodule or controller resets while its counterpart in another subsystem is waiting on a handshake, the handshake protocol may hang indefinitely in an unrecoverable state.
Safe RDC requires reset isolation logic (clamping signals to known inactive states during reset), synchronous reset release via reset synchronizers, and glitch-free reset distribution trees.