A Quick Check on the Status of UVM 1.0

Regular readers know that I've blogged a lot about the Open Verification Methodology (OVM) and the upcoming Accellera Universal Verification Methodology (UVM), whose 1.0 EA (Early Adopter) release is virtually identical to the OVM. I've been silent for a while, waiting for the Accellera VIP-TSC to complete the second phase of its work and release UVM 1.0, without that annoying and misleading "EA" label. In the meantime I've argued strongly (1 - 2 - 3 - X) that users should ignore this label and start using the UVM today.

As I've noted before, many users are doing exactly that. However, I still hear from some customers that they want to wait until the "production" release of the UVM. So I've been urging the TSC to get UVM 1.0 out quickly and not to get bogged down in creeping featurism. I rather enjoy the role of TSC gadfly; I've spent years in the trenches with Accellera and other standards bodies so I understand fully well the challenges they face. However, I maintain that the TSC did itself and the industry a disservice with the "EA" label. Every week that users don't adopt the UVM is another week for legacy methodologies and internal proprietary methodologies to continue to proliferate.

But that's ancient history; what's important now is that the TSC meet its original deadline to release UVM 1.0 no later than November. Some of what I'm hearing from the committee makes me optimistic that they will indeed hit this date, but some of the details do worry me. My Mentor colleagues Dennis Brophy and Mark Glasser recently published blog entries about the TSC's work on UVM 1.0 so I don't need to repeat a lot of the details. The good news is that TSC is not breaking backward compatibility with the EA release or with OVM 2.1.1, thereby erasing one concern among those who have been reluctant to adopt the UVM yet.

The good and bad news is that UVM 1.0 will likely contain several major enhancements beyond the EA version. This is good in that most of the new features will have value for users, but it's risky since some of these are significant additions with new, relatively untested code. It seems to me as an outsider that the register package is inherently the biggest risk, since it is based on a Verification Methodology Manual (VMM) extension rather than the OVM. As I understand it, the proposed package still needs modifications to meet some of the TSC requirements. This process is essential, although it will leave even less time to solidify the code before November.

I've never been shy about offering unrequested (and, as I've been told explicitly, at times unwelcome) advice to the TSC throughout the whole UVM process. I'm not going to stop now. It would be detrimental for UVM 1.0 to slip into 2011, so I urge the TSC to meet the November deadline. If that means dropping a feature or two to make the date with high-quality code fully validated on all simulators, then so be it. What's so wrong with having a good starting point for UVM 1.1? As we learned in the OVM development effort, sometimes it's better to get a solid release out without tossing in everything on the wish list. Bring on UVM 1.0 and let's go!

 Tom A.

 The truth is out there...sometimes it's in a blog.