In reply to Farhad:
It really should not matter what the size of your design is. What matters is the size of your testbench, how many people will be involved in its development, and how long will it need to be maintained either as a single project, or in follow-on projects.
The UVM could actually shorten learning overhead in terms of all the time it would take someone else to learn your custom SystemVerilog testbench where you’ve basically re-invented all the things in the UVM anyways.
There is a lot of stuff in the UVM, but there is no need to use most of it when getting a simple testbench running. Here are the bare minimum UVM concepts I recommend learning first. You can get a fair amount of constrained random testing done with the UVM just by understand just these three basic concepts.
- Components: Understand how to construct testbench hierarchy and the key components of any testench architecture: the top-level test, drivers and monitors. The basic phases needed for a class based testbench: build_phase, run_phase, and report_report, and how to determine when it’s time to end your test.
- Reporting: gives you a mechanism for filtering messages as well as promoting and demoting severity levels. Another key benefit is giving you a quick summary count of all the messages
- Configuration: A way of sharing data between components, especially the top-level testbanch component and the lower levels. Also gives you an easy way of setting test “knobs” from the command line without having to recompile your test
The next three concepts I highly recommend learning when getting started
- Transactions: standardizing the way class objects get cloned, copied, compared, and printed.
- Factory: Makes tests more reusable by overriding class types
- Sequences: A way of organizing stimulus and responses into sets of procedures.
Of course there is a larger list of thing you will probably never use, but it’s there when you need it.