Question bank — Clock domain crossing

False. Metastability is physics and can never be removed; the synchronizer only gives the first flop time to resolve, pushing the probability of failure down so MTBF becomes astronomically large but still finite.

False. Same frequency but unknown or drifting phase still means the source can change data inside the destination's setup/hold window, so it is still an asynchronous crossing needing a synchronizer.

True. Each extra stage adds one clock period of settling $t_s$, and MTBF $\propto e^{t_s/\tau }$, so reliability is multiplied by $e^{T_{clk}/\tau }$ — a huge factor per stage.

False. A faster clock means a shorter period, so less settling time $t_s$ per flop and a higher $f_{clk}$ in the denominator — both shrink MTBF. Faster is generally worse for a fixed synchronizer.

False. Each bit resolves after an independent random delay, so bits can land on different cycles; the receiver may assemble a word that was never actually sent — this is data incoherence.

True. If only one bit is changing during a transition, even if that bit goes metastable the receiver reads either the old or the new count — both are valid, off by at most one.

False. Only the 1-bit req/ack control lines are synchronized; the data bus is held stable and is only sampled after the receiver knows (via synced req) it is safe, so the bus itself never crosses through a synchronizer.

True. More frequent asynchronous input changes means more chances to violate setup/hold, so MTBF $\propto 1/(f_{clk}{f}_{data})$ — a rarely-changing signal is inherently safer.

False. MTBF is a statistical mean; a failure could occur tomorrow, just with vanishingly small probability. "Astronomically unlikely" is not "impossible."

Missing terms. The correct window is $t_s=T_{clk}+t_{cq,FF1}-t_{su,FF2}$: FF1's output appears only after its clock-to-Q delay (extends the window) and FF2 needs data one setup time early (shrinks it).

Wrong tap point. The metastable node (FF1 output) must feed nothing but FF2; any other logic reading a mid-resolution voltage can itself go metastable or diverge. Only FF2's stable output is used.

Confused symbols. $\tau$ is the flop's regeneration time constant (a fixed technology property, ~tens of ps). The time we choose to wait is $t_s$; safety comes from making the ratio $t_s/\tau$ large.

Backwards and impossible. $T_0$ is a measured device constant you cannot tune, and it sits in the denominator — larger $T_0$ gives worse MTBF. You fix MTBF by increasing $t_s$ (more stages).

Fatal. req and ack are the very control signals crossing the boundary — if they are not synchronized they can go metastable and the entire handshake can deadlock or double-latch. The single-bit control lines are exactly what must be synchronized.

Misapplied. Gray code only guarantees single-bit changes for values that increment/decrement by one (like counters/pointers). Arbitrary data can jump by many bits at once, breaking the one-bit-change guarantee — use a handshake or FIFO instead.

Because near the peak the flop acts as a positive-feedback amplifier, $v(t)=v_0{e}^{t/\tau }$; the probability it is still unresolved decays as $e^{-t_s/\tau }$, so each extra bit of waiting multiplies reliability rather than merely adding to it.

The goal is to hand data safely into the destination's timing; sampling with the destination clock is what aligns the resolved value to the destination edges. Using the source clock would leave the crossing unsynchronized.

Each control bit must be synchronized through two flops in each direction (req over, ack back), costing several clock cycles of latency per transfer — the price paid to guarantee the data bus is stable and coherent.

The read and write pointers must cross into the opposite clock domain to compare full/empty; Gray coding ensures only one pointer bit changes per step, so a metastable bit still yields a pointer off by at most one — safe for the comparison logic.

Each stage multiplies MTBF by a finite factor $e^{T_{clk}/\tau }$; the product is enormous but always finite because the initial imbalance $v_0$ can be arbitrarily close to zero, giving a non-zero (if tiny) chance of not resolving in any fixed time.

Only that single edge can violate setup/hold, so there is at most one metastability event; after it resolves the signal is stable and safe. Low $f_{data}$ makes MTBF large — this is the friendliest case.

Then the crossing may be mesochronous/synchronous — with a fixed, characterizable phase relationship you might meet setup/hold by static timing analysis and skip synchronizers, but only if the skew is truly bounded and known. Treat as CDC otherwise.

The first flop has no time to resolve before FF2 samples it, so the synchronizer offers essentially no protection; MTBF collapses toward the raw failure rate. You must slow the clock, add stages, or redesign.

With no more clock edges, FF2 never re-samples, so the metastable voltage on FF1 continues to resolve on its own (analog physics) but the resolved value is not captured until clocking resumes — a stalled clock does not "freeze" metastability, it just delays capture.

Yes. If the source pulse is narrower than the destination clock period, the slow domain can sample between edges and miss it entirely. This needs pulse-stretching or a proper handshake, not just a two-flop synchronizer.