Open Reisswolf opened 3 years ago
Interesting question. I think I have it designed so that if tready is not connected, then it is assumed to be constant 1, at least for AXI stream. But if the IP has a tready signal and you want to ignore it, the bus object will still grab on to it. Is simply not exerting backpressure from the testbench insufficient? The models should never drop tready unless you either set pause, configure a pause generator, or configure a maximum queue depth.
Just tried it one more time and I used the axis_test testbench and disabled the back-pressure test for simplicity. I can see some activity on the TREADY in the captured waveform. I think it is at the beginning of each test_run if I am not mistaken. VALID is low though. Maybe I am overthinking this.
In some implementations it is possible to use tready as optional port. While the module has a physical tready port for source and sink interfaces it is not required to use these ports. The port would be tied to const "1" on the master side of the module if not needed. Xilinx even has a HAS_TREADY flag as part of some of their IPs that is auto-propagation to connected IPs - only used in the in the block design implementation flow. I was experimenting and trying to find a way that would allow for automatic test coverage for both cases. It would be testing with toggling TREADY and back-pressure etc. in one case and with static TREADY forced by the testbench in the second case.
You could argue that an active high on TREADY should always work for the module and that it doesn't need to be tested separately. I found that I often end up with a design variation as part of the module that is more resource efficient for this case (bypassed additional registers, fifos, skid-buffers, etc.). Testing it in both configurations gives peace of mind since the design is not exactly the same anymore.
I didn't find a way that would keep TREADY high-all the time and I was wondering if I missed something or if you have an idea how to facilitate the static high TREADY.