14 / 24 · Concept
Ready/valid and stalled state
The output stage holds A with out_ready=0 while input B is valid. What must the stage and producer do at the next edge?
Lessons are free to read. Enroll to save your learning progress.
Advance only on a transfer
A producer asserts valid when its current item is available. A consumer asserts ready when it can accept that item. At a rising edge with both asserted, one transfer occurs. Advance pixel coordinates, line-buffer state and the associated accumulation input only then. Advancing on valid alone loses data during a consumer pause; advancing on ready alone counts nonexistent input.
While valid is high and ready low, keep the same data and valid. To continue accepting input while output is blocked, provide storage and derive readiness from its remaining capacity. The example RTL is a one-item stage: it accepts a new item when empty or when the current item can leave.
Worked transfer sequence
For cycles zero through four, valid=[0,1,1,1,1] and ready=[0,1,0,1,1] give fire=[0,1,0,1,1]. Five clocks accept three pixels. The item stalled in cycle two remains until cycle three. A width-four row counter has not completed its first row. Counting clocks instead of transfers shifts every later window coordinate.
If the stage holds A with out_valid high and out_ready low, in_ready is low and A remains stored. When out_ready becomes high, it may send A and accept B at the same edge. With no replacement input, it clears output valid. Document whether simultaneous replacement is allowed and what latency is implied.
Reset clears validity as well as data. A new frame needs a defined coordinate and window-valid reset. Receiving the last input differs from consuming the last output; asserting done too early can let a new frame overwrite outstanding work.
The code is a transfer stage, not a complete convolution engine. If your installed workflow supports SystemVerilog editing and simulation, manually create a file and test stability under pause plus simultaneous replacement. No RTL-simulator execution is claimed here. The diagram illustrates fire; it is not a captured hardware trace.
module sample_stage (
input logic clk, reset,
input logic in_valid,
output logic in_ready,
input logic signed [7:0] in_data,
output logic out_valid,
input logic out_ready,
output logic signed [7:0] out_data
);
assign in_ready = !out_valid || out_ready;
always_ff @(posedge clk) begin
if (reset) begin
out_valid <= 1'b0;
out_data <= '0;
end else if (in_ready) begin
out_valid <= in_valid;
if (in_valid) out_data <= in_data;
end
end
endmoduleView waveform data
| Signal | Wave | Bus values |
|---|---|---|
| clock | p.... | |
| valid | 01111 | |
| ready | 01011 | |
| fire | 01011 |
Try it yourself
The output stage holds A with out_ready=0 while input B is valid. What must the stage and producer do at the next edge?
Read the explanation
The stage drives in_ready low and retains A with out_valid. The producer retains B with in_valid. Stable items can later transfer exactly once.