Learning OSVVM with AXI4

[Adam]

I’ve experimented with OSVVM previously, but I’m now using it on a real design for the first time – and finding it very useful!. My design bridges an AXI4 subordinate to generic read and write ports. The ports are separate, cycles can run concurrently on each. So, I’d like to run AXI4 reads and writes concurrently and independently in my simulation. Presumably I could instantiate a couple of OSVVM AXI4 managers, one wired for writes, one wired for reads, with unused signals tied off – then use separate (concurrent) processes to send transactions to each?

Is there a way – or are enhancements planned – to introduce some randomness into the OSVVM AXI4 manager’s behavior? For example, to have it emit write data one or more cycles prior to write address when the write channel is idle? To introduce random pauses in address and/or data streams?

Any feedback much appreciated!

[Jim Lewis]

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

[Jim Lewis]

Hi Adam,
I just pushed a new version of Axi4Manager.vhd with random delays. They maintain backward compatibility, and hence, you have to turn on the randomization features. No documentation yet. I still have to add random delays to Axi4Memory and Axi4Subordinate – I also need to add them to the VTI versions of the VC. Also the initial delay values will likely need a tune-up to be better suited to what we need to accomplish with the interface.

See test casesTbAxi4_ManagerRandomTiming1.vhd and TbAxi4_ManagerRandomTimingAsync1.vhd in the directory OsvvmLibraries/AXI4/Axi4/TestCases.

I added random delays to AxiStream VC first (but also not VTI yet). It is looking like the control capability for Axi4 has more capability than is needed, but comes in handy for AxiStream.

Cheers,
Jim

[Jim Lewis]

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

[Adam]

Thanks very much Jim, I will take a look. I am now also working on an AXI Stream tranmitter as part of the same project. I will get back to you if I see anything interesting.

[Jim Lewis]

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

[Joseph]

I have a test bench that is run from a DO file. It is based on OSVVM. We were wanting to add code coverage, so I was looking into making a PRO file with the settings SetCoverageAnalyzeEnable and SetCoverageSimulateOptions set to true. But I’m not sure how to run the DO file in that PRO file. I’m relatively new to OSVVM, so any input is appreciated. I wasn’t sure how to post this question, so I put it in this post. Is there a way to run a DO file, which contains all of the compile and simulation commands needed, in a PRO file? Thanks.

[Jim Lewis]

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

[Joseph]

Hi Jim,

Thanks for the speedy reply. I can’t post the DO file, but I can try to post the what it is supposed to do. This test bench passes vector files which poke around registers. The vector files use a custom API that my team developed that go through a VHDL file to a VHDL test bench. It is based on OSVVM, but there’s the extra layer from our custom API. There are some Verilog and Systemverilog files involved in the project.

set variables to directories
set variables to default command line options

while loop parsing command line options from ModelSim command line and sets variables to them

a number of vlib, vmap, vcom, vlog, and vsim commands for various files and folders

I’m quite limited in what I can post. I hope it’s enough to get somewhere. It’s a pretty complicated DO file.

It sounds like I would have to translate that into a PRO file. Is there a way it could be called in a TCL file and that be called in a PRO file? Or is there a way to put the coverage controls into the DO file itself? Can OSVVM compile Verilog or Systemverilog files?

Thanks,
Joseph

[Jim Lewis]

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

[Author]

Posts