SystemVerilog 2012, DVCon 2010, and Travel
What Keeps You Up at Night?

Motivation for the UVM

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.

Why would I say such a thing? Because I’ve spoken with users from many companies over the years, including a large number in just the last few weeks as I’ve traveled around the country. The number one concern I hear from users is that they want to choose a verification language and methodology that does not tie them down to a single vendor. They mostly do not care about reuse between companies and frequently don’t actually care about reuse between groups (though they will not say this directly). Within a single company each group often (but not always) makes a decision on methodology based on personal preference, not on corporate edict. The only decision that really gets made by edict is the purchasing decision on which tools to use.

Purchasing managers have largely bought into the fallacy that by using SystemVerilog they can easily switch vendors should they choose to do so. But language support between the vendors is still different enough to make it challenging to maintain code for more than one simulator. Vendors have been resistant to publicly sharing the level of support their simulators have for the SystemVerilog language, and no independent comparison is possible due to onerous licensing restrictions.

But I digress... The VIP TSC will be meeting face to face the second week of March to work out the requirements for the UVM development effort. If my suspicions prove accurate, a lot of time and energy will be spent debating the fine points of verification methodology architecture, but the end result may be no closer to helping the average verification engineer solve the most pressing issues they face. But as usual, I am happy to be proven wrong. So, in the spirit of the great Linda Richman, is the UVM's purpose to finally solve the SystemVerilog cross-methodology interoperability problem once and for all, or is it a red herring to distract us from the still elusive goal of a vendor independent tool flow... discuss! And feel free to "talk amongst yourselves!"

Comments