Still Time to Blow Up UVM

Blowing up UVM is something I ran on my own blog a few years ago. Considering not much has changed with respect to UVM – that it continues to dominate verification circles – I figured it’s a discussion worth re-starting. In my mind, it’s not too late to take a few steps forward by blowing up UVM.

A little history… the idea to blow up UVM was motivated by a slide snapshot posted to twitter during DVCon back in 2013. Almost 3 years later, I still love this snapshot because it provides an opportunity for a very constructive conversation around the future of UVM; a conversation that for me is a long (long) time coming.

In 2013, that slide represented the peer pressure verification teams were facing to conform to an over-engineered UVM standard. Now 2016, I’d say the peer pressure has doubled at least as UVM has cemented itself as the industry standard for testbench development. Discussion within functional verification circles revolves around UVM. If a team hasn’t yet adopted UVM – or done the hard work as JFK might suggest – they’re planning on it. And if they aren’t planning on it… well… maybe they’re just not that interested in reusable, interoperable, industry standard testbench IP!

The constructive new discussion I’ve been hoping for, a radical new direction as a friend pointed out, is one where people talk about alternatives to the UVM monolith. I call UVM a monolith because that’s exactly what it is. It’s one big package that includes everything; everything to the point it’s become a frankenmess of interwoven compromises and good intentions. Case in point: the UVM register package. Great idea and a perfect opportunity for modularity. Alas, it was dumped into the same uvm_pkg to become part of the monolith.

Now, you might be saying “just because it’s part of the uvm_pkg doesn’t mean the register package isn’t modular”. I don’t completely agree but that’s correct’ish. It does stand well on it’s own and from what I can tell the dependencies on the register package are limited to macros. If you don’t want to use it, the only impact is extra code through the compiler. That also goes for the TLM1 and TLM2, most of the monitor and scoreboards, most of the miscellaneous odds and ends (side note… who’s using the uvm_heartbeat? anyone??) and the deprecated features that have yet to be dropped altogether. The same is not true, however, for the sequencer or the config_db or the reporting or the transaction recorder or the factory. Those are there whether you’re using them or not – like it or not. If you think the sequencer is hard to understand, the config_db dangerously opaque, the reporting over-engineered and the recording less than useful, they’re an integrated part of UVM that you can’t get rid of; too bad.

Which brings me to an alternative. I proposed the Open Verification Platform (OVP) in the original post back in 2013. No one has taken me up on it yet, so if at first you don’t succeed…

The OVP is decidedly non-universal nor is it fully featured. It is the minimalists starting point for modular testbench development. The value of the OVP is that it’s a platform on top of which users integrate or build the components to meet their development objectives. In short, the OVP is a platform on top of which people create solutions while UVM is a solution that people apply to their problems.

To give you an idea of what the OVP could look like relative to UVM, one option would be to start with the entire UVM library, then remove everything except the uvm_component and uvm_transaction. That leaves you with a base component, base transaction and defined run-flow; the 3 critical components of a testbench. No more. There’s your platform.

Step two is to take the thousands of lines of removed code and divide it into a list of plugins that are compatible with the platform. That’d give you the sequencer plugin, the config_db plugin, the register plugin, TLM1/TLM2 plugins, scoreboard plugin(s), heartbeat plugin, etc.

As for the open part of the OVP, open means it’s user driven so anyone can publish plugins no matter how complicated, simple, excellent or completely lame they might be (in stark difference to the pay-to-play approach to maintaining UVM). Point is, the OVP is where users drive the experience with their ideas. I would expect creativity and competition in plugin development. While standardization in my mind is not the objective, eventually some level of conformance could arise as great ideas emerge and plugins find a user base.

Finally, believers of the UVM can take comfort in the fact that it could be entirely rebuilt on top of the OVP by plugging everything back together. So if you love UVM, carry on. If you don’t, you get the chance to take a step back and decide for yourself how to go forward and what, exactly, you’re taking with you.

So how about we start talking alternatives to UVM? OVP is one option but I bet we could think of 100 others. Unless you think UVM will be around forever, now might be the right time to get started.