Adopting SystemVerilog can be challenging to some, and learning the UVM at the same time might seem overwhelming. There is no getting over the fact that if you are going to develop any reasonably sized testbench in SystemVerilog, you need to learn how to declare and construct a class. You also need to learn a few Object-Oriented programming principles so you can extend a UVM class into something for your particular needs.
Once you lean those principals, adopting the UVM can significantly reduce the amount of time it takes to build your testbench because it provides the infrastructure to handle many of the common tasks used in functional verification today. Just a few examples of some of the features included in the UVM are:
- Coordinating stimulus across multiple interfaces in your design
- Setting “knobs” to configure your test from a single location without having to modify or re-compile lower level source code
- Determining when it is time to end the test
By using a common set of industry standard verification methodology and practices, engineers are given the ability to develop modular, reusable verification IP developed by project teams internal or external to their company. Another benefit of the UVM is that it is extensively documented as well as having a considerable amount of tutorial and example material readily available. Mentor Graphics provides the Verification Academy Cookbook and the Cookbook Recipe of the Month Seminar Series to get you started.
One of the significant features of the UVM that differentiates it from what was lacking in the OVM is its Register Layer (it was so lacking that Mentor back-ported the UVM Register Layer to the OVM for those users not yet able to migrate to the UVM). The compelling use model for the UVM Register Layer is that it abstracts away much of the UVM that one needs to learn as a test writer. You write much of your test as you would in software:
spi_rm.ctrl.read(status, read_data, .parent(this));
spi_rm.ctrl.write(status, write_data, .parent(this));
Here we are issuing read and write commands to the control register of an SPI register model. All of the underlying translations to a specific DUT interface with its specific protocol are handled by Register Layer with configuration information set up by the testbench architect.