Home > Community > Blogs > Functional Verification > a quick check on the status of uvm 1 0
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Functional Verification blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

A Quick Check on the Status of UVM 1.0

Comments(3)Filed under: Verification methodology , OVM, VIP, uvm, Accellera VIP TSC

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.


By Scott Roland on October 21, 2010
I think you are incorrect in saying that UVM 1.0 does not break backward compatibility with OVM 2.1.1. As Doulos said, "[Y]ou should beware that the implementation of the objection mechanism and callbacks has changed somewhat between OVM 2.1.1 and UVM, so UVM is not strictly backward compatible with OVM 2.1.1." www.doulos.com/.../uvm
I for one appreciate the "EA" label.

By tomacadence on October 21, 2010
Thanks for the comment, Scott. As I understand it, the Accellera VIP-TSC has pledged a high degree of backward compatibility but reserves the right to make small changes if the end result will benefit users. I'll ask one of my colleagues who attends the TSC meetings to respond with more detail.
Tom A.

By SharonR on October 21, 2010
This is indeed correct that there are some minor backward compatibility differences. The Accellera VIP-TSC made these modifications to have a better API moving forward, with the knowledge that they are extremely minor and would not affect most OVM users.

Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.