Learning OSVVM with AXI4

Hi Adam,
WRT randomness in dispatching each channel, that is what I am currently working on. I added it to AxiStream in a Beta form in an earlier OSVVM release – it has changed some on the Dev branch. I will be adding it to Axi4 VC next. Each channel will be independent, so a write data should randomly happen prior to write address, as will random pauses. I can let you know when it is in the Dev branch if you like.

You can have write data happen before write address by using the asynchronous and single channel operations. If you want to do this in a determinist fashion, then you can do:

-- WriteDataAsync needs ByteAddr to determine the ByteEnables.  It is typically a value.  If left off, 0 is used.
WriteDataAsync(ManagerRec, ByteAddr, X"AA00") ;   
WaitForClock(ManagerRec, 2) ; 
WriteAddressAsync(ManagerRec, X"A0000") ; 

If you want to drive the Read and Write interfaces from separate processes, you can use two separate instances of the Axi4Manager VC as you suggested. Alternately, if you just want to do read and write operations simultaneously, you can use the asynchronously dispatched operations as shown below. The downside to this is that the ReadCheckData is blocking (there are plans to address this too, however, it is further out than randomization).

for i in 1 to 5 loop 
    WriteAsync(ManagerRec, "X10000"+i, X"1000"+i) ; 
end loop ; 
WaitForClock(ManagerRec, 2) ; -- Add enough wait for one write to complete
for i in 1 to 5 loop 
    ReadAddressAsync(ManagerRec, "X10000"+i) ; 
end loop ; 
for i in 1 to 5 loop 
    ReadCheckData(ManagerRec, X"1000"+i) ;  -- These block until data is available
end loop ;  

Cheers,
Jim

Oops. It took me until now to push the files to GitHub properly.

Hi Adam,
The AxiStreamTransmitter and AxiStreamReceiver both have randomization in them. There is a corresponding test case that has good examples in it, TbStream_SendGetRandom1.vhd. You can find it in OsvvmLibraries/AXI4/AxiStream/TestCases. It was just updated (meaning just before this post) to better show the different use models for either using the existing settings or changing them.

Best Regards,
Jim

Hi Joseph,
The coverage controls work in a coordinated fashion with the OSVVM scripts that analyze and simulate the design. How about posting your do file – or a representative piece of it and I can suggest how to update it to use the OSVVM script API instead – it is actually quite a bit simpler than using the vendor commands directly.

For future questions, it is good practice to start a new thread.

Jim

Hi Joseph,
A pro file is tcl plus a procedure abstraction layer that replaces the calls to vlib, vmap, vcom, vlog, and vsim with library, LinkLibrary, analyze, analyze, and simulate (respectively).

Sounds like your do file is fairly complicated. Not sure if you can successfully transition it or not. However, here is how to try to do it:
replace vlib with library
replace vmap with LinkLibrary (or library)
replace vcom and vlog with analyze
replace vsim with simulate
start your pro script with build (replacing do or source)
within a pro script call other pro scripts with include (replacing do or source)

You only need to do the above for the part that you want to run coverage on needs to use analyze and simulate. Since pro scripts are tcl, it is ok to mix do scripts with pro scripts.

Generally analyze and simulate do not need options like language version (because you set it once and forget it) and library (since it remembers the setting from the previous library command). That said then, if vcom, vlog, or vsim use a -work or -lib option, be sure that the last OSVVM library command referenced that library.

There are additional benefits to going this path. By running your simulation with OSVVM’s simulate and starting the script with build (rather than do or source), you will be able to get OSVVM’s reporting. For details on this see: https://osvvm.github.io/Overview/Osvvm3Reports.html.

For more on OSVVM scripting see Script_user_guide.pdf in the OsvvmLibraries/Documentation directory.

Jim