Simulating Backpressure with the AXIS VC

[Brad Adam]

Hello,

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.

[Jim Lewis]

Hi Adam,
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
RunTest ./TestCases/TbStream_SendGetDemo1.vhd
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.

Best Regards,
Jim

[Brad Adam]

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.

[Jim Lewis]

Hi Adam,
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.

Best Regards,
Jim

[Brad Adam]

Thank you for this update, I’ll check it out in future testing.

[Jim Lewis]

Hi Adam,
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.

Best Regards,
Jim

[Author]

Posts