UVM: Giving Users What They Want

The development of UVM in the Accellera VIP-TSC brings up, yet again, the age-old philosophical question: should software releases be feature-driven or schedule-driven? I’ve been doing this a long time, and one thing I’ve learned is that it’s in no one’s best interest to drag schedules out to add functionality that no one wants, nor is it a good idea to ship something before it has the features that users demand. Schedules are important, because we don’t want things to drag on indefinitely (believe me, the last thing I want is for this to drag on one minute longer than absolutely necessary), but at the same time we have to realize that there are certain minimum criteria necessary for the standard to be useful and therefore widely adopted (in other words: successful).

Back in March, the TSC decided on a “Top 10” list of features that needed to be in UVM. A few of them got into the UVM-EA kit that was released back in May, but the two biggest features were additional run-time phases and a register facility. If we’re really going to make UVM a standard that everyone is going to use, it’s got to have these features in it. Although OVM users have been able to do a lot with the single run phase in OVM, a consensus has emerged that supporting additional phases and allowing multiple VIP components to be phased independently at run-time would make life easier for some folks. That’s fine, and the TSC is currently working on this functionality, based on a spec and initial implementation provided by Mentor.

As you might imagine, the addition of this new phasing functionality has significant implications on both the underlying UVM infrastructure and the architecture and implementation of VIP to take advantage of it. It would be simply irresponsible of us to try and release a UVM standard without this functionality because it would be asking users to begin developing VIP in a way that is different from the vision that we have and that users have asked for. Any responsible verification team would simply wait until the full functionality is available and develop their VIP accordingly. So what would be the point of releasing sooner?

Similarly, the register facility is equally important and far-reaching. The TSC did a thorough vetting of two contributions and overwhelmingly voted to select the Mentor/Synopsys RAL-based proposal over the Cadence proposal. The RAL proposal shows what can happen when two vendors collaborate on a solution to benefit users without regard for who gets the credit. The reality is that the underlying infrastructure is based, with minor modifications, on the VMM-RAL utility that has been in use for over five years. Mentor was able to provide our expertise in conforming this extensive infrastructure to fit better into the existing UVM environment and integrating it with the use of UVM sequences and other familiar UVM constructs.

Recently, some have argued that users are more worried about having a UVM that is called “official” than about having a UVM that meets their requirements. That is simply nonsense on stilts. As my good friend JL Gray reported back in April, “[a] full 89% of respondents want to see the UVM include a register package, and 75% would be willing to delay the release of the UVM so that a register package could be included.” The overwhelming majority prefers a UVM that is feature-driven and not schedule-driven.

The TSC is doing its best to provide the required functionality in a timely manner. There is a very good chance that we’ll get it done to meet the end-of-year goal, but worst case is we’ll have it shortly thereafter. To argue that we should remove the register functionality in order to meet an arbitrary deadline is simply disingenuous.

Releasing UVM without standardizing on a register facility will simply lead to further division in the industry. Without a standard way of modeling registers and, as importantly, interacting with those registers at the sequence level, UVM users will be forced to choose one way or another, with no guarantee that the tests or sequences they write will work with VIP that someone else may have developed. What kind of a standard is that?

If I were a cynical person, I might suggest that someone promoting this idea was simply looking for a way to get around the committee process so that they could try and proliferate something that they were not able to convince the TSC was the better solution. A cynical person might question the commitment of that company to the success of the VIP-TSC as a standards body, and the UVM as a standard.

It’s a good thing I’m not too cynical.