During the recently completed DAC I was repeatedly asked about the expected backwards compatibility (or lack thereof) between the currently released UVM 1.0EA and the to-be-released UVM 1.0.    Why this concern was so prevalent was not clear to me, but what did become clear is that some potential UVM users were hesitant to adopt UVM 1.0EA because they were worried that anything they did with this release might need to be extensively rewritten once UVM 1.0 was released.

When asked about this potential issue, I answered that the VIP Technical Subcommittee developing UVM was committed to keeping backwards compatibility as a first principle.  Luckily, the Co-Chair of the VIP TSC, Tom Alsop of Intel, has now directly addressed this issue here.  The bottom line is that potential UVM users need not let worries about backwards non-compatability keep them from digging into UVM 1.0EA today.

In a previous article, I mentioned the Accellera DAC Breakfast panel on UVM.  The moderator of the panel, Gabe Moretti, posed the following dilemma: UVM is to be released as open source, but it is also going to be a standard.  How, Gabe asked, can a standard, which implies a fixed definition, be able to be modified and redistributed by anyone under an open source license? This was a very perceptive question– not surprisingly given Gabe’s long history of contributing to and supporting standards activities.  Unfortunately, the panelists did not really address Gabe’s question.

One problem is that the term “UVM” is being overloaded.  On the one hand, there will the “UVM Standard”, a reference manual that precisely sets forth the details of UVM.  If the standard is done correctly, anyone wishing to implement UVM will be able to do so solely by using the description found in this manual.  This UVM Standard will be issued under a standard Accellera license, and will not be able to be modified and redistributed.  In other words, the Accellera UVM manual will not be licensed under an open source license, Apache 2.0 or otherwise.

On the other hand, there will be a “UVM Reference Implementation” that will be issued under an open source license (very likely under the Apache 2.0 license).  This Reference Implementation will not be the UVM Standard, but will be an example, albeit an officially released example, of UVM.  Anyone may take this Reference Implementation, modify it and redistribute it as long as they follow the fairly lightweight requirements imposed by the Apache 2.0 license. Of course, when the UVM Reference Implementation is modified, it will likely no longer be an accurate implementation of the UVM Standard, although one can imagine that someone might modify the official UVM Reference Implementation to make it a better implementation of the Standard if it corrects issues found in the official release.  That aside, in no case will a change to the UVM Reference Implementation constitute a change to the UVM Standard.

The source of the confusion is there are “open standards” and “open source”, but “open source standards” is something of an oxymoron.  Open standards are “open” due to the way they are developed—in an open collaborative manner– not because of the manner in which they may be modified once issued.  Indeed, once approved, even the most open standard is closed to further modification, until the group that issued the standard decides to modify it.  On the other hand, a piece of IP issued under an open source license may be modified and redistributed under that license with very few restrictions.

Thus, to Gabe’s dilemma: how can the forthcoming Accellera UVM Standard be open source?  The simple answer is that it will not be.  It will be a standard developed in a very open manner, but one that will be as “locked down” as any other Accellera Standard.   The UVM Reference Implementation will be available under an open source license, but it will not be the Standard.

Note that this there is substantial precedence for this Standard/open source Reference Implementation split: for over 10 years OSCI has been developing LRMs and open source Reference Implementations (OSCI calls them “proof of concept” implementations).  Some users may find the source code more interesting, since it can be compiled, run, experimented upon and so forth.  Moreover, LRMs generally make poor textbooks, and are of interest mainly to tool developers.  Nonetheless, all OSCI Standards make it very clear what is the Standard and what is the example of the Standard.  Accellera will do the same with regard to the UVM Standard and its Reference Implementation.

The recently completed 47th DAC in Anaheim proved to be the “coming out party” for Accellera’s nascent Universal Verification Methodology (UVM) efforts.  Of course, there has been a core of people who have been working on and/or following the development of UVM, but DAC provided a venue to let the entire community learn about UVM.

To help spread the news about UVM 1.0 EA and future releases, Tom Alsop of Intel and Hillel Miller of Freescale (co-chairs of Accellera’s VIP Technical Subcommittee) gave ½ hour presentations at both the Cadence/Mentor-sponsored OVM-UVM booth and the Synopsys-sponsored Standards Booth.  A copy of the slides used by Tom and Hillel can be found at http://www.uvmworld.org/pdf/VIP-TSC-Roadmap-June-2010.pdf.  Both presentations were quite well attended, and multiple clarifying questions were asked by the attendees.

Hillel Miller and Tom Alsop Discuss UVM

UVM was also the focus of an Accellera Breakfast panel discussion, sponsored by Cadence, Mentor and Synopsys.  The panel, moderated by Gabe Moretti of the “Gabe on EDA” blog, featured six very technically focused participants: Mohamed Elmalaki of Intel, Hillel Miller of Freescale, Stacey Seacatch of Xilinx,  Janick Bergeron of Synopsys, Tom Fitzpatrick of Mentor and Sharon Rosenberg of Cadence.  The panelists focused less on the history of UVM, and more on the internals of UVM technology and the technical path they wanted UVM to follow.

Gabe Moretti moderating the Accellera UVM breakfast panel

A measure of the interest in UVM can be gained by observing that the panel was a “sell out”—I saw very few empty seats, and I would judge attendance at between 100-150.  Very impressive for a panel starting at 7:30 AM the morning after the Denali party.

UVM was also the topic of a session in Synopsys’ Conversation Central.  In this session, the audio for which can be found at http://www.blogtalkradio.com/synopsys/2010/06/15/current-live-show-at-dac-jun-15-2010-1230pm,  JL Gray of Verilab questioned Tom Alsop and Hillel Miller on multiple facets of UVM.  I was only able to hear the first part of the session, but I did hear JL asking user-oriented questions focused how a user can migrate from OVM or VMM.

JL Gray, Tom and Hillel discuss UVM in Conversation Central

The type of questions asked by JL were perhaps the most important asked at DAC with regard to UVM, because the answers can help remove the “fear factor” associated with migration to UVM.  As Tom and Hillel expertly detailed, migration from use of OVM to UVM is straightforward, since UVM has been based on OVM.  Moreover, VMM users have not been neglected, since there is now a VMM-UVM Interoperability library available from Accellera.  Thus, Tom and Hillel assured the audience, no matter whether starting from an OVM or a VMM environment, a smooth migration to UVM is there by design.

DAC has always been intertwined with Standards for me.  In fact, the main reason I attended my first DAC in Las Vegas in 1986 was to attend the 1076 VHDL face-to-face meetings that were held before that DAC.  Over the subsequent 25 years (25 consecutive DACs!), I have, of course, attended multiple other Standards meeting in conjunction with DAC.  This year in Anaheim will be no different, starting with the North America SystemC User’s Group meeting on Sunday, running through the Accellera UVM Breakfast panel on Tuesday and a subsequent Accellera Board meeting, through a 2 day OSCI Board F2F on Thursday and Friday—with lots of other Standards-related meetings in between.

Moreover, it occurred to me recently that the place/role of Standards at DAC has evolved over the last 25 years.  At DAC in 1986, there was, of course, little mention of EDA Standards, but as VHDL and Verilog starting gaining market traction in subsequent years, EDA Standards were first mostly used as sales hooks—“our simulator covers the first 90% of VHDL, and we are close to covering the second 90%”.  Later as Standards became the common infrastructure for EDA tools, vendors concentrated less on their coverage of any particular Standard and more on what their tool suites did with that Standard.  Of course, as the periodic “Standards War” erupted, DAC was turned into a battle field in that war.  I can still (oh so fondly) recall listening to colleagues at various companies explaining how this or that event, or this or that sign (“30 feet high and right at the entrance to the rest rooms”) would decisively win the current Standards war.

However in contrast to most trends, things have actually gotten better in recent years with regards to how EDA Standards are treated at DAC.  Indeed, there seems to have been a recognition among EDA vendors and users alike that promoting EDA Standards in a more or less neutral way is good business.  Thus, for example, I shall be representing OSCI in the Cadence booth for 30 minutes on Monday, but I shall not mention Cadence’s contributions to SystemC.  Rather, I shall be vendor-neutral and focus on the activities in which OSCI is engaged that will help make technology like Virtual Platforms a practical reality.

Similarly, you will be able to hear Tom Alsop and Hillel Miller the co-chairs of the Accellera VIP Technical Subcommittee (the home of UVM) talking about UVM in both the Cadence/Mentor-sponsored OVM-UVM booth and in the Synopsys Standards booth.  In each case, Tom and Hillel will speak about UVM with at most passing reference to the sponsors of the booth in which they are speaking.  In other words, the EDA vendors sponsoring the talks will gain value for that sponsorship solely by being associated with the development of a free and open Standard.  This is quite a welcomed change from the days where DAC was the battlefield for the Standards war du jour.

In an earlier blog entry, I pointed readers to the new UVMWorld.org site.  I’d like to do this again in order to highlight two recently added items that will be of interest to the UVM community.

The first is an entry by Tom Alsop (co-chair of the VIP-TSC) indicating how to report bugs and errors in UVM.  This has been viewed over 100 times in the week since it was posted, but it deserves an even wider audience.

www.uvmworld.org/forums/showthread.php?28-How-to-report-bugs-and-enhancement-requests-for-UVM

The UVM 1.0 EA was  released to allow users to try out UVM in their environments, to see what works well, what could use improvements and to catch bugs that may have slipped through the VIP-TSC vetting process.  Of course, catching bugs in this release will not be very effective unless there is a defined process for reporting them to the UVM development team.  Tom’s post specifies that process in good detail.

The other item of interest on UVMWorld.org is an FAQ– questions that have been frequently asked about the site, and answers to those questions.  http://www.uvmworld.org/blog/  I invite you to take a look at these Q&A’s.  If other questions occur to you, please feel free to post them as comments either on the UVMWorld site or as comments to this article.