UVM testbenches are widely used for verification, and Vunit could be used as a flow-controller for such methodologies, if some adaptations are made.
UVM testbenches have a top-level SystemVerilog module which has a slightly different style than a Vunit-based SystemVerilog testbench. Nevertheless, it would be nice to add the support for this style either using SystemVerilog or Python-based adaptations.
Here are the differences:
The toplevel module which is passed to the simulator command calls a run_test (from the UVM base), which dynamically creates the class-based testbench hierarchy. The argument for this function is specified at run-time using the simulator argument +UVM_TESTNAME=. Testcases/testsuites are not declared within the top-module in the SystemVerilog world.
Constrained-randomization based testbenches require a seed value to be passed from the simulation command-line at run-time. This cannot be specified within the SystemVerilog/HDL code, and therefore need to come from the Python world
The simulation stop command is issued by a $finish task deep in the UVM base-classes. So, a testcase run actually ends the simulation without returning control back to the Vunit runner. Therefore, the Vunit runner assumes that the test simulation just stopped unexpectedly
UVM has its own messaging/logging/verbosity. A pass/fail test result is decided by parsing the UVM_ERROR and UVM_FATAL messages within the simulation transcript/log
a test-suite description contains the testcase name, along with the number of random seeds it has to be simulated with. The list of seeds may also be specified with fixed values. The testcase along with the seed can be seen as a test-configuration in Vunit terms. This would ideally be in the Python world (for example in a UVM TB specific run.py file).
UVM has an internal timeout mechanism, which triggers a UVM_ERROR message, and then exits the simulation. This timeout value can be either set in the testbench code, or using the simulation command-line option +UVM_TIMEOUT=<>/. This should be supported by all simulators. It allows the user to extend the timeout for specific tests which may run longer than a default timeout.
the UVM messaging mechanism also comes its own verbosity handling. All messages of type UVM_INFO are affected by the verbosity level set for that particular message or that scope. The verbosity level is specified by the simulation command-line option +UVM_VERBOSITY=<>. All messages of type UVM_WARNING, UVM_ERROR and UVM_FATAL are displayed regardless of the verbosity level.
UVM testbenches are widely used for verification, and Vunit could be used as a flow-controller for such methodologies, if some adaptations are made.
UVM testbenches have a top-level SystemVerilog module which has a slightly different style than a Vunit-based SystemVerilog testbench. Nevertheless, it would be nice to add the support for this style either using SystemVerilog or Python-based adaptations. Here are the differences: