The reports of OVM’s death are greatly exaggerated (with apologies to Mark Twain)

Now that the Accellera VIP-TSC has released UVM-EA, effectively narrowing the choice of verification methodologies to UVM or OVM, many people are asking which way to go — OVM or UVM?  The answer depends a lot on where you are in code development and what your risk tolerance is.  The good news is that neither is a bad choice. One thing is certain: OVM is not dead yet.  It will be around for a long time.  Across the industry a lot of IP has been built and testbenches have been put into production all with OVM.  These must remain operational and supported for a similarly long time. Right now, OVM is the lowest risk choice overall.  There is tons of tool support and lots of IP available along with training and other material from a variety of vendors.  We know OVM is stable and production-worthy just by how widespread its use is.

In its current state UVM is for the more adventurous.  By and large it is OVM with the Os changed to Us.  That’s why we can say it is stable and not necessarily a bad choice.  The risk comes not from whether or not UVM itself works, but in how much support of various kinds is currently available.  Vendors are now updating their tool sets to support UVM, but that work is far from complete.  I imagine as the Accellera committee gets close to releasing UVM-1.0 we’ll see announcements from vendors around their tool support for UVM. Training, examples, and other material is under development as well and will probably be available from their respective  sources shortly after UVM-1.0 is out.

Another aspect to the risk involves 3rd party IP.  IP vendors are also working on converting their IP to be UVM compatible.  If you use 3rd party IP you will need to know when your vendor will make available the components you need converted to run under UVM. The biggest risk comes from the potential of UVM not being entirely backward compatible with OVM (factoring out the simple syntactic name changes).  The VIP-TSC has stated that backward compatibility is a goal, but not a hard requirement.  For example, the VIP-TSC is now looking deeply at phasing.  Proposals are being considered that enable phases to run in parallel and to add additional default phases.  If done properly these changes would add significant capability to UVM and be entirely backward compatible.  If not, UVM could require architectural changes in drivers and monitors to accommodate new phases.  Exactly which way this will go is not clear right now. Mentor, of course, is making a case to retain backward compatibility.

The availability of UVM-EA in advance of the standard affords a prime opportunity to kick the tires and to start some early planning.  Go ahead and download it and start evaluating it.  Try it out on small- to medium-sized pieces of code.  The UVM-EA includes a script to change the Os to Us.  It’s the same script that was used to import OVM as the seed for UVM development.  You can use UVM-EA to figure out what you need to do to convert your environment from OVM to UVM.

Eventually there will be a tipping point and UVM will become the obvious choice for a testbench methodology.  That day is still in the distance.  In the mean time OVM is around and provides all the features necessary to build sophisticated testbenches.