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

#2407
Jim Lewis
Member

> With VUnit I can pass a switch to the run.py and get list of tests and then run a specific test. I can choose whether to run it in in GUI mode or batch mode. How can I do that with OSVVM AXI4 tests?

> I can see that with OSVVM, each test is a different architecture of the same entity. But can OSVVM list tests like we do with VUnit and then run a specific test in GUI mode of QuestaSim?

Do you like this feature?

I have not found a use case for that at this point.

I start testing with a test plan and a list of items that identify what needs to be tested.

In a testbench directory (often named testbench), I create the test harness that connects the DUT, Verification Components, and Test Sequencer (often named TestCtrl). I put each separate test harness in a separate directory. I put each in a separate library – this allows every testbench to use the name TestCtrl for the test sequencer. I create a script that analyzes (compiles) the test harness – often named either testbench.pro (matching the directory name) or build.pro.

If I have just a few test cases, I will put them in the same directory as the test harness – this is what is done in OsvvmLibraries/UART/testbench.

If I have many test cases or have multiple test harnesses that will use the test cases, I put the test cases in a separate directory. In both Axi4 and AxiStream the test cases are in the TestCases directory (see OsvvmLibraries/AXI4/Axi4/TestCases). These too have a script that analyses and runs them – such as TestCases.pro (again matching the directory name) or build.pro.

Test cases are an architecture of the TestCtrl entity. Generally each test architecture has a configuration declaration with it – put in the bottom of the file. Since the configuration declaration runs the test case, I name it with a “Tb” or “tb_” prefix and that is what I tell the simulator to run. The suffix of the name is generally the test case name – which most often also matches the architecture name.

The first run of a test case is done interactively with the following three steps:

TestName  Tb_Test1
analyze   Tb_Test1.vhd
simulate Tb_Test1

Here Tb_Test1 is the name that the VHDL code gives the test case, with the SetTestName(“Tb_Test1”) in the VHDL code. The file Tb_Test1.vhd contains both the test architecture (named Test1) and the configuration declaration (at the bottom and named Tb_Test1). If you follow this naming methodology, then to create test2, copy Tb_Test1.vhd to Tb_Test2.vhd and inside the file replace Test1 with Test2 and you are good to go (no additional configuration declaration to create)

If you follow the steps in the above paragraph, then you can run the test with the shorthand:
RunTest Tb_Test1.vhd

Once I get a test case running, I add it to a the script that is in the same directory as the Test Cases (as noted above, this may be either the testbench or TestCases – depending on the number of test cases).

Once a test case is run and passes, it is only run as a regression unless it fails in regression and requires debugging.

Coming back to your question then, either
1) I am in the process of developing a test case and I run it interactively, so the name is fresh in my mind or
2) The test case failed in regression, so I have its name and I run it interactively.

So while I think the VUnit capability is cool, I have not found a use case (need) for it.