CDC interview questions, with worked answers, RTL and numericals

A CDC is any signal launched by a flop on one clock and captured by a flop on another clock that has no fixed, known phase relationship to it. STA can't guarantee setup and hold because the capture edge can land anywhere relative to the data change.

• Metastability: the capturing flop samples during a transition and takes an unpredictable time to settle.
• Data loss: a short pulse or a quickly changing value is never seen by the slower destination.
• Data incoherency: bits of a bus, or related signals, are captured in different cycles, so the destination sees a value that never existed.

None of these show up in ordinary RTL simulation, because the simulator has no metastability and resolves every edge cleanly. That's why CDC needs its own design rules and its own verification.

A flop's storage element is a pair of cross-coupled inverters with two stable states and one unstable balance point. If the input changes inside the setup–hold window, the latch can be left near that balance point. Positive feedback eventually pushes it to 0 or 1, but the time it takes is random: the probability of still being unresolved after time t falls as e^−t/τ.

MTBF = e^(t_r / τ) / (T0 · f_clk · f_data)

• t_r: resolution time you allow before the next flop samples.
• τ: the flop's regeneration time constant, tens of picoseconds; worse at low voltage.
• T₀: the flop's metastability window.
• f_clk, f_data: how often you sample, and how often the input changes.

Because t_r is in the exponent, a little more resolution time buys an enormous MTBF gain, while frequency only acts linearly.

// src_level must come straight from a flop in the source domain
(* ASYNC_REG = "TRUE" *) logic [1:0] sync;
always_ff @(posedge clk_dst or negedge rst_dst_n)
  if (!rst_dst_n) sync <= '0;
  else            sync <= {sync[0], src_level};
assign dst_level = sync[1];

• The first flop may go metastable; the second samples it a full period later, after it has almost certainly resolved.
• The source must be registered: combinational logic can glitch, and a glitch can be captured as a real pulse.
• No logic between stages, and keep them close together: every picosecond of routing is resolution time lost.
• Only for single-bit levels that stay stable long enough to be sampled (about 1.5 destination periods).
• Use three stages when the clock is very fast or MTBF requirements are strict.

A one-cycle pulse at 500 MHz lasts 2 ns. A 50 MHz destination samples every 20 ns, so it will usually miss it. Options:

• Toggle synchronizer: each source pulse flips a toggle flop; the level is synchronized and an XOR of the last two stages recreates one pulse per event.
• Pulse stretching: hold the pulse as a level for at least ~1.5 destination periods. Needs the destination frequency to be known.
• Handshake: when the source must know the event was received before sending the next.

// source domain
always_ff @(posedge clk_src) if (pulse_src) tog <= ~tog;
// destination domain
always_ff @(posedge clk_dst) s <= {s[1:0], tog};   // s[0], s[1] synchronize
assign pulse_dst = s[2] ^ s[1];

Each bit has its own routing delay and its own metastability resolution, so when several bits change at once, some may be captured this cycle and others next cycle. The destination can see a value that never existed in the source.

Example: a counter goes from 0111 to 1000. All four bits change. The destination might capture 1111, 0000 or any mix for one cycle.

The fix follows one principle: either only one bit changes at a time, or the data is held stable while a single control bit is synchronized. That gives Gray code, handshakes, MUX-enable schemes and async FIFOs.

The one exception is a Gray-coded pointer, where per-bit synchronization is safe precisely because only one bit changes per step.

always_ff @(posedge clk or negedge arst_n)
  if (!arst_n) rs <= 2'b00;              // assert immediately
  else         rs <= {rs[0], 1'b1};      // release synchronously
assign rst_n_sync = rs[1];

Reset asserts asynchronously, so the domain is reset even without a running clock. It de-asserts synchronously: the release passes through two flops, so every flop in the domain sees reset end on the same clock edge with valid recovery and removal timing.

Each clock domain needs its own reset synchronizer. If some flops leave reset a cycle before others, an FSM can start in a corrupt state.

1. Source puts data on the bus and holds it, then raises REQ.
2. REQ is synchronized into the destination. When the destination sees it, it captures the data (stable for many cycles) and raises ACK.
3. ACK is synchronized back to the source, which then drops REQ.
4. The destination sees REQ low and drops ACK; when the source sees ACK low, it may send the next word.

Only REQ and ACK are synchronized; the data bus is held stable, so it can be captured safely. Each transfer costs two synchronizer delays in each direction, so throughput is low. That's fine for configuration values or occasional status words; for streams use an async FIFO.

A two-phase handshake uses transitions instead of levels, halving the round trips at the cost of slightly more complex edge detection.

• A dual-port memory is written on the write clock and read on the read clock.
• Each side keeps a binary pointer with one extra MSB (to tell full from empty), converts it to Gray, registers the Gray value, and passes it through a two-flop synchronizer into the other domain.
• Empty is computed in the read domain: rgray == wgray_sync.
• Full is computed in the write domain: wgray == {~rgray_sync[N:N-1], rgray_sync[N-2:0]}.

The synchronized pointer is a few cycles old. That makes the flags pessimistic: empty stays set a little after data arrives, full stays set a little after space frees up. They never allow overflow or underflow, which is what matters.

Reconvergence happens when two or more signals cross separately, each through its own synchronizer, and then combine in the destination. Each synchronizer can resolve in a different cycle, so for one cycle the destination can see a combination the source never produced.

Example: an FSM's one-hot state bits are synchronized individually and decoded in the destination. During a state change, the decoder can briefly see two hot bits or none and take a wrong branch.

Fixes:

• Synchronize one control signal and capture the rest as stable data (qualifier / MUX-enable).
• Encode the group so only one bit changes per update (Gray).
• Use a handshake or FIFO for the whole group.

# Truly asynchronous clocks: stop STA timing the crossings
set_clock_groups -asynchronous -group {clk_a} -group {clk_b}

# Gray-coded pointers: bound skew instead of ignoring the path
set_max_delay -datapath_only 2.0 \
  -from [get_cells wptr_gray_reg*] -to [get_cells wptr_sync1_reg*]

• Asynchronous clocks get clock groups (or false paths) so STA doesn't report impossible violations.
• Multi-bit Gray buses and handshake data get bounded max-delays (about one destination period, data path only), so routing skew can't break the one-bit-change assumption.
• Check precedence: in many tools a clock group overrides a max-delay, so the bounded paths must be constrained in a way that survives.

Constraints never make a crossing safe; the RTL scheme does. They just make timing analysis honest.

RDC happens when a flop with one asynchronous reset drives a flop with a different reset (or none), even if both use the same clock. If the source is reset while the destination isn't, the source's output changes at an arbitrary time relative to the clock, so the destination can go metastable or capture a corrupt value.

Typical example: a block is reset by software while a neighbour on the same clock keeps running and samples its outputs.

Fixes:

• Gate or isolate the destination's inputs while the source is in reset (a qualifier from the reset controller).
• Put the destination into reset at the same time, or sequence resets so receivers reset first.
• Synchronize the source's reset into the destination's domain before it's used.

A plain mux on two asynchronous clocks can produce a runt pulse when the select changes, clocking some flops and not others. A glitch-free clock mux makes the switch in two steps:

1. Each clock has an enable flop, clocked on its falling edge (so the gated clock can't be cut mid-high).
2. Each enable is cross-coupled with the other: a clock can be enabled only after the other clock's enable has been seen low, through a synchronizer in that clock's domain.
3. The output is (clk0 & en0) | (clk1 & en1).

So the old clock stops cleanly on its low phase before the new one starts on its own low phase. Both clocks must be running during the switch, or the mux can hang; designs that might switch away from a dead clock need a bypass or a timeout.

1. Capture context: which subsystem hangs, and its state registers through debug access.
2. Review CDC and RDC reports and the waivers for that area. Rare field failures often hide behind a waiver.
3. Check MTBF at the real worst case: hot corner and lowest voltage, where τ is largest. A synchronizer that's fine at nominal can be marginal there.
4. Look for handshakes that can deadlock if one side is reset or its clock stops mid-transfer.
5. Reproduce under stress: temperature, frequency and voltage sweeps, plus metastability-injection simulation of the suspected protocol.

• Gray pointers are registered in the source domain before crossing (no combinational binary-to-Gray on the crossing).
• Pointer synchronizers have ASYNC_REG and are placed next to each other.
• Max-delay constraints exist on the pointer crossings and aren't overridden by a clock group.
• Full and empty logic is right, including the extra pointer bit.
• Both sides are reset consistently, so pointers don't start out of step.
• The writer honours full (no overflow ignored), and the depth is really enough.

Then put an ILA on flags and pointers, triggered on the corruption.

Treat the claim as something to prove, not accept:

• Check that the bus is written only while the destination is in reset or idle, and never changes while it's active.
• If that's true, it's a quasi-static signal: document it, write a precise waiver for that bus only, and add an assertion that fires if it ever changes while the destination is active.
• If it can change at run time (a register software might rewrite), redesign: a handshake, or a shadow register with a synchronized "commit" pulse.

• A pulse crossing a plain level synchronizer into a slower domain: short pulses are missed.
• A toggle synchronizer with events arriving faster than ~2–3 destination cycles apart: two toggles cancel before they're seen.
• The destination clock is gated or stopped when the event arrives: nothing samples it.
• A pulse stretcher sized for one destination frequency, now running at another (DVFS).

Measure the worst-case event rate against the destination clock. If events can arrive close together, use a counter crossed with Gray code, or an async FIFO, instead of single events. For gated domains, use sticky levels or wake the clock first.

• Retiming moved logic into the synchronizer chain, or between its stages.
• The two flops were merged or duplicated, or turned into a shift-register primitive (SRL) without proper characterisation.
• Logic was optimised so a Gray encoder became combinational and glitchy on the crossing.
• Scan insertion added a mux in front of a synchronizer stage.
• Placement put the stages far apart, eating resolution time.

Protect synchronizers with dedicated sync cells or dont_touch/ASYNC_REG attributes, exclude them from retiming, and re-run CDC analysis on the synthesized netlist, not only on RTL.

A binary counter changes many bits at once (think 0x...FFFF → 0x...0000), so it can't be synchronized bit by bit. Options:

• Gray counter: count in Gray (or convert and register in the source), synchronize all bits, convert back. Works because only one bit changes per increment, as long as the destination samples at least as often as the count changes, or the occasional skipped value is acceptable.
• Request-driven snapshot: the destination sends a request; the source copies the counter into a holding register and returns an acknowledge; the destination captures the held value. Works for any counter behaviour.
• Common time base: if both domains can run their own counters from a shared reference, align them once instead of crossing continuously.