Difficulty: Hard · Puzzle 4 of 6 · Topic: CDC Basics Puzzles
An 8-bit word crosses from a 10 ns clock to a 14 ns clock with a req/ack four-phase handshake: data and req change together, req is double-synchronised into the destination, the destination captures data and raises ack, ack is double-synchronised back, the source then drops req and the destination drops ack. What does the destination capture, and when is the earliest safe moment for the source to change data?
`timescale 1ns/1ns
module tb;
reg clks = 0, clkd = 0;
always #5 clks = ~clks; // source period 10
always #7 clkd = ~clkd; // destination period 14
reg [7:0] data = 0;
reg req = 0, ack = 0;
reg r1 = 0, r2 = 0; // req synchroniser (destination clock)
reg a1 = 0, a2 = 0; // ack synchroniser (source clock)
always @(posedge clkd) begin r1 <= req; r2 <= r1; end
always @(posedge clks) begin a1 <= ack; a2 <= a1; end
always @(posedge clkd) begin
if (r2 && !ack) begin ack <= 1; $display("t=%0d dst captures data=%h", $time, data); end
else if (!r2) ack <= 0;
end
task send(input [7:0] v);
begin
data <= v; req <= 1; // data and req change together; data then stays put
@(posedge clks); while (!a2) @(posedge clks);
req <= 0; // ack seen: now data may change again
@(posedge clks); while (a2) @(posedge clks);
end
endtask
initial begin
@(posedge clks);
send(8'hA5); send(8'h3C); send(8'hFF);
$display("t=%0d three transfers complete", $time);
#1 $finish;
end
endmoduleThe destination captures when it sees req; why is the data stable at that moment?
1) The source changes data and req on the same edge. Data is not synchronised: it is only used after req has passed through the two destination flops.
2) By the time the destination sees req (two destination edges later, at least) the data bits have been stable for more than one full destination period, so all bits are captured consistently.
3) The destination captures at that moment and raises ack. The source sees ack after another two source edges, then drops req.
4) The destination drops ack once it sees req low, and the source waits until it sees ack low before the next word, so the three words are captured in order: a5, 3c, ff.
5) The earliest safe moment to change data is after the source has seen ack high (the destination has certainly captured). Changing it earlier would break the capture; changing it only when ack drops again, as the code does, is the conservative choice.Answer: The destination captures A5 at t=35, 3C at t=175 and FF at t=315, in order, so each word takes 140 ns. The source may change data only after it has seen ack high: the destination has captured by then. The design is safe because data is stable for at least the whole req and ack round trip.
Checked by running the code in Icarus Verilog 13; the printed output supports the answer above. Icarus: all three words are captured intact and in order.
Synchronising the data bits too, or changing data when req drops without waiting for ack. The data is never synchronised: it is held stable and sampled when the synchronised req arrives. The cost is latency: a transfer takes several clock cycles of both domains, so the throughput is low.
How many source cycles does one word take, and what would you use for higher throughput? Model answer: about 14 source cycles (140 ns) per word in this example, because req and ack each cross a two-flop synchroniser twice (up and down); for throughput use an asynchronous FIFO or a pulse-based handshake with data held in a register.