Commercial CDC Tools

Manual RTL review catches maybe 40% of clock domain crossing bugs. On a million-gate SoC with dozens of asynchronous interfaces, the other 60% silently ship to silicon and explode in the field. Commercial CDC tools close that gap: they parse the entire RTL, extract every clock domain, and identify every unsynchronized crossing in minutes. This day covers the three industry-standard tools — Synopsys SpyGlass CDC, Cadence JasperGold CDC App, and Mentor Questa CDC — plus open-source alternatives, common violation codes, and where each tool fits in the design flow.

1. Why dedicated CDC tools are needed

A modern SoC might have 8–16 independent clock domains: a CPU cluster at 3 GHz, a display engine at 148.5 MHz, a USB PHY at 480 MHz, an LPDDR controller at 800 MHz, dozens of APB peripherals at 100 MHz, and more. Each domain boundary is a potential metastability injection point.

Manual review fails for three reasons:

• Scale — A million-gate design has thousands of flip-flops. You cannot trace every net by hand.
• Subtlety — Reconvergence bugs (two paths from the same crossing re-joining in the destination domain) are invisible to the eye but catastrophic at runtime.
• Combinational glitches — A multi-bit bus sampled asynchronously can produce glitch pulses that no simulation testbench ever exercises.

CDC tools perform structural analysis — they do not simulate. They read RTL, build a connectivity graph, tag every register with its clock domain, and walk every net to find domain crossings. A complete run on a 10-million-gate design takes 30–60 minutes versus weeks of manual review.

2. Synopsys SpyGlass CDC

SpyGlass CDC is the industry standard for RTL CDC checking. It is used by virtually every major semiconductor company for CDC signoff. SpyGlass performs static structural analysis — it never runs simulation.

Key capabilities

• Clock domain extraction — Automatically identifies all clock domains from RTL and constraint files (SDC). Recognizes generated clocks, clock muxes, and gated clocks.
• Crossing identification — Walks every net in the design and identifies which crossings have no synchronizer, which have synchronizers, and which have structural reconvergence.
• Synchronizer structure check — Verifies that synchronizers have the correct number of stages, correct attributes, and correct clock assignment.
• Reconvergence analysis — Detects when two paths from the same crossing point re-join in the destination domain. This is the most dangerous CDC violation because it can cause functional errors even when individual crossings appear safe.
• Waiver management — Allows designers to waive false positives with justification comments tracked in the CDC closure report.
• CDC reports — Produces a structured report of all violations, their severity, and their location in the design hierarchy.

SpyGlass CDC workflow

The typical SpyGlass CDC run follows five steps: read RTL, define clocks, run the CDC goal, review violations, waive false positives, and export a closure report.

# --- Step 1: Read RTL ------------------------------------------------
read_file -type verilog {
    rtl/clk_a_domain.v
    rtl/clk_b_domain.v
    rtl/cdc_synchronizer.v
    rtl/top.v
}

# Read constraints (SDC)
read_file -type sdc constraints/top.sdc

# --- Step 2: Set clock definitions -----------------------------------
# (Usually already in SDC, but can be set manually)
define_clock -name clk_a -period 4.0  [get_ports clk_a]
define_clock -name clk_b -period 6.67 [get_ports clk_b]
define_clock -name clk_c -period 10.0 [get_ports clk_c]

# Mark async clock pairs (no phase relationship)
set_clock_groups -asynchronous \
    -group {clk_a} \
    -group {clk_b} \
    -group {clk_c}

# --- Step 3: Set CDC goal and run ------------------------------------
current_goal CDC/lint -top top

# Enable reconvergence checks (off by default in older versions)
set_option enableReconvergenceCheck true

# Run CDC analysis
run

# --- Step 4: Review violations ---------------------------------------
# Get all violations
set viols [get_violations -goal CDC/lint]
foreach v $viols {
    puts "VIOLATION: [get_attribute $v violation_name] \
          SEVERITY: [get_attribute $v severity] \
          LOCATION: [get_attribute $v location]"
}

# --- Step 5: Waive false positives -----------------------------------
# Waive a known-safe path with justification
waive -rule Ac_unsync01 \
      -regexp {req_sync/d_in} \
      -comment "Handled by 2-FF synchronizer in cdc_synchronizer.v line 42"

# Waive reconvergence where data is gray-coded (safe)
waive -rule Ac_conv01 \
      -regexp {gray_counter/q\[} \
      -comment "Gray-coded bus: only 1 bit changes per cycle, reconvergence is safe"

# --- Step 6: Re-run and export closure report -----------------------
run
report -type cdc -output reports/cdc_closure.rpt

# Export waiver log for review board
report_waivers -output reports/cdc_waivers.rpt

3. Cadence JasperGold CDC App

JasperGold CDC is Cadence's formal CDC verification tool. Rather than structural analysis, it uses model checking — a mathematical technique that exhaustively explores all possible input sequences to prove properties about the design.

This makes JasperGold fundamentally different from SpyGlass:

• SpyGlass says "this crossing has no synchronizer" (structural).
• JasperGold says "I have proven that this crossing is safe under all possible inputs" or "I have found a counter-example where it fails" (formal).

JasperGold is significantly slower than SpyGlass (hours versus minutes for large designs) but eliminates false positives and can automatically generate waivers for paths it proves safe. It also provides coverage metrics: which CDC paths were exercised by simulation, and which were only proven safe by formal.

# --- JasperGold CDC App invocation ----------------------------------
# Run from: jg -cdc -allow_unsupported_OS

# Load design
analyze -sv09 {
    rtl/clk_a_domain.sv
    rtl/clk_b_domain.sv
    rtl/cdc_synchronizer.sv
    rtl/top.sv
}

elaborate -top top -work worklib

# --- Clock and reset specification ----------------------------------
clock clk_a -period 4
clock clk_b -period 6
reset -expression {!rst_n}

# --- CDC App: prove synchronizer correctness ------------------------
# Enable CDC property generation
cdc_app -enable

# Set synchronizer depth to check
cdc_app -sync_depth 2

# Run formal proof
prove -all

# --- Review CDC results ---------------------------------------------
# Proven-safe crossings (auto-waivable)
report -type cdc_proven   -out reports/jg_cdc_proven.rpt

# Crossings with counter-examples (real bugs)
report -type cdc_violated -out reports/jg_cdc_violated.rpt

# Coverage: which CDC paths exercised by simulation
report -type cdc_coverage -out reports/jg_cdc_coverage.rpt

# Generate automatic waivers for proven-safe paths
cdc_generate_waivers -proven -output waivers/auto_cdc_waivers.svwf

4. Cadence Xcelium CDC — Dynamic CDC Checking

Xcelium is Cadence's primary RTL simulator. It includes a built-in runtime CDC checker that instruments the design during simulation and reports CDC violations as they actually occur — catching dynamic violations that static analysis cannot find.

The key advantage: Xcelium CDC can detect protocol violations that depend on simulation stimulus. A handshake protocol that is structurally correct but violates timing under specific traffic patterns will only be caught at runtime. Xcelium CDC also integrates with Cadence CCOV to show which CDC crossings were exercised during simulation, helping teams understand their CDC coverage gap.

# Compile with CDC instrumentation enabled
xmvlog -sv -64bit \
    -define CDC_ENABLE \
    rtl/top.sv rtl/cdc_synchronizer.sv

# Elaborate with CDC runtime checks
xmelab -64bit \
    -access +r \
    -cdc_enable \
    -cdc_report reports/xm_cdc_runtime.rpt \
    worklib.top

# Run simulation -- CDC checker fires on violations
xmsim -64bit \
    -cdc_enable \
    -cdc_max_violations 1000 \
    worklib.top

# After simulation: review CDC runtime report
# Violations appear as:
#   CDC_VIOLATION at time X ns in module Y
#   port Z crossing from domain A to domain B without synchronizer

5. Mentor Questa CDC

Questa CDC (now under Siemens EDA) combines static CDC analysis with tight integration into the Questa simulation environment. Its key strength is mixed static + dynamic verification: it performs an initial structural analysis pass, then instruments the RTL for runtime checking during simulation.

Questa CDC produces a CDC coverage report after simulation that shows which crossings were exercised during the sim run, which were clean, and which produced violations. This makes it very powerful for directed CDC regression testing — you can write testbench scenarios specifically targeting CDC paths and verify every crossing was exercised.

# --- Step 1: Static CDC analysis ------------------------------------
qvl_compile -f filelist.f -top top

# Run static CDC check
cdc check -d top \
    -clock  {clk_a 4ns} \
    -clock  {clk_b 6.67ns} \
    -reset  {rst_n -low} \
    -report reports/questa_static_cdc.rpt

# --- Step 2: Instrument RTL for dynamic CDC -------------------------
# Generate an instrumented netlist for simulation
cdc instrument -d top \
    -out_file work/top_cdc_inst.sv

# --- Step 3: Simulate instrumented design ---------------------------
vlog -sv work/top_cdc_inst.sv
vsim -t 1ps top_tb

# Run test
run -all

# --- Step 4: CDC coverage report ------------------------------------
cdc report -db questa_cdc.db \
    -type coverage \
    -output reports/questa_cdc_coverage.rpt

# CDC coverage shows:
#   EXERCISED  -- crossing was sampled in simulation
#   CLEAN      -- no violation observed
#   VIOLATED   -- runtime CDC violation detected
#   UNREACHED  -- crossing never exercised (coverage gap)

# --- Step 5: Waiver management -------------------------------------
cdc waiver -rule CDC_ASYNC_RESET \
    -scope {top.u_core.u_rst_sync} \
    -comment "Asynchronous reset synchronizer -- by design"

6. Tool comparison table

7. Open-source CDC checking

Commercial tools are expensive. For smaller teams, open-source alternatives provide partial CDC coverage:

• SymbiYosys — Open-source formal verification framework that can run CDC-style properties written in SystemVerilog Assertions (SVA). No built-in CDC extraction; you write the assertions manually. Effective for targeted formal CDC proofs on small blocks.
• Verilator — High-performance RTL simulator with lint-like static analysis. Limited CDC checking but can be extended with custom lint rules. Useful for CI-stage CDC sanity checks before a commercial tool run.
• Yosys — Open-source synthesis tool with netlist analysis capabilities. Scripts exist to extract clock domains and flag structural crossing issues. Not a purpose-built CDC tool but useful for structural exploration and academic projects.

8. Common tool violation codes — what they mean and how to fix them

SpyGlass CDC uses standardized violation codes. These codes appear in all major CDC tools in similar forms. Understanding them is essential for triaging a CDC signoff report.

# --- GOOD waiver: documented, scoped, justified ---------------------
waive -rule Ac_unsync01 \
      -regexp {u_gray_counter\.q\[} \
      -comment "SAFE: Gray counter output -- only 1 bit changes per \
                clock cycle. Analyzed by CDC lead 2026-06-20. \
                Jira: CDC-142."

# --- BAD waiver: blanket waive without justification ----------------
# NEVER do this -- it masks real bugs
# waive -rule Ac_unsync01 -regexp {.*}   ;# DO NOT USE

# --- Reconvergence waiver with evidence ----------------------------
waive -rule Ac_conv01 \
      -regexp {u_arb\.req_sync} \
      -comment "Reconvergence on arbitration request. Both paths \
                converge at u_arb.grant_r which is qualified by \
                u_arb.lock -- lock prevents simultaneous assertion. \
                Design review signoff: DR-2026-031."

9. CDC tool integration in the design flow

CDC tools are not run once and forgotten. They belong at multiple stages of the design flow, and the output of each run feeds into the next:

10. Practical tips for CDC tool runs

• Always start with complete SDC — CDC tools are only as good as your clock constraints. A missing clock definition means the tool cannot identify that domain. Garbage in, garbage out.
• Run CDC before simulation — Structural violations caught by SpyGlass in 30 minutes would take weeks to surface through simulation. Run SpyGlass first, fix structural issues, then simulate.
• Never blanket-waive — Waiving all instances of a violation rule masks real bugs. Every waiver must be specific (regexp to an exact net), documented, and reviewed by a second engineer.
• Track waivers in version control — Waiver files (.awf for SpyGlass, .svwf for JasperGold) belong in your repository alongside RTL. A waiver file without version history cannot be audited at tapeout.
• Re-run CDC on every RTL change — New RTL can introduce new crossings. CDC checking must be part of the CI pipeline, not a one-time event at freeze.
• Use formal for buses — SpyGlass can flag multi-bit bus crossings, but only JasperGold can prove that your gray-coded counter actually satisfies the single-bit-change property under all possible inputs.

FAQ

← Full course roadmap