Q1.What is a clock domain crossing (CDC), and why is it dangerous if left unprotected?
A CDC is any signal that passes from one clock domain into a different, asynchronous clock domain. It's dangerous because the receiving flip-flop has no way to know when the source data is stable relative to its own clock edge — if the signal changes too close to the sampling edge, the receiving flop can go metastable: its output hovers at an invalid voltage for an unpredictable amount of time before settling to a 0 or a 1. Because RTL simulators are zero-delay, this failure mode never shows up in ordinary functional simulation, which is exactly why CDC bugs are one of the most common causes of real first-silicon failures rather than being caught pre-tapeout.
Q2.What is metastability, physically, and how long can it last?
Metastability occurs when a flip-flop's input changes within its setup/hold window around the clock edge, so the internal cross-coupled latch structure is pushed into a balanced, in-between voltage state instead of cleanly resolving to a rail. Physically it's like a ball balanced exactly on top of a hill — it will eventually roll to one side or the other, but the time it takes is unbounded and follows an exponential decay distribution. In practice it usually resolves within a fraction of a nanosecond, but there is no hard upper bound, which is why synchronizer design is about reducing the probability (MTBF) of a metastable value escaping downstream, not eliminating it entirely.
Q3.How does a 2-flop synchronizer work, and why not just use one flip-flop?
A 2-flop synchronizer places two flip-flops in series, both clocked by the destination clock. The first flop absorbs the metastability risk — it may go metastable, but it's given a full clock period to resolve to a valid 0 or 1 before the second flop samples it. A single flop gives no such settling time, so the metastable value (or its aftereffects) could propagate directly into downstream logic. A 3-flop synchronizer is sometimes used at very high frequencies or when very low MTBF risk is required, trading one extra cycle of latency for a much lower probability of a residual metastability event escaping.
Q4.Why can't you just use a 2-flop synchronizer on a multi-bit bus?
A 2-flop synchronizer only guarantees that a single bit resolves to a valid, stable value — it says nothing about which bits change together. If several bits of a multi-bit value change on the same source clock edge, the synchronizers on each bit can independently resolve at slightly different times, so the destination domain can briefly sample a combination of bits that never actually existed on the source side (e.g. 3'b011 flipping to 3'b100 gets sampled as 3'b111 or 3'b000). This is why multi-bit values either need to be gray-coded so only one bit changes at a time, or transferred via a full handshake/FIFO protocol instead of a plain synchronizer.
Q5.Explain how gray coding solves the async FIFO pointer problem.
An async FIFO's write pointer increments in the fast write-clock domain and has to be compared against the slow read-clock domain (and vice versa for the read pointer) to compute full/empty flags safely. If the pointer were kept in plain binary, multiple bits could change on a single increment (e.g. 3 → 4 flips three bits), which reintroduces the multi-bit CDC problem. Gray code guarantees that only a single bit changes between any two consecutive values, so a bit-wise 2-flop synchronizer on each pointer bit is sufficient — even if the destination domain samples the pointer mid-transition, it only ever sees either the old value or the new value, never an invalid combination.
Q6.What's the difference between synchronous and asynchronous FIFOs, and when is each appropriate?
A synchronous FIFO has both its read and write ports clocked by the same clock, so full/empty flag generation is trivial pointer comparison with no CDC concerns at all — used for simple buffering or pipeline decoupling within one clock domain. An asynchronous FIFO has independent read and write clocks (e.g. a fast core writing into a slower peripheral, or vice versa) and needs gray-coded pointers plus cross-domain synchronization of those pointers to safely generate full/empty flags without either overflowing or underflowing. Asynchronous FIFOs are the standard building block anywhere two genuinely unrelated clock domains need to exchange a stream of data.
Q7.FIFO sizing: write clock is 100MHz, read clock is 50MHz, and the write side bursts 120 back-to-back writes. How deep does the FIFO need to be?
Over the burst, the write side pushes 120 words. In the time it takes to write 120 words at 100MHz (1.2μs), the read side at half the frequency can only pop roughly 60 words. Worst case, the FIFO needs to absorb the difference — about 60 words of headroom — so a depth in the 64-128 range (rounded to a convenient power of two, accounting for synchronization latency on the pointers) is the right ballpark; the exact number depends on how continuous the read side is.
Q8.Explain pulse/toggle synchronization for a single-cycle enable signal crossing to a slower clock domain.
A one-cycle pulse in a fast domain can be missed entirely by a slower destination clock. The fix is to convert the pulse into a toggle (flip a flop's state instead of pulsing it), synchronize the toggle bit with a standard 2-flop synchronizer, then detect the edge of the synchronized toggle in the destination domain to regenerate a clean single-cycle pulse there.
Q9.What is a req/ack handshake and when would you use it instead of a plain synchronizer?
A req/ack handshake is used when a full multi-bit value (not just gray-coded pointers) needs to cross domains safely, or when the source side needs positive confirmation that data was received. The source asserts a request signal alongside stable data; that request is synchronized into the destination domain via a 2-flop synchronizer; once the destination domain sees the synchronized request, it processes the data (which has been stable and unchanging the whole time) and asserts an acknowledge back, which is itself synchronized back into the source domain. Because the data bus is held static throughout the entire handshake, there's no multi-bit CDC hazard, at the cost of extra latency compared to a free-running gray-coded FIFO.
Q10.What does MTBF mean in the context of CDC synchronizers, and what improves it?
MTBF (Mean Time Between Failures) here is the expected time between a metastable event actually escaping the synchronizer and corrupting downstream logic. It's improved by adding more synchronizer stages (each additional flop roughly squares the settling probability), using flip-flops with a shorter metastability resolution time constant (tau) in the standard cell library, and running the synchronizer as fast as reasonably possible relative to the source clock so there's more settling time available per stage. MTBF calculations are a standard deliverable in CDC signoff reports for any multi-clock ASIC.
Q11.What is Reset Domain Crossing (RDC), and how is it different from ordinary CDC?
RDC is the reset-signal equivalent of CDC: when an asynchronous reset is generated in one domain but deasserts and needs to be observed correctly in another domain, its release edge can itself cause metastability or cause flops in the destination domain to come out of reset in different cycles relative to each other. It's handled with its own synchronizer on the reset release, and sign-off tools check it as a separate category from data-path CDC.
Q12.How do you handle an asynchronous reset that needs to be safely released?
The standard pattern is 'assert asynchronously, release synchronously.' The reset can be asserted immediately and asynchronously across the whole chip since forcing everything into a known state is always safe. But de-asserting (releasing) the reset must be synchronized to each destination clock domain — usually via a small reset synchronizer (an async-set, sync-clear flop chain) — because if reset releases asynchronously, different flops in the same domain could come out of reset on different edges, violating the assumption that the whole domain starts from a known, aligned state. CDC tools flag missing reset release synchronization as W_ASYNC_RST_FLOPS.
Q13.Two clocks are muxed together with a control signal choosing which one drives downstream logic. What's the risk, and how do you handle the switch safely?
Switching the select line asynchronously can create a runt pulse or a glitch right at the mux output if the switch happens near either clock's edge, which can violate min-pulse-width requirements downstream or even double-clock a flop. The standard fix is a glitch-free clock mux structure that only switches when both the outgoing and incoming clocks are at a safe (usually low) phase, gated through extra flops in each clock's own domain.
Q14.What is the W_MASYNC violation category in CDC static analysis tools, and why is it hard to catch?
W_MASYNC flags a case where two or more signals, each individually passed through its own correct synchronizer, reconverge into the same downstream combinational logic cone. Each signal on its own is 'CDC safe' — but because they were synchronized independently on unrelated clock edges, the combination the downstream logic sees can momentarily be a state that was never intended to occur together on the source side (a classic reconvergence/loss-of-correlation bug). It's hard to catch because no single signal looks wrong in isolation; a tool has to trace relationships across a whole group of signals, and simulation almost never happens to hit the narrow timing window where the bug manifests.
Q15.What does the W_GLITCH violation mean, and why does combinational logic before a synchronizer matter?
W_GLITCH flags combinational logic — a gate, a mux, an OR of two sources — inserted between the source flip-flop and the first stage of a synchronizer. Combinational glitches (momentary, unintended transitions caused by unequal gate delays along different paths) are harmless within a single clock domain because they settle out before the next capturing edge. But if a synchronizer samples a signal asynchronously, it has no guarantee it will only sample after the glitch has settled — it could latch the glitch itself as if it were real data. The fix is a direct register-to-register connection into the synchronizer with no combinational logic in between.
Q16.What's the difference between a DATA and a CNTL classification in CDC signoff tools like Meridian CDC or SpyGlass CDC?
These tools classify every signal crossing a clock domain boundary. CNTL means the signal correctly reaches its destination through a recognized synchronization structure (a proper 2/3-flop synchronizer, a handshake, gray-coded pointers) — it's treated as safely handled. DATA means a signal crosses the boundary and reaches a destination flop with no recognized synchronization structure protecting it — a serious structural violation, because an unprotected multi-bit or even single-bit path has no guarantee against metastability propagation. Sorting every crossing into these buckets is the first pass of any CDC signoff run, before deeper checks like W_MASYNC or W_GLITCH are applied.
Q17.Why can functional RTL simulation completely miss a CDC bug that shows up in real silicon?
RTL simulators use idealized, zero-delay clock edges and deterministic event scheduling — a signal changing a picosecond before or after a clock edge behaves identically to changing far away from it, so metastability (a fundamentally analog, timing-dependent phenomenon) simply cannot be modeled. In real silicon, clock edges and data transitions have jitter and skew that vary chip to chip and even cycle to cycle, so a synchronizer can appear to work perfectly across millions of simulation cycles and still fail intermittently on actual hardware. This gap is exactly why CDC verification uses dedicated static/structural tools rather than relying on simulation coverage.
Q18.How would you debug a chip that fails intermittently in the lab but passes all simulation and even most silicon units?
This pattern — intermittent, unit-to-unit variable, simulation-clean failures — is the classic signature of a CDC/metastability bug rather than a logic bug. The debug approach is to review the design for any signal crossing between asynchronous or even just non-integer-related clock domains, check whether it went through CDC static signoff (and if any violations were waived without full justification), and look specifically at signals that reconverge from multiple synchronizers (W_MASYNC-style bugs) since those are the hardest for a first pass of CDC tools or ad-hoc review to catch. Correlating the failure rate against voltage/temperature/frequency corners can also help, since metastability resolution time is sensitive to exactly those conditions.
Q19.What's the difference in CDC risk between two clocks with an integer/rational relationship versus two truly asynchronous clocks?
If two clocks are related by a fixed, known integer or rational ratio and phase relationship (e.g. one clock is exactly 2x the other, in phase), the timing relationship between their edges is deterministic and can, in principle, be handled with plain synchronous timing analysis and careful multicycle constraints rather than full CDC synchronizers — though many teams still synchronize defensively. Truly asynchronous clocks (e.g. two independent PLLs, or a clock sourced from an external, uncorrelated oscillator) have no fixed edge relationship at all — the phase between them drifts continuously — so there's no way to reason about their relationship statically, and a full synchronizer or handshake is mandatory.