Day 28: Metastability and why synchronizers exist
The unavoidable failure mode
If a flip-flop's data changes right at the clock edge — violating setup or hold — its output can enter a metastable state: hovering between 0 and 1, or oscillating, for an unpredictable time before resolving to a random-but-valid level. This isn't a bug you can design out; it's physics. Any time a signal from *another clock domain* or an *asynchronous input* (a button, an off-chip line) meets a flip-flop, metastability is possible.
You can't eliminate it, only make it *vanishingly rare*. A two-flip-flop synchronizer samples the async signal with one flip-flop, then feeds its (possibly metastable) output into a second flip-flop a full clock later — giving the first almost a whole period to resolve. The residual failure rate is captured by MTBF (mean time between failures), which grows exponentially with the settling time you allow.
This returns as CDC — the interview favorite
Every clock-domain crossing in Stage 2 (async FIFO, control-signal synchronizers) and every real-world button in Stage 4 relies on exactly this synchronizer. 'Why do CDC bugs pass simulation but fail on hardware?' and 'design a synchronizer' are near-guaranteed interview questions — and the answer is this page.
Key terms
- Metastability
- An indeterminate flip-flop state (between 0 and 1) caused by a setup/hold violation, resolving after a random time.
- Resolution time
- How long a flip-flop takes to settle out of metastability; longer allowance → far lower failure rate.
- MTBF
- Mean time between (metastability) failures; increases exponentially with allowed settling time.
- Two-flip-flop synchronizer
- Two cascaded flip-flops that give a crossing signal ~a full clock to resolve before use.
- Clock-domain crossing (CDC)
- A signal passing between two unrelated clocks — where synchronizers are mandatory.
Before moving on, you should be able to
Why does a two-flip-flop synchronizer reduce the chance of a metastability failure?
