Interview Question · Concept

The Two-Flop Synchronizer and MTBF

L0 FresherL1 JuniorL2 Mid-Levelcdcmetastabilitysynchronizers

Asked at NVIDIA
Asked at Texas Instruments
Asked at Apple

The interviewer asks

Why do we put two flip-flops in a row to bring a single-bit signal into a new clock domain?

Reveal the Model Answer

A flop that samples an asynchronous input can violate setup or hold time and go metastable, hanging between 0 and 1. It then settles to 0 or 1 after an unbounded time. The second flop gives the first almost a whole destination period to settle before any logic uses the value. MTBF (mean time between failures) grows exponentially with that settling time. The pair does not make the value right on a given cycle. It makes a clean 0 or 1 overwhelmingly likely.

One Flop Settles Late, Two Flops Read ItArrows show signals. status changes just before an edge of clk; s1 samples it and hovers; both state flops read s1 at the next edge.

A change inside the window
status changes a fraction of a nanosecond before edge k. That is inside s1's setup and hold window, the short time around an edge when a flop's input must stay still.
Follow the calls, values and waits
1. data change: status → s1
The flop hovers
The flop goes metastable: its output sits between 0 and 1, then falls to one side at an unpredictable time. The longer you wait, the less likely it is still undecided.
Two readers, two answers
At edge k+1, s1 has still not settled. idle_q's logic may see a 1 while busy_q's sees a 0, and the machine is in neither state. The opposite reading puts it in both.
Follow the calls, values and waits
1. data neither 0 nor 1: s1 → idle_q
2. data neither 0 nor 1: s1 → busy_q

Read the diagram as text

status: a flop on clk_a
clk: edges k and k+1
s1: samples status at edge k
idle_q: reads s1 at edge k+1
busy_q: reads s1 at edge k+1

status → s1: changes near edge k
clk → s1
s1 → idle_q: via ~s1
s1 → busy_q: via s1

Drawn from the timing rules of a real flop. A zero-delay simulator samples exactly at the edge and always sees a clean 0 or 1, so it never shows this.

Flop 1 samples
The input may change inside the setup or hold window, so the output can hang between 0 and 1.
One period to settle
Nothing reads flop 1 except flop 2, so it has nearly a full clock to resolve.
Flop 2 hands over
Logic sees a clean value. MTBF = e^t_r/τ / (T₀ · f_c · f_d).

The MTBF formula with illustrative numbers: 0.2 ns left to settle with one flop, 1.0 ns with two.

RUNIcarus Verilog · in your browser

Edit the code, then run it

Expected: one flop: MTBF = 1.10e-02 s two flops: MTBF = 2.59e+15 s (8.2e+07 years)

module tb;
  // Illustrative numbers: tau 20 ps, window T0 20 ps, 1 GHz destination clock,
  // data changing at 100 MHz.
  real tau = 20e-12, t0 = 20e-12, fc = 1e9, fd = 1e8;
  real one_flop, two_flops;
  initial begin
    one_flop  = $exp(0.2e-9 / tau) / (t0 * fc * fd);   // 0.2 ns left to resolve
    two_flops = $exp(1.0e-9 / tau) / (t0 * fc * fd);   // about one more period
    $display("one flop:  MTBF = %0.2e s", one_flop);
    $display("two flops: MTBF = %0.2e s (%0.1e years)", two_flops, two_flops / 3.156e7);
  end
endmodule

Self-Check

Tick each key point you covered in your answer.

Key point 1 A flop that samples an asynchronous input can violate setup or hold time and go metastable, hanging between 0 and 1. Key point 2 It then settles to 0 or 1 after an unbounded time. Key point 3 The second flop gives the first almost a whole destination period to settle before any logic uses the value. Key point 4 MTBF (mean time between failures) grows exponentially with that settling time. Key point 5 The pair does not make the value right on a given cycle. Key point 6 It makes a clean 0 or 1 overwhelmingly likely.

What Interviewers Listen For (Fresher)

A good fresher answer explains setup and hold violations, metastability, and why the second flop buys time to settle. It knows this synchronizer is only for single bits.

Cross-Questions

Where the interviewer goes next. Open a node to practise that follow-up.

WhyWhat IfProve ItBreak ItCompareScale It

The Two-Flop Synchronizer and MTBF
WhyWhy One Flop Is Not EnoughL0 FresherL1 Junior
Why is a single flop not enough to synchronize an asynchronous input?
2:30

You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.

Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
Reveal the Model Answer

With one flop, logic reads its output in the same cycle that it might be metastable. Only the slack left after that logic is available for settling. Different gates can even read the same hanging value as different levels. The second flop isolates that settling from all other logic, and gives it about a full period.

The Model's Bad Cycle, One FlopEdges 11 to 17 of a simulator bench with a metastability model, sampled on clk. One value per edge, printed 1 ns after it.

Cycle 2
Edge 13: s1 has been 1 since edge 12, and the machine is in BUSY.
Cycle 3
Edge 14: status fell 0.70 ns before the edge. The model makes s1 metastable; it settles to the old 1, after 3 ns.
Cycle 4
Edge 15: 3 ns is more than the 2 ns the state flops can wait. Each reads its own bit, and both read 0: the bench prints ILLEGAL.
Cycle 5
Edge 16: s1 is a clean 0 again and the machine recovers into IDLE.

Over 2000 edges of this bench, s1 went metastable 90 times. The state flops read it unsettled 22 times, and the machine was in an illegal state for 12 edges.

Self-Check
Tick each key point you covered in your answer.
Key point 1 With one flop, logic reads its output in the same cycle that it might be metastable. Key point 2 Only the slack left after that logic is available for settling. Key point 3 Different gates can even read the same hanging value as different levels. Key point 4 The second flop isolates that settling from all other logic, and gives it about a full period.
Half-Truth

"One flop is enough if the clock is slow."

A slower clock helps MTBF. But logic after a single flop still reads a possibly unsettled value. The exponent depends on the time left after that logic.
- Lesson R6.1Metastability and MTBF
What IfWhen One Period Is Not Enough Settling TimeL1 JuniorL2 Mid-Level
What if the clock is so fast that one period is not enough settling time? What do you change?

Reveal the Model Answer

MTBF grows exponentially with settling time, so a third flop adds a full period and multiplies MTBF. Compute MTBF from the flop's library data at the worst corner. Add stages until it is far beyond the product lifetime. Each stage also adds one cycle of latency to the crossing.

Self-Check
Tick each key point you covered in your answer.
Key point 1 MTBF grows exponentially with settling time, so a third flop adds a full period and multiplies MTBF. Key point 2 Compute MTBF from the flop's library data at the worst corner. Key point 3 Add stages until it is far beyond the product lifetime. Key point 4 Each stage also adds one cycle of latency to the crossing.

Half-Truth

"A third flop is always safer, so use three everywhere."

Every stage adds a cycle of latency to each crossing. Add it only where the MTBF calculation needs it.
- Lesson R6.1Metastability and MTBF
What IfA Fast Pulse into a Slow Clock DomainL1 JuniorL2 Mid-Level
Asked if they say "any single-bit signal"

What if the source clock is faster than the destination clock and the signal is a one-cycle pulse?
log
```
Illustrative event excerpt (ns)
 0: destination rising edge; source pulse=0
 4: source pulse rises
 8: source pulse falls
10: destination rising edge; source pulse=0
```
2:30

You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.

Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
Reveal the Model Answer

The pulse can rise and fall between two destination edges and never be sampled. One fix is to hold the signal for at least about 1.5 destination periods. Another is to turn the pulse into a toggle, synchronize the level, and turn each change back into a pulse. For events that must not be lost or merged, use a handshake.

One-Cycle Pulses Through a Two-Flop SynchronizerEdges 3 to 13 of a simulator bench, sampled on clk (10 ns). The sender's clock has a 3 ns period, so each pulse on level lasts 3 ns.

Cycle 1
Edge 4: the first pulse has come and gone between two edges. No edge of clk ever saw level at 1.
Cycle 5
Edge 8: the second pulse is lost the same way.
Cycle 9
Edge 12: edge 11 fell inside the third pulse, so pulse_s fires once. The other pulses of the run are all lost.

Samples of level taken 1 ns after each edge never catch a pulse here. The run ends with sent=7 seen=1.

Self-Check
Tick each key point you covered in your answer.
Key point 1 The pulse can rise and fall between two destination edges and never be sampled. Key point 2 One fix is to hold the signal for at least about 1.5 destination periods. Key point 3 Another is to turn the pulse into a toggle, synchronize the level, and turn each change back into a pulse. Key point 4 For events that must not be lost or merged, use a handshake.
Missed Corner

"A two-flop synchronizer carries any single-bit signal."

It carries a level that stays stable long enough. A pulse shorter than a destination period can be missed completely, as the twin shows.

Run It

A one-cycle pulse from a 250 MHz domain into a 100 MHz domain, through two flops.

RUNIcarus Verilog · in your browser

Edit the code, then run it

Expected: source sent 1 pulse, destination counted 0 FAIL: the pulse fell between two destination edges and was lost

See the Fix
module tb; logic sclk = 0, dclk = 0, tog = 0, s1 = 0, s2 = 0, s3 = 0; int sent = 0, seen = 0; always #2 sclk = ~sclk; // fast source: edges at 2, 6, 10, ... always #5 dclk = ~dclk; // slow destination: edges at 5, 15, 25, ... // The fix: turn the pulse into a level change, synchronize the level, and // turn each change back into one destination pulse (s2 ^ s3). always @(posedge dclk) begin s1 <= tog; s2 <= s1; s3 <= s2; end always @(posedge dclk) if (s2 ^ s3) seen++; initial begin @(posedge sclk); @(posedge sclk); tog <= ~tog; sent++; #60; $display("source sent %0d pulse, destination counted %0d", sent, seen); if (seen != sent) $display("FAIL: the pulse fell between two destination edges and was lost"); else $display("PASS: the level change crossed and became one pulse"); $finish; end endmodule
Prints: source sent 1 pulse, destination counted 1 PASS: the level change crossed and became one pulse
- Lesson R6.3Pulse, Toggle and Handshake Synchronizers
- Problem R6.3.1One Event, One Byte
Prove ItSolve R6.3.1: One Event, One ByteSimulator-graded

Show it, don't just say it: this Silicon Lab problem is graded by the simulator.
Open Problem R6.3.1
CompareGray-Code Pointers vs a Handshake for Multi-Bit CrossingsL2 Mid-Level
Compare a Gray-coded value with a request/acknowledge handshake for carrying a multi-bit value across clock domains.
2:30

You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.

Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
Reveal the Model Answer

Gray code changes one bit per step, so a value caught mid-change is either the old or the new one. It suits counters that move by one, such as FIFO pointers. A handshake holds any data stable while a synchronized request crosses and an acknowledge comes back. It carries any value, but takes several cycles per transfer. Choose Gray for streaming pointers, and a handshake or FIFO for occasional wide data.

The Same Edges with Gray PointersAn asynchronous FIFO with Gray-coded pointers, sampled at the read clock clk.

Cycle 1
Edge 21: empty is 1 while the FIFO holds two words. The read side has not seen those writes yet.
Cycle 2
Edge 22: the pointer steps from 1000 to 0000, one bit, the Gray wrap from 15 to 0.
Cycle 4
Edge 24: read_level is 1 with two words held. Low is safe; the read side just waits a cycle.

Edges 20 to 25 of the run: the level the read side sees never rises above the words held.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Gray code changes one bit per step, so a value caught mid-change is either the old or the new one. Key point 2 It suits counters that move by one, such as FIFO pointers. Key point 3 A handshake holds any data stable while a synchronized request crosses and an acknowledge comes back. Key point 4 It carries any value, but takes several cycles per transfer. Key point 5 Choose Gray for streaming pointers, and a handshake or FIFO for occasional wide data.
Half-Truth

"Gray-code any multi-bit bus and it crosses safely."

Gray only helps when consecutive values differ by one step. Arbitrary data jumps change many bits at once.

Source Cummings, CDC Design and Verification Techniques (SNUG Boston 2008) §5.7.2-5.7.4; Mehta, ASIC/SoC Functional Design Verification ch. 8.3.4 (p155-156)
Prove ItSolve R6.4.2: The Torn PointerSimulator-graded

Show it, don't just say it: this Silicon Lab problem is graded by the simulator.
Open Problem R6.4.2
Break ItBreaking a Two-Flop Synchronizer Without Touching Its FlopsL2 Mid-Level
How can a two-flop synchronizer fail even though its two flops are exactly right?
2:30

You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.

Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
Reveal the Model Answer

Combinational logic in front of the first flop can glitch, and the destination may catch the glitch. Synchronizing one signal in two places lets the two copies resolve differently. Signals synchronized separately and then combined again lose any timing relationship between them. Logic between the two flops eats the settling time.

One Synchronizer per BitArrows show the bit wires from the sender's flops to the receiver. Each synchronizer decides alone in which clk cycle its bit changes.

Three bits make edge 11
Edge 11 of clk is at 115 ns. Bits 0, 1 and 3 have their new values by then.
Bit 2 misses it
Bit 2 arrives at 115.55 ns, after the edge, so its synchronizer still holds the old 1.
A torn value
The receiver sees new 1, 0, 0 for bits 3, 1, 0 and old 1 for bit 2: 1100. The count never held 12 here.

Read the diagram as text
count_tx: 0111 to 1000 at 112.75 ns
bit 0 sync: arrives 113.15 ns
bit 1 sync: arrives 113.95 ns
bit 3 sync: arrives 114.75 ns
bit 2 sync: arrives 115.55 ns
count_q: reads 1100 at edge 12
count_tx → bit 0 sync: 0.4 ns
count_tx → bit 1 sync: 1.2 ns
count_tx → bit 3 sync: 2.0 ns
count_tx → bit 2 sync: 2.8 ns
bit 0 sync → count_q
bit 1 sync → count_q
bit 3 sync → count_q
bit 2 sync → count_q

Times from a simulator bench. With metastability added, this can happen even with perfectly matched wires, because each first flop settles on its own.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Combinational logic in front of the first flop can glitch, and the destination may catch the glitch. Key point 2 Synchronizing one signal in two places lets the two copies resolve differently. Key point 3 Signals synchronized separately and then combined again lose any timing relationship between them. Key point 4 Logic between the two flops eats the settling time.
Missed Corner

"Synchronize the signal once per module that needs it."

Two synchronizers on one signal can resolve on different cycles. So the two modules disagree for a cycle.

Source Golson, Synchronization and Metastability (SNUG 2014) §2.3 (Figure 9); Mehta, ASIC/SoC Functional Design Verification ch. 8.5 (PDF p186, re-convergence)
- Lesson R6.2The Two-Flop Synchronizer and What It Cannot Carry
Scale ItCDC Sign-Off on a Many-Clock SoCL3 SeniorL4 Staff
How do you sign off clock domain crossings on an SoC with dozens of clocks?

Reveal the Model Answer

Start with structural analysis: define the clocks and their relationships. Then let the tool find every crossing and check that each has the right synchronizer for its type. Next comes protocol checking: each scheme's rules, such as hold times and Gray steps, become assertions in formal and simulation. Add reconvergence checks and reviewed waivers. Use metastability injection in simulation to expose designs that assume exact timing.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Start with structural analysis: define the clocks and their relationships. Key point 2 Then let the tool find every crossing and check that each has the right synchronizer for its type. Key point 3 Next comes protocol checking: each scheme's rules, such as hold times and Gray steps, become assertions in formal and simulation. Key point 4 Add reconvergence checks and reviewed waivers. Key point 5 Use metastability injection in simulation to expose designs that assume exact timing.

Tool as Truth

"Our regressions pass with all clocks running, so CDC is covered."

RTL simulation never goes metastable and rarely hits the bad clock phase. CDC needs structural and protocol checks, not only passing tests.

Source Mehta, ASIC/SoC Functional Design Verification ch. 8.5 (PDF p186-188); Sutherland, RTL Modeling with SystemVerilog ch. 8.1.6

Wrong Altitude

A staff-level answer that stops at "run the CDC tool".

The interviewer wants the flow: constraints, structure, protocol, reconvergence, waiver review and who owns each step.
- Lesson F5.6CDC and RDC with Formal
- Lesson R6.2The Two-Flop Synchronizer and What It Cannot Carry

What People Get Wrong

Common wrong answers and why they fail. Run It shows the wrong belief failing on a real simulator.

Misconception

"Two flops make the synchronized value correct."

They only make a clean 0 or 1 very likely. The value can still resolve either way and arrive a cycle earlier or later than expected.

Source Mehta, ASIC/SoC Functional Design Verification ch. 8.2 (p150-151), 8.3.1 (p151-152); Golson, Synchronization and Metastability (SNUG 2014) §2.2-2.3

Misconception

"Put a two-flop synchronizer on every bit and a bus crosses safely."

Each bit can land on a different destination edge. So the destination can see a mix of old and new bits. The twin shows a value the source never sent.

Run It

A 3-bit count crosses with a two-flop synchronizer on every bit. Bits arrive 1, 5 and 3 ns after the change.

RUNIcarus Verilog · in your browser

Edit the code, then run it

Expected: destination saw 2 FAIL: 2 is a value the source never sent destination saw 4

module tb;
  logic dclk = 0;
  logic [2:0] src = 3'd3;                  // a counter value in the source domain
  wire  [2:0] sent = src;                  // the belief: plain binary is fine
  logic [2:0] routed = 3'd3, s1 = 3'd3, s2 = 3'd3;
  logic [2:0] last = 3'd3, value;
  always #4 dclk = ~dclk;                  // destination edges at 4, 12, 20, ...
  // Routing skew: each bit reaches its synchronizer at a different time.
  always @(sent[0]) routed[0] <= #1 sent[0];
  always @(sent[1]) routed[1] <= #5 sent[1];
  always @(sent[2]) routed[2] <= #3 sent[2];
  // A two-flop synchronizer on every bit.
  always @(posedge dclk) begin s1 <= routed; s2 <= s1; end
  assign value = s2;
  always @(value) if (value !== last) begin
    $display("destination saw %0d", value);
    if (value != 3 && value != 4) $display("FAIL: %0d is a value the source never sent", value);
    last = value;
  end
  initial begin
    #10 src = 3'd4;                         // binary 011 -> 100: all three bits change
    #40;
    $finish;
  end
endmodule

See the Fix

module tb;
  logic dclk = 0;
  logic [2:0] src = 3'd3;                  // a counter value in the source domain
  function automatic logic [2:0] to_gray(logic [2:0] b); return b ^ (b >> 1); endfunction
  function automatic logic [2:0] to_bin(logic [2:0] g); return {g[2], g[2] ^ g[1], g[2] ^ g[1] ^ g[0]}; endfunction
  wire  [2:0] sent = to_gray(src);         // the fix: Gray code, so 3 -> 4 changes one bit
  logic [2:0] routed = 3'b010, s1 = 3'b010, s2 = 3'b010;
  logic [2:0] last = 3'd3, value;
  always #4 dclk = ~dclk;                  // destination edges at 4, 12, 20, ...
  // Routing skew: each bit reaches its synchronizer at a different time.
  always @(sent[0]) routed[0] <= #1 sent[0];
  always @(sent[1]) routed[1] <= #5 sent[1];
  always @(sent[2]) routed[2] <= #3 sent[2];
  // A two-flop synchronizer on every bit.
  always @(posedge dclk) begin s1 <= routed; s2 <= s1; end
  assign value = to_bin(s2);
  always @(value) if (value !== last) begin
    $display("destination saw %0d", value);
    if (value != 3 && value != 4) $display("FAIL: %0d is a value the source never sent", value);
    last = value;
  end
  initial begin
    #10 src = 3'd4;                         // binary 011 -> 100: all three bits change
    #40;
    $display("PASS: every value the destination saw was one the source sent");
    $finish;
  end
endmodule

Prints: destination saw 4 PASS: every value the destination saw was one the source sent

Misconception

"A third flop triples the MTBF."

MTBF is exponential in the settling time. One more period of settling multiplies it by about e^T/τ, which is enormous, not 3.

Run It

The MTBF formula with illustrative numbers. How much does one more flop (one more period to resolve) buy?

RUNIcarus Verilog · in your browser

Edit the code, then run it

Expected: third flop multiplies MTBF by 5.18e+21 FAIL: the gain is exponential in the added resolution time, not 3x

module tb;
  // Illustrative numbers: tau 20 ps, window T0 20 ps, 1 GHz clock, data changing at 100 MHz.
  // The belief: a third flop triples the MTBF.
  real tau = 20e-12, t0 = 20e-12, fc = 1e9, fd = 1e8, period = 1e-9;
  real two, three;
  initial begin
    two   = $exp(1.0e-9 / tau) / (t0 * fc * fd);
    three = $exp((1.0e-9 + period) / tau) / (t0 * fc * fd);
    $display("third flop multiplies MTBF by %0.2e", three / two);
    if (three / two < 4) $display("PASS: about three times");
    else $display("FAIL: the gain is exponential in the added resolution time, not 3x");
  end
endmodule

Tool as Truth

"If there were a CDC bug, RTL simulation would show it as an X."

RTL flops have no setup or hold time, so a crossing never goes metastable in RTL simulation. It works with or without a synchronizer.

Source Sutherland, RTL Modeling with SystemVerilog (2017) ch. 8.1.6 (p295-296); Mehta, ASIC/SoC Functional Design Verification ch. 8.5

Find Your Next Track

Put Your Skills to Work

Prepare to Explain Your Thinking

An Idea to Try? Pick a Tool.

The Two-Flop Synchronizer and MTBF

Your Answer

Self-Check

What Interviewers Listen For (Fresher)

What Interviewers Listen For (Senior)

Cross-Questions

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

What People Get Wrong

Learn It, Then Prove It

The Question

Your Answer

Self-Check

What Interviewers Listen For (Fresher)

What Interviewers Listen For (Senior)

Cross-Questions

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

What People Get Wrong

Learn It, Then Prove It