Metastability & Why Simulators Can't Model It

Chapter 9 · Section 9.2 · CDC & Asynchronous Behaviour in GLS

Project thread — the mini-SoC's crossings rely on synchronizers (9.3) whose whole purpose is to tolerate metastability. This lesson is why simulation can't verify that tolerance — MTBF does.

1. Why Should I Learn This?

The single most misunderstood point in CDC-and-GLS is what a crossing X means.

• Metastability is analog and unpredictable — real physics.
• Simulators can't model it — they inject X (risk flag) or resolve deterministically.
• The X marks risk, not proof; MTBF + static CDC verify survival.

Getting this right prevents both false alarms and false confidence.

2. Real Silicon Story — the synchronizer "proven" by a clean simulation

A team ran their synchronizer in simulation, saw no X (the tool resolved crossings deterministically), and declared it metastability-proof. In silicon, a rare metastable event propagated and caused an intermittent failure.

The simulation had resolved every crossing to a definite value — it cannot model the analog metastable state, so absence of X proved nothing about metastability. The synchronizer's real defence is statistical (MTBF), and its depth/timing — verified by MTBF analysis, not by a clean sim.

Lesson: a simulator cannot model metastability. Neither an X nor its absence proves anything about metastability survival — that is MTBF and static CDC.

3. Concept — the phenomenon and the modelling gap

The phenomenon (analog, real):

• A flop samples data changing in its aperture window → enters a metastable (balanced, undefined) state.
• It resolves to 0 or 1 — unpredictable value — after an unpredictable time (could exceed a clock cycle).
• Governed by electrical physics; characterised statistically (MTBF).

Why simulators can't model it:

• Digital simulation is discrete (0/1/X/Z) and event-driven — it has no analog resolution model.
• Two behaviours, neither faithful:
  • Inject X — a timing-check violation drives the flop X (8.5): flags the risk, but X is not the analog state, and it may over- or under-propagate (pessimism, Ch6).
  • Resolve deterministically — event ordering picks 0 or 1: hides the risk entirely.
• Metastability-injection/randomization modes model the risk statistically (random resolution) — a model of the risk, still not the physics.

How to interpret the X (accuracy):

• A crossing X = metastability risk flagged — investigate the structure (is it synchronized?).
• Absence of X (deterministic resolve) = nothing proven about metastability.
• Survival is verified by MTBF (probability math) and static CDC (structure) — not GLS.

4. Mental Model — a coin landing on its edge

Metastability is a coin flipped so gently it lands on its edge — balanced, undecided.

• In reality, it wobbles for an unpredictable time, then falls heads or tails — you can't say which or when (analog physics).
• A digital simulator can't show a coin on its edge. It either paints it grey (X — "undecided", a risk flag) or forces it flat to heads/tails (deterministic resolve — pretending it decided instantly).
• Neither is the wobble. To know how often the coin lands on edge and how long it wobbles, you need the physics of coins and tables (MTBF), not a photo (simulation).

The grey coin (X) says "it could land on edge here" — a risk flag, not a measurement of the wobble.

5. Working Example — X as a risk flag, not proof

The crossing flop and the two simulator behaviours (representative):

// Crossing flop sampling async data — REPRESENTATIVE
DFFRX1 u_meta (.D(async_sig), .CK(clk_b), .RN(rst_n), .Q(sync1));
//  async_sig changes in u_meta's aperture window:
//    behaviour A: timing check fires -> notifier -> sync1 = X   (flags the RISK, 8.5)
//    behaviour B: event ordering resolves sync1 = 0 or 1        (HIDES the risk)
//  NEITHER is the analog metastable state. The X (A) is a risk flag, not a measurement.

# Interpreting the crossing (tool-neutral):
#   sync1 = X   -> metastability RISK flagged -> check the STRUCTURE (synchronized? 9.3)
#   sync1 = 0/1 -> deterministic resolve -> proves NOTHING about metastability
#   survival?   -> MTBF analysis (probability) + static CDC (structure) -- NOT GLS
#   metastability-injection mode -> models risk STATISTICALLY (a model, not the physics)

Practical context (representative, tool-neutral):

# What verifies metastability survival (tool-neutral) — NOT GLS:
#   MTBF analysis: mean-time-between-failures math (settling time vs available time, freq, rate)
#   static CDC:    every crossing has a proper synchronizer (structure)
#   GLS role:      flags RISK (X) + reveals real-delay behaviour (9.1) -- COMPLEMENT
#   never conclude "no X in sim -> metastability-safe" (deterministic resolve hides it)

The two simulator behaviours vs the (unmodellable) reality, as a real waveform:

6. Debugging Session — reading a crossing X as metastability proof

7. Common Mistakes

• Reading a crossing X as a confirmed metastability bug. It's a risk flag (possibly pessimistic).
• Reading absence of X as metastability-safe. Deterministic resolve hides the risk.
• Expecting GLS to reproduce metastability. No analog model exists in digital sim.
• Skipping MTBF/static CDC because "sim was clean."
• Treating injection modes as the physics. They're a statistical model of the risk.

8. Industry Best Practices

• Verify metastability survival with MTBF (probability) and static CDC (structure).
• Read a crossing X as a risk flag — check the structure, don't over-conclude.
• Never infer safety from absence of X (deterministic resolve).
• Use GLS for real-delay CDC behaviour (9.1), not metastability proof.
• Treat injection modes as statistical models of the risk.

Senior Engineer Thinking

• Beginner: "No X in simulation, so the synchronizer handles metastability."
• Senior: "The sim can't model metastability — it just resolved a value. Survival is MTBF and static CDC. A crossing X would only flag the risk, not measure it."

The senior never infers metastability behaviour from a simulator, using MTBF and static CDC instead.

Silicon Impact

Metastability is the hardest CDC failure to catch because it is statistical and analog — and the deadliest misconception is that simulation can verify it. A team that trusts a clean sim (deterministic resolve) as "metastability-safe" ships a design whose synchronizer depth was never actually verified, and a rare metastable event propagates in silicon as an intermittent, un-reproducible failure (the classic CDC field bug). The correct methodology is layered: MTBF bounds the probability (sets synchronizer depth), static CDC ensures structure, and GLS flags the risk (X) and reveals real-delay behaviour (9.1) — but none of GLS proves metastability survival. Understanding why the simulator can't model it is what keeps a team from the false confidence that ships CDC bugs.

Engineering Checklist

• Read a crossing X as a metastability risk flag (check structure), not proof.
• Did not infer safety from absence of X (deterministic resolve).
• Verified survival with MTBF and static CDC (not GLS).
• Used GLS for real-delay CDC behaviour (9.1), not metastability.
• Treated any injection mode as a statistical model of the risk.

Try Yourself

1. Drive async_sig to change inside a crossing flop's aperture window; run once with timing checks on (see X — risk flag) and once with them off (deterministic resolve — no X).
2. Observe: the same physical scenario shows X or a definite value depending only on the simulation setup — proving neither is the phenomenon.
3. Change: reason about MTBF — what synchronizer depth does the settling-time math require?
4. Expect: you can't get that answer from the waveform — only from MTBF/static CDC. Internalize the modelling gap.

Any free Verilog simulator shows both behaviours (checks on/off); MTBF is an analysis, not a simulation. No paid tool required.

Interview Perspective

• Weak: "If there's no X, metastability is handled."
• Good: "Simulators can't model metastability; they inject X to flag the risk or resolve deterministically."
• Senior: "Metastability is analog — unpredictable value and settling time — with no representation in digital simulation. A crossing X flags the risk (and may be pessimistic); absence of X (deterministic resolve) hides it. Survival is verified by MTBF (probability) and static CDC (structure), never by GLS. GLS's job is flagging risk and revealing real-delay behaviour."

9. Interview / Review Questions

10. Key Takeaways

• Metastability is a real, analog phenomenon: a flop sampling data in its aperture window resolves to an unpredictable value after an unpredictable time (physics, characterised by MTBF).
• Digital simulators cannot model it — they either inject X (via a timing-check violation → notifier, 8.5) to flag the risk, or resolve deterministically to 0/1 (hiding the risk). Neither reproduces the analog state.
• A crossing X marks the metastability risk (check the structure) — not a confirmed event; absence of X (deterministic resolve) proves nothing.
• Metastability survival is verified by MTBF (probability) and static CDC (structure) — not by GLS; metastability-injection modes are a statistical model of the risk.
• GLS's CDC role stays as in 9.1: flag risk + reveal real-delay behaviour, complementary to static CDC/MTBF (dynamic; STA signs off timing, 0.3). Next: 9.3 — synchronisers under real delays.

Quick Revision

Metastability = analog, unpredictable value + time (physics; MTBF math). Simulators CAN'T model it — they inject X (risk flag, 8.5) or resolve 0/1 (hides risk); neither is the phenomenon. A crossing X = risk flag (check structure), absence proves nothing. Survival verified by MTBF + static CDC, NOT GLS. Injection modes = statistical model of the risk. Next: 9.3 — synchronisers under real delays.