What GLS Reveals About Clock-Domain Crossings

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

Project thread — the counter/FSM lived in one clock domain; the mini-SoC has several (CPU, bus, peripherals) that must cross safely. This chapter is what GLS shows about those crossings; 9.5 catches a real-delay CDC glitch.

1. Why Should I Learn This?

Using GLS for CDC means knowing exactly what it can and cannot answer — misuse it and you draw wrong conclusions.

• GLS reveals real-delay CDC behaviour (glitches, synchronizer timing, gray-code, reconvergence).
• GLS does not reveal actual metastability (9.2), and is not a CDC signoff tool.
• Static CDC + MTBF verify crossings; GLS complements them.

This frames the chapter (9.2 metastability, 9.3 synchronizers, 9.4 async FIFO, 9.5 the glitch).

2. Real Silicon Story — the CDC glitch static analysis missed

A design passed static CDC — every crossing was structurally synchronized. But it failed intermittently in silicon.

The bug was a combinational glitch on a multi-bit signal that reconverged before a crossing — a real-delay phenomenon that structural CDC (which checks topology, not timing) didn't flag. GLS with real delays did show it: the glitch appeared on the crossing signal and corrupted the captured value. Static CDC and GLS were complementary — each caught what the other couldn't.

Lesson: GLS is not a substitute for static CDC, but it reveals real-delay CDC behaviour (glitches, reconvergence) that structural analysis can miss. Use both.

3. Concept — GLS's role in CDC

What a CDC is:

• A signal crossing between two asynchronous clock domains (unrelated clocks) — the receiving domain can sample it any time, including mid-transition.

What GLS reveals (with real delays):

• Synchronizer behaviour — a 2-flop synchronizer resolving under real clk-to-Q/setup (9.3).
• Crossing glitches — combinational glitches on signals that cross domains (3.5 + reconvergence).
• Control-signal timing — enables/handshakes crossing domains.
• Gray-code correctness — single-bit-change pointers (9.4).
• Reconvergence — multiple synchronized bits recombining.

What GLS does not reveal:

• Actual metastability — the analog, unpredictable resolution (9.2). GLS models the risk as X, not the phenomenon.

GLS's role (accuracy):

• Not a CDC verification tool. Static CDC checks structure (every crossing synchronized); MTBF does the metastability math.
• GLS complements them — real-delay behaviour static tools miss.
• Timing checks on async crossings are meaningless (8.4) → disabled per-path to avoid false X.

4. Mental Model — GLS is a high-speed camera, not the physics lab

Think of verifying a CDC as studying a fast, risky handoff.

• Static CDC is the blueprint review — confirms every handoff has a catcher (synchronizer). Structural, exhaustive, timing-blind.
• MTBF analysis is the physics lab — computes the probability the catcher fumbles (metastability math).
• GLS is a high-speed camera — it films the handoff with real delays, catching visible mishaps (a glitch, a mistimed control) — but it can't film the quantum uncertainty of the catch itself (metastability).

Use the camera for what it sees (real-delay behaviour); use the blueprint and physics lab for structure and metastability. Don't ask the camera to prove the physics.

5. Working Example — a crossing, and what GLS shows

A CDC and its synchronizer (representative):

// Signal crossing from domain A to async domain B via a 2-flop synchronizer — REPRESENTATIVE
// Domain A:
DFFRX1 u_a  (.D(data_a), .CK(clk_a), .RN(rst_n), .Q(sig_a));       // launched in A
// Domain B (async): 2-flop synchronizer (9.3)
DFFRX1 u_s1 (.D(sig_a),  .CK(clk_b), .RN(rst_n), .Q(sync1));       // may go metastable -> GLS: X
DFFRX1 u_s2 (.D(sync1),  .CK(clk_b), .RN(rst_n), .Q(sig_b));       // resolves -> used in B
// Timing checks on u_s1's D (the async crossing) are DISABLED per-path (meaningless, 8.4).

# What GLS shows here (tool-neutral):
#   sig_a crosses to clk_b -> u_s1 may sample mid-transition -> GLS models RISK as X (not real metastability)
#   the X resolves through u_s2 (synchronizer working structurally under real delays)
#   GLS REVEALS: glitches on sig_a's combinational source, control timing, gray-code (9.4), reconvergence
#   GLS does NOT prove metastability is safe -> that's MTBF + static CDC

Practical context (representative, tool-neutral):

# CDC verification stack (tool-neutral) — GLS is ONE layer:
#   static CDC:  every crossing synchronized? (structural, exhaustive) -> SIGNOFF for structure
#   MTBF:        metastability probability math -> SIGNOFF for metastability
#   GLS:         real-delay behaviour (glitches, reconvergence, control timing) -> COMPLEMENT
#   note: DISABLE timing checks on async crossings (meaningless, 8.4) -> avoid false X

A crossing and its synchronizer resolving, as a real waveform:

6. Debugging Session — treating GLS as CDC signoff (it isn't)

7. Common Mistakes

• Treating a clean GLS run as CDC signoff. GLS can't model metastability or verify all crossings.
• Dismissing a GLS CDC glitch because static CDC passed. Static checks structure, not real-delay timing.
• Leaving timing checks on async crossings. They're meaningless → false X (8.4).
• Expecting GLS to reproduce metastability. It models the risk as X, not the phenomenon (9.2).
• Using only one tool. Static CDC, MTBF, and GLS are complementary.

8. Industry Best Practices

• Use static CDC for structural signoff (every crossing synchronized).
• Use MTBF analysis for metastability probability.
• Use GLS to reveal real-delay behaviour — glitches, reconvergence, control timing.
• Disable timing checks on async crossings (per-path) to avoid false X.
• Investigate GLS-caught CDC glitches — they're real-delay effects static misses.

Senior Engineer Thinking

• Beginner: "GLS is clean, so the CDC is verified."
• Senior: "GLS can't model metastability or verify crossings — that's static CDC and MTBF. But GLS does reveal real-delay glitches and reconvergence static misses. I use all three, each for its role, and I disable checks on async crossings."

The senior places GLS as a complement — revealing real-delay CDC behaviour — not as CDC signoff.

Silicon Impact

CDC bugs are among the most feared silicon failures — intermittent, temperature/voltage-sensitive, and nearly impossible to reproduce. No single tool catches them all: static CDC ensures structure, MTBF bounds metastability, and GLS catches real-delay effects (glitches, reconvergence, control-timing) that structural analysis is blind to. Mis-scoping GLS is dangerous both ways: over-trusting it (as CDC signoff) skips static CDC/MTBF and lets a structural or metastability bug through; under-trusting it (dismissing its real-delay glitch findings) lets a real reconvergence bug ship. Using GLS for the right CDC questions — and only those — is what makes the layered CDC methodology actually protective.

Engineering Checklist

• Used static CDC for structural signoff (every crossing synchronized).
• Used MTBF for metastability.
• Used GLS to reveal real-delay behaviour (glitches, reconvergence, control timing).
• Disabled timing checks on async crossings (avoid false X, 8.4).
• Investigated GLS-caught CDC glitches; did not treat GLS as CDC signoff.

Try Yourself

1. Build a signal crossing from clk_a to an async clk_b through a 2-flop synchronizer.
2. Observe: with real delays, the first synchronizer flop may show X (risk), resolving through the second (GLS reveals the crossing behaviour).
3. Change: add a combinational glitch on the crossing signal's source and re-run.
4. Expect: GLS shows the glitch propagating across the crossing — a real-delay effect static CDC (topology-only) would miss. Note: GLS still isn't proving metastability safety (MTBF does).

Any free Verilog simulator with two async clocks reproduces the crossing behaviour. No paid tool required.

Interview Perspective

• Weak: "GLS verifies the CDC."
• Good: "GLS reveals real-delay CDC behaviour — synchronizer resolution, glitches — but it can't model metastability."
• Senior: "GLS is complementary to static CDC (structure) and MTBF (metastability math): it reveals real-delay effects — crossing glitches, reconvergence, control timing — those tools miss, but it's not CDC signoff and can't reproduce metastability. I disable timing checks on async crossings and investigate GLS-caught glitches as real."

9. Interview / Review Questions

10. Key Takeaways

• A CDC is a signal crossing between two asynchronous clock domains; the receiver can sample it any time, including mid-transition.
• GLS reveals (with real delays): synchronizer behaviour (9.3), crossing glitches, control-signal timing, gray-code correctness (9.4), and reconvergence.
• GLS does not reveal actual metastability — it models the risk as X (9.2), not the analog phenomenon.
• GLS is not a CDC verification tool — static CDC (structure) and MTBF (metastability math) verify crossings; GLS complements them by catching real-delay effects they miss.
• Disable timing checks on async crossings (meaningless → false X, 8.4); investigate GLS-caught CDC glitches as real. Next: 9.2 — metastability & why simulators can't model it.

Quick Revision

CDC = signal between two async clock domains. GLS reveals (real delays): synchronizer behaviour, crossing glitches, control timing, gray-code, reconvergence. GLS does NOT reveal metastability (models risk as X, 9.2) and is NOT CDC signoff — static CDC (structure) + MTBF (math) verify crossings; GLS complements. Disable timing checks on async crossings (8.4). Investigate GLS-caught glitches as real. Next: 9.2 — metastability & simulators.