Reply To: Dissecting the OSVVM AXI Master BFM
Why OSVVM™? › Forums › OSVVM › Dissecting the OSVVM AXI Master BFM › Reply To: Dissecting the OSVVM AXI Master BFM
Jim Lewis> I can see that the scripts use the explicit name of the file for analyze and run_test TCL commands. However, it is also possible to just do a file search and with the filenames in a list, iterate over the list and call analyze or run_test for each of them.
> Why isn’t it done in this way?
It comes down to testing philosophy. I see the scripts as an exact specification of what must be analyzed and/or simulated. No matter what else changes, I can depend on these exact things being analyzed or run.
In a CI/regression flow, we always analyze and simulate everything – so there is no advantage to using a make flow. I saw a post from a simulation vendor a while back suggesting that we should be using their clever file based compile flow – lets get real, compiling all of OSVVM takes 20 to 60 seconds depending on the simulator. Compiling the whole thing is not so painful.
> Also, I was expecting to see a whole lot of commands that only compile the files and then, a whole lot of commands to run tests. But then I realized that since each testcase has a different configuration in its architecture, we compile one file and run simulation and then move to the next file. So the TCL scripts compile all files except the test cases, these are compiled using run_test command and this causes the test to be run as soon as that file has been compile.
The pro scripts that start with OsvvmLibraries/OsvvmLibraries.pro analyze all of OSVVM – so this hierarchy of scripts is a whole lot of compile.
The pro scripts that start with OsvvmLibraries/RunAllTests.pro compile the OSVVM public test suite and run the test cases – this set of scripts is a little compile to build the test harnesses, and then it is RunTest (which calls TestName, analyze, and simulate). You should note that to use RunTest you have to follow a naming pattern where the TestName matches the file name and matches the configuration name that is used to run the test case. This is explained in the Script_user_guide.pdf.
As I am developing tests, I keep a build.pro for the design, I keep a build.pro for the test infrastructure, I keep a RunAllTests.pro that runs all the debugged test cases, and a debug.pro for the test cases I am developing. Once a test case is debugged, it moves from debug to RunAllTests.pro. If a test case fails regression and it takes a lot of debug, it might move back to debug.pro temporarily or alternately I can just rerun it using RunTest from the command line if needed.