Skip to content
STIMSMITH

Clock Domain Crossing (CDC)

Concept WIKI v1 · 7/16/2026

Clock Domain Crossing (CDC) refers to the transfer of data or signals between separate clock domains within a digital design. CDC paths are susceptible to metastability, requiring synchronization primitives and dedicated verification flows to ensure functional correctness.

Clock Domain Crossing (CDC)

Definition

A Clock Domain Crossing (CDC) occurs when a signal, data word, or control signal generated in one clock domain is consumed in another clock domain that operates asynchronously (i.e., with an unrelated or derived clock frequency/phase). SoC and FPGA designs frequently contain multiple asynchronous clock domains, particularly under the Globally-Asynchronous Locally-Synchronous (GALS) power-management approach used to improve energy efficiency.

Metastability and Functional Risk

When a signal transitions near the sampling edge of a receiving flip-flop in another domain, the receiving storage element can enter a metastable state, potentially propagating an indeterminate logic value downstream. CDC paths are therefore prone to metastability-induced functional bugs. Per the formal-verification literature on CDC, conventional methods such as register-transfer-level (RTL) simulation and static timing analysis are not sufficient on their own to catch every CDC issue, leaving verification gaps. CDC-related bugs are among the most common causes of costly silicon re-spins.

Mitigation: Synchronization Primitives

The standard mitigation is to insert synchronization primitives on the crossing path so that metastability cannot propagate functional errors. In OpenTitan's design governance, for example, the sign-off checklist requires that "All CDC synchronization flops use behavioral synchronization macros (e.g. prim_flop_2sync) not manually created flops." Such two-flop (or multi-flop) synchronizers are constructed from carefully separated back-to-back flops that give the metastable state time to resolve before downstream logic samples the value.

Verification Practice

Recommended verification practice for CDC includes:

  • Setting up a dedicated CDC checking run when tooling is available.
  • Ensuring the CDC run shows no must-fix errors, with any remaining issues captured in a reviewed waiver file.
  • Block-level CDC flows may be waived only when no such tooling exists at the block level.
  • Complementing structural CDC checks with pragmatic formal verification, including Metastability Injection (MSI) on identified CDC paths, to reduce verification gaps.

Related Considerations

  • Reset Domain Crossing (RDC): Closely related discipline covering reset signal propagation across domains. The OpenTitan checklist treats it as a parallel requirement, with an RDC run expected to be configured and free of must-fix errors.
  • Distributed configuration memory: Settings-register architectures can be distributed to support clock-domain crossing and dynamic partial reconfiguration, trading off fan-out for resource efficiency on FPGAs.

See Also

  • prim_flop_2sync — behavioral synchronization macro used to implement CDC flops.

LINKED ENTITIES

1 links
prim_flop_2sync USES

CITATIONS

5 sources
5 citations
[1] SoC designs often operate on multiple asynchronous clock domains, creating CDC paths prone to metastability effects. Pragmatic Formal Verification Methodology for Clock Domain Crossing (CDC)
[2] Conventional verification methods such as RTL simulation and static timing analysis are not sufficient to fully address CDC issues, and CDC-related bugs are common causes of silicon re-spins. Pragmatic Formal Verification Methodology for Clock Domain Crossing (CDC)
[3] OpenTitan sign-off requires CDC synchronization flops to use behavioral synchronization macros (e.g. prim_flop_2sync) instead of manually created flops. Signoff Checklist - OpenTitan Documentation
[4] A CDC checking run must be set up when tooling is available, show no must-fix errors, and have any remaining issues captured in a reviewed waiver file. Signoff Checklist - OpenTitan Documentation
[5] A distributed settings-register memory architecture can be used to support clock-domain crossing and dynamic partial reconfiguration, reducing resource cost. A distributed memory, local configuration technique for re-configurable logic designs