--- Quote Start ---
Your classifications of interfaces is incorrect and not necessary. An Avalon component needs to have a wait request or it must accept commands on every clock cycle. This is spelled out in the Avalon spec and has nothing to do with a slave that is 'fast' or 'slow'.
--- Quote End ---
The fast and slow classification referred to how fast a component can deliver data to the Avalon interface, and how to implement the waitrequest control for both styles. You point out a slight variation, so I'll address that.
The implementation detail that requires separation into these two classifications is that the device should have both input and output registers. These registers are there to cut the timing path between the fabric and your custom component.
1) Slow devices.
If a device cannot deliver data onto an Avalon bus at a
sustained rate, comparable to the Avalon clock rate, then its slow. For example, an LCD or other off-chip device. Slow devices can start with
waitrequest active.
The input registers on the read/write controls delay those signals into the component by one clock. If waitrequest was deasserted, then the component would have already accepted one transaction. Given that the component waitrequest output is also registered, then by the time it asserts the response handshake, it may have had to accept two transactions. By starting out with waitrequest active, the control FSM can deassert the control for a single clock, and then process the transaction.
2) Fast devices.
A fast device such as a RAM, registers, or an interface with a FIFO can generally start with
waitrequest deasserted. RAM or registers can handle writes on every clock, and deliver data after a pipeline delay, so their waitrequest signals can generally remain low. During reset, their waitrequest should be asserted (per the Avalon specification recommendations).
FIFO devices need to make use of their almost-full flags when determining the state of waitrequest. If there have been no transactions for a while, and the transaction FIFO has drained, then waitrequest can be deasserted. For example, a write-burst can occur on the Avalon bus and be write-posted to the FIFO. Those transactions can then drain from the FIFO to the external device, eg. an SRAM, at a slower rate. If another write or read transaction occurs on the Avalon bus before the FIFO has been drained, then the control FSM can either leave
waitrequest asserted until it is completely finished with the previous transaction, or it can use the FIFO almost-full flag to determine whether to accept more transactions into the FIFO.
The key aspect of the FIFO is that its flags can be use to accommodate the pipeline delay due to the input/output registers.
--- Quote Start ---
As an example where your classification breaks down, consider a simple fifo inside the slave. The fifo exists because the output at certain times cannot keep up with the input. The input side can accept new data on every clock cycle (so it would be 'fast' by your classification), but could fill up so it would need to have a wait request output which is connected to the fifo full signal. Having the wait request would make it 'slow' by your classification. So this example would be both 'fast' and 'slow' according to you. Your classification of 'fast' and 'slow' is meaningless and does nothing to define how to implement wait request.
--- Quote End ---
I hope the above comments clarify the classification.
Cheers,
Dave
Honored Contributor
