Keeping a streaming RTL interface correct under backpressure

The design question

A hypothetical data-processing block accepts a stream of requests and passes results to a downstream consumer. The consumer can pause without warning. The architecture must decide when a request is accepted, where it is stored and how the producer learns that capacity is exhausted. The important question is not simply whether a simulation runs: it is whether every accepted request has a defined, observable outcome.

This example assumes a single clock domain and an explicitly specified ready/valid handshake. It is not an AXI implementation claim. Multiple clocks, packet reordering, retries and power-domain crossings would each add requirements. Keeping those boundaries visible prevents an apparently small interface from silently becoming a much larger protocol design.

Define the transaction contract

Write the acceptance rule before discussing the number of pipeline stages. State whether a transfer occurs only when both ready and valid are asserted at the sampling edge. Define who owns the payload during a stall and whether it must remain stable. Clarify whether transaction identifiers are required, whether responses can be reordered and how malformed requests are reported.

A timing diagram should show an uninterrupted stream, a single-cycle stall and a long stall with a full buffer. Add simultaneous enqueue and dequeue at the occupancy boundary. Review zero-length operations and the maximum supported transfer size if the interface includes lengths. These examples expose ambiguous specification language before that ambiguity becomes RTL.

Choose a buffering strategy

A combinational ready path can be simple but may become a timing bottleneck when many blocks are connected. Registering backpressure changes the timing relationship and can require additional storage to absorb an already accepted request. Compare a skid buffer, a FIFO and an extra pipeline stage against the actual interface contract rather than treating one structure as universally preferable.

For each option, record capacity, added latency, full and empty behaviour, and the effect of simultaneous input and output activity. Separate steady-state throughput from the latency of an isolated request. A proposed architecture should explain how it behaves when the consumer remains stalled longer than expected; extra buffering postpones congestion but does not remove the need for flow control.

Make correctness observable

Use an independent queue model to record accepted input transactions and compare them with completed output transactions. Assertions can check that payload stays stable while a valid transfer is blocked, that occupancy remains within range and that outputs do not appear without a corresponding accepted input. A checker should observe interface events rather than reuse the implementation’s internal decision logic.

Coverage should distinguish empty, partially occupied and full states, including transitions between them. Cross stall length with occupancy where that answers a real requirement. Retain failing seeds and a reduced reproducer. A high count of passing random tests is useful evidence only when the stimulus and checking actually exercise the behaviours the design promises.

Handle reset deliberately

Reset during an outstanding transaction requires a product decision. The block might discard in-flight data, drain work before reset or require the surrounding system to replay requests. Select one contract and describe what the receiver will observe. Clearing counters without defining the fate of accepted transactions can leave the system waiting forever for a response.

Exercise reset when idle, when full and when output is blocked. Check the first legal transaction after reset and any status or error reporting. If asynchronous reset release is used, its synchronization and implementation requirements need a separate review. Functional simulation alone does not establish safe reset distribution in a physical design.

A concrete review exercise

Sketch a producer sending transactions A, B and C on consecutive cycles. Let the consumer accept A, then stop accepting data while B is presented. Ask each reviewer to mark the cycle on which B becomes the block’s responsibility, the location where C can be held and the signal that prevents a fourth transaction from being accepted without storage. The exercise is useful because it exposes whether different people are using the same meaning of accepted.

Now add a reset before B completes. Compare the expected output sequence with the written reset policy. If the team cannot agree whether B is canceled or replayed, the next action is a specification decision, not more RTL. Once the contract is clear, turn the sketch into a directed test and an assertion where appropriate. Keep it as a small integration example that a downstream engineer can understand without reading the entire verification environment.

What a useful handoff would show

The illustrative outcome is a review package, not a claimed performance improvement. It would contain the interface contract, buffering comparison, synthesizable RTL, assertion list, test plan and results tied to a design revision. Include unresolved timing assumptions and the supported parameter combinations. The receiving team should be able to run the focused tests without reconstructing the author’s workstation.

Before accepting the block, review whether the integration environment obeys its assumptions. A correct block can still fail in a system whose producer changes stalled data or whose reset controller breaks the agreed sequence. Use the same transaction examples in the integration test so that architectural intent survives the move from block-level verification to system use.

What to bring. What to review.

Questions before you begin.