AxiStreamReceiver: Multiple Drivers on Transaction Record.

[Gianico]

Hello!

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?

Please advise.

Thank you!
Nico

[Jim Lewis]

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

Best Regards,
Jim

[Gianico]

Hello Jim!

Thank you very much for the very informative response.

We will apply what we have learned.

Best regards,
Nico

[Cols]

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,

[Jim Lewis]

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.

Best Regards,
Jim

[Jim Lewis]

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.

Best Regards,
Jim

[Cols]

Hi Jim,

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.

Thank you.

Regards,
Cols

[Cols]

Hi Jim,

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.

Regards,
Cols

[Mahmoud]

Hi Jim,

I’ve seen in your reply above:

“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.”

How this can be achieved? I have a similar situation where I would like to stop one process from driving a rec and start driving it from another process.

Many thanks,
Mahmoud

[Jim Lewis]

Hi Mahmoud,
Please see test case OsvvmLibraries/AXI4/Axi4/TestCases/TbAxi4_ReleaseAcquireManager1.vhd

Best Regards,
Jim

[Jim Lewis]

Hi Lars,
OSVVM has an InterruptHandler.vhd in OsvvmLibraries/Common/Src. It handles switching records for you. When there is no interrupt pending, it connects the transaction record of TransRec to the AddressBus VC (such as Axi4Manager or Axi4LiteManager). When an interrupt is pending it connects the InterruptRec to the AddressBusVC.

The InterruptRec can come from either TestCtrl or a separate entity (especially if it is always the same).

Testbench that tests it is here: OsvvmLibraries/Common/Src/TbInterrupt/Testbench
You do not need the InterruptGenerator if you already have a source of interrupts. The array of interrupts is defined by: InterruptGlobalSignalPkg also in OsvvmLibraries/Common/Src, but you are not required to use this as long as you have an array of interrupts (even an array of 1 to 1).

Documentation is here: OsvvmLibraries/Documentation/InterruptHandler_user_guide.pdf

Best Regards,
Jim

[Author]

Posts