The Universal Verification Methodology (UVM) 1.0 standard has been released by Accellera, but (surprise, surprise) it's not perfect and more needs to be done. What's still missing, and what should Accellera do next? Most panelists and audience members at the DVCon conference March 1 appeared to be leaning towards an approach that will clarify and simplify the new standard before forging ahead with major new features.
Titled "UVM - Final Answer or Phone a Friend," the panel was moderated by Cliff Cummings of Sunburst Design. Panelists included the following UVM experts, shown left to right in the photo below:
The good news is that major companies are moving ahead with UVM. Fowler noted that AMD has been using a "slightly modified version" of the Open Verification Methodology (OVM) since 2008, and is now undergoing a "very large migration effort" to move from OVM to UVM.
"We have traction inside Intel with UVM," Alsop said. "Major design teams are definitely aligning towards UVM. Now that the 1.0 release is out, the next step for us is to do some internal testing. We do have some infrastructure changes to make."
How Open is UVM?
The UVM reference implementation is available for online download under an Apache open-source license. "Contributions are really encouraged," Sarkar said. "Users can contribute by joining the forums and sending us patch code. Even if you don't have development access, you can still add code and submit your patches."
But that doesn't mean it's a free-for-all. "If you're trying to contribute code you need to be aware there is a process," Alsop said. "It's open source but it's open source through a committee. We will absolutely look at it, but it's going to be reviewed by the entire committee."
It should be noted that the reference implementation is not the standard - the standard is a PDF reference manual. The reference implementation will be updated in accordance with the standard, but as Bergeron noted, "the standard is the standard."
What's Missing From UVM?
UVM 1.0 added several significant new features to its OVM predecessor, including run-time phasing, a register package, and support for the Open SystemC Initiative (OSCI) transaction level modeling (TLM-2) standard. But panelists had some thoughts about features that are still lacking. Bergeron's list included a scoreboard, performance analyzer, and hardware abstraction layer.
"There are quite a few things that could be added, whether it's extensions to coverage, various constraints, and aspect-oriented modeling," Rosenberg said. Fowler said that language deficiencies should be handled by the SystemVerilog language committee, not the UVM committee. An example of a feature that should be pushed to the language committee, he said, is field macros.
"I am involved in the IEEE SystemVerilog language committee, and we are pushing for enhancements like AOP [aspect-oriented programming], multiple inheritance, and overloading," said Alsop. "We're doing some of these enhancements with an eye towards improving UVM." Alsop also added that "we really need to be moving towards a multi-language capability for UVM." He noted, however, that there has been some "pushback" on features like AOP.
Bergeron echoed some of that pushback. "I challenge people here," he said, "to tell me whether you are really confident using virtual methods and polymorphism. And now we're starting to talk about multiple inheritance? And putting AOP on top of that?"
One audience member asked about the possibility of a mixed-signal UVM. As Rosenberg noted, Cadence presented a paper on a "UVM-MS" methodology at DVCon the very same morning.
Is It Time to Cool It?
A couple of audience members said things have gone far enough for now. "I think if we put anything else into engineers' heads they're going to explode," one said. "Now that we're done [with UVM 1.0], let's cool off, and fix what's there. The register package is a new thing and there are going to be bugs."
"You guys keep adding more and more features," another said. "When do we stop so we can figure out what we need to do?"
"We shouldn't artificially bridle this thing," Fowler responded. "There's a lack of capability in some areas that need to be addressed." However, he added that "there is nothing huge on the table right now that's going to require months and months of effort on the committee. We're not going to sit on our hands for the next six months, but we'll focus on completing the features we know about."
"There are small things we may need to enhance, but we need to clean up the methodology," Rosenberg said. "Ease of use is probably the biggest challenge for UVM right now. If we want wide adoption we need to make sure UVM is easy to use, consolidated and consistent."
"There are things we're still learning in going from OVM to UVM," Fitzpatrick noted. "When you add in new run-time phases, what are you going to do with them? We could use feedback from users."
Alsop noted that the Accellera committee is being very careful to maintain backwards compatibility as new features are considered. He also noted that UVM is a committee effort, and that "people who are passionate about the features and fixes they want to get in are going to win."
Further information about UVM is available at the UVM World web site.
Photo by Joe Hupcey III
Excellent summary of a very interesting panel session. On the spec vs. the reference implementation question, yes Janick said the spec is the spec, but Tom and Ambar pointed out that the way the process actually works right now, much of the documentation that is "the spec" comes directly from code comments in the reference design. This is significant. Like most open source projects, the code basically is the spec. This isn't a spec with several competing proprietary implementations that each have varying degrees of spec compliance. This is open source code that you can download and run anywhere.