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.