Michael Stellfox Blog

The Future of OVM, VMM, and UVM

mstellfox — Mon, 24 May 2010 18:30:00 GMT

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

UVM - 10 Years in the Making ...

mstellfox — Tue, 18 May 2010 03:22:00 GMT

In case you the missed the news today, the Accellera VIP TSC released the first version of the Universal Verification Methodology (UVM). This represents a significant achievement on the part of the TSC as it is the first standard SystemVerilog Base-Class Library and Methodology. While there has been a lot of hard work by many members of the TSC since December of last year when the OVM was chosen to be the basis of the UVM, for some of us, the road to get here was actually much longer - nearly 10 years in the making. Don't let the "Early Adopter (EA)" tag on this first release of UVM give you the wrong impression, since it is based on testbench best practices that have been used by hundreds of verification engineers for nearly a decade.

It all started back in 2000 at a small start-up named Verisity. At that time, Verisity was having success selling Specman, for building constrained-random, coverage-driven testbenches. However, there was a significant challenge to ramp up new engineers on how to build these powerful, automated verification environments, and there were a lot less verification engineers than today (still not enough in the industry but that is another story). Moshe Gavrielov, as the CEO, decided to form a team called "Specware" who created the first set of verification methodology best practices in the form of software verification patterns in the "Verification Advisor". This was a great start for helping proliferate verification knowledge transfer, but it was not enough. Verisity had a lot of very savvy Verification AEs and customers, and every AE and customer was very creative in developing their own style of testbench - so creative, in fact, that it was practically impossible for anyone other than the original developer to comprehend the code that had been written, which made testbenches difficult to reuse and a lot of effort to write and maintain.

This lead to Yoav Hollander, the founder of Verisity, working with the Specware team, AEs, and some expert customers and consultants to take things a step further by building the first commercial methodology for constructing reusable verification components, known as the e Reuse Methodology (eRM). (I was fortunate to be one of the AEs involved in this effort.) The eRM was built by generalizing all the best practices that had been accumulated by that time. It included most of the key methodology concepts you see today in UVM including:

Interface verification components as the base reusable building blocks
Env/Agent architecture with separate BFM/Driver from Sequence_driver/Sequencer and monitor
Common configuration options like active/passive agents, signal port maps, etc...
Sequences for building constrained-random, reusable stimulus and having a common test-writer interface
Debug messaging and logging and control of messages

Here is an "old-school" slide from when we introduced the original vision of eRM:

Over the next several years, the eRM was adopted by hundreds of customers, and Verisity used the eRM to build the first commercial e Verification Components (eVCs) for standard protocols like PCI, AHB, and Ethernet. Many additions were made to eRM including a register package (vr_ad), module to system reuse, and HW/SW co-verification, and customers across the world continue to adopt and apply eRM on projects today.

When Cadence acquired Verisity in 2005, SystemVerilog was starting to gain attention as a second standard verification language, so several of the original eRM experts decided to adapt the eRM concepts to build a SystemVerilog verification methodology, which was released as the URM in 2006. The URM was a single verification methodology for both SystemVerilog and e, including support for multi-language environments. At the time Mentor had developed the AVM base-class library for SystemVerilog, and since both Cadence and Mentor were making their libraries available via open-source, and they shared a common communications approach based on the OSCI TLM standard, the two companies decided to unify AVM and URM to create the OVM, which was released open-source on OVMWorld in January of 2008. The OVM has been a very successful joint development effort and Cadence not only managed to bring to it all the mature, proven concepts of eRM, we also contributed a number of SystemVerilog specific features including:

The factory & configuration mechanism
Field automation, message macros, & objection mechansim
A robust register package
Multi-language interoperability with OVM e verification components and OVM SystemC models

OVM has been a huge success in the market, which eventually lead the Accellera VIP TSC to choose it as the basis of the UVM, It has been a long time in the making but the core methodology concepts from eRM to URM to OVM to UVM have remained consistent with small refinements along the way. So, as we celebrate the "birth" of UVM today, we also celebrate the 10 year anniversary of the of eRM - a bit corny but appropriate...

Mike

Re: Verilog, System Verilog and SystemC

mstellfox — Thu, 03 Sep 2009 13:03:58 GMT

What do you mean by testing using Verilog? What differentiate the test and verify?

In Verilog, you can write procedural code to define tests to stimulate and check your design. This is a manual process since you have to think of each test, and then write the stimulus and check the expected behavior. This is a way to "verify" the design, but it is a "test-driven" manual approach, and not very efficient or effective.

if i use System Verilog for RTL design, what is the disadvantage?

You need to make sure that all the tools you use support the SystemVerilog constructs you intend to use. This is the only disadvantage.

What is the thing Verilog can do while System Verilog cant?

SystemVerilog is a superset of Verilog.

Re: Verilog, System Verilog and SystemC

mstellfox — Wed, 02 Sep 2009 18:55:24 GMT

Hi Jasonkee111,

Good questions. As you have discovered there are many languages available for design and verification with various advantages/disadvantages. I will try to give you some recommendations based on my experience working with many customers.

For RTL design, Verilog is still the main language being used today (alongside VHDL). SystemVerilog offers some nice new capabilities to Verilog RTL and these new design constructs are incremental and fairly easy for a Verilog RTL designer to understand. These features are mainly "convenience" syntax enhancements but do very little to raise the level of abstraction beyond the register transfer level. If you are doing directed testing, you can use Verilog to write a basic testbench and directed tests for your design. However, for verification most people are moving to a more automated approach to verification applying Coverage Driven and Metric Driven methodology, where you define your verification goals using functional coverage, leverage constrained-random stimulus generation to create the tests automatically, and define your checks independent of your tests. The two best languages being used today for this type of advanced verification are e and SystemVerilog, where a lot of users find the e language to be easier and more efficient for building this type of testbench. SystemVerilog can also be a good choice here, but you should keep in mind that this is a completely separate part of the language from the SystemVerilog constructs you use for design. SystemC provides a class library which extends C++ and defines a common way to write Transaction Level Models (TLM) which are at a much higher abstraction level compared to Verilog/SystemVerilog RTL models. SystemC has traditionally been used for creating models architectural exploration and for providing an early model of the hardware design for software development. Cadence is now offering a synthesis tool, C-to-Silicon, which can be used to synthesize the SystemC TLM. This enables capturing the design at a much higher level of abstraction, while still being able to use the same model for architectural analysis and software development. As part of this offering, Cadence is building a complete methodology for enabling both design and verification to start at the TLM level. For the verification at the TLM level, we are leveraging the same automated Metric driven approach that people are applying on RTL designs today, where e is a more natural choice for the verification language since SystemVerilog was built primarily for Verilog/RTL verification. If you decide to use e or SystemVerilog for verification, you should probably leverage the Open Verification Methodology (OVM) which provides class libraries, utilities, and methodology guidelines for making it easier to write SystemVerilog or e testbenches.

Hopefully that clears up some of your questions.

Regards,
Mike

RE: regarding e ports

mstellfox — Fri, 17 Apr 2009 00:00:09 GMT

Hi Krishna,

I am pretty sure simple ports existed in Specman 4.3.1. You might be setting the record for using the oldest version of Specman since 4.3.1 is about 6 years old. Is there any reason why you can’t upgrade to the latest version, 8.2?

Mike

The OVM extended to support e and SystemC

mstellfox — Wed, 25 Feb 2009 17:25:21 GMT

In case you missed the press release, the Open Verification Methodology (OVM) has been updated to support e as well as SystemC: http://www.cadence.com/cadence/newsroom/press_releases/Pages/pr.aspx?xml=022309_extended_ovm

The first implementation of OVM was for SystemVerilog back in 2007. This donation from Cadence extends it to both e and SystemC.

For eRM users, OVM e is effectively the next version of eRM with some nice new enhancements, as well as extensions to align it with OVM SystemVerilog to better enable multi-language verification. Since the OVM SystemVerilog methodology is heavily based on the eRM, the OVM e updates are fully backward compatible with eRM.

Many companies are moving to SystemC for architectural exploration and as a way to provide an early virtual prototype for software development, as well as starting to design at the TLM level. The initial focus of OVM SystemC is to enable better consistency and connectivity between SystemC models or basic testbenches with Coverage-driven OVM SystemVerilog or e testbenches. You can download the open-source OVM Multi-language kit from OVM World in the contributions area at:http://ovmworld.org/contributions.php The release includes libraries, examples, and the OVM Multi-language User Guide. Mike Stellfox

"...Yes, Virginia there is a Specman"

mstellfox — Mon, 02 Feb 2009 12:00:00 GMT

I usually try to visit many of our customers in Europe (and other parts of the world) at least a couple of times a year. On my last trip in October, while I was in Stockholm, I ended up having beers at a pub with one of our local AEs and a Specman customer. This customer had been telling me about all the "good stuff" that he was leveraging with our Specman Verification Solution which was great to hear, but I also like to understand the "bad and the ugly". I am always interested to hear ideas from customers on how we can improve our verification solutions, so I figured I would take advantage of the fact that after a few beers most people tend to be a bit more "forthcoming" about what they really think.

When I asked this Verification Engineer what he wanted to see us improve, I expected him to start asking for all kinds of new features that would make his life easier, but instead he started hammering on me about his perception that Cadence is promoting SystemVerilog all the time and not saying anything about e and Specman. He was clearly frustrated and didn't hold back in telling me how, from his perspective, we were screwing up (I did ask for it after all). He explained how after ramping up on Specman and applying our Metric-Driven Verification Methodology over the past couple of years, he was really enjoying his work and success as a bug-finding machine compared to the dark ages of directed testing he endured before using Specman. However, due to the fact that there was a lot more marketing and hype around SystemVerilog relative to Specman/e over the last year, our competitors were spreading rumors to his management that since Cadence was investing in SystemVerilog, they were going to kill Specman/e. This was making his management and him question whether they should continue using e or consider switching to SystemVerilog.

In fact, I have heard this type of FUD being spread to other customers, so I explained that this was simply not true and highlighted all of the recent significant advancements we had made to our Specman solution including Intelligen and the new generation debugger which are technology innovations well beyond anything being offered by any of our competitors. I also explained that over the past couple of years we had not made a lot of noise about Specman/e because our competitors were using that to spread more FUD to customers about Cadence not being serious about SystemVerilog. However, at the end of 2007 when we introduced the OVM for SystemVerilog with Mentor Graphics and effectively took a position of leadership in the SystemVerilog testbench market with the massive adoption of OVM by customers in 2008, this cleared up any doubts about Cadence being a serious player in the SystemVerilog market. For those customers that choose to use SystemVerilog we will provide the best solution by leveraging our Specman technology and expertise from the past 10+ years, but make no mistake, we absolutely are investing in providing the state-of-the-art solution for e users - the number of which continues to grow every year. I made a promise that we were not going to be shy about promoting our Specman e solution anymore.

When I came back to the US, I explained my conversation over beers with this customer, and challenged the Specman Team to make it clear to the world that Cadence is as serious about Specman and e as it is about SystemVerilog. They rose to the challenge and started up the "Team Specman" Blog on the Cadence web-site at the end of last year. This is a really cool blog since it involves many people across Cadence who work on Specman and e from AEs, Core Comp, R&D, and Methodology Engineering. Each week different people from these organizations write technical blogs on all things Specman. They felt this was the best way to connect directly with Specman customers, and also give some transparency into the large number of people at Cadence across the world who are developing or supporting Specman and e-based verification methodology. So, "yes [Michael] there is a Specman" - thanks for hammering on me and if you haven't started reading the Team Specman Blog, you really need to check it out.

In fact, rumor has it that Synopsys monitors this blog closely as they continue to work on bringing their e implementation in VCS to the market... ;-)

Mike

RE: RE: RE: Temporal expression in e

mstellfox — Fri, 16 Jan 2009 17:17:10 GMT

First, I would read the “N” signal value to a simple_port and use the simple_port in your temporal expression. Below, I assume that the “N” signal value will not change during the evaluation of the temporal expression, and then I think this will work:

extend sys {

            n:         in simple_port of uint is instance;

            event clk is @sys.any;

            event a;

            event b;

            event a_n_is_0 is true(n$ == 0)@a;

            event a_n_greater_0 is true(n$ > 0)@a;

            expect (@a_n_is_0 and @b)@clk or

                            ((@a_n_greater_0) => {[n$ - 1];@b})@clk;

Mike

RE: RE: Temporal expression in e

mstellfox — Thu, 15 Jan 2009 16:09:10 GMT

Ok, then you need one temporal expression to capture the case when @a and @b occur on the same cycle, as well as the case when the don’t occur on the same cycle. See below – I think this will work for you.

expect (@a and @b)@clk or ((@a and not @b) => {eventually @b})@clk;

Mike

RE: Temporal expression in e

mstellfox — Wed, 14 Jan 2009 14:41:11 GMT

Hi Spark,

Can you write down the english expression of what you want to check? It is not clear from your description below.

Is this what you want to check:

If event a occurs, then b must occur on the same cycle as a or any number of cycles after a

Or do you need to check something else??

Mike