With all of the excitement in the “front end” of the SOC design/verification/modeling community about Accellera’s UVM, it is easy to loose track of work being done around another significant front end language—SystemC.  For those not aware, there is an IEEE group (P1666-2011) that is working diligently on updating the very popular 1666-2005 release of SystemC that was originally developed by OSCI.  The charter of the current IEEE SystemC group is to add clarifications and fix errata in the 2005 standard, add  TLM 2.0 and formalize the description of the TLM 1.0 message passing facility.  There will likely also be several new features added that do not already exist in the OSCI version of SystemC, including process control extensions.  Work is expected to wrap on this new version of IEEE SystemC in late 2010, with final approval in the first half of 2011.

The “entities” that belong to this IEEE SystemC P1666 committee are Accellera, Cadence, Freescale, Intel, JEITA, Mentor, NXP, OSCI, ST Micro, STARC, Synopsys and Texas Instruments.  Note that this is a very geographically diverse group, with representation from the US, Europe and Japan.  Indeed, when I (as chair of the group) hold a P1666 teleconference, I typically find in the conference call summary report more than 10 different country codes for the phone numbers of the attendees (including non-member observers).

The country where SystemC may—a very non-scientific “may”, based on an educated gut feel– have gained the most traction is Japan.  Two events that I recently attended in Japan point to this popularity of SystemC in that country—one overtly and one more subtly.  The first was the day-long “SystemC Japan” symposium that was held in Shin-Yokohama on July 2.  This event featured speakers from both EDA and User companies talking about SystemC products and the language’s use in projects. The seminar attracted 448 attendees, and had a considerable waiting list, since the room in which it was held could not accommodate a larger crowd.  Of course, 448 is a nice size crowd under any circumstances, but consider that this event was not held in conjunction with any other event such as a trade show, and was held in Shin-Yokohama, not in Tokyo or Osaka where many major electronics companies are headquartered.  Add in the fact that the continuing economic downturn has globally reduced attendance at such events, and the fact that 448 people attended speaks volumes about the place of SystemC in the Japanese Electronics world.

Part of the crowd at the July 2 SystemC event

I would also add an observation as an non-Japanese outsider.  At many Japanese public events, the audience is fairly passive.  On the contrary, while I would not classify the audience at SystemC Japan as “raucous”, there was a palpable sense of energy that manifested itself in a surprising number of questions from the audience, and lots of energetic discussions during the breaks.  I was particularly impressed that the room was very nearly as filled at 5:30 PM on a Friday as it had been at 10 AM.  All in all, SystemC Japan spoke very well for the future of SystemC in Japan (and elsewhere, given Japan’s place in the Electronics ecosystem).

Speaking with less volume about SystemC’s place in Japan, but perhaps as importantly, was a world-wide meeting of the IEEE P1666 Working Group that took place (also in Shin-Yokohama) the day before the SystemC Japan event.  Sharp-eyed readers will have noticed that both STARC (a consortium of Japanese Semiconductor Companies) and JEITA (the Japan Electronics and Information Technology Industries Association, under which falls groups that track EDA standards) are both members of the P1666-2011 group.  Both of STARC and JEITA have been tracking SystemC’s progress very closely, and JEITA has submitted a detailed list of proposed clarifications/feature requests to the IEEE SystemC committee to consider.

Hiroshi Imai (JEITA/Toshiba), Kaz Yoshinaga (STARC), Satoshi Kojima (JEITA/NEC) & Kiyoshi Makino (JEITA/Mentor) at the Shin-Yokohama P1666 meeting

Representatives from both STARC and JEITA attended the P1666 meeting held in Shin-Yokohama, as they have via telephone in prior months when the meetings were held during the middle of the night Japan time.   During the meeting, John Aynsley of Doulos, who is leading the P1666 technical effort, discussed the JEITA requirements, and made it clear that all of them with one minor exception will be addressed in the upcoming release.  Hiroshi Imai of Toshiba, who also heads the JEITA “SystemC Working Group”, acknowledged that John had correctly understood their requests.  Thus, it appears certain that Japan’s voice will be clearly heard—as will be other regions—when the new IEEE SystemC is released next year.

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.

Karen Bartleson’s book on Standards, for which I was pleased to write a blurb for its front pages, is now out: http://synopsysoc.org/thestandardsgame.  As I indicate in my blurb, Karen’s book does a very good job of illuminating the sometimes murky world of Standards, EDA and otherwise.

It may seem odd that I would highlight and praise a book written by an employee of a major rival.  In fact, for those whose views of Standards are centered around the so-called “Standards Wars”, this may appear really odd.  Indeed, in the heyday of EDA journalism, periodically such “wars” played out on the front pages of various “newspapers”.  Because of this, there are many who still view EDA Standards groups as places where the basic tenor is one of conflict between the participants.

There is some reason behind this perception.  To paraphrase Karen 5th commandment: “Realize there is no neutral party”.  A company like Cadence, for which I work, or Synopsys, for which Karen works, spends enough (between dues and cost of participating employees) on EDA Standards to fund a nice-sized engineering group(s).  They (and multiple other companies, including companies that use EDA standards) spend large sums in this area precisely because EDA Standards are critical to their business interests.  Hence, they are not neutral to the results that come out of the Standards groups, and no one ought to be surprised when conflicts of interest occasionally erupt into a “war”.

But this is only a small part of the picture, and ignores the overarching cooperative nature of Standards activities.  Indeed, in what other forum can one find representatives from Cadence, Synopsys, Mentor and other EDA companies working in a (for the most part) cooperative manner?  Moreover, it is not only EDA companies that sit with their competitors at these meetings: it surprises no one to find companies like Intel, AMD and ARM sitting side by side in a Standards meeting.  At the end, the fact that competitors are willing to sit down with each other, and are often willing to extend non-discriminatory licenses on reasonable (often no cost) terms to what was previously proprietary technology, reveals the essential nature of a standards meeting—it is a tension-filled peace conference, not the battlefield itself.

This is the first of an ongoing series of posts related to EDA Standards activities.  In some cases I’ll be highlighting “standards happenings”, while in other posts I’ll speak out about various developments in the EDA Standards world.  I expect to use my 25+ years in Standards activities to help shed light on an area that is often murky to the uninitiated.

This initial post comes at an excellent time for the EDA Standards world, because it coincides with the release of the Accellera Universal Verification Methodology 1.0 Early Adopter (“UVM 1.0 EA” to those in the know).  The UVM, for those who are not aware, is designed to enable the development of interoperable Verification IP (VIP) in SystemVerilog.  Currently there are two dominant “Verification Methodologies”, the OVM and the VMM.  While the Accellera VIP Technical Subcommittee (TSC) created a “best practice” in 2009 for allowing VMM VIP to operate in an OVM environment (and vice versa), it was felt that an industry standard Verification Methodology was required.  Thus was born the UVM, developed using OVM 2.1.1 as a base with additional functionality taken from the VMM.  The expectation is that as time progresses, the interoperability of VIP will become increasingly less of an issue, because more inter and intra-company project teams will be using the same Universal Verification Methodology.

The creation of UVM 1.0 EA is an industry-wide collaboration triumph.  Between gathering the initial industry needs,  developing a set of requirements, narrowing that requirement set down to a manageable subset for the first UVM release, code development, code testing and documentation, multiple thousand person hours have been invested.  Indeed, even if one ignores all of the work done outside of the actual TSC meetings, my back of the envelope calculation is that since the beginning of 2010 the VIP TSC members have collectively logged nearly 1,000 person hours in committee meetings—quite the undertaking, but to very good effect.

It is also my pleasure to announce the opening of UVMWorld.org website.  As many readers will know, the OVM and the VMM both had vibrant supporting websites where users were able to tap the verification ecosystem for rapid answers to their verification questions, OVMWorld.org and VMMCentral.org, respectively.  We at Cadence believe that UVM will greatly benefit from having such a supporting website, and have chosen to create and fund UVMWorld as an open site, on which news, forums, blogs and potential extensions about/to UVM can be posted by the entire community.  This site is offered for use by the whole community in the same way that the unbranded SystemVerilog.org site was offered to promote SystemVerilog.

Thus, the UVM community has a home.  Please feel free to come home to UVMWorld.org, take your shoes off, stay a while to help make UVM the success the whole community wants it to be.