Difficulty: Medium · Puzzle 4 of 6 · Topic: Valid/Ready Handshake Puzzles
A source has 4 beats to send. The sink raises READY only after it has seen VALID. In design 'bad' the source raises VALID only after it has seen READY; in design 'good' the source drives VALID whenever it has data. After 12 cycles from reset, how many beats does each design transfer, and which rule of the protocol did 'bad' break?
`timescale 1ns/1ns
module link(input bit clk, input bit fix);
bit valid = 0, ready = 0;
int left = 4, xfers = 0;
always @(posedge clk) begin
if (valid && ready) begin xfers++; left--; end
ready <= valid; // sink: raise ready only after it has seen valid
valid <= (left > 0) && (fix || ready); // source: fix=0 waits for ready first
end
endmodule
module tb;
bit clk = 0;
always #5 clk = ~clk;
link bad (.clk(clk), .fix(1'b0));
link good(.clk(clk), .fix(1'b1));
initial begin
#(10*12);
$display("source waits for ready : transfers in 12 cycles = %0d", bad.xfers);
$display("source drives valid : transfers in 12 cycles = %0d", good.xfers);
$finish;
end
endmoduleReset leaves both flags low. Who is allowed to go first?
1) After reset valid=0 and ready=0.
2) 'bad': the sink waits for valid=1, the source waits for ready=1. Neither condition can ever become true, so nothing moves: 0 transfers in 12 cycles.
3) 'good': the source drives valid at the first edge, the sink sees it and raises ready one edge later; beats then flow on four consecutive cycles. 4 transfers.
4) The rule broken by 'bad' is that a source must not wait for READY before asserting VALID. The sink waiting for VALID is legal.Answer: 'bad' transfers 0 beats (deadlock from reset), 'good' transfers 4. The protocol lets READY depend on VALID but forbids VALID depending on READY.
Checked by running the code in Verilator 5; the printed output supports the answer above. Both flags start low; when each side waits for the other, nothing ever moves.
The tempting diagnosis is 'the sink must not wait for VALID'. That is allowed (and common: a slave may wait for AWVALID before asserting AWREADY). The illegal dependency is the source-side one. Also, simulation only shows silence, so a testbench with an overall timeout and no 'beats sent' watchdog reports a hang with no hint of the cause.
Which direction of combinational dependency between VALID and READY is allowed? Model answer: READY may be a combinational function of VALID (and of other state), but VALID must never be a function of READY. The asymmetry guarantees there is no combinational loop and no mutual-wait state.