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.
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.
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.
Loading mtbf plot…
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.
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.
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 |
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.
`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
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.