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
  • Metastability and Synchronizers16
    • MTBF & Synchronizer Math
      • Metastability Mechanism
      • Resolution Time and MTBF
      • Worked MTBF Example
      • Two or Three Stages
    • Two-Flop Synchronizers in Practice
    • Multi-bit CDC Hazards
    • Synchronizer Selection Guide
  • 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

‹MTBF & Synchronizer Math
  1. Topics
  2. CDC & RDC
  3. Metastability and Synchronizers
  4. MTBF & Synchronizer Math
  5. Metastability Mechanism

Part 2 · Metastability and Synchronizers · All levels

Metastability Mechanism

The setup/hold window, what happens inside the flop, and why resolution is probabilistic.

On this page

    A flip-flop needs its data input stable for a setup time before the clock edge and a hold time after it. A signal from another clock domain can change at any moment, so sooner or later it changes inside that window. That event is the root of every clock-domain bug.

    What happens inside the flop

    A typical flop is two latches in series with regenerative feedback: once the latches start deciding, positive feedback pushes the internal nodes apart toward a clean 0 or 1. If the input changes inside the window, the latches start from a nearly balanced state with almost no push in either direction.

    The output then hovers between 0 and 1 instead of switching crisply. Stronger imbalance resolves faster; a near-perfect balance resolves slowly. The flop always resolves eventually in a real circuit, but the delay is unbounded in theory and the final value can be the old one or the new one.

    Input timing

    Flop behaviour

    Stable through the window

    Normal capture of the settled value.

    Changes well outside the window

    Normal capture; the change belongs to the next or previous cycle.

    Changes inside the window

    The output may hover, resolve late, and settle to either the old or the new value.

    Why it is probabilistic

    The designer controls neither the phase between the two clocks nor the exact picosecond the source changes, so each crossing samples a random point of the window. Whether a given edge lands inside it, how deep inside, and which way the flop resolves are all effectively random.

    This is why simulation cannot prove a crossing safe: a simulator evaluates the flop model deterministically, while silicon rolls the dice on every edge. Signoff handles metastability structurally, with synchronisers, not by simulating harder.

    Common pitfall

    Do not picture metastability as the output stuck halfway forever. The practical failure is late resolution: downstream gates sample the hovering output at different moments and disagree, so one unresolved flop corrupts several destinations at once.

    Interview

    “What is metastability?” Name the window, describe the balanced internal state resolving late to either value, and finish with the consequence: it cannot be eliminated, only given time to resolve, which is what a synchroniser buys.

    Check yourself A flop samples an input that changed 1 ns before the clock edge, with a setup time of 0.1 ns. Is this a metastability risk?

    No. The input was stable through the whole window, so the flop captures normally. The risk is only a change inside the setup/hold window.

    Check yourself Two gates read the same synchroniser first flop while it is still hovering. Why can they disagree?

    Each gate has its own switching threshold and timing, so one can interpret the hovering level as 0 while the other sees 1. That disagreement is the failure, and it is why only the second flop's output is ever used.

    Related topics

    • Resolution Time and MTBF

    • RTL: Metastability and Synchronisation

    Previous

    15 / 179

    Next: Resolution Time and MTBF

    Up next

    Up nextResolution Time and MTBF

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Worked MTBF Example
    • Two or Three Stages