The Future of OVM, VMM, and UVM

In my last blog, I took a look back at the history of how we got to the first delivery of UVM. Now, let's take a look forward.  Over the past week since UVM was released, and Cadence opened the UVMWorld portal to support the new UVM Community and ecosystem, I have seen a number of customers asking questions about when to move to UVM as well as the future of OVM and VMM.   Since my team has been developing the OVM over the past few years, as well as being one of the main contributors to the Accellera UVM development effort, I want to make the Cadence position on this very clear.

For the question about when to move to UVM, of course it depends on where you are in your project, but for OVM Users I recommend you move to UVM as soon as you can.  There should not be any significant risk in moving, since the UVM is based on the OVM code base with a few small enhancements.  I cut & pasted a section of the UVM-1.0EA release notes below which clearly states this as well as the areas where there are some small backward incompatibilities and new code in the UVM library.

The UVM is built on the same code base as OVM-2.1.1, with the following new feature enhancements which are described in greater detail in the "New Features" section below and any API changes described in the "API Changes" section. 

• All ovm_* symbols converted to uvm_*.
• Enhancements to the OVM callback facility, including a new message catching facility. These enhancements introduce some minor backward incompatibilities to the OVM callback facility.
• Enhancements to the OVM objection mechanism. These enhancements introduce some minor backward incompatibilities to the OVM objection mechanism.

As you can see, unless you are using the relatively new callback or objection mechanism OVM features which were introduced in OVM 2.1, the only changes to the OVM library are the renaming of the symbols from ovm_* to uvm_*.  You should also be aware that any OVM features which were already deprecated have been removed (as documented in the OVM releases in the file named "deprecated.txt").  Cadence has already migrated several customer environments from OVM to UVM leveraging the script which is included in the UVM release which automates the ovm_* to uvm_* changes. 

In general, we have found the migration to be pretty painless, and it can typically be achieved in a couple of hours with no issues.  If you have been using callbacks or the objection mechanism, there are some small manual code changes required but these are simple changes.  If you are using the Cadence Incisive Simulator, versions IUS92s18/INCISIV92s15 run UVM today and if you are using Cadence OVM VIP, we plan to have UVM VIP Early Adopter support by July, with the 10.2 production release to follow in Q4.

For VMM users, the move to the UVM will be a bit more challenging.  We have had a lot of experience over the past couple of years helping VMM users move to the OVM by leveraging a VMM-OVM interoperability library we created and later provided to the Accellera VIP TSC.  The TSC extended this interoperability library and created a Best Practices Standard last year, and Cadence just recently updated the interoperability library to support VMM-UVM interoperability and provided this back to Accellera.  This should make it easier for VMM users to consolidate their legacy environments into new UVM environments so they too can gain the productivity advantages of the UVM ecosystem.

The remaining question that customers have been asking is -- "does this mean that OVM and VMM are dead?"  I will leave it to Synopsys to answer the question regarding VMM.  OVM is certainly not dead since it is the basis of UVM, and as I describe above, there is a straightforward process for OVM users to easily move to the UVM.  Cadence will absolutely continue to support customers using the OVM, but since the standard methodology will be based on UVM, moving forward you should expect to see Cadence continue its leadership in methodology innovation and support on top of the UVM.

Mike Stellfox