Reset Domain Crossing (RDC) Explained: Hazards and Fixes

Reset domain crossing is the reset-side cousin of clock domain crossing, and it is one of the quietest sources of intermittent silicon failures. The hazard is simple to state: when a flop reset by one reset feeds a flop reset by a different, asynchronously related reset, the moment one reset moves and the other does not, the downstream flop can sample a changing value near its clock edge and go metastable. Like CDC, it survives a clean lint pass and a green simulation, because a simulator’s idealized flop never goes metastable. This page explains the hazard, the standard fix, the common bugs, and how RDC is checked. It assumes you are comfortable with the CDC fundamentals.

Why a reset is a crossing

An asynchronous reset can assert at any time, which is fine — the flop drops to its reset value immediately. The danger is on deassertion. If the reset releases close to a clock edge, it violates the flop’s recovery/removal timing and can drive it metastable, exactly like a data input changing in the setup/hold window. And if a single logical reset reaches two clock domains and releases at slightly different times in each, the difference between the two release events is itself an asynchronous crossing. A design with multiple independent resets has this hazard even if it has only one clock.

RDC vs CDC

CDC asks whether a signal crosses between asynchronous clock domains; RDC asks whether it crosses between asynchronous reset domains. They are related — an async reset is an async event — but they are not the same check. A purely single-clock design with two unrelated reset sources passes CDC and can still fail RDC. That is why mature flows run a dedicated RDC pass next to the CDC checker rather than folding it in.

The fix: async-assert, sync-deassert

The standard cell is the reset synchronizer: it asserts the instant the raw reset drops (no clock needed) and deasserts only after two clean destination-clock edges, so the release can never violate recovery/removal timing. Instance one per destination clock domain, and never share an instance across domains. It assumes a clean reset source and does not filter glitches, so debounce or clean a glitchy reset upstream.

// Async assert, sync deassert reset synchronizer.
// Asserts the instant async_rst_n drops; deasserts only after two clean
// dst_clk edges, so the release cannot violate recovery/removal timing.
// It does NOT filter glitches on async_rst_n -- it assumes a clean source.
// One instance per destination clock domain; never share across domains.
module rst_sync (
  input  logic dst_clk,
  input  logic async_rst_n,
  output logic dst_rst_n
);
  (* ASYNC_REG = "TRUE" *) logic meta_q;
  (* ASYNC_REG = "TRUE" *) logic sync_q;

  always_ff @(posedge dst_clk or negedge async_rst_n) begin
    if (!async_rst_n) begin
      meta_q <= 1'b0;     // async assert
      sync_q <= 1'b0;
    end else begin
      meta_q <= 1'b1;     // sync deassert, two edges later
      sync_q <= meta_q;
    end
  end

  assign dst_rst_n = sync_q;
endmodule

Common RDC bugs

• One raw reset fanned out to many domains. The same async reset deasserts at slightly different times in each domain, so the inter-domain paths see a reset crossing. Synchronize the deassertion per domain.
• A flop in reset domain A feeding a flop in reset domain B. If A resets and B does not, B captures a value that is changing underneath it. Treat the path with a synchronizer or guarantee the resets move together.
• Shared reset-synchronizer instance. Reusing one reset synchronizer across multiple clock domains defeats the per-domain deassertion guarantee. One instance per destination domain.
• An inferred latch on a reset path. An unintended latch in the reset distribution destroys the timing the synchronizer was sized for and is doubly dangerous.

How ChipVerify checks this

ChipVerify AI runs structural reset-domain-crossing analysis alongside its CDC analysis: it builds the reset structure of the design, identifies paths that cross between asynchronous reset domains, and flags the ones without an async-assert/sync-deassert reset synchronizer, with the file and line. It can also generate a correct-by-construction reset synchronizer so you start from a known-good cell. This is structural, pre-signoff evidence — bounded analysis that names suspicious crossings and is honest about what it cannot see — not a foundry signoff or a certification.

FAQ

Related reading

• Clock domain crossing — the data-side counterpart, with synchronizers and MTBF.
• Free CDC checker for Verilog — the structural pass RDC runs alongside.
• Tapeout readiness — CDC and RDC closure are line items before a cut.