What is a Request-Acknowledge synchronizer?

A Req-Ack synchronizer is a 4-phase handshake circuit for safely transferring data across two unrelated clock domains. The source asserts REQ; the destination synchronizes it with a 2-FF chain, captures the data, then asserts ACK; the source synchronizes ACK back and de-asserts REQ; the destination then de-asserts ACK. This guarantees metastability-free data transfer at the cost of throughput.

Why use Req-Ack instead of a 2-FF synchronizer directly on data?

You must NEVER put a multi-bit bus through a 2-FF synchronizer directly — each bit resolves independently, so you can capture a mix of old and new values (a bus tear). A Req-Ack handshake is safe because only the single-bit REQ and ACK signals cross domains through synchronizers. The multi-bit data is held stable for multiple clock cycles before the destination captures it, so there is no metastability risk on data bits.

When should I use Req-Ack vs a Gray-coded async FIFO?

Use Req-Ack when throughput is low (one transfer every several clock cycles is acceptable) and you need acknowledgment. Use a Gray-coded async FIFO when you need continuous high-bandwidth data flow across clock domains. The Req-Ack handshake has a minimum latency of 4-6 cycles in the destination domain per word; an async FIFO can accept new data every destination clock cycle once primed.

How many clock cycles does a Req-Ack transfer take?

Minimum: 2 cycles to sync REQ to destination + 1 cycle to capture + 2 cycles to sync ACK back to source + 1 cycle to de-assert REQ + 2 cycles to sync REQ-low to destination + 1 cycle to de-assert ACK. Total: ~9 destination-clock cycles minimum per transfer in steady state, depending on clock ratios.

Request-Acknowledge Synchronizer — CDC Handshake

System-Level Architecture

Two unrelated clock domains — only single-bit REQ and ACK cross the boundary through 2-FF synchronizers

2-FF Synchronizer — Internal Structure

Applied to both REQ (A→B) and ACK (B→A) signal paths — never applied to the data bus

4-Phase Handshake Protocol

Each transfer requires exactly four phase transitions — REQ↑, ACK↑, REQ↓, ACK↓

PHASE 1

SRC asserts REQ

Source locks data onto the bus and asserts req_a ↑. Data is now stable and will not change until the full handshake completes.

PHASE 2

DST sees REQ, asserts ACK

After 2-FF sync delay, req_sync_b ↑ is seen in CLK_B domain. Destination captures data into its local register, then asserts ack_b ↑.

PHASE 3

SRC sees ACK, de-asserts REQ

After 2-FF sync delay, ack_sync_a ↑ is seen in CLK_A domain. Transfer is confirmed. Source de-asserts req_a ↓. Data may now change.

PHASE 4

DST sees REQ low, de-asserts ACK

After 2-FF sync delay, req_sync_b ↓ is seen. Destination de-asserts ack_b ↓. System is now reset — ready for the next transfer.

Timing Waveform

Signal progression across both clock domains — sync delays shown as shaded regions

Controller FSM — Both Domains

Source FSM (CLK_A) and Destination FSM (CLK_B) drive the 4-phase handshake

SOURCE FSM (CLK_A)

DESTINATION FSM (CLK_B)

IP Interface — Port List

Top-level ports for the parameterizable Req-Ack synchronizer module

Port	Width	Domain	Dir	Description
clk_a	1	CLK_A	IN	Source clock — rising-edge active
rst_a_n	1	CLK_A	IN	Active-low synchronous reset in source domain
send_req	1	CLK_A	IN	Pulse high for 1 cycle to initiate a transfer. Ignored while busy
data_a	N	CLK_A	IN	Data to transfer — must be stable from send_req until transfer_done
transfer_done	1	CLK_A	OUT	High for 1 CLK_A cycle when ACK handshake completes
busy	1	CLK_A	OUT	High while a transfer is in progress
clk_b	1	CLK_B	IN	Destination clock — rising-edge active
rst_b_n	1	CLK_B	IN	Active-low synchronous reset in destination domain
data_b	N	CLK_B	OUT	Captured data in destination domain — valid when data_valid_b is high
data_valid_b	1	CLK_B	OUT	High for 1 CLK_B cycle when data_b has been captured from source

Verilog RTL

Full synthesizable implementation — 2-FF synchronizers + FSMs for both domains

Verilog req_ack_sync.v

module req_ack_sync #(
    parameter DATA_W = 8
) (
    // Source domain (CLK_A)
    input  wire             clk_a, rst_a_n,
    input  wire             send_req,
    input  wire [DATA_W-1:0] data_a,
    output reg              transfer_done,
    output wire             busy,
    // Destination domain (CLK_B)
    input  wire             clk_b, rst_b_n,
    output reg  [DATA_W-1:0] data_b,
    output reg              data_valid_b
);

// ── Source FSM states ───────────────────────────────────────────
localparam [1:0] S_IDLE=2'd0, S_ASSERT=2'd1, S_WAIT=2'd2, S_DEASSERT=2'd3;
reg [1:0] src_state;

// ── Destination FSM states ──────────────────────────────────────
localparam [1:0] D_IDLE=2'd0, D_CAP=2'd1, D_ACK=2'd2, D_DEACK=2'd3;
reg [1:0] dst_state;

// ── Raw handshake signals ───────────────────────────────────────
reg              req_a;      // driven by source FSM
reg              ack_b;      // driven by dest FSM
reg [DATA_W-1:0] data_latch; // locked at send_req, released after done

// ── 2-FF synchronizer: req_a → CLK_B domain ────────────────────
reg ff1_req_b, ff2_req_b;   // synthesis attribute: async_reg
always @(posedge clk_b or negedge rst_b_n)
    if (!rst_b_n) {ff1_req_b, ff2_req_b} <= 2'b0;
    else          {ff2_req_b, ff1_req_b} <= {ff1_req_b, req_a};
wire req_sync_b = ff2_req_b;

// ── 2-FF synchronizer: ack_b → CLK_A domain ────────────────────
reg ff1_ack_a, ff2_ack_a;   // synthesis attribute: async_reg
always @(posedge clk_a or negedge rst_a_n)
    if (!rst_a_n) {ff1_ack_a, ff2_ack_a} <= 2'b0;
    else          {ff2_ack_a, ff1_ack_a} <= {ff1_ack_a, ack_b};
wire ack_sync_a = ff2_ack_a;

// ── Source FSM (CLK_A) ──────────────────────────────────────────
assign busy = (src_state != S_IDLE);
always @(posedge clk_a or negedge rst_a_n) begin
    if (!rst_a_n) begin
        src_state <= S_IDLE; req_a <= 0; data_latch <= 0; transfer_done <= 0;
    end else begin
        transfer_done <= 0;
        case (src_state)
            S_IDLE: if (send_req) begin
                        data_latch <= data_a;
                        req_a      <= 1;
                        src_state  <= S_ASSERT;
                    end
            S_ASSERT: src_state <= S_WAIT; // let req_a propagate 1 cycle
            S_WAIT:   if (ack_sync_a) begin
                          req_a     <= 0;
                          src_state <= S_DEASSERT;
                      end
            S_DEASSERT: if (!ack_sync_a) begin // wait for ACK to fall
                            transfer_done <= 1;
                            src_state     <= S_IDLE;
                        end
        endcase
    end
end

// ── Destination FSM (CLK_B) ─────────────────────────────────────
always @(posedge clk_b or negedge rst_b_n) begin
    if (!rst_b_n) begin
        dst_state <= D_IDLE; ack_b <= 0; data_b <= 0; data_valid_b <= 0;
    end else begin
        data_valid_b <= 0;
        case (dst_state)
            D_IDLE: if (req_sync_b) begin
                        data_b    <= data_latch; // data_latch is stable here
                        dst_state <= D_CAP;
                    end
            D_CAP: begin
                       data_valid_b <= 1;
                       ack_b        <= 1;
                       dst_state    <= D_ACK;
                   end
            D_ACK: if (!req_sync_b) begin // REQ has fallen (source de-asserted)
                       dst_state <= D_DEACK;
                   end
            D_DEACK: begin
                         ack_b     <= 0;
                         dst_state <= D_IDLE;
                     end
        endcase
    end
end

endmodule

Critical Design Rules

Violating any of these causes hard-to-debug intermittent failures in silicon

🚫

Never sync a multi-bit bus

Each bit resolves independently — you can capture a half-old, half-new bus. Only sync single-bit REQ and ACK.

🔒

Lock data before asserting REQ

Data must be stable on the bus before req_a goes high and must not change until transfer_done is received.

⏱

Minimum 2 clock cycles per sync

Never reduce to a 1-FF chain to save area. One extra cycle is the MTBF insurance — removing it causes failures at scale.

📌

Mark async_reg in synthesis

Annotate the 2-FF chain registers with ASYNC_REG / async_reg so the tool keeps them close in placement and doesn't retime them.

📊

Use for low-throughput transfers

One word every ~10+ cycles. For bulk streaming data, use a Gray-coded async FIFO — Req-Ack is not designed for continuous flow.

⚡

Clock ratio doesn't matter

Req-Ack works correctly regardless of CLK_A vs CLK_B frequency ratio — including when one is much faster or completely asynchronous.

Req-Ack vs Other CDC Techniques

Choose the right synchronizer for your use case

✓ Use Req-Ack when

Transferring multi-bit data at low rate
You need guaranteed acknowledgment
Clock domains are completely asynchronous
Transfer rate: <1 word per 10 cycles
Control path signals crossing domains

✓ Use 2-FF Sync when

Crossing a single-bit signal only
Enable, reset, or flag signals
No multi-bit data involved
No acknowledgment needed
Fastest solution — 2-cycle latency

✓ Use Async FIFO when

High-bandwidth data streaming
Producer and consumer run independently
Audio, video, network packet streams
Back-pressure / flow control needed
1 word per destination clock throughput

Interactive animations for all CDC techniques

Open CDC Lab →

Req-Ack Synchronizer