Reply To: Running AXI4 Simulation from OSVVM Libraries repository

Why OSVVM™? Forums OSVVM Running AXI4 Simulation from OSVVM Libraries repository Reply To: Running AXI4 Simulation from OSVVM Libraries repository

Jim Lewis

> Does OsvvmLibraries contain test plan that describes what specific tests exist?

I have not published one. I have it in my notebook. It would be a good idea to publish it.

> These TCL commands TestSuite, RunTest and SkipTest appear to be defined in the OsvvmProjectScripts.tcl. There are other commands like build, analyze, include for which I have found no description anywhere. Is there a detailed exposition of the TCL API anywhere or it is considered not important for the end user?

Script documenation is in the Script_user_guide.pdf in OsvvmLibraries/Documentation. Currently all of the OSVVM API (TestSuite, RunTest, SkipTest, build, analyze, include, build) are defined in OsvvmProjectScripts.tcl – it is large and it may be refactored in the future.

Full documentation on OSVVM starts with README.rst (this reads better at – see bottom of page) or if you prefer pdf, start with OSVVM_Overview.pdf also in OsvvmLibraries/Documentation.

> This second script ( makes no mention of the RunTest TCL command.

OSVVM’s include and build replace tcl’s “source” and eda tool macro’s “do”. Use build from the simulator command line. Use include from inside a *.pro script.

The “include ./TestCases” in is short-hand for “include ./TestCases/”. If you look in ./TestCases/ you will find the

> Also, I see that two libraries are created: osvvm_tbaxi4, osvvm_tbaxi4_multiplememory. How come testbench test case/sequence libraries are being created for the AXI4 but not for Ethernet, UART and DPRAM?

For those the library and test suite are in the testbench script. When there are multiple testbench directories that run in different libraries then the library and TestSuite need to be where the testbench directories are.

> I do not understand how the library command suddenly creates a new library that is full of precompiled files since the earlier scripts did not compile them.

The library command creates a library if it does not exist, if it does exist, create a mapping to it, and then activate that library such that future calls to analyze (or RunTest) compile things into that library. Hence, if you have already done RunAllTests for a given directory at some time in the past, its library will exist and anything previously compiled into that library will still exist.

> The TbAxi4_DemoMemoryReadWrite1 contains axi4manager, axi4monitor, axi4memory along with the TestCtrl entity that has the configuration to compile the TbAxi4_DemoMemoryReadWrite1 test sequence architecture.

The TbAxi4_DemoMemoryReadWrite.vhd contains an architecture of TestCtrl and the configuration declaration TbAxi4_DemoMemoryReadWrite1 that binds the test architecture to the test harness for simulation. The test architecture has a separate process for each independent interface in the test harness. The test harness contains instances of the DUT, VC (axi4manager, axi4memory), and TestCtrl.

Do some reading starting with the OSVVM_Overview.pdf then follow the other documents. Alternately SynthWorks offers classes on OSVVM: Advanced VHDL Testbenches and Verification see: We have an on-line class coming up in early June. We have in person classes coming up in late June in Germany and September in UK.

> If I need any files to be compiled again like the testbench or DUT files, I guess I could just recall the again or run the analyze command on the specific file.

Generally I setup the or files to compile all the sources that are the OSVVM library sources. I setup the to compile the test harness, and compile and run test cases. When I am running test cases, I run them interactively as I am developing the test cases and then for regression, I run them by creating a for that specific test harness or suite of test cases.

Generally for your design, you will run one time to build the OSVVM libraries. You will need to create a to build your DUT, a to build your test harness, and a to build your verification components. When you fix a design bug, you will need to rerun and – hence the reason why we build separately. The compilation is fast enough that it is faster to run a script that builds many things than to just the things that need analyzed.

I apologize if I missed any of your questions, please repost them if I did.