Archive for October, 2010

14 October, 2010

23rd Synopsys EDA Interoperability Forum Features a Verification Session with focus on the UVM Register Package

UVM_Logo As readers of the Verification Horizons BLOG know from recent posts, progress towards a register & memory facility in UVM 1.0 is well underway.  While the Accellera VIP-TSC is making good progress, limited information is available to non-participants.  This limited knowledge is true for both eventual users of the standard as well as for many EDA, IP and VIP companies that don’t participate directly in the development activities but whom could benefit from planning for tool and IP interoperability.  As the standard nears completion, it is important for other EDA and IP companies to know how they might collaborate with others in support of the pending standard.

The 23rd Synopsys EDA Interoperability Forum offers EDA and IP companies and others who will integrate the use of tools and Verification IP from several vendors a first look at the new UVM 1.0 Register Package.    The Forum’s 3:15 p.m. – 4:15 p.m. session will focus on Verification and UVM Register Package interoperability.

Mark Glasser, Methodology Architect at Mentor Graphics, will share the presentation time with a couple other presenters.  His presentation is “Building Register Verification Environment in UVM.” We encourage those who can make it to the event and have the time on October 21st to attend to do so.  Mark and other experts will be able to share their UVM development experiences and offer key insight into the newer UVM 1.0 Register Package features.

The event is free of charge, but registration is required to attend this session and any others at the Forum.  Forum details are:

Date: 21 October 2010
Time: 9:30 a.m. – 4:30 p.m.
Location: Oracle Conference Center at Agnews Historic Park, Santa Clara, CA 95054 USA
Forum Website:

, , , , , ,

5 October, 2010
Technorati Tags: ,,,

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.

@dennisbrophy tweets

Follow dennisbrophy

@dave_59 tweets

  • @BooneJS Someone still needs to design that FPGA, and you won't see FPGAs in a mobile device. U still need metrics to verify quality
  • @BooneJS Facebook/Google/etc... is why no one wants to work on HW - it's a solved problem. BTW the engr student in the article is my son.

Follow dave_59

@jhupcey tweets

Follow jhupcey