Just as it seems the verification community has converged on a methodology – a universal methodology as it were – that finally meets the needs of EDA vendors, IP providers and users, along comes somebody to suggest we should blow things up entirely and start again.
‘Somebody’ is me.
This post was set in motion by DVCon coverage via twitter last week and a snapshot posted from a UVM talk. I’m pointing out this snapshot because I think it provides an opportunity for a very constructive conversation around the future of UVM; a conversation that I think needs to happen (To be clear, I have none of the context around the photo. I know nothing of the talk it came from – topic, presenter or otherwise – and I’m definitely not doing it to slight the presenter – for the record, I think it’s an effective slide for the point I’m assuming he/she is trying to make).
What does this slide say to you? To me, it represents the peer pressure verification teams are currently facing to conform to an over-engineered UVM standard. Over the last few years, UVM has been shown as the one, natural, heavily promoted, near unanimously supported option for industry standard testbench development. Discussion within functional verification circles revolves around UVM for the most part. 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!
That’s what that slide means to me and my initial reaction was a quick twitter rant. With the rant out of my system (almost), it’s time to get constructive here. I want to propose a new direction, a radical new direction as a friend pointed out, to encourage people to start talking 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. I believe it’ll continue to include everything so as to eventually – if it hasn’t already – transform itself into a giant 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 dependancies 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 and you can’t really get rid of them.
Which brings me to an alternative. I’d like to propose the the Open Verification Platform (OVP).
The OVP is specifically not 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 - there is nothing methodological about it (see: UVM Still Isn’t A Methodology) – on top of which users integrate or build the components to meet their development objectives. I think of UVM as a solution that people apply to their problems. The OVP is a platform on top of which people create their solutions.
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.
Is this a joke? What do we do with everything else? Surely you’re not suggesting we throw years of effort away?
Of course not. What’s left would be divided into a list of plugins that are compatible with the platform. You’d have the sequencer plugin, the config_db plugin, the register plugin, TLM1/TLM2 plugins, scoreboard plugin(s), 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. Point is, the OVP is where users drive the experience with their ideas. I would expect creativity and competition in plugin development. While standardization is quite obviously 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 the UVM could be entirely rebuilt on top of the OVP. Just take all the OVP plugins and… uh… plug them 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.
If you’ve made it this far, congratulations. I know I’ve been a bit rant’y in the past when it comes to UVM so my intention in this post was to at least temper the rant with something constructive. Also, as I’ve said in the past, I’ll repeat that it’s not my intention to berate the effort that went into creating UVM. I do, though, think that if UVM is to be a long term solution, it’s going to need to take a different form as we refocus on and re-emphasize a user-centric solution to testbench development.
To sum things up, I’d like people to view the UVM and the OVP as opposities; one is a kitchen sink methodology that stresses standardization and interoperability, the other is a radical, opt-in style free-for-all where users decide.
With that, I’ll leave it to you to tell me what you think. Am I on the mark with an open verification platform? Is it the right way forward or is UVM fine as it is? Most importantly, is there anyone out there with an equally radical idea that needs to be heard? I’m sure I already look like some crazy idiot verification heretic so if you’re shy about sharing ideas, now might be a good time to speak up .