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

[Author]

Posts