Bug in AxiStream Receiver for SetAxiStreamOptions that changes WaitForGet

[Hassan]

I require that when the simulation starts the AxiReceiver TReady is low and it stays this way until the VC is given command to read input. This is one of the tests that I have written.

The WaitForGet is declared in line 153 of the AxiStreamReceiver. I tried to change its state using SetAxiStreamOptions(StreamRxRec, RECEIVE_READY_WAIT_FOR_GET, TRUE); as the first line in the AxiReceiverProc. However, it changes state in the VC itself on the first rising edge of the clock inspite of this.

I am forced to change the WaitForGet in the VC soure code itself so the TReady signal of the VC does not get asserted after the simulation starts. This is because the TReady is asserted by the VC before the reset is released and before the clock signal starts to toggle. Why is the TReady being asserted so soon?

[Jim Lewis]

Hi Hassan,
The 2024.07 release will have a limited set of predefined events added to OSVVM. One of them will signal that the test case has initialized the VC and the VC can start handler type operation.

I have an initial proof of concept test case working at this point and expect to release it to the Dev branch sometime soon.

In addition, sometime in the future (probably not 2024.07) we will make these settings configurable. The initial value for the WaitForGet will be included as part of this. I am trying to be very conscious about making changes that break backward compatibility. With the safety net of a configuration package and the ability to retain backward compatibility, I will feel empowered to reconsider what the default should be.

Jim

[Ariel]

Hi Jim,

Are there any updates on this?

I am also looking to not having tready asserted by the receiver at the beginning, but instead using RECEIVE_READY_BEFORE_VALID=FALSE and RECEIVE_READY_DELAY_CYCLES to assert tready after tvalid is asserted. See here https://ibb.co/jZVyy9ZH
Thank you.

ps: Do you have a new and updated documentation for the AxiStream user guide? I couldn’t find RECEIVE_READY_WAIT_FOR_GET there.

[Ariel]

Update: I re-transmitted again and on the second batch of data, then a_ready_in is asserted the clock cycles I set with RECEIVE_READY_DELAY_CYCLES. See here: https://ibb.co/MxD4D0fF

Is there any specific reason? Is it possible to set at the beginning of the process whether tready should be 1 or 0?

[Author]

Posts