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
that users should ignore this label and start using the UVM today.
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.
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.
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
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!
truth is out there...sometimes it's in a blog.
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.
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.
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.