Get email delivery of the Cadence blog featured here
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.
Hi Sreedhark, both e and SystemVerilog provide good syntax for writing functional coverage, and both provide good capabilities for developing coverage driven verification environments. Since my team is developing both eRM and SystemVerilog OVM, I can say that I don't see any technical advantages in SystemVerilog OVM over eRM, especially if you are coming from an e background. We found that many things tend to be easier to do with e and take less lines of code compared to SystemVerilog. A lot of the advantages of e over SystemVerilog are due to the fact that it is both Object-oriented and Aspect-oriented, while SystemVerilog is only object-oriented.
Hi Michael, I am working on 'e' language for 1 year. As for as functional coverage is concerned, eRM is supports very well. I would like know to what extent the functional coverage that can be acheived using System Verilog's OVM is comparable with eRM.which can be better.? I have never worked on System Verilog.