OVM - The Methodology for Enabling an Industry-wide VIP Eco-System

As the leader of the Cadence OVM development team, I was reading Richard Goering's recent article about the Cadence, Mentor, and Synopsys support for the OVM and VMM class libraries, and I wanted to make sure some key technical points were not lost. 

Before I get to that, I have to say I found it interesting that Synopsys does not plan to support OVM as Goering reported, "Bartleson said, however, that Synopsys has no intent to support OVM" - not sure how that will sit with the 4000+ customers who have downloaded the OVM from OVMWorld.  Then again, Synopsys is supposedly not supporting the e language either, right Karen (wink, wink), and yet I have heard from multiple customers around the world that Synopsys has told them they are supporting the e language, including this thread at the end of last year on the Verification Guild where several customers discussed VCS e support. 

I guess only time will tell, but I would be surprised if Synopsys really does not plan to support the SystemVerilog IEEE1800 standard within VCS, which is all that is needed for them to support the OVM.  Hopefully if you read Richard's article, it is clear that both Mentor and Cadence are providing a migration path to help customer's who have legacy VMM code easily move to the OVM. 

When we initially decided to develop the OVM and donate it into the open-source community, one of our main objectives was to provide an open class library and more importantly, a methodology to enable an industry-wide VIP ecosystem.  I hear a lot of people talking about the VMM vs. OVM class libraries, but the class libraries just provide the basic building blocks for constructing reusable verification environments. 

Beyond the class libraries, the key to having plug & play, reusable VIP is following a complete methodology for constructing the environments.  VMM provided some methodology guidelines, but it has not provided enough to enable full verification component reuse without customers having to add a lot of custom class library and methodology extensions, which end up yielding customer-specific VMM variant methodologies, which in turn limits reuse.  While the OVM is new to SystemVerilog, the methodology is based on the most mature and widely used commercial verification methodology today, the eRM, originally developed by Verisity and Verisity customers in 2002 and the AVM developed by Mentor Graphics a few years ago (as JL Gray pointed out in his recent blog on this topic). 

There are many hundreds of commercial and internally developed reusable eRM verification components used by customers all over the world, and there are many examples of customers sharing these verification components both internally and across companies.  With the OVM introduction at the end of last year, SystemVerilog customers have also started realizing these same reuse benefits.  There are many technical advantages that OVM offers over VMM for enabling better module to system, and project to project verification IP reuse including:

• Architecture for fully encapsulated interface verification components including support for module to system reuse
• Reusable constrained-random stimulus in the form of sequences and virtual sequences
• Hierarchical configuration of verification components without editing the original source
• Standard TLM communication channel for inter/intra-component communication

The other significant benefit of the OVM is that it was built for multi-language support (not as an after-thought) in order to provide VIP interoperability with SystemC models and eRM verification components (I recently blogged on this here).

Putting all the technical benefits of the OVM aside - when you consider the momentum and the fact that more than two-thirds of the EDA market is supporting the OVM, including support for not only SystemVerilog but also SystemC and e, I think we are on track for fulfilling the objective of enabling an Industry-wide VIP ecosystem around the OVM.  Unlike Karen, I'm not too concerned about customers getting confused about this...

 Mike Stellfox