Clock Domain Crossing: The Digital Design Interview Topic That Trips Up Even Experienced Candidates

Ask a room of digital design candidates to draw a two-flop synchronizer and almost everyone can do it. Ask them why a two-flop synchronizer is fine for a single control bit but dangerous for a multi-bit bus, and the room thins out fast. Clock domain crossing (CDC) is one of the most reliably asked topics in digital design and SoC interviews, precisely because it's easy to memorize the standard diagram and much harder to reason about the failure modes it's protecting against.

For related technical deep-dives, see our static timing analysis interview questions and RTL design interview questions guides.

Why do interviewers keep asking about CDC?

Almost every modern SoC has multiple asynchronous clock domains: a high-speed core clock, a slower peripheral bus, an always-on domain for low-power modes, sometimes an entirely separate reference clock for I/O. Any signal that crosses between those domains without proper synchronization is a latent bug that may not show up in simulation at all, because simulators typically don't model the metastable window realistically. That gap between "passes simulation" and "fails in silicon" is exactly why interviewers lean on CDC questions. It tests whether you understand a class of bug that your verification environment might not catch for you.

Which CDC questions separate strong candidates?

• "Explain metastability, precisely." Not just "the flip-flop output is unstable": interviewers want to hear that a flip-flop's setup/hold window was violated, that the output can hover at an invalid voltage level for longer than a clock period, and that it eventually resolves to a valid 0 or 1, but not deterministically to the "correct" value.
• "Why does a two-flop synchronizer work for one bit but not for a multi-bit bus?" The answer they're listening for is bit-slip: each bit could resolve after a different number of clock cycles, so a multi-bit value crossing domains can transiently be an invalid combination of old and new bits. The fix is either a Gray-coded pointer (common in FIFO design, where only one bit changes at a time) or a handshake protocol that only samples the full bus once the sender confirms it's stable.
• "How do you verify CDC? Can simulation catch it?" This is where candidates who've only worked in fully-verified group environments sometimes stumble. The honest answer is that static CDC tools (Spyglass CDC, Questa CDC) that structurally analyze the design for missing or incorrect synchronizers are the real workhorse here, because simulation alone can't exhaustively exercise every possible arrival-time relationship between asynchronous clocks.
• "What's the difference between a false path and a multicycle path in the context of CDC?" A common trap: candidates conflate CDC constraints with timing exceptions. A synchronizer's first stage is typically constrained as a false path for setup analysis (since the two clocks are asynchronous, there's no meaningful setup relationship to check) but often still needs a max-delay or specific hold constraint to bound the metastability window, not simply "ignore timing here."
• "When would you use a handshake instead of a synchronizer, and what can go wrong with a naive handshake?" Interviewers are checking whether you know handshakes have their own failure modes: a request pulse that's too narrow to be reliably captured by the receiving domain, or an acknowledge signal that itself needs synchronizing back, creating a second CDC problem you have to solve correctly.

What does a strong CDC answer sound like?

The candidates who do well here don't just recite the synchronizer diagram. They narrate the failure mode first ("here's what breaks if you don't do this") and then explain the fix as the direct answer to that failure mode. That ordering signals you understand the problem, not just the standard solution taught in every RTL course. It's also worth being ready to talk about a CDC bug you've actually debugged, even a minor one, since "I read about this" and "I've chased this in a lab with a logic analyzer" read very differently to an interviewer.

What this means for your prep

If CDC feels shaky, don't just re-read the synchronizer circuit. Work through why each failure mode exists first, then treat the standard fixes as answers to problems you already understand. Interviewers in this space are consistently better at detecting memorized answers than candidates expect, and CDC is one of the easiest topics to expose that gap in, precisely because the follow-up questions are so easy to generate from "why does that work."

FAQ

Q: Why is a two-flop synchronizer fine for one bit but not for a multi-bit bus? Each bit could resolve after a different number of clock cycles, so a multi-bit value can transiently be an invalid combination of old and new bits. The fix is a Gray-coded pointer or a handshake that samples the bus only once the sender confirms it is stable.

Q: Can simulation catch CDC bugs? Not reliably. Simulators typically do not model the metastable window realistically, so static CDC tools like Spyglass CDC and Questa CDC, which analyze the design for missing or incorrect synchronizers, are the real workhorse.

Q: What goes wrong with a naive handshake? A request pulse can be too narrow to be reliably captured by the receiving domain. The acknowledge signal also needs synchronizing back, which creates a second CDC problem you have to solve correctly.

Q: How should I prepare if CDC feels shaky? Work through why each failure mode exists first, then treat the standard fixes as answers to problems you already understand. Do not just re-read the synchronizer circuit.