10 Clock Domain Crossing (CDC) Interview Questions and Answers

• When a flop's setup or hold time is violated (for example by an asynchronous input), its output can hang between 0 and 1 for an unpredictable time before settling to a random value
• It cannot be removed completely, only made very unlikely
• Synchronizers give extra time for the value to settle
• Reliability is measured as MTBF

Common mistake: Saying a two-flop synchronizer removes metastability completely; saying the settled value is always correct

Interviewer may ask next: What does MTBF depend on in a synchronizer?

• The first flop may go metastable when sampling the asynchronous signal
• It gets almost a full destination clock cycle to settle before the second flop samples it
• This raises MTBF a lot
• It adds about two cycles of latency
• It is safe only for single-bit, level signals that stay stable long enough to be seen in the destination clock domain

Common mistake: Using it on multi-bit buses; using it on short pulses from a faster clock

Interviewer may ask next: What changes if the destination clock is very fast, and when would you use three flops?

• Each bit can settle on a different destination clock cycle, so the destination may see a mix of old and new bits that was never sent
• Safe methods: gray-coded values (only one bit changes at a time), a handshake (req/ack) with stable data, an asynchronous FIFO, or a mux/enable scheme where a synchronized control signal says when the stable data can be sampled

Common mistake: Thinking the bits will always arrive in the same cycle because the wires are equal length

Interviewer may ask next: When is gray code a valid solution and when is it not?

• A short pulse can be missed completely by the slow clock
• Convert the pulse to a toggle (level change) in the source domain, synchronize the toggle with two flops in the destination, then detect the change with an XOR of the last two synchronized values to make a one-cycle pulse
• Or stretch the pulse long enough, or use a req/ack handshake
• Pulses must not come faster than the destination can see them

Common mistake: Sending the pulse straight through a two-flop synchronizer

Interviewer may ask next: What happens if two source pulses come too close together?

• The read and write pointers must be passed to the other clock domain to make full and empty flags
• In gray code only one bit changes per increment, so if the pointer is sampled while it changes, the result is either the old or the new value, both safe
• A binary pointer can change many bits at once and be seen as a completely wrong value
• Pointers have one extra MSB to tell full from empty

Common mistake: Saying gray code makes the FIFO faster; forgetting the extra pointer bit

Interviewer may ask next: Why must the FIFO depth be a power of two for a simple gray-code pointer?

• Empty is made in the read clock domain: read pointer equals the write pointer synchronized into the read domain
• Full is made in the write clock domain: write pointer equals the synchronized read pointer with its top two bits inverted (gray code)
• Because the synchronized pointers are a few cycles old, the flags are pessimistic (they assert on time and release a little late), which is safe

Common mistake: Making both flags in one clock domain; saying the delay can cause overflow

Interviewer may ask next: How do you choose the depth of a FIFO for a given burst?

• Reset asserts immediately (asynchronously) so the design resets even without a clock
• Reset release passes through two flops so it leaves reset aligned to the clock
• This avoids recovery/removal timing violations and makes all flops leave reset in the same cycle
• Each clock domain needs its own reset synchronizer

Common mistake: Synchronizing the reset assertion too (then reset needs a running clock); using one synchronizer for several clock domains

Interviewer may ask next: What are recovery and removal checks?

• The source puts data on a bus, holds it stable and raises req
• The destination synchronizes req, captures the stable data, then raises ack
• The source synchronizes ack, then drops req
• The data bus itself needs no synchronizer because it is stable when sampled
• It is safe for multi-bit data but slow (several cycles per transfer), so it suits low-rate control or configuration data

Common mistake: Changing the data while req is high; using a handshake for high-bandwidth streaming data

Interviewer may ask next: How would you compare a handshake with an asynchronous FIFO for a design?

• MTBF (mean time between failures) is roughly e^(t_r/τ) / (T0 × f_clk × f_data), where t_r is the time allowed for resolution, τ and T0 are flop constants, f_clk is the destination clock and f_data the data change rate
• MTBF grows exponentially with resolution time
• Improve it by adding a third synchronizer flop, using flops with smaller τ (fast, special synchronizer cells), keeping the flops close together, or lowering the data toggle rate

Common mistake: Thinking MTBF improves linearly with more flops; ignoring the data change rate

Interviewer may ask next: Why do high-frequency designs often use three-flop synchronizers?

• It finds signals crossing between clock domains without a proper synchronizer, multi-bit crossings without a safe scheme, combinational logic (which can glitch) in front of a synchronizer, and reconvergence
• Reconvergence is when related signals are synchronized separately and combined later, so they may arrive one cycle apart and create a wrong combination
• Normal simulation and STA do not catch these issues

Common mistake: Thinking STA or normal RTL simulation will find CDC bugs

Interviewer may ask next: How would you fix a reconvergence problem?