Why I Like UVM Express

This week Mentor released an extension to UVM called UVM Express. Normally, when someone announces an extension to the UVM, it involves more code or more tools. Not so in this case. With the library passing 67,000 lines of code (can that be right??), Mentor isn’t just piling on more code. UVM Express is an “extension” that helps people use what’s already there.

Here’s a few excerpts from the UVM Express page on Mentor’s verification academy with some additional commentary:

The UVM Express is a collection of techniques, coding styles and UVM usages that are designed to increase the productivity of functional verification. The techniques include raising the abstraction level of tests, writing tests using BFM function and task calls, adding functional coverage, and adding constrained-random stimulus generation.

Seasoned (aka: skeptical) verification engineers that have seen their share of new product announcements promising “increased productivity in functional verification” and suggesting “raising the level of abstraction” might be tapping the back button by this point but I’d encourage those skeptics to read on. I think the “revelations” appear in the next few sentences.

If you don’t have a full-time verification expert on staff, or if you are not a full-time verification engineer, UVM Express might be for you. Most verification teams do not have a full-time verification expert on staff, have time and budget restrictions and cannot adopt the UVM in whole or adopt it as quickly as they might like. These teams are usually under-staffed, under-funded and over-worked. They are exactly the kind of people that the UVM is meant to help, but the first step towards adoption is too high.

The UVM Express can be thought of as a series of steps or train stops on a journey that may ultimately lead to Full UVM.

That, to me, is an all important recognition that while UVM is great new technology for functional verification, adopting UVM and actually realizing the benefits is extremely challenging.

In reading on you’ll see that UVM Express is a 3 step approach for building BFMs, coverage agents and stimulus agents with UVM. It’s not an all or nothing thing which means there’s value in going 1 step, 2 steps, 3 steps or further to “Full UVM” adoption. It also doesn’t touch all aspects of building a testbench (there’s still modeling and scoreboarding which UVM Express doesn’t touch); it focuses on a few important aspects of testbench development and leaves the rest, presumably, for later. A 3 step approach means you can use UVM Express to encourage people to master one particular expertise before moving on. I like that because UVM tends to be a giant wave of classes, macros, global variables, under-the-hood control and hidden optimizations that easily overwhelms newbies. Seems UVM Express could reduce that giant wave into a more manageable series of ripples. There’s more to it obviously, so I’d encourage people read through the material and watch the videos Mentor has posted to get the idea.

Unfortunately, the one thing that Mentor doesn’t explicitely say in their UVM Express collateral (maybe I missed it) is that UVM Express takes steps towards restoring a sense of inclusiveness within front-end development that has been steadily crumbling over the last 10 or so years.

It used to be that designers and verifiers all wrote code in the same language and used simple directed testing techniques. Then, in around 2000, came the invention of HVLs and release of verification libraries like eRM, RVM, VMM, AVM, OVM and now UVM. The upside of that transition was increased productivity for verification engineers, provided they could successfully climb the learning curve. The downside, however, is that HVLs and new verification libraries – not mention constrained random w/functional coverage, assertion libraries, formal and others – quickly became a wedge that’s now been driving design and verification engineers apart for more than a decade. In my opinion, UVM has the potential to become the biggest wedge of all. Left unchecked, not only will it drive designers and verifiers further apart, it will also further the gap between novice and expert verifiers.

UVM Express seems to be a baby step toward restoring the inclusiveness we had when everyone wrote simple Verilog or VHDL. That’s huge and I don’t think the importance of a restored sense of inclusiveness can be overstated, especially when you consider the newest gap in our development process between hardware and software engineers (we’ll leave that for another time :)). That’s really why I like UVM Express and hope that similar ideas are on the horizon.

For teams that are interested in agile development, UVM Express should be of particular interest. The method of incremental UVM adoption plays very nicely with the idea of incremental development. For example, a first product increment might require implementing a small subset of design features, completion of UVM Express step 1 (aka: the BFM step), creation of a simple test harness and a short list of directed tests. With that, a team can sanitize the design without UVM and designers would have a testbench that they’d be comfortable with, just like the old days. Subsequent increments could mean either expanding the functionality of this basic arrangement or, if necessary, moving on to UVM Express steps 2, 3 and beyond.

Very reasonable idea, no?

Another thing to mention is that UVM Express still does not address the issue of quality and robustness of verification IP (not a slight against UVM Express… it’s not meant to do that). Verifiers don’t normally do much in terms of testing-the-testbench so initial testbench quality tends to be pretty bad. I think test-driven development (TDD) is the answer there and I think TDD plays very nicely with the focus and incremental approach that UVM Express suggests. If you read my last post or follow me on Twitter (@nosnhojn), you’ll know that I’ve already started building examples for how one would pair TDD, SVUnit and UVM Express. I’ve described how I went through the BFM step in my last post. You can expect more examples that describe the addition of coverage and random stimulus as I get through them.

To finish up, I’d recommend people take a look at UVM Express and form their own opinion while thinking about how it can be used in agile development as you go. I’d also recommend Mentor and others carry on from UVM Express. Accessibility to UVM and a battered sense of inclusiveness in hardware development have become a big problem that’s only getting worse. Seems to be a sliver of daylight on the horizon though so I get the feeling it’s not too late to turn things around.

Hopefully lots of exciting stuff to come!


Q. What ideas out there am I missing that improve accessibility to UVM and foster inclusiveness in hardware development?

One thought on “Why I Like UVM Express

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.