• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Blogs
  2. Verification
  3. Why is OVM important for Specman/e customers?
mstellfox
mstellfox

Community Member

Blog Activity
Options
  • Subscribe by email
  • More
  • Cancel
Verification methodology
Functional Verification
OVM
eRM

Why is OVM important for Specman/e customers?

12 Jul 2008 • 2 minute read

With all of the press and interest from customers adopting it, I am sure most of you have heard about the OVM (Open Verification Methodology), which is jointly developed and supported by Mentor Graphics and Cadence.  If you haven't heard about the OVM, you can check out the OVM World site to read all about it.

The main focus of the OVM so far has been on providing a testbench methodology and class library for SystemVerilog.  The OVM provides many benefits for SystemVerilog customers including a robust class library, the ability to create scalable and reusable verification environments, and many ease-of-use, convenience features, but I wanted to make sure it is clear to Specman/e customers why OVM is actually good news for them.  (In the mean time, for those SystemVerilog customers trying to understand some of the technical advantages of OVM, JL Gray did a nice job of explaining some of the advantages in his blog a few months back).

The initial focus of the OVM so far has been on providing a SystemVerilog methodology and class library since there wasn't a good solution available for many customers.  However, from its initial conception, OVM was architected to support interoperability across multiple languages including e and SystemC.  In fact, if you are an e user, you will notice that most of the methodology in the OVM for developing reusable verification components is based on the eRM.  For example, consider the architecture for an OVM interface verification component:

For eRM customers, this should look very familiar with the exception of some small differences in the names of the sub-components (sequence_driver -> sequencer, bfm -> driver).  In fact, eRM and OVM are nearly the same methodology, so there is already good interoperability between eRM verification components and SystemVerilog OVM verification components, and my team at Cadence is working to extend OVM to make it even easier for e and SystemVerilog customers to share verification components written in both languages.  When you consider the fact that most of the reusable verification IP developed by customers and commercial providers available in the world today is based on eRM, this is good news for both e and SystemVerilog customers.

It means that e customers can continue to use Specman and enjoy the unique benefits of the e language and Specman development environment while still having the ability to share their verification IP with SystemVerilog users inside or outside of their company.  For OVM SystemVerilog customers, this means that they can reuse the huge number of eRM verification components that are already available instead of rewriting those verification components from scratch.  From my experience, I believe that the key for achieving verification IP reuse is standardizing on the methodology vs. trying to force everyone to use the same language.  It is important for Specman/e customers to work with their colleagues who choose to use SystemVerilog to help them adopt OVM so that they can easily exchange VIP. 

Mike

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information