Simulating Backpressure with the AXIS VC
February 27, 2023 at 16:55 #2166
I’ve been using OSVVM for several months with great success but I’ve run into a problem with simulating backpressure. At a high level my test bench looks like the following:
AXIS Transmitter –> DUT –> AXIS Receiver
I’d like to test my DUT for operation in the case that the AXIS Receiver is not ready for more data but the transmitter is ready to send. I’ve looked into the AXIS Receiver VC and found that the TReady signal is set by the DoAxiReadyHandshake() function but at the end of the transaction it looks like this function sets TReady to ‘0’. I’m not seeing where this would be set back to ‘1’ so that I could possibly control that and simulate the receiver not being ready for more data.
Is there a way to more directly control this ready signal in OSVVM? Or maybe there is already a system in place for simulating backpressure that I am not familiar with?
Any help is much appreciated.February 27, 2023 at 17:43 #2167
Currently the features that control these is described on pages 26 and 27 of the AxiStream_user_guide.pdf in OsvvmLibraries/Documentation. There are two controls for this:
RECEIVE_READY_BEFORE_VALID – this is true by default and allows TReady to be generated even if TValid is not asserted.
RECEIVE_READY_DELAY_CYCLES – Number of clocks to delay the assertion of TReady. This setting depends on the RECEIVE_READY_BEFORE_VALID setting. If RECEIVE_READY_BEFORE_VALID is TRUE, then delay (in clocks) is referenced to the completion of the previous cycle. If RECEIVE_READY_BEFORE_VALID is FALSE, then delay (in clocks) is referenced to when RValid is asserted.
This is demonstrated in the test cases TbStream_AxiTiming2.vhd and TbStream_AxiTimingBurst2.vhd. You will find these in the OsvvmLibraries/AXI4/AxiStream/TestCases directory. See the AxiReceiverProc. If you want to run these and look at the results, I recommend modifying OsvvmLibraries/AXI4/AxiStream/RunDemoTests.pro – this is exactly what it is intended to be used as. Simply replace the
with (the SetInteractiveMode logs all signals and allows you to display waveforms after the test case finishes running).
SetInteractiveMode TRUE RunTest ./TestCases/TbStream_AxiTiming2.vhd RunTest ./TestCases/TbStream_AxiTimingBurst2.vhd
Setting these is done via SetAxiStreamOptions transaction. The following generates RReady once every 5 clocks independent of whether RValid is asserted or not.
SetAxiStreamOptions(StreamRxRec, RECEIVE_READY_BEFORE_VALID, TRUE) ; SetAxiStreamOptions(StreamRxRec, RECEIVE_READY_DELAY_CYCLES, 5) ;
The following generates RReady 5 clocks after RValid is asserted.
SetAxiStreamOptions(StreamRxRec, RECEIVE_READY_BEFORE_VALID, FALSE) ; SetAxiStreamOptions(StreamRxRec, RECEIVE_READY_DELAY_CYCLES, 5) ;
Looking into the near term future, we have plans to update this to use randomization. We have been brainstorming about its operation/use model. I think the new features are ready to implement. The challenge is maintaining backward compatibility with the current features – and I think we have that sorted out.
JimFebruary 27, 2023 at 18:20 #2168
Thank you for the detailed response, Jim.
I misunderstood the correct way to use RECEIVE_READY_BEFORE_VALID and RECEIVE_READY_DELAY_CYCLES but this makes a lot of sense.April 8, 2023 at 01:52 #2189
I have added some beta features to the 2023.04 release to see if we can address this better. As a Beta feature, there is no documentation yet – as it may change. See AxiStream/TestCases/TbStream_SendGetRandom1.vhd.
JimApril 19, 2023 at 20:52 #2195
Thank you for this update, I’ll check it out in future testing.May 30, 2023 at 04:55 #2210
Adding random delays is a work in progress. I am posted about updates in https://osvvm.org/forums/topic/learning-osvvm-with-axi4#post-2209.
- You must be logged in to reply to this topic.