Streaming hardware is easier to reason about when we separate what a transaction means from how many cycles it takes to process one. A module can add latency while preserving the same sequence of accepted and produced transactions.
Start with a contract
For a simple ready/valid interface, a transfer occurs on a clock edge when both signals are asserted:
transfer = valid && readyThe contract should also say what happens when valid is high and ready is low. In a common convention, the producer holds valid and the associated data stable until the transfer happens.
This rule makes backpressure concrete. A consumer can pause the stream, and the producer must preserve the item that has not yet been accepted.
Latency is not throughput
Latency counts how many cycles an item takes to travel through a design. Throughput describes how frequently items can be accepted or produced. A fully pipelined block may have several cycles of latency while still accepting one item each cycle, assuming there are no stalls.
When documenting an interface, state both properties separately. Also specify reset behavior, data width, and whether packets or frames have boundary markers.
Verify the edges
Useful simulation scenarios include:
- the consumer is always ready;
- the consumer pauses for one cycle;
- the consumer applies backpressure for several cycles;
- reset occurs before and during activity, if that is supported;
- data arrives in adjacent cycles and at the slowest allowed rate.
Check that accepted inputs appear in the output in the right order, and that no item is duplicated or lost when the pipeline stalls.
A compact design note
Before implementation, write down the transaction rule, the expected latency, the maximum sustained rate, and the behavior during reset and backpressure. This small contract gives RTL, testbench, and integration work a common reference.
The exact details depend on the chosen protocol and module. The important habit is to make them explicit before timing behavior becomes difficult to untangle.