Difficulty: Medium · Puzzle 5 of 6 · Topic: Reset Puzzles
A producer and a consumer share one clock but have separate resets. The producer sends exactly one beat in the first cycle after its reset releases. The producer is released at t=12, the consumer at t=42. How many beats are sent and how many are received? Give the minimum fix for the ordering.
`timescale 1ns/1ns
module tb;
reg clk = 0;
always #5 clk = ~clk; // one clock, two reset domains
reg rstp_n = 0, rstc_n = 0;
reg p_valid, p_done;
reg [3:0] rx;
integer sent = 0;
// producer: sends exactly one beat, in the first cycle after its own reset releases
always @(posedge clk)
if (!rstp_n) begin p_valid <= 1'b0; p_done <= 1'b0; end
else begin p_valid <= !p_done; p_done <= 1'b1; end
// consumer: counts the beats it receives
always @(posedge clk)
if (!rstc_n) rx <= 4'd0;
else if (p_valid) rx <= rx + 1;
always @(posedge clk) if (p_valid) sent <= sent + 1;
initial begin
#12 rstp_n = 1; // producer leaves reset first
#30 rstc_n = 1; // consumer leaves reset at t=42
#18 $display("t=%0d beats sent=%0d received=%0d", $time, sent, rx);
#1 $finish;
end
endmoduleLook at what the consumer does at the edge where valid is high.
1) The producer leaves reset at t=12. At the edge at t=15 it raises p_valid; the edge at t=25 lowers it, so valid is high for one cycle (visible at the edge at t=25).
2) The tb counter sees p_valid high at that edge: sent=1.
3) The consumer is still in reset at t=25 (it is released at t=42), so its reset branch runs and the beat is ignored.
4) After t=42 the producer never sends again: received stays 0.
5) Fix: release the consumer before (or at least not after) the producer, or make the producer wait for an explicit ready from the consumer before it sends.Answer: sent=1, received=0: the only beat is lost because the consumer was still in reset. Release the receiver's reset first (or gate the sender on the receiver's ready) so nothing is sent into a block that is still in reset.
Checked by running the code in Icarus Verilog 13; the printed output supports the answer above. Icarus: one beat is sent while the consumer is still in reset; it is never received.
Treating reset release as one global event. Reset domains release at different times and a block that comes out early talks to a block that is still in reset. Verification must check reset release order, not only that every block is eventually reset.
If you cannot change the release order, how does a ready/valid interface still lose the beat? Model answer: it does not, provided the sender holds valid until it sees ready and the receiver drives ready low during reset; the sender then simply waits until the consumer is out of reset.