Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
  • Timing & Clocking39
  • Reset & CDC34
    • Reset Architecture
    • Metastability and Synchronisation
      • What Metastability Means in Practice
      • The Two-Flop Synchroniser
      • When to Use Three Flops
      • CDC Constraints and Implementation Hygiene
      • Do Not Synchronise Buses Bit by Bit
    • Asynchronous FIFO
    • CDC Protocols
    • Reset Domain Crossing
    • CDC Verification
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
  • Glossary and Notation
Loading lesson

‹Metastability and Synchronisation
  1. Topics
  2. RTL Design
  3. Reset & CDC
  4. Metastability and Synchronisation
  5. When to Use Three Flops

Part 6 · Reset & CDC · Intermediate

When to Use Three Flops

MTBF across clock speeds, stage-count guidance, and a parameterised synchroniser test.

On this page

    Why this matters

    Two flops are often enough at moderate clock rates, and not enough at very high ones. The number of stages is a reliability budget you calculate, not a habit.

    After this lesson you can: estimate the MTBF of a synchroniser and decide whether two or three stages meet a system budget.

    Each extra flop adds another settling interval

    A third flop adds one cycle of latency and multiplies MTBF by e^(Δt_r/τ), where Δt_r is the additional stage's usable settling time, not automatically a whole period. Sum the interstage timing slacks, including clock-to-Q, setup, routing and clock effects. The need for it depends on clock speed and the implemented slack.

    The table below uses illustrative parameters: τ = 25 ps, T_W = 30 ps, f_data = f_clk / 10, and 0.2 ns of each period lost to clock-to-Q and setup.

    With these simplified equal-stage assumptions, t_r(2FF) = T − 0.2 ns and t_r(3FF) = 2(T − 0.2 ns). Values below use unrounded settling times and 365.25 days per year before rounding for display; they are calculations, not measured reliability.

    Clock

    t_r (2FF)

    MTBF with 2 flops

    t_r (3FF)

    MTBF with 3 flops

    200 MHz

    4.8 ns

    6.4 × 10⁷⁰ years

    9.6 ns

    1.6 × 10¹⁵⁴ years

    500 MHz

    1.8 ns

    7.9 × 10¹⁷ years

    3.6 ns

    1.5 × 10⁴⁹ years

    1 GHz

    0.8 ns

    0.83 years

    1.6 ns

    6.6 × 10¹³ years

    1.5 GHz

    0.47 ns

    6 × 10⁻⁷ years (about 19 seconds)

    0.93 ns

    about 77 years

    2 GHz

    0.3 ns

    4 × 10⁻¹⁰ years (about 14 ms)

    0.6 ns

    7 × 10⁻⁵ years (about 37 minutes)

    The parameters are illustrative, so only the shape transfers to real designs.

    Calculated MTBF against clock frequency for two and three flops, using the illustrative parameters of the table (log scale: each grid line is a factor of 10^10)

    Read the vertical axis as a power of 10: 0 is one year, 10 is ten billion years, and -10 is about 3 ms. Each dot is one row of the table.

    • Both curves fall steeply: going from 0.5 to 1 GHz costs the two-flop design about 18 powers of 10.

    • The three-flop curve sits above the two-flop curve by a gap that also shrinks with frequency, because the extra stage only adds T - 0.2 ns of settling.

    • At 1.5 GHz the third flop turns about 19 seconds into about 77 years, but at 2 GHz even three flops give only about 37 minutes.

    Try it: MTBF against clock frequency

    The calculator starts on the table's parameters at 1 GHz with two flops (τ = 25 ps, T_W = 30 ps, data toggling every 10 cycles, 0.2 ns lost per stage): about 0.83 years for one synchroniser. The dashed curve is the same design with one more flop.

    Synchroniser MTBF

    Loading mtbf plot…

    Calculated MTBF on a log scale (each unit is a power of 10 years) for the chosen stage count and one more, from 100 MHz to 3 GHz. The dot is the current clock; the dashed line is a 10-year target.
    • Set three flops: 6.6 × 10¹³ years, because the extra stage adds 0.8 ns of settling and multiplies MTBF by e^32, about 7.9 × 10¹³.

    • Keep three flops and raise the clock to 2000 MHz: about 37 minutes, below the target. Four flops would give about 11 years.

    • Back at 1000 MHz with three flops, set 2,000 synchronisers: the chip MTBF falls by a factor of 2,000, to about 3.3 × 10¹⁰ years. Set the overhead to 0.35 ns at 3000 MHz and the synchroniser has no settling time at all.

    Check yourself At 2 GHz with 0.2 ns overhead per interstage interval, what are the 2FF and 3FF settling times?

    T = 0.5 ns: 2FF gets 0.3 ns, and 3FF gets 0.6 ns, not 0.8 ns. The third stage's multiplier is e^(0.3 / 0.025) = e^12. Use the sum of actual implementation slacks for signoff.

    • In this illustrative parameter table only, two flops give extremely large calculated MTBF at 200 and 500 MHz.

    • With these same assumptions, the 1 GHz two-flop result is about 0.83 years; compare it with the system reliability requirement rather than treating 1 GHz as a universal threshold.

    • In this table, three flops give about 77 years at 1.5 GHz but only about 37 minutes at 2 GHz; whether either meets the target also depends on synchroniser count.

    • For a real design, use library-characterised τ and T_W, actual interstage settling slack, data toggle rate, synchroniser count and the required system MTBF. Frequency alone does not select a safe stage count.

    When to add a stage

    The frequency-based cases below refer only to the illustrative parameters above, not a general stage-count policy. Select stages from implemented settling slack and the system MTBF budget, and check that the protocol tolerates the added latency.

    Typical starting point (confirm with the MTBF calculation above)

    Stages

    Clocks up to a few hundred MHz, typical logic

    2

    2FF MTBF below the system budget (with the parameters above, that happens near 1 GHz), or a high-reliability or safety-critical product

    3

    Very fast clocks, long-life systems

    3 or more, plus library synchroniser cells

    Many synchronisers in a large chip (failure rates add up)

    Consider the total: MTBF of the chip is MTBF per synchroniser ÷ count

    Tip

    Make the number of stages a parameter of your synchroniser wrapper (STAGES) and set the default from the project's CDC policy. Then moving a block to a faster clock is a one-line change.

    Common mistakes

    Common pitfall

    Adding a stage costs latency that the protocol must tolerate. For a handshake, each extra stage adds one cycle to both directions of every transfer. Count it when you specify throughput.

    Check yourself A chip has 2,000 independent synchronisers, each with an MTBF of 10⁶ years. What is the chip-level MTBF?

    About 500 device-years, or 228 failures per billion device-hours (FIT), using 365.25 days/year. This is not automatically acceptable for any product category. An illustrative 10 FIT allocation would be exceeded by about 23 times. Compare the actual allocated budget, fleet exposure, fault consequences, detection and containment; distinguish a synchroniser failure from an uncontained system hazard. Parameters and implementation evidence still need signoff.

    Testbench

    meta_ff.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    `timescale 1ns/1ps
    
    // Sampling uncertainty only: random digital capture at fixed TCQ after a window hit.
    // No analogue state, late-resolution tail, or downstream disagreement is modelled.
    module meta_ff #(parameter real TCQ = 0.3, TSU = 0.15, THD = 0.1) (
      input  logic clk, d,
      output logic q
    );
      realtime t_d = -100.0, t_clk = -100.0;
      int      meta_events = 0;
      initial q = 1'b0;
    
      always @(d) begin
        t_d = $realtime;
        if ($realtime - t_clk < THD) begin                    // changed just after the edge (hold window)
          meta_events++;  q <= #TCQ $urandom_range(0, 1);
        end
      end
      always @(posedge clk) begin
        t_clk = $realtime;
        if ($realtime - t_d < TSU) begin                      // changed just before the edge (setup window)
          meta_events++;  q <= #TCQ $urandom_range(0, 1);
        end else q <= #TCQ d;
      end
    endmodule
    
    
    // N-stage synchroniser
    module sync_n #(parameter int STAGES = 2) (input logic clk, d, output logic q);
      logic [STAGES:0] chain;
      assign chain[0] = d;
      for (genvar i = 0; i < STAGES; i++) begin : g_stage
        meta_ff f (.clk, .d(chain[i]), .q(chain[i+1]));
      end
      assign q = chain[STAGES];
    endmodule
    

    Remember

    • MTBF falls quickly as the clock and data rates rise.

    • A third flop adds one cycle of latency and more settling time, and the protocol must tolerate the extra cycle.

    • Choose stages from the implemented settling slack and the system MTBF target, not from frequency alone.

    Rule of thumb: make the stage count a parameter of one wrapper, so a faster clock is a one-line change.

    How this was checked

    Source checker, run with Icarus Verilog 13.0 (2026-10-16): prints PASS with 400 of 400 window hits. It runs 20,000 deterministic safe-phase transitions and checks every output at the first, second and third subsequent destination edges, which proves the extra latency edge only within this fixed-delay digital model. Another 400 setup-window transitions require window-hit coverage and bounded convergence separately. The two chains randomise independently in that phase, so their exact latency difference is deliberately not asserted. Neither phase verifies physical resolution tails or MTBF.

    Keep going

    • Practice: A 3-flop synchroniser that still causes glitches

    • Practice: Metastability in a CDC control path, analysed from a waveform

    • Interview: run a mock interview on this topic

    Related topics

    • Constraints and hygiene

    Previous

    162 / 350

    Next: CDC Constraints and Implementation Hygiene

    Up next

    Up nextCDC Constraints and Implementation Hygiene

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • What Metastability Means in Practice
    • Do Not Synchronise Buses Bit by Bit