Reply To: Running AXI4 Simulation from OSVVM Libraries repository

[Jim Lewis]

The scripting provided as part of OSVVM is hierarchical. If we take a look at $OsvvmLibraries/OsvvmLibraries.pro, we will see:

include ./osvvm/osvvm.pro
include ./Common/Common.pro

if {[DirectoryExists UART]} { 
  include ./UART/UART.pro
}
if {[DirectoryExists AXI4]} { 
  include ./AXI4/AXI4.pro
}
if {[DirectoryExists DpRam]} { 
  include ./DpRam/DpRam.pro
}
if {[DirectoryExists Ethernet]} { 
  include ./Ethernet/Ethernet.pro
}
if {[DirectoryExists VideoBus_LouisAdriaens]} { 
  include ./VideoBus_LouisAdriaens/VideoBus.pro
}
if {[DirectoryExists SPI_GuyEschemann]} { 
  include ./SPI_GuyEschemann/SPI.pro
}
if {$::osvvm::ToolNameVersion ne "XSIM-2023.2"} {
  if {[DirectoryExists CoSim]} { 
    include ./CoSim/CoSim.pro
  }
}

Each directory contains a script (*.pro) to analyze the files in it. By convention that file is named either Directory.pro (historical) or build.pro (newer). The build/include command sources a *.pro script and replace TCL’s source (and the tool vendors do). When called with build/include, files specified in a *.pro have a path relative to the location of the script. This makes it easy to organize VC and the OSVVM libraries as you see fit as the only thing that needs to know a path is a high level script.

The scripts (*.pro) are a procedure layer (hence pro) that runs on top of tcl. So the scripts are allowed to include tcl as needed. The if statements in the script check and see if a given submodule (lower level repository) is present and if it is run its script to analyze it.

The osvvm.pro and common.pro are not optional, but the rest are and are only compiled if they are present. Generally though there is no disadvantage to including all of the OsvvmLibraries submodules as it takes less than 60 seconds to analyze.

Now for your questions:
> 1. What are all those scripts inside the Scripts folder of the OsvvmLibraries? Are they required by user for every user project? I was hoping to see a make file but Osvvm does not seem to use that.

In general, if you are just using OsvvmLibraries and not editing it, you only need to compile it once. So you run the build $OsvvmLibraries/OsvvmLibraries.pro one time as you are establishing your project (or each time a CI/CD regression is running). It takes less than 60 seconds.

Makefiles remove redundant compilations on portions of code you are actively developing. If you are not working on the OsvvmLibraries themselves, then there is no need for a makefile – you are going to build OSVVM one time.

As a developer, a make file would be worth creating if compilation took some tangible amount of time. It doesn’t. So I have not bothered. Since VHDL has libraries, VHDL tools know the dependencies – tools could internally implement a make capability.

> 2a. We have RunAllTests.pro, RunAllTestsVti.pro and RunDemoTests.pro.

OsvvmLibraries includes the OSVVM test suite used to test each VC. The regression test suite for a given VC is named RunAllTests.pro. A demo test suite is provided in RunDemoTests.pro.

The RunAllTestsVti.pro are used to test the Virtual Transaction Interface (VTI) version of the AXI4 and AxiStream verification components. The VTI VC connect to the test sequencer using external names (see AXI4/Axi4/testbenchVti) for an example of how this works. It is also documented in the Axi4_VC_user_guide.pdf in the OsvvmLibraries/Documentation directory. The VTI VC are required when a VC is internal to the DUT, such as with Xilinx Zynq.

Other than the interface, the VTI VC are identical to the port based VC. Hence the differences in the tests are in the testbench and testbenchVti directories and the use the same TestCtrl architectures as test cases.

> 2b. Why do we need all these in the AXI folder and also the OsvvmLibraries folder?
The test cases are hierarchical. This allows you to do, build $OsvvmLibraries/RunAllTests.pro to run everything that is present in your distribution (meaning if you do not have the UART repository, its test cases will not run).

> 3. For the AXI4 MM BFM, in the src folder we have these files Axi4Manager.vhd, Axi4Manager_xilinx.vhd, Axi4ManagerVti.vhd. Why do we need different versions of the same thing as different source files?

Axi4Manager.vhd is the port based version of the VC. It is what we originally built and as a result maintain. The Axi4ManagerVti.vhd creates the transaction API as an internal signal (named TransRec in the entity declarative region) that the test sequencer (TestCtrl) connects to using an external name. Again this is to allow the Axi4ManagerVti to be internal to a Xilinx DUT and the TestCtrl to connect to it without adding a signal to the DUT.

The Axi4Manager_xilinx.vhd is an experimental version for Xilinx. We are trying to bring up all of OSVVM within Xilinx XSim. Sometimes this requires tool specific work arounds. That said, we have most/all of the OSVVM utility library (osvvm) working (except for some of the resolution functions). Running the VC is currently problematic, but we have all of our blocking issues submitted to Xilinx and are hopeful for a solution in 2024.

Hopefully the Axi4Manager_xilinx.vhd will go away. The Axi4Manager.vhd and Axi4ManagerVti.vhd are here to stay.