Cool Verification

Update January 18, 2013

I appreciate the responses to this post. The Accellera folks have been able to fill the slots needed for the UVM Tutorial at DVCon. So no more responses are required! 

--------

Have you spent some portion of the last year or two adopting the UVM verification methodology? Would you be interested/able to present your experiences to the wider verification community as part of a tutorial session at DVCon next month in San Jose? If so, please contact me directly ASAP. 

Earlier this year, the Accellera VIP-TSC approved version 1.0 of the UVM. Supported by all of the major EDA vendors, the UVM has been billed as the next generation in verification methodology goodness. Better than the VMM. Better than the OVM. A chance for the verification community to shed some of the baggage carried over from years of backward-compatibility requirements and methodology fits and starts. Another purported benefit is that testbenches written with SystemVerilog/UVM can be more easily ported to simulators from different vendors. There is also a developing market in UVM verification IP to allow testbenches, in theory, to be quickly constructed from commercially available components.

All of this sounds great, right? Vendors standardizing on languages and methodologies and competing on tools. It's how the world should be. Except there are a few small problems that vendors are unlikely to tell you about before you start your next project.

First and foremost is a problem that is glaringly obvious to anyone who's tried learning SystemVerilog and the UVM (or one of the other VMs over the years): it's difficult and time consuming to learn SystemVerilog and any of the VMs... especially if you have never used a verification language before.  Folks with limited software backgrounds (read: most design and verification engineers) find seemingly simple concepts like inheritance and factories to be mind boggling, even if they won't admit it. And folks with deep software backgrounds will find SystemVerilog an absolute pit of despair when compared with modern languages such as Python and Ruby, and the UVM complex in a way that clearly is meant to patch over serious deficiencies in the underlying language. Plus, any testbench that has to deal with multi-language issues is clearly out of luck in the simplicity and ease of use department.

Now that the UVM has arrived and the methodology bickering between the major vendors has mostly (well, somewhat) ceased, the complexity of the UVM and the earlier VMs on which it is based can be viewed more clearly and with less controversy. And the results are not good.  After years of experience working with many multiple clients, it seems the only way out of our current dilemma is to start looking at other languages and development frameworks. For that to happen, major semiconductor companies may need to start funding this type of development again, since it is abundantly clear the EDA vendors are incapable of this level of innovative thinking. Or more kindly, perhaps they feel there is no money in innovation. Either way, major advances in design and verification productivity need to get here sooner rather than later.  

As I mentioned earlier in the week, the Universal Verification Methodology – Early Adopter release (UVM-EA) was announced on Monday and can be downloaded from the Accellera website. The process for putting together this release has been both exhilarating and frustrating, and it has highlighted (at least for me) the potentially transformative impact wide adoption of this library could have on the industry. Many users, from those with the most basic skills to those with the most advanced, have held off selecting a commercially available verification methodology for SystemVerilog. Initially, this may have been because they did not want to be locked in to a specific SystemVerilog simulator, though until recently (and, to be honest, still somewhat today), it was extremely difficult to write code that compiled on all three major simulators regardless of methodology. Some felt the VMM and OVM were too complex; others felt the libraries were ill-suited to their particular needs. 

Though I doubt anyone is going to stop what they’re doing and adopt the UVM mid-project, I believe engineers starting new verification efforts will take a serious look at the UVM.

Just a quick note - the Universal Verification Methodology Early Adopter (UVM-EA) release is now available on the Accellera website. I'll post additional details on what the release includes later today.

I gave a presentation earlier today on the UVM register package survey results. I decided to record a video of the presentation for your viewing pleasure. One thing I didn't address in the video is a question I've received a few times about how many companies (as opposed to individuals) responded for each package. The biggest responses were for Synopsys and Cadence packages. 36 companies responded that they used the Synopsys SystemVerilog register package. 10 companies responded that they use the Cadence package. Remember - these numbers are influenced by package usage and by how much vendors promoted my survey to their customers. So I make no claims (nor should you) about register package market share from the answers for Question 1 in the survey.

As always, comments welcome! And just in case, here is the link to the video if it doesn't show up below.

Some of you may have seen an announcement on Friday describing an early adopter kit of the UVM "based on the Accellera Verification IP Technical Subcommittee (VIP-TSC) decisions to date". Being a member of the Accellera VIP-TSC myself, I can assure you that the detailed technical contents of the purported "EA" release are still in flux. Anyone announcing such a release, even as a "kit" provided to allow users "to confidently start the process verifying your OVM products offerings in an UVM environment" is at best, misinformed about the current state of the UVM development effort and at worst endeavoring to hamper progress of the UVM. 

Consider yourselves warned.

One other point worth mentioning is that, at present, the UVM will be based on the OVM 2.1.1 code base but will only be reasonably backward compatible[*] with the OVM 2.0.3. Of course, this is subject to change based on future committee votes. I wish I didn't have to say this, but anyone telling you otherwise is probably trying to sell you something... 

For those of you who submitted responses to my register package survey, I've tabulated the results but am still working on anonymizing comments so I can share the details with Cool Verification readers and the VIP-TSC. Stay tuned!

[*] Updated since the original post - the UVM will not actually be directly backward compatible with any version of the OVM. Names of classes will be changed, some implementation details may be changed or deprecated, etc. Best to wait for official word from Accellera on what the first release of the library will look like.

Update March 26, 2010: The UVM register package survey is now closed. I am working on compiling the results from 107 valid responses. Stay tuned!

Updated 3/10/2010: Survey link wasn't working from email version of this post. Added a second link.

Many of the Accellera VIP TSC members are in Marlborough, MA this week discussing what features should be part of the first release of the new UVM (Unified Universal Verification Methodology). For those of you who are not familiar, the UVM is meant to be a SystemVerilog library supported by all three vendors. It will be based on the OVM 2.0.3 and will include support for features from other methodologies as we on the committee see fit. 

One of the hot topics during the discussions today was whether the UVM should contain a register package. I believe most of the vendors agree that such a common package is needed. They don't all agree on what form it should take (Cadence, Mentor, or Synopsys version) or when this package should be included in the UVM. For example, is a common register package important enough to delay the release of the UVM 1.0? Should it be based on an existing package or should the vendors attempt to merge their implementations?

Based on these questions, I have a favor to ask of you, my loyal readers. If you have a couple of minutes, please fill out the UVM Register Package Survey (UPDATE 3/10/2010: If that link to a pop-up version of the form doesn't work try this direct link to the survey) and let me know what you think about register packages and the UVM! I'll share the information with the VIP TSC. Also feel free to comment on this post or send me a private email at jl at coolverification dot com.

Some of you may wonder why I ask for company name and email address on the form. These types of surveys have a history of vote packing... I want to make sure I can verify that votes are from real people and not somehow the result of any shenanigans.  If anything looks suspicious, or if I have questions about your comments, I may contact you. I will absolutely not use this info for any other purpose.

Thanks in advance for all your help.

In the beginning, there was SystemVerilog, and it was good. Through it some testbenches were made; without it other testbenches were made. In SystemVerilog was light, but also darkness in the form of a set of missing features that had to be implemented as library on top of verification languages by each user and also in the form of a lack of interoperability of language features between simulators.

To address the missing features there came a verification methodology sent from Synopsys; its name was VMM. The URM from Cadence and the AVM from Mentor came also and later merged to form the OVM, so that through them all engineers might believe in verification libraries.  The libraries did not completely address users’ concerns, but they did serve to validate users’ concerns as valid and worthy of consideration.

The libraries were the solution, and though the solutions were made through them the verification community did not recognize them as the solution because interoperability had not been solved.

Cool Verification 1:1-15 … ;-)

Ahem… As many of you are aware, the Accellera Verification IP Technical Subcommittee (VIP TSC), of which I am a member, is currently working on creating a unified universal verification methodology (UVM) that will be supported by the big three EDA vendors.  Ostensibly the library is being created so that users don’t have to make a (potentially limiting) choice between the OVM and VMM, but can instead use a library that is considered an industry standard. Sounds good, right? I’m going to make the potentially controversial claim that very few semiconductor companies actually care about using an industry standard methodology.

Now that the SystemVerilog 2009 standard has been released, the P1800 working group is getting ready to start work on the next version of the SystemVerilog standard.  As part of that effort, they are soliciting feedback in preparation for an open meeting on February 26 (the Friday after DVCon) where new features will be discussed (see also Brad Pierce's blog article on the topic).  Since you'll already be at DVCon (you ARE going to DVCon, right?), it should be easy to take the time to attend the IEEE meeting the next day.  Having said that, I'm going to miss the meeting as I'll be on my way to Shanghai to kick off a week of workshops in Asia, but one of my colleagues from Verilab may be attending.  

Speaking of DVCon, the early registration deadline is fast approaching.  Full conference registration is $485 before January 29.  After that, registration goes up to $565. The conference should be outstanding this year, despite the fact that I will be more actively involved than ever before ;-).  If you're planning to attend, please stop by and say hello at one of the following events:

• Monday Tutorial: Advanced Verification Techniques Using VMM - I'll be presenting for 45 minutes on the new phasing and factory features in the VMM 1.2.
• Wednesday Industry Leader's Panel: "What Keeps You Up At Night?" (2010-02-17 - I'm moderating this panel - check out my recent post What Keeps You Up at Night for details)
• Thursday session 12.1: Stimulating Scenarios in the OVM and VMM - My favorite methodology topic now as a DVCon paper with my coauthor Scott Roland.
• Thursday Panel: Ever-Onward! Minimizing Verification Time and Effort - Somehow I managed to sneak onto this panel with this distinguished group of panelists. Come by and heckle me for a bit while the votes for best paper are calculated.

As a side note, I'll be traveling extensively in the next couple of months.  If you're located in any of the following cities, send me a note and perhaps we can catch up while I'm in town:

• Boston (this week!)
• Mountain View (next week)
• Irvine (next week)
• San Jose (for DVCon)
• Shanghai (first week of March)
• Taipei/Hsinchu
• Tokyo

Finally, if any of you are reading this and thinking - why isn't JL writing about something more interesting like, say, the UVM, please send me a note letting me know. I've had blog writer's block/burnout for the last few months and could use the encouragement ;-).

I've been having a discussion on Twitter over the last couple of days that the rest of you may find interesting. The question I posed was: