AxiStreamReceiver: Multiple Drivers on Transaction Record.
Why OSVVM™? › Forums › OSVVM › AxiStreamReceiver: Multiple Drivers on Transaction Record.
- This topic has 7 replies, 3 voices, and was last updated 1 year, 3 months ago by Cols.
February 23, 2022 at 06:36 #1932GianicoMember
I would like to consult this matter.
Currently we are involved in a project where our testbench has 2 AXI4 Stream Receiver VCs. This is due to the DUT has 2 output image streams to be checked.
In the Testcase, there are 2 processes for each instance of AXI4 Stream Receiver VC. The 2 processes are running in parallel. As a result we are encountering “AxiStreamReceiver: Multiple Drivers on Transaction Record.” from each instance of AXI4 Stream Receiver VC before the test simulation ends.
Is it ok if we are encountering that “FAILURE” results? Is there a way how to avoid that results?
NicoFebruary 23, 2022 at 17:03 #1933
Each AxiStreamReceiver needs its own transaction record. In the OSVVM testcases, we are using a single record named StreamRxRec. You need separate ones, such as StreamRx1Rec and StreamRx2Rec.
There is an example of this done with the Axi4 interface. See directory OsvvmLibraries/AXI4/Axi4/testbench_MultipleMemory. In there see the test case TbAxi4_Shared1.vhd which uses Manager1Rec and Manager2Rec. The test harness, TbAxi4_MultipleMemory.vhd, also uses the same names.
The whole purpose of the multiple driver error message is that when you cut and paste pieces of code in this environment, it is easy to forget to use the transaction record that corresponds to the process that drives it.
Generally speaking then, a given record only driven by a single process. We have a methodology to allow that to stop driving a record in one process so another process can drive it, but that is not the case you are looking at.
JimFebruary 24, 2022 at 04:24 #1934GianicoMember
Thank you very much for the very informative response.
We will apply what we have learned.
NicoFebruary 28, 2022 at 04:22 #1938
Hi Jim, we have done your suggestion but still encounter the Failure error.
It can still read multiple drivers per process even if we declared it separately.
Do you think it is advisable to finish all transactions first on the first instance of axi stream receiver before proceeding to the transactions of the 2nd axi stream receiver?
Thank you very much.
Regards,February 28, 2022 at 04:57 #1939
Hi Cols and Nico,
Did you look at TbAxi4_Shared1.vhd? Each instance of the VC needs to have its own record. See TestCtrl_e.vhd in the same directory.
Send me an email with your TestCtrl in it. It would probably be good to see your test harness also.
JimFebruary 28, 2022 at 16:16 #1940
Hi Cols and Nico,
This brings up a bigger question, “how do we debug our simulations when something like this happens?”
First observe the time at which something happens. Look at what transactions were running before that time.
If our simulator supports interactive debugging such as single step and/or breakpoint, then the following may help you find the root cause:
* Run the simulation until it fails and single step beyond the failure point to find which call caused the failure.
* Run until a time value just before the failure happens. If your simulator supports breakpoints, it may be helpful to set them on the transactions that ran just before the time of failure. Single step until the test fails. You can single step over many calls. First we are looking for the call that causes the failure. Once we identify the call, we can step into it as necessary.
If our simulator does not support interactive debugging (such as GHDL), you can probably find this problem doing code analysis. In your editor, find all uses of the transaction record for the first VC. Are any of them outside of a single process? Now do the same for the other transaction record.
Again, if you can share your code with me, I can help you identify the problem.
JimMarch 1, 2022 at 06:11 #1941
Thank you very much for responding. We are currently debugging and we are doing the method you suggested when our simulator does not support interactive debugging. Please check our reply.
ColsMarch 1, 2022 at 07:05 #1942
We have resolved the issue. We checked our other components and found out that the one causing the error is in the test.
We are truly grateful for your help.
Thank you very much.
- You must be logged in to reply to this topic.