axi_stream_slave with check function requires TREADY

[eschmidscs]

Hi

Change 3e098f5 modifies the behaviour of the check_stream/check_axi_stream function.
The check functions call the pop function one by one. The command queue to the VC thus always runs empty, causing TREADY going low with the current implementation. This results in max 50% duty cycle of the checked stream.
However, TREADY is optional by the AXIS spec.

I don't grasp the full background of the change above. Is the only reason to have it implemented the same way?

Best regards,
emanuel

[kraigher]

A check operation is currently a blocking operation just like a read since the check is done in the client code. A blocking operation will limit the throughput as you notice. To solve the situation you need to queue up many reads using non blocking calls and do the checks afterwards. You can already do this using the non blocking read calls today.

The situation could be improved in two ways:

• Keep check a client side operation but make a procedure which will work on an entire array such that reads can be queued up internally.
• Move the check into the VC. The client code must add a wait_until_idle call to ensure the check has happened.

[eschmidscs]

The problem was solved before the mentioned commit, so it is not impossible to implement. However, if you want to have the message handler implemented as it is now, it probably does not work (even though being an "artifact" of how the simulator works).

I hope I find time to look at your second option. I think non-blocking checks would be nice anyway.

Sidenote: I find the naming confusing here. It is obviously blocking, as it waits for the actual transfer. That it causes the next cycle to be idle is something more than blocking.

[kraigher]

As you mention blocking is only a problem if there is latency from request to response. Maybe the way the AXI stream VC is implemented adds a latency such that the next clock edge is missed. Maybe for AXI stream the latency could be zero and a blocking operation have full throughput. However for a memory mapped AXI port such as AXI4 lite there will typically be a latency and a blocking operation will never have full throughput.