Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Path
  • CDC/RDC Glossary
  • CDC/RDC Metrics Reference
  • CDC/RDC Interview Prep
  • CDC/RDC Signoff Cheatsheet
  • Clock Domains and Failure Modes8
    • Crossings and Failure Modes
      • What Is a Crossing?
      • Domain Relationships
      • Failure Modes
      • Why Simulation Misses CDC
    • Identifying Domains
  • Metastability and Synchronizers16
  • CDC Protocols and Handshakes16
  • Reconvergence and Gray Coding16
  • Reset Domain Crossing16
  • Architecture and Design Rules16
  • CDC Signoff Methodology24
  • RDC Signoff16
  • Debug and Case Studies11
  • CDC and RDC Interview Prep30
  • Capstone: Sign Off a Multi-clock Peripheral4
Loading lesson

‹Crossings and Failure Modes
  1. Topics
  2. CDC & RDC
  3. Clock Domains and Failure Modes
  4. Crossings and Failure Modes
  5. Why Simulation Misses CDC

Part 1 · Clock Domains and Failure Modes · All levels

Why Simulation Misses CDC

Zero-delay RTL looks clean, gate-level and random-skew runs still cannot prove safety, and what simulation can do.

On this page

    The most dangerous CDC sentence after "same frequency" is "but it passed simulation". Simulation is essential for CDC work and almost useless as CDC proof. This lesson draws the line.

    Zero-delay RTL simulation shows clean transfers

    Functional RTL simulation uses ideal clocks with no setup, hold, or delay: a signal change is visible to every sampler at once, and every flop captures a clean 0 or 1. Metastability cannot appear, skew cannot appear, and a pulse placed by the testbench lands exactly where the testbench put it. A crossing that is broken in silicon looks perfect here, because the failure physics is absent from the model.

    Gate-level and random-skew simulation still cannot prove safety

    Adding delays or randomising clock skew samples some relative phases on some runs. That finds easy bugs, which is worth doing, but it proves nothing: a design exercised at a thousand skews can still fail at the thousand-and-first, and a simulator resolves near-coincident edges deterministically while silicon resolves them statistically. Absence of failure in simulation is one data point, not a bound on the failure rate. Gate-level runs have a second gap: they model one timing corner, while the tape-out must survive all of them.

    Why structural and formal methods exist

    Method

    What it establishes

    What it does not do

    Structural analysis

    Every crossing is found and each has an approved scheme with its rules (no logic between synchroniser flops, one-bit-only, stable data, and similar checks)

    Prove the protocol correct under all timings

    Formal property checking

    The crossing protocol holds for every possible clock alignment and input sequence (no missed or duplicated events, no torn values)

    Model the analogue settling of a real flop

    Simulation

    The design behaves correctly when crossings resolve cleanly, and the protocol makes progress under traffic

    Prove anything about the cases it did not hit

    The three methods cover each other's blind spots: structure guarantees the synchroniser is present and wired legally, formal guarantees the protocol is correct for all timings, and simulation guarantees the surrounding logic actually works. Signoff needs all three; any one alone leaves a hole.

    What simulation CAN do

    • Check the protocol: handshakes complete, FIFOs never overflow or underflow, back-pressure propagates, all under traffic and stalls.

    • Exercise both directions and extreme ratios: fast-to-slow pulses, slow-to-fast holds, bursts, and resets during transfers.

    • Run metastability-aware models: a capture flop that resolves randomly to old or new when data changes inside a window (deterministic with a fixed seed or an explicit pattern, as in the RTL synchroniser lessons). A protocol that survives arbitrary resolutions is robust; one that needs lucky resolutions is broken. But the model validates the protocol, not the flop physics: it cannot give a failure rate.

    Common pitfall

    Quoting simulation coverage as CDC confidence: "we randomised skew over 10,000 runs with no failure". That bounds nothing, because the next skew is still untested. Report it as protocol testing, and point at the structural and formal results for the safety claim.

    Check yourself A gate-level run with randomised skew passes 50,000 transfers across an async FIFO. The designer declares the crossing safe. What is missing?

    Proof: the run sampled some timings at one corner and found no bug, which exercises the protocol but bounds nothing. Safety needs the structural result (correct Gray pointers, legal synchronisers) and ideally a formal proof of the full/empty logic, plus this simulation as behavioural evidence.

    Check yourself A handshake testbench uses a synchroniser model that resolves window hits randomly with a fixed seed, and the test passes. What exactly did that prove?

    That the handshake protocol tolerates either resolution of each crossing, i.e. the protocol is robust. It did not prove anything about the real flop's likelihood of hitting the window or settling in time; that is the structural and electrical argument.

    Related topics

    • RTL: CDC verification

    • Failure Modes

    • Glossary

    Previous

    10 / 179

    Next: Identifying Domains

    Up next

    Up nextIdentifying Domains

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • What Is a Crossing?
    • Domain Relationships