Will UVM 1800.2 Leave You Behind?

We recently reached yet another important milestone in the life of the Universal Verification Methodology. The IEEE 1800.2 UVM Standard was recently approved and will be published shortly. That’s great news, especially to those of us who have spent the past few years working on this effort. This IEEE effort was a bit different from the development of previous UVM versions in Accellera because our IEEE deliverable was just a “paper” specification, instead of the reference base class library implementation that we’ve traditionally provided via Accellera.

In developing the IEEE 1800.2 spec, we started with UVM1.2, which is the latest “official” version, and took advantage of the opportunity to clean up the spec. Since our efforts in Accellera always focused on developing a reference implementation for UVM, each version of the Accellera standard served as documentation of the entire UVM library, including classes and methods to provide the infrastructure for UVM that users were not expected to (and never should) call directly. Most of our work in the IEEE committee involved identifying and documenting the “user-facing” API, including adding accessor methods and other “proper” object-oriented programming practices that had been left out of previous versions. The theory is that someone should be able to take the 1800.2 spec and implement a compatible library that, even if the underlying implementation is different from the reference implementation, would still work when compiled with a user’s UVM code.

Well, now we’re back in Accellera and we’re trying to update the reference implementation so that it matches the 1800.2 spec and also includes all the infrastructure to make it work. And now we’re faced with the scourge of all new software versions: backward compatibility. Each version of UVM not only is different from the previous version but also deprecates certain features, which means that we try to write the code so that users will be notified if they’re using a feature that they shouldn’t be or that’s changed from the previous version. The idea is to allow an easy migration path from the previous version to the new version, and so far it’s worked pretty well. It doesn’t mean that users won’t have to change their code, but it helps identify where the changes need to be made.

The problem that we’re facing is that, even though UVM1.2 is the previous version, there is a large number of UVM users – likely a significant majority – who never migrated from UVM1.1d to UVM1.2. There’s even a significant number of OVM users out there. It would be exceedingly difficult for the committee to release an implementation that flags deprecated constructs from both previous releases, so we will probably only flag the 1.2 deprecated features. I would never recommend that a 1.1d user migrate to 1.2 just to migrate to 1800.2, so the 1.1d-to-1800.2 path will be a bit more difficult than a typical version change. Of course, if you followed our cookbook suggestion of writing UVM 1.1.d that is fully compatible with UVM 1.2, you’ll be in much better shape.

Now that 1800.2 is going to be the official UVM standard, once it becomes official and Accellera releases the accompanying reference implementation around the end of the year, it’ll be time to make the change. Please let us know if you’re a current 1.1d or 1.2 user, and when you think your company will be making the move. There are a few things we can do to help and we’ll do whatever we can to help you migrate quickly and easily.

And for those of you attending DVCon US February 27 – March 2, please make sure to stop by the Mentor booth on the Exhibit Floor and let us know what you think about this.