Testbench in Master fails to run

[JimLewis]

I just forked the main branch of the repository so I can integrate it into OSVVM. The testbench had two issues. The first is in #7.

The second issue is when the sync1 signals are used to allow all TX to finish before starting RX, RX transactions complete without time passing (only delta cycles) and we run out of delta cycles (5000). I have to look at the RX pattern better (used by many OSVVM VC) as this may be an issue with the pattern itself.

[Louadria]

I had this issue as well when testing with bigger video frames.
I solved it by either receiving and sending simultaneously (thus not using the sync1 signals as you mentioned) or by adding wait statements. What I don't like about the latter is that when looking at the simulation waveforms, there are long periods of waits simply due to the transactions happening.

[JimLewis]

Sending words of a burst transfer one item at a time has a significant overhead.

The MIT also supports burst transactions. With a burst transaction on a TX interface, the test case first fills the burst FIFO and then does a SendBurst. With the RX interface, it first does a GetBurst and then receives the data. The issue with the receive interface then is somewhere in the process, it needs to know where the transfer boundaries are. I think for the Video interface, this is well defined - some other interfaces, not as much.

The FIFO in the transaction interface is relatively recent (around 2020). One adjustment that has not been made yet is to provide an option in which all the data is sent via the FIFO (including single word operations). This would then make it so the transaction handler did not have to move data from the BurstFIFO to the interface handler FIFO (TransmitFifo in VideoBusTx). The interface handler FIFO would only need to provide the additional transaction information - such as transfer characteristics (video shape and settings).

The other change that is coming is the Params data structure is now a singleton (you can still use it as a protected type though). There will be a field in the record to hold the ParamsID for a VC. This will allow the setting to be handled entirely by subprograms and not have to go through the SetModelOptions interface. I am thinking that there may need to be a SetModelParams to differentiate between Options being passed to the Transaction Decoder to handle (via SetModelOptions) and SetModelParams which allow options to be directly set. I will be making this change to the AXI VC sometime the first 2024 release.

[JimLewis]

The interesting aspect about the burst FIFO is then we would have a helper function that copies the contents of a BMP file into the BurstFIFO.

The AXI models need to be updated for bursting as in the TransactionDispatcher, they copy the burst FIFO information into the interface FIFO. I want to reduce the shuffling of data. However there are probably issues that need to be sounded out with the use model. I am looking forward to having time to work on it.