Cool Verification

Listening to the discussion about UVM extensibility today on the Accellera VIP-TSC call, I was reminded of a great post from Steve Yegge of Google.

It's *very* long, but a good read. In summary, Steve proposes that there are two competing world views when it comes to programming:

"Conservative" programming views

1. Software should aim to be bug free before it launches.
2. Programmers should be protected from errors. 
3. Programmers have difficulty learning new syntax. 
4. Production code must be safety-checked by a compiler. 
5. Data stores must adhere to a well-defined, published schema. 
6. Public interfaces should be rigorously modeled. 
7. Production systems should never have dangerous or risky back-doors. 
8. If there is ANY doubt as to the safety of a component, it cannot be allowed in production 
9. Fast is better than slow. 

"Liberal" programming views

1. Bugs are not a big deal. 
2. Programmers are only newbies for a little while. 
3. Programmers figure stuff out amazingly fast when their jobs depend on it. 
4. Succinctness is power. 
5. Rigid schemas limit flexibility and slow down development. 
6. Public interfaces should above all else be simple, backward-compatible, and future-compatible.
7. System flexibility can mean the difference between you getting the customer (or contract) vs. your competitor nabbing it instead. 
8. Companies should take risks, embrace progress, and fiercely resist ossification. 
9. Premature optimization is the root of all evil. 

Steve's point is that everyone falls somewhere on the spectrum between conservative and liberal (programming), whether they realize this or not.

On the Accellera VIP-TSC, and often in our everyday verification work, each of us often has debates where one side or the other claims a technical position assuming their position is based on a fundamental law of nature. It can be useful to admit to yourself that there are different views of acceptable programming practices, and there are pros and cons of each. Understanding this can improve your interaction with your team members, and can allow a team to more efficiently make conscious decisions about preferred styles as we move through a development process.

Many of you using the UVM library are aware that runtime phasing was one of the areas most heavily tweaked from the original OVM codebase. But there have been disagreements since the UVM 1.0 was released back in 2011 about whether the phasing mechanism as released was useful and if so, sufficient for creating reusable verification components and environments. Verilab is conducting a survey to find out whether UVM users are currently taking advantage of runtime phasing and phase jumps, and if so, whether or not they would be impacted by certain changes the committee might propose. 

• Verilab UVM Phasing Survey

I'd love to get some detailed responses from Cool Verification readers to share with the Accellera VIP-TSC. Your help on this is greatly apprecated!

Note - this survey is geared towards active UVM users only. 

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.

For some reason, the video I embedded in yesterday's blog post didn't show up in the email that many of you receive. Here is a direct link to my video on how to participate in the Accellera VIP-TSC UVM effort.

I've been looking into doing some online videos recently, and thought it would be fun as a test to show how simple it is for non-members to participate in the Accellera Verification IP technical subcommittee UVM development effort.

Signing Up to Participate in the Accellera UVM Effort (direct link)

Keep in mind this is the first time I've created a web video... constructive comments or questions are very much appreciated!

A little over a month ago I sent out a request for your feedback on the possibility of adding a standardized register package to the UVM. Over the next 10 days I received 119 entries, 107 of which I consider valid (meaning they included an apparently real name and company email address, and did not appear to be duplicate submissions). Those 107 entries came from 63 different companies. The goal of the survey was to allow me to provide better input into the Accellera Verification IP TSC on whether a register package should be part of the UVM at some point.  The survey included the following questions:

1. Which SystemVerilog register package do you currently use?
• Cadence
• Mentor
• Synopsys
• Multiple
• Home grown
• None
• Other 
2. How important is it that the UVM contain a register package?
• Critical - we won't adopt the UVM without it
• Important - should be in the first release, but would be satisfied with the UVM even without this feature
• Low - Happy with whatever the TSC comes up with
• Don't care at all 
3. Would you be willing to delay the release of the UVM so that it could include a register package?
• Yes
• No
• Don't Care 

Many respondents also included comments. I’m going through those comments and will share them once I have a chance to scrub them of any personally identifying information. So, without further ado, here are the results. Values are listed as the number of responses for each answer.

Just to update everyone on the warning I posted last week. As expected, the current state of the Unified Universal Verification Methodolgy (UVM) library has changed such that the UVM-EA "kit" that was announced last week is already out of date. Actually, to be precise, the kit was never "in date", if that's even a valid phrase. But things have moved forward even in the last few days. If you're looking for information on the UVM, my recommendation is to be patient. Things are changing on a weekly basis, and the only way to stay on top of things for now is to start becoming involved with the Accellera VIP TSC. If you'd like to find out how to participate, please let me know and I'll fill you in on all the gory details.

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.