Reply To: AXI Verification Components, OSVVM vs UVVM

[Jim Lewis]

> 1. Do the OSVVM VC for these AMBA busses support all parts of the specification for these busses?
That is certainly the intent.

> 2. What is the difference between the OSVVM VC for these busses and the ones from UVVM?
I will only talk about the OSVVM VC as I don’t pay attention to the UVVM VC.

All OSVVM VC use the OSVVM Model Independent Transaction (MIT) capability. The OSVVM MIT defines the transaction API and transaction interface for address bus (aka memory mapped – such as AXI4, Avalon, Wishbone) and streaming (such as UART, AxiStream) interfaces. All OSVVM VC implement a subset of the transaction API defined for their class (address bus or stream).

From a test case developer perspective, if you know the MIT transaction API for a given class, then to work with a new VC in that same class only requires you to look up the subset of transactions supported by the VC. There will also be cases where you may be able to reuse subprograms that do multiple transactions on an interface.

From a testbench perspective, if for a given chip, you have to switch between AXI4 and Avalon, if you were careful about how you wrote your test cases, the intent is that you will be able to reuse the tests that test the functionality of the design – you will need additional test cases that test the specifics of the interface.

If we look at the OSVVM AXI4, Axi4Lite, and AxiStream VC, each of them support a fairly sophisticated means to randomize the cycle in which xValid and xReady are asserted for the interface. All aspects of the interface are accessible.

For more details on the AXI4 VC see OsvvmLibraries/Documentation/Axi4_VC_user_guide.pdf. I noted that the randomization capability is not yet discussed in the user guide. You can find examples of using it at OsvvmLibraries/AXI4/Axi4/TestCases/TbAxi4_ManagerMemoryRandomTiming1.vhd. More details of the DelayCoverage is in OsvvmLibraries/Documentation/DelayCoveragePkg_user_guide.pdf.