The 2-Flip-Flop Synchronizer

// 2-Flip-Flop Synchronizer (Parametrized Width)
// Resolves metastability from async input using two-stage pipeline
module sync_2ff #(
  parameter WIDTH = 1,
  parameter INIT = 0
) (
  input  clk,           // Receiving clock domain
  input  rst_n,         // Active-low async reset
  input  [WIDTH-1:0] async_in,   // Async input from other domain
  output [WIDTH-1:0] sync_out    // Synchronized output (2 FF stages)
);

  reg [WIDTH-1:0] ff1, ff2;

  // Stage 1: Accept metastability risk
  always @(posedge clk or negedge rst_n) begin
    if (!rst_n)
      ff1 <= INIT;
    else
      ff1 <= async_in;  // Can go metastable here
  end

  // Stage 2: After 1 cycle, ff1 has settled. ff2 captures clean value.
  always @(posedge clk or negedge rst_n) begin
    if (!rst_n)
      ff2 <= INIT;
    else
      ff2 <= ff1;  // ff1 is now stable
  end

  // Output from second flip-flop is safe
  assign sync_out = ff2;

endmodule

// Example: Instantiate a 4-bit synchronizer
// sync_2ff #(.WIDTH(4), .INIT(0)) sync_inst (
//   .clk(clk_b),
//   .rst_n(rst_n),
//   .async_in(req_from_a),
//   .sync_out(req_synced)
// );

This module accepts an async input and produces a synchronized output after 2 clock cycles. The output is guaranteed stable for use in downstream logic. You can extend it to 3 or more FF stages by adding another register stage for higher MTBF.

5. Testbench: verifying synchronizer behavior
A comprehensive testbench should verify that the synchronizer properly handles async transitions and allows settling time:


  

    tb_sync_2ff.sv
    

      Copy
      Download
    
  
  
// Testbench: 2-FF Synchronizer
module tb_sync_2ff;
  reg clk, rst_n;
  reg async_in;
  wire sync_out;

  sync_2ff #(.WIDTH(1), .INIT(0)) dut (
    .clk(clk),
    .rst_n(rst_n),
    .async_in(async_in),
    .sync_out(sync_out)
  );

  // Clock generation
  always begin
    #5 clk = ~clk;  // 10ns period = 100 MHz
  end

  initial begin
    clk = 0;
    rst_n = 0;
    async_in = 0;

    // Reset
    #20 rst_n = 1;
    $display("@%0t: Reset released", $time);

    // Test 1: stable low-to-high transition
    #30 async_in = 1;
    $display("@%0t: async_in goes high", $time);
    #30 $display("@%0t: sync_out = %b (should see transition here)", $time, sync_out);

    // Test 2: high-to-low transition
    #30 async_in = 0;
    $display("@%0t: async_in goes low", $time);
    #30 $display("@%0t: sync_out = %b (transition should complete)", $time, sync_out);

    // Test 3: rapid changes to stress synchronizer
    repeat(10) begin
      #15 async_in = ~async_in;
    end
    $display("@%0t: Rapid transitions completed", $time);

    #50 $finish;
  end

  initial begin
    $dumpfile("tb_sync_2ff.vcd");
    $dumpvars(0, tb_sync_2ff);
  end
endmodule

When you run this testbench in a simulator (ModelSim, VCS, Vivado), you'll see that the synchronizer output always lags the input by exactly 2 clock cycles, and the transition is clean (no ringing or metastability visible at the output).

6. Best practices: when to use and when NOT to use a 2-FF synchronizer

  
Use 2-FF synchronizer for:
Do NOT use for:
  

    
Single-bit control signals (req, ack, enable)
Multi-bit buses (use Gray code instead)
    
Low-frequency async inputs
Very high-frequency signals (use PLLs or clock domain unification)
    
Simple async reset release (with caution)
Data with strict latency requirements (use pulse or handshake)
    
Standard library cells (always use library synchronizer cells!)
Hand-coded register chains (use library cells for certified MTBF)
  



  
✅ Golden rule: use synchronizer library cells
  
Never use a hand-coded register chain in production. Your foundry (TSMC, Samsung, Intel) provides pre-characterized synchronizer cells with certified MTBF values. Synopsys DesignWare also has DW_cdc modules. Use those. They are sized and characterized for metastability resolution at your target process node.


7. Latency trade-offs
The 2-FF synchronizer introduces a 2-cycle latency: the output only updates 2 clock cycles after the input changes. This is important for:

  
Tight control loops: If your system requires immediate response to async events, 2 cycles might be too slow. Use pulse or handshake protocols instead.
  
Clock frequency matching: If your receiving clock is much slower than the input transitions, use 2-FF. If both clocks are similar or very fast, consider deeper synchronizers or different approaches.
  
FIFO applications: Synchronizing read/write pointers across clock domains (covered in Day 5) uses gray code + 2-FF sync in each direction.



  
🎯 Day 2 takeaways
  

    
2-FF synchronizer architecture — two flip-flops in series, clocked by receiving domain
    
Exponential settling — first FF accepts metastability, settles by second clock cycle
    
MTBF calculation — depends on input frequency, clock period, and FF settling time constant
    
Typical MTBF — 100 MHz input with 2-FF: ~1,000 years; 500 MHz: ~200 years
    
2-cycle latency — output updates 2 clock cycles after input changes
    
Use library cells, never hand-code — foundry-provided synchronizers have certified MTBF
    
Good for single-bit signals — multi-bit buses require Gray code (Day 3)
  


FAQ
Why does the 2-FF synchronizer work?
The first flip-flop accepts metastability from the async input. By the time the second flip-flop clocks (one clock cycle later), the first FF has settled exponentially. The output of the second FF is stable with very high probability.
How many flip-flops do I need?
For most designs, 2 flip-flops are sufficient. For extremely high-frequency applications (>10 GHz) or aggressive MTBF requirements, use 3 or deeper. Always calculate MTBF for your specific application.
Can I use 1 flip-flop?
No. A single flip-flop can still go metastable and produce invalid outputs. The entire purpose of the synchronizer is to add time (additional FF stages) for settling.
What is MTBF and how do I calculate it?
MTBF is Mean Time Between Failures — the expected time before metastability escapes the synchronizer. Calculate it as: MTBF = 1 / (f_in × P_meta), where P_meta depends on settling time constants and synchronizer depth.
Should I use library cells or hand-code?
Always use library cells from your foundry or Synopsys DesignWare. They are pre-characterized with certified MTBF values at your process node. Hand-coded synchronizers may not meet safety requirements.
What about reset synchronization?
Async reset synchronization is tricky. You typically use a 2-FF or 3-FF synchronizer on the reset_n signal. However, release from reset requires special care — covered in more detail on Day 7.


  Previous
← Day 1: The Metastability Problem
  Next
Day 3: Gray Code →



↑