Thoughts On SystemC Users’ Groups

I ate breakfast a few weeks ago with Gabe Moretti of GabeOnEDA fame—always a pleasant event.  During our discussion, Gab opined that the Open SystemC Initiative (OSCI) was superior to other front-end standards organization because of its SystemC Users’ Groups like NASCUG, ESCUG, the Taiwan SystemC users’ Group, SystemC Japan and so forth.  At a certain point I had to interrupt

Gabe Moretti

him, and tell him that OSCI did not actually organize or run any users’ groups.  True, it funds to a greater or lesser degree the various SystemC User Groups around the world, but it does not control them in any way.  I went on to argue, that this is the “right” way to do things.

To clarify this point, consider the case of a wealthy person who wants to help the homeless.  She might decide to directly organize an effort to build houses for people who have none.  To do this, she could provide the financial backing for the project, get subcontractors lined up to install/erect the various subsystems of the house, and maybe even enlists the help of some volunteers.   Alternatively, she could give a substantial donation to an organization like Habitat For Humanity, which would run the project, including soliciting and organizing the volunteers who would do most of the actual work. 

Neither way of getting houses built for the homeless is ultimately “better”—people get homes in either case.  However, I think that most people would agree that there is something more impressive about the second path—volunteers coming together to help their fellows.  This does not diminish the virtue of the donation that the wealthy person makes to Habitat, but adds a sort of layer of goodness above it.

An analogous situation can be seen in the relationship between OSCI and the various SystemC User Groups.  In the early days of OSCI, the “Promotions Group” funded and organized most of the public meetings at which use of SystemC was presented.  Anyone who has ever organized such public meetings, knows that there are a lot of logistical headaches, not the least of which is getting users’ (who are generally working engineers with day jobs) presentations in on time.  Thus, the OSCI people, who organized these early SystemC User events, put in a lot of effort—effort that was rewarded by the steady growth of SystemC usage.

But a funny thing happened on the way to the proliferation of SystemC usage that we have witnessed over the past few years.  A group called the “European SystemC Users’ Group” (ESCUG) was formed in the early 2000’s.  This group did not ask OSCI to organize their meetings in any way, but only asked for some funding to help pay for things like refreshments, meeting rooms and so forth.  In return, OSCI was given a slot on the ESCUG agenda to present an organizational update.  It (OSCI) was not involved in any way in the organization, or in the execution of the twice-a-year ESCUG meetings.  Indeed, it did not seek to be involved, since those grass toots-level meetings turned out to be of very high quality.

A similar organization, the North American SystemC Users’ Group (NASCUG) was founded in 2005, and while also funded by OSCI, was treated in a similar hands-off manner.  Other such groups arose in Japan, Taiwan, Brazil and India.  In some cases, OSCI provided funding, while in others, the local meetings were held completely independently of OSCI.

Note the parallel with the home building case described above.  In the case of each SystemC Users’ Group, OSCI could have formed the group and administered its meetings.  Users would still have attended, and SystemC would have prospered to some (impossible to quantify) degree.  However, I would argue that SystemC prospered even more because of the substantial effort expended by users in pulling together the SystemC meetings in their regions.  Nothing fosters adoption of a technology like users feeling (and having) ownership of it.

Thus, my response to Gabe, who (I believe) immediately saw my point.  Yes, OSCI could have fulfilled its mission of supporting SystemC usage by directly organizing and hosting Users’ Group meetings around the world.  Indeed, it effectively did so in North America in the early days.  However, I would claim that it fulfilled its support mission much more efficiently by funding motivated SystemC users, and “letting them have at it”.

SystemVerilog in Japan

During the EDSF show held in Yokohama in late January, there were several meetings between members of JEITA and members of the IEEE

Hamaguchi-san (SystemVerilog WG Chair, Panasonic), Kojima-san (JEITA Fellow, NECST), Imai-san (SystemC WG Chair, Toshiba)

Design Automation Standards Committee (DASC).  These meetings were designed to bring the various organizations‘members up to speed on the other groups’ activities.  This is important, given that there are overlapping interests among the various groups, but time zone differences often make meeting together difficult.

First, an introduction to JEITA—the Japan Electronics and Information Technology Industries Association.  According to its website, JEITA’s purpose is:

The list of product areas covered by JEITA is wide ranging– from the component level (e.g., transducers and electronic tubes) to the full product

Figure 1. The EDA-TC's place in JEITA

level (e.g., broadcasting equipment and computers)—and basically covers every corner of the world of electronics. Most relevant to this article, one of the topics that JEITA covers is software in the electronics space, including EDA software.

During the meeting, Satoshi Kojima, from NEC System Technologies and a JEITA Fellow, presented an introduction to the EDA Technical Committee (EDA-TC) of JEITA, which as figure 1 shows, falls in the JEITA hierarchy in the semiconductor area.  As shown in figure 2 below, the EDA-TC, which is lead by Yoshida-san of Renesas has three main areas of focus:

1. Acceleration of standardization
2. Solutions for technical challenges
3. Promotion of EDA technology

Focusing on the first topic area, EDA standardization, there are three topics of interest: SystemC, LSI-Package-Board Interoperable Design and SystemVerilog. 

Figure 2. The JEITA EDA-TC's structure

The SystemC Working Group (WG), led by Hiroshi Imai of Toshiba, was very active in 2010, providing significant input to development of the IEEE P1666 SystemC standard.  This draft standard is now working its way through the latter stages of the IEEE process, and P1666-2011 is expected to be approved this year.  Given this, the JEITA SystemC Working Group will be winding down its work this year, while the SystemVerilog WG, to be lead by Kasumi Hamaguchi of Panasonic,  will be ramping up in anticipation of the P1800-2012 SystemVerilog effort currently being developed under the auspices of the IEEE DASC.

The first informational meeting held in Yokohama was between the entire DASC and JEITA.  In this meeting, the DASC WG chairs introduced the JEITA members to the details of the various working groups that the DASC sponsors.  Kojima-san then provided an update on the JEITA EDA-TC—the two slides I used above came from his presentation.

This meeting was followed by a second meeting during which the IEEE P1800 SystemVerilog WG’s plans were outlined by its chair (Karen Pieper of Tabula).  Karen outlined the organization of the P1800 group:

1. The Working Group management layer, where all changes to the SystemVerilog Language Reference Manual (LRM) are approved, and business aspects, e.g., hiring technical writers, are handled.
2. The champions—a group of SystemVerilog gurus, whose charter is to look at the work produced by the various technical committees, and ensure consistency across the language.
3. The technical committees that look at specific aspects of SystemVerilog and enhance, correct and clarify the language.

Figure 3 shows the organization of the P1800 WG.

Figure 3. IEEE P1800 (SystemVerilog) WG organization

Each of the chairs of the technical committees subsequently presented the areas they are investigating.  All are working towards producing a new draft SystemVerilog LRM by the end of 2011, with the vote on this draft and subsequent approval by the IEEE anticipated during 2012.

Finally, Tom Alsop of Intel, co-chair of the Accellera VIP Technical Subcommittee (VIP -TSC), informed the JEITA attendees of the work that has been done on the Universal Verification Methodology (UVM) standard that is expected to be approved early in 2011.  While the IEEE P1800 group is defining a newer version of the SystemVerilog language itself, Tom’s VIP-TSC group has developed a way of using the language to help “define standard technology and/or methods to realize a modular, scalable and reusable generic verification environment”, according to the group’s Accelelra.org web page.

One question that was raised concerned the potential for the IEEE P1800 “language-definition” work and the UVM “language-use” work getting out of sync.  After all, it was asked, if UVM is released in 2011 and a new version of SystemVerilog is released in 2012, is there not a danger that the UVM will quickly become out of date due to language changes?  This concern was addressed by Karen Pieper by noting that the 2012 version of SystemVerilog will be backwards compatible with the current version of the language.  Thus, as Tom Alsop noted, while the UVM might be updated later to take advantage of new features found in P1800-2012, it will remain compatible with both the current and future versions of SystemVerilog.

At the end of the joint meeting, the members of the JEITA SystemVerilog WG indicated that they had a good understanding both of the ongoing work of the IEEE SystemVerilog group, and of the more imminent UVM release.  They also indicated that they would be meeting to decide whether to directly participate in the IEEE WG activities, or to produce a set of requirements for the consideration of the P1800 group (or both).  In any case, users in an important region will have their voices heard in 2011 as SystemVerilog is developed, much as in 2010 the JEITA SystemC WG helped channel the voices of Japanese SystemC users during the development of the P1666-2011 standard.

Standards– This Time It’s Personal

On Sunday evening December 6, I came face-to-face with part of my past.  The window to my past was opened by meeting (after a very long hiatus) two of the “founding fathers” of the EDA standards world, Hal Carter and Ron Waxman, at the IEEE Standards Association Awards Banquet in New Brunswick, NJ.

Before I go further, a bit of personal history might be useful to put things in context.  I am currently in my second career—my first career was as a philosophy/symbolic logic professor.  Indeed, one can still find some of my early articles on various aspects of symbolic logic on the internet—articles that researchers still sometimes mention in their bibliographies.  These researchers probably ask themselves, “Whatever happened to that Krolikoski fellow?  Wrote a few moderately interesting essays, and then disappeared.  Probably living on a park bench somewhere.”

What actually happened was a dose of reality— it is not easy to earn a living as a researcher into the foundations of mathematics.  Insurance companies might be interested in hiring mathematicians to construct actuarial tables, but they are not keen to hire someone worried about whether mathematics is a product of the human mind, or (as Plato thought) a firm part of reality and independent of humans doing math.  I discovered that Platonists like me are not sure-fire employment candidates.

However, “high technology” is another matter, and, at a certain moment in the early 1980’s, I went back to school, and eventually found work at Honeywell.  To be honest, I made the transition a bit begrudgingly—the study of symbolic logic and philosophy in general just seemed more interesting than computer science.

My graduate work had actually been in what we now call EDA—minimization of PLAs– but, once I got to Honeywell’s Computer Sciences Center, I became engrossed in research on architectures for artificially intelligent machines.  AI appealed to me as being the closest thing in high technology to Philosophy.

And so, there I sat in Minneapolis in 1986 at my Symbolics machine, happily typing LISP code, when my manager came to me and said “We need you to go to a meeting on some work the DoD is doing– some language called “VHDL”.  This is a onetime only thing, and we’ll find someone else to cover for you for the next meeting.”  Since the ‘V’ in “VHDL” (which my manager mispronounced as “Vheedle”) stood for “VHISIC” and Honeywell was one of the three (along with IBM and TI) prime VHSIC contractors, it was imperative that someone from Honeywell be at the Vheedle meeting, and I was the luckily fellow chosen.  I was not thrilled about this assignment to say the least.

That was almost 25 years ago, and my Honeywell manager obviously did not get someone else to cover for me for subsequent meetings.  Instead, he inadvertently put me on an unexpected career path in which EDA Standards have played an integral part.

I have, of course, met many interesting people along the way in doing Standards, but, as it turns out, I met two of the most interesting (and influential) at that first meeting on VHDL: Ron Waxman and Hal Carter.  Ron was working at IBM and Hal was in the Air Force at the time I met them, although both soon took jobs elsewhere—Ron joined the University of Virginia and Hal joined the University of Cincinnati.  They were very different personality-wise, but each had a vision of a future set of standards– VHDL being the first—that would help bring order out of the chaos of proprietary formats and languages in which the electronics industry found itself in the mid 1980’s.  To this end in 1985 they created an organization, the Design Automation Standards Subcommittee (DASS) under the IEEE Computer Society with the vision that the DASS would be the home of electronic standardization.

Clearly their vision was very compelling to me, since I have stayed around in the DASS (and its successor the DASC—“Subcommittee” became “Committee”) with only short breaks for more than 25 years, and am currently its Chair.  Indeed, it was Ron’s and Hal’s vision of the DASS/DASC as a future key element of the electronic industry’s infrastructure that “spoke to me” in a way that little in my post-philosophy career had.  Simply put, they (and a few others like John Hines and Erich Marscher from those early days of the DASS and VHDL) are the reason I am writing this blog on Standards.

Hal Carter (center right) receives the Ron Waxman Award at the IEEE Standards Association Awards Banquet. Ron Waxman is on the left. Also shown are Charlton Adams and Ted Olsen of the IEEE

This brings me back to this past Sunday’s Awards Banquet.  A few years ago the DASC established the “Ron Waxman Design Standards Committee Meritorious Service Award” as a sort of analog to the lifetime achievement award at the Oscars.  This year Hal Carter was awarded the Ron Waxman award, and was introduced at the banquet by none other than Ron Waxman himself.

A DASC pre-Awards Banquet get together. Shown (left to right) are Dennis Brophy, Rich Goldman, Joe Daniels, Yatin Trivedi, Victor Berman, Hal Carter, Stan Krolikoski and Karen Bartleson

Of course, the citation that went along with the award mentioned Hal’s impressive contributions as a founder of the DASC, one of the forces behind VHDL and his work in higher education promoting research based on DASC Standards.  All this, of course, is very accurate, and the vision of the DASC as the home of EDA standards has to a large degree been fulfilled—the DASC sponsors the VHDL, SystemVerilog, IP-XACT and SystemC Standards to name a few.  However, from a personal standpoint, the award ceremony touched me more than, for example, seeing a sportsman, or an actor, or even an electronics executive receive an award would have.  Seeing Ron Waxman on stage along with Hal Carter helped me validate the choice that I made long ago to help at least a bit in implementing their vision of an Electronics Industry bolstered by an infrastructure of EDA standards.

Thanks Hal.  Thanks Ron.  Thanks for pointing me in the right direction.

Another Standard Forthcoming in 2011

In my most recent post I highlighted two Standards that are scheduled to be released in 2011, viz., UVM from Accellera and SystemC from the IEEE P1666 Working Group (WG).  In this post, I’ll focus on another Standard that will be put to a vote (and presumably approved) in 2011.  The Standard is the “e” language standard developed by the IEEE P1647 WG, chaired by Darren Galpin.

Darren was kind enough to give me a list of new features in the upcoming P1647 release with a brief explanation for each feature.  Rather than try to rephrase his excellent summary, I will use Darren’s list almost verbatim with only light editing:

1.  Define-As-Computed Macros. This capability allows the definition of a new language construct using an action block to build the replacement code. It is included in the new revision requirements due to a direct user request.

2.  Interface Ports. The intent here is to support ports of standard transaction level model (TLM) interfaces (originally developed by OSCI as part of SystemC).

3.  Named Checks. Every check statement can be uniquely tagged with a name. This allows coverage to be collected automatically on checks, and coverage can be extended by constraints based on the name.

4.  Named Constraints. Every constraint can be uniquely tagged with a name, which allows individual constraints to be overridden by other higher-level constraints, or perhaps switched off if certain behavior is not desired.

5.  Parameterized Types. This allows template types in which you can define generic structs and units that are parameterized by type. They can be instantiated later by giving specific types as actual parameters.

6.  Real Data Type. This provides support for real numbers.

7.  Type Constraints. These restrict the declared type of a field to one of its kind, or as subtypes for a given context.

A “Ballot Group” to vote on the LRM developed by the P1647 WG was recently formed. This Ballot group consists of 30 individuals from around the world, all of whom signed up as to vote either because they use e, develop e-based tools, or because of a general interest in the standard. Once a few minor editorial changes are made to the P1647 LRM, the first month-long round of the ballot will take place.

At this point in an IEEE-literate world, I could stop the discussion and move onto another topic.  However, I find that most people (including not a few participants in IEEE activities) are baffled by the IEEE voting rules. Thus, it probably makes sense to add some explanation in this context.

The simplest way to gain insight here is to remember the “75/75 rule”.  For any standard at least 75% of registered voters in a Ballot Group must actually vote. Of that 75+% of registered voters, at least 75% must vote to approve the draft standard. In the case of P1647, this high voting bar means that at least 23 of the 30 individuals registered to vote must actually cast a vote.  Assuming that exactly 23 votes were received, 18 would have to be positive for the process to proceed.  Note that any voters, who vote negatively, must give a reason for their negative vote.

After the first ballot, assuming that the 75/75 rule is satisfied, then any negative comments made during the first round of voting must be addressed. This “addressing” does not necessarily mean “rectifying”, although that is, of course, always a good outcome.

Once all of the issues raised in the first round of balloting have been addressed, a second (once again, month long) “recirculation” ballot will be held. During this recirculation ballot, members of the Ballot Group will be able to either change their initial vote, or to vote for the first time.  If at the end of this second ballot, at least 75% of the members of the Ballot Group have cast a positive vote (either unchanged from the first round, changed  to positive in the second round, or cast for the first time as a positive vote in the second round), then the draft Standard will go on to “higher level” committees in the IEEE, where, barring unforeseen issues, the Standard will be made official.

One final point to raise concerns who casts the votes in these sorts of elections, or, rather, whom the voters represent when voting. The answer is “it depends”.   Working Groups in the IEEE Standards Association may be formed at “individual” or “entity” based.  In the former case, members are individual experts, and represent themselves when making decisions (of course, what their employers want may also be in the back of their minds).  In the entity-based WG case, the members of the WG all represent an “entity”– a corporation, an association, a university etc.  In such an entity-based WG, all actions are taken by representatives of the entities that are members of the WG.

I discussed this difference previously, so I will not go any deeper into the different types of IEEE Working Groups.  However, this difference is relevant to this post, since the simple rule is that a Ballot Group formed to vote on a draft Standard that was developed by an individual-based WG (like P1647) will be made up of individuals.  Not surprisingly, a Ballot Group formed to vote on a draft standard that was produced by an entity-based WG will be composed of representatives of entities (not limited to those entities that participated in the WG).

In my next post I shall examine an IEEE Working Group– the P1734 IP Quality WG– that in the near future will be forming an entity-based Ballot Group with an eye to approval and release in 2011.

New & Updated EDA Standards Coming In 2011

I have not posted in a few weeks, but not because things have been quiet in the Standards world.  Rather, too much has been happening, and it has been hard to find time to sit down and summarize for those who might not be intently following such things.   To make up for this neglect,  I plan in the next few weeks to highlight several Standards efforts that bear serious watching.  In this post, I’ll focus on Accellera’s UVM and the IEEE’s SystemC upcoming releases.

First, some words about the Accellera UVM effort.  As many of you will have observed in this blog and elsewhere, there has been a lot of publicity around this emerging standard.  This is not surprising, given the importance to the industry of developing a standardized methodology for describing Verification IP.  Of course, there already existed several very popular (and very technically complex) verification methodologies, e.g., eRM, VMM, URM, AVM and OVM.  However, all of these were supported by at most two of the major simulator vendors, and none were standardized.  EDA tool user companies such as Intel and Freescale took notice of this overabundance of methodologies—the classic ‘too much of a good thing”.  To bring some order to this relative chaos, they brought the three major EDA vendors along with multiple other user companies and smaller EDA companies to the table, and pushed to develop a single “Universal Verification Methodology”.  So was born UVM.

Of course, the publicity that accompanied the development of UVM was the (relatively) easy part.  Producing the initial release of UVM, the so-called “Early Adopter” release, was much harder, and the release of the full UVM 1.0 release has proven even harder.  Developing  a real Standard and a creditable reference implementation to accompany  that standard is always really difficult work—work that is made even more difficult by the twin facts (a) that the work is done part-time by volunteers and (b) that fierce competitors are working together to produce a common “product”.   Thus, it is not surprising that the development of UVM 1.0 has been a major time-consuming undertaking that has required steadfast and dedicated participation by the members of the Accellera Verification IP Technical Subcommittee (VIP TSC).

However, I am pleased to report that despite the difficult nature of the task, the VIP TSC is successfully working its way towards the release of UVM 1.0 near the end of Q4 2010.  Thus, in Q1 2011 users can expect to see an Accellera Standard UVM, and can start planning to adopt UVM during 2011 as new projects are begun.

More discussion by me on UVM, albeit a little bit more from a Cadence perspective, can be found here.  For more information on UVM 1.0 and to get involved on the 1.0 or future releases, contact Tom Alsop, the co-chair of the VIP TSC..

The other standard that I’d like to highlight in this post is the IEEE P1666, i.e., SystemC, standard.  SystemC has steadily grown in popularity since its introduction at the beginning of this decade to the point that most of its erstwhile C-based competitors in 2000 have passed from the scene.  Indeed, it is not an exaggeration to say that SystemC and C++ (upon which SystemC is based) have become the two languages most used for high-level hardware modeling.

The success of SystemC aside, it also as had the peculiarity of being a “Standard language” split between two standards groups.  The original SystemC language was, of course, developed by the Open SystemC Initiative (OSCI) in the early 2000’s.  In 2005, the SystemC language was transferred to the IEEE, and IEEE 1666 was released in 2005.   OSCI later made the outstanding decision to fund the ability of users to freely download the SystemC Language Reference Manual (LRM).  This decision, to my mind, was a key factor in SystemC becoming king of the ESL language hill.

However, time (as it usually does) marched on, and OSCI produced two addition standards on top of SystemC, viz., TLM 1.0 and TLM 2.0.  TLM 1.0 was never completely fully documented, while TLM 2.0 was adopted as an OSCI standard in 2008.  Thus, the “SystemC standard” was spread across two organizations, and in the case of TLM 1.0, not completely documented.

As it turns out, the IEEE SystemC standard was due for a revision beginning in 2010, since—as with all IEEE Standards—it is required to undergo a process at least every five years in which it is either reaffirmed (accepted again without change), revised or withdrawn.  Given this, and given that IEEE 1666 was released in 2005, this meant that 2009-2010 was the year to begin work on an updated standard.  A new P1666 working group was formed in late 2009, and it was decided that the main thrusts of this new IEEE SystemC Standard would be:

1. Fixing any errata and adding clarifications to the previous IEEE 1666 version
2. Better formalization of TLM 1 Message Passing Interface
3. Incorporation of  OSCI’s TLM 2 standard
4. Addition of selected new features.

The major new feature to be added under the latter category is a “process control” extension to the SystemC language.

The good news is that the P1666 work is proceeding nicely, and a completed LRM is poised to be released to the members of the working group for a 45 day review at the end of November.  It is then expected that a full “Sponsor Ballot” will be conducted during Q1 of 2011 with full IEEE approval of IEEE 1666-2011 SystemC Standard later in that year.  I am chair of the P1666 working group, so for more information on that group’s effort, readers may contact me directly.

Thus, 2011 will see the release of major new standards related to both SystemVerilog and SystemC.  In my next post, I’ll talk about other very interesting EDA Standards that will be released in 2011.

Planning For IEEE Standards Association Corporate Membership

With the 2011 Corporate budget planning cycle about to begin in many companies, I thought it appropriate to review the IEEE Standards Association (SA) Corporate membership plan, including both its costs and benefits.  This will allow companies that feel that SA membership is beneficial for them to put the membership dues in their 2011 budgets.

The IEEE, as almost all of you will know, is the body under which numerous standards are developed.  These include not only such familiar EDA-related standards as SystemVerilog, SystemC, VHDL, PSL, IP-XACT, UPF, JTAG and e, but also somewhat lesser known (but certainly not of lesser importance to their users) standards like Rosetta and Esterel.  What you may not realize is that the IEEE SA has in recent years begun to emphasize its Corporate membership program.  Under this program, more IEEE working groups (WGs) are being organized as “entity-based”, i.e., are being set up as composed of members that are “entities” (corporations, non-profit organizations, consulting firms and so forth) as opposed to being a group of individual experts.

Such entity-based WGs have the distinct advantage that the influence of a member is not a function of its size and/or the number of individuals it can send to a meeting. Specifically, in an entity-based WG a very large company, a non-profit standards support organization and a small consulting firm will each have the same number of votes —one— on any issue.  Not all IEEE WGs are entity-based, although most of the EDA standards that are sponsored by the Design Automation Standards Committee (DASC) are.  However, the trend inside of the IEEE SA seems to be heading in the direction of such entity-based standards WGs.

To facilitate this movement, the SA has instituted a two-level Corporate membership structure: “Basic” and “Advanced” Corporate memberships in the SA are available.  The details and benefits of the various levels of membership are explained in detail on the SA’s website. However, most relevant to this article, the two levels of membership determine the extent and manner in which a member may participate in the meetings of entity-based WGs.  Advanced Corporate members may fully participate for no additional dues in any entity-based WG—“full participation” meaning (among other things) the ability to make proposals and technical contributions, serve as officers of the WG, vote on motions and so forth.  Basic Corporate SA members, on the other hand, may join an unlimited number of entity-based WG as an observer for no additional dues.   Non-SA members may attend a single entity-based WG meeting, but only as observer—presumably to get enough information to decide whether to join the SA.

The cost of such corporate memberships might have become a sticking point if handled badly.  Indeed, it would have undermined the above-mentioned advantage of leveling the playing field inside of an entity-based WG if each prospective member had to pay the same amount of membership dues.  Simply put, what might be a small fee for a large company could easily be prohibitive to a small consulting firm.  To mitigate this potential problem, the SA put its annual corporate dues on a sliding scale based on revenue.  Yes, there is still a cost to join, and some pain associated with the dues–  especially in the current down economy.  However, for those organizations to whom standardizing technology is critical, the sliding scale attempts to turn these dues into an affordable “cost of doing business”.

The sliding scale for IEEE SA Corporate membership dues is located at the bottom of the same web page on which they give information about the membership levels.

This is where you, the readers, are given an action item.  If you have read this far, then you likely have an interest in EDA standards.  That being the case, it may very well make sense for you to work to get the proper level of SA Corporate dues into your organization’s 2011 budget.  Depending on your organization’s financial situation, Basic Corporate membership may be the only viable option, but such membership will still have the distinct advantage of allowing members of your organization to observe at WG meeting, thereby giving you early information about upcoming Standards.  Of course, the Advanced Corporate membership option looks to be an even better choice, since such a membership level will allow your organization’s voice to be fully heard.  In either case, the worse choice will be to do nothing,  and discover next year that you are not eligible to attend or participate in an IEEE WG of high importance to your organization.  This will force you to either sit on the sidelines, or go back and try to find the relevant monies for dues in an already set (and often very tight) budget.

Standards & Reference Implementations

In a previous blog entry, I spoke about the relationship between Standards and Open Source software, concluding that “open source standard” was an oxymoron.  One topic that I did not discuss was the relationship between a Standard and the so-called “Reference Implementation” (“RI” for short) of that Standard.  This relationship is not as straightforward as it might first seem, and is, in fact, the subject of important discussions in several of the EDA Standards groups with which I am currently involved.   Because of this, I have been doing a lot of thinking about the issues surround RIs, and hope the following can help focus those discussions.

First the basics:  an RI is a piece of software that is associated with a Standard.  This “software” need not be code that can be compiled into an executable program—the RI that the SPIRIT Consortium developed for their IP-XACT Standard is text-based xml.  Nor does an RI necessarily come from the same group that developed the associated Standard—for example, the Fraunhofer Institute, not OSCI, developed the RI for SystemC AMS.  Finally, an RI need not be made available under an open source license—the very successful Si2 Open Access RI, for example, is available under a non open source license.

The allure of an RI is not hard to see.  It provides a concrete embodiment of a Standard, i.e., something that both users and tool developers can sink their teeth into— something besides  a “mere”  precise (and non-executable) specification.  Indeed, on multiple occasions (including in the past two weeks) I have heard sophisticated users declare that a Standard’s RI is the only item in which they truly are interested.  Often the users who take this position summarily dismiss the actual Standard as being only a “paper spec”.  Other users understand the power of a true Standard, but also value an RI as a means of facilitating early adoption of a Standard before it is implemented by vendors.  Everyone, or at least almost everyone, seems to love RIs.

However, all that love aside, every Standards organization makes it clear that when one of their specifications and an associate RI conflict, the specification, i.e., the Standard, takes precedence.  In other words, the RI is an accompaniment, not the main course. But what sort of accompaniment is an RI?

There are, as far as I can see, three possible relationships between an RI and the Standard to which it refers:

1. Lockstep—the Standard is always released with an accompanying RI, and each RI is designed to fully embody the Standard with which it is released.  In this case, the Standard and the RI can be viewed as two sides of the same coin, with the usual caveat that the Standard takes precedence in case of dispute.
2. Proof-of-concept—the RI is meant to make new standardized technology more approachable, i.e., to prove the Standard’s relevance/usability.  As this standardized technology becomes mainstream, its proof-of-concept RI may be allowed to “get rusty”, or may even be discontinued.
3. Snapshot—the release of Standard and its associated RIs are decoupled.  Periodically the group that standardizes technology and develops associated RIs takes a “snapshot” of the current RI, and produces a formal specification that embodies the new version of the Standard.  Additional (backwards compatible) RIs that add onto the RI captured in the latest Standard are subsequently developed and released.  Eventually, the group will take a snapshot of one of those new RIs, and after appropriate formal documentation, an updated standard will be released. The cycle will then repeat.

A Standards group may decide to not have any RI associated with its Standards—the IEEE Design Automation Standards Committee (and, I believe, the entire IEEE Standards Association) works this way.  However, if a Standards organization’s working groups are permitted/expected to produce RIs, then that organization’s governing body must decide what the relationship is to be between the generated Standard(s) and the RI(s).   Nothing good can happen, for example, when a Board of Directors is split between those who expect a lockstep relationship between its Standard and RI, and those who favor a proof-of-concept relationship.  One part of the group will expect that any released Standard will be accompanied by a comprehensive RI, while the other faction will expect a retirement plan for any RI as its associated Standard goes mainstream.  Similarly, warning flags need to be raised if a working group is chugging along assuming a snapshot model between the Standard and RIs that it will produce, while the organization’s Board of Directors is still assuming a lockstep relationship.  There are advantages and disadvantages to each Standard/RI relationship, but there are no advantages to not settling on one such relationship and sticking with it.

The Importance of Front End Standards

It was recently announced that Shishpal Rawat has been elected Chair of Accellera, a key “Front End” (i.e., RTL and above) EDA Standards organization.  This by itself is a fine development, since I have absolutely no doubt that Accellera will prosper under Shishpal’s leadership.  However, it is also a continuation of a trend.  The Chair of OSCI, another very important Front End EDA Standards organization, is Eric Lish, also of Intel.   Looking further, the “Configuration, Control & Inspection” (“CCI”) Working Group, one of OSCI’s hottest technical groups, is chaired by Trevor Wieman of Intel.  Finally, swinging back to Accellera, the Verification IP Technical Subcommittee (VIP TSC), which is developing the (much in the news) UVM, is co-chaired by Tom Alsop of (surprise!) Intel.

What to make of this?  I can make no claim to speak for Intel, but one of my observations over the years has been that it is a very well run company, and things rarely happen there by happenstance.  Thus, I take the fact that Intel management has agreed to not only have some of its talented employees participate in, but to actually lead key Front End Standards activities is an excellent indicator of the continuing importance of such Standards.

The “Open Source Standard” Oxymoron

Recently I explained why the forthcoming Accellera UVM Standard will not be released under an open source license.  UVM will have an open source reference implementation associated with it, but the actual UVM Standard will not be open source.  After the blog was posted, some people reasonably complained that I did not really explain the differences between Standards and open source, and that I was much too cursory in why I deem “open source Standard” to be an oxymoron.  In response to these comments, I replied that a more detailed examination of the issue would be forthcoming.  This is it.

First, “Standard” is short for “standard definition”.   Different sorts of items may be standardized, e.g., a unit of measurement like the meter, protocols for a type of communication like the 802.11 standards, or a design language like SystemVerilog.  In every case, the definition of an item must meet the following four criteria to be a full Standard:

• Completeness. There ought to be no need to look outside the definition, except to other Standards from which this Standard is derived.
• Unambiguity. The definition must not leave an expert reader of the Standard unsure of the Standard developers’ meaning on any point.
• Stability. The definition must be valid for a substantial period of time during which users of the Standard can rely on the definition not changing.
• Owned. There must be a person/group in charge of the definition to whom defects, e.g., ambiguity, can be reported, and who will determine when and how the definition will be updated.

Of course, many Standards, including EDA Standards, fall short in meeting some of the above criteria– ambiguity is particularly problematic.  However, whatever their particular failings, any Standards setting entity must have the intention of meeting the stated criteria to be legitimate.  Indeed, all of the EDA Standards groups of which I am aware do strive to meet these criteria.

Note also that there is no mention in the above list of the openness of the Standard’s making process– a good Standard could be declared by Imperial fiat.  Nor is there any requirement for a formal Standards organization to be involved.  A Standard could be defined within a single company, have no validity/visibility outside of that company, but could still be a fine company Standard.

Finally, there is no uniqueness requirement for Standards.  One of the “funny lines” that I have heard far too often is “Standards are great because we have so many of them to choose from”.  My (generally muted) response is: “What’s your point?”  For example, both NEMA and EESTI have developed Standards for electrical plugs (for the US and most of Continental Europe, respectively).  The fact that their plug Standards are very different does not make them any less Standards.  If you have a device with a plug that meets the EESTI plug Standard, that device will be able to be used without adapter in any EESTI compliant socket.  It might, as a matter of fact, be better for only a single Standard to exist in a particular technology area/market, but that is not an issue directly related to Standardization itself.

Unlike Standards, open source IP (software, hardware, documentation…) is very much defined by the license under which it is released, rather than characteristics of the IP itself.  For example, the Open Source Initiative has developed a very good set of criteria with which open source software must comply.  Note that all of these criteria, except the second, refer to characteristics of the license under which open source software must be released.  An open source license, for example, must allow for unencumbered re-distribution of both the original software and any derived works.  The license must not discriminate against any person, groups or field of endeavor, and so on.  In general, almost all of the OSI’s criteria are focused on the terms under which the open source software is released.

The outlier is the OSI’s second criterion.  This is not about a license, but about the required presence of source code in an open source release– which makes sense given that this set of criteria comes from a software organization.  I would generalize this requirement to read that open source IP must be delivered in a “modifiable” form.  To see how this “modifiable” criterion applies beyond the software case, consider the UVM User’s Guide.  This document is available in MS Word format under the Apache 2.0 open source license as part of the UVM release (and, as such, is easily modifiable).  On the other hand, it would have been inappropriate if this document had been released in PDF form under Apache 2.0, since it would then not have been easily modifiable.

I shall not go through the exercise here of generalizing all of the other OSI criteria to make them apply to open source IP in general, since such generalizations ought to be fairly obvious.  Rather, I want to focus on the overarching thrust of these criteria: the ability of the open source licensee to modify the licensed open source IP, and re-distribute the “derived works” without significant restrictions.  The Holy Grail for most developers/distributors of open source IP would be a sort of viral reaction, where open source licensees take the original IP, modify it to add significant improvements and redistribute the resulting IP to other developers.  The developers receiving the derived works would in turn make further significant improvements, redistribute the results, and so on.  In an ideal world, all of these improvements would be periodically collected (“swept up”) into an updated single open source release, and the process could begin again.  As anyone who ever confronted the multitude of Linux releases can attest, this rarely happens, but the intention remains.

Now, let’s compare open source IP with Standardized IP.  Looking at the four criteria I proposed above for a true Standard, there is no reason why the specification of open source IP cannot be complete and/or unambiguous.  Of course, completeness and unambiguity is rarely a focus of open source developers.  However, neither criterion can be excluded a priori by the nature of open source.  Furthermore, most (if not all) open source “groups” have an ownership group—for example, Linus Torvalds still owns the core Linux.

The real difference between a Standard and open source IP lies in the “stability” criteria.  A Standard is by its very nature fixed until its owner(s) changes it. It is this stability that allows users to rely on the definition at the core of the Standard.  Open source IP, on the other hand, is by its very nature “open”. While there may be a core version owned by some group, the glory of open source IP is the fact that it may be modified and redistributed pretty much at will.

There is an irreconcilable divide that has been drawn here. In short, any Standard that is allowed to be freely modified and redistributed, even if such modifications are required to be clearly identified, has its status as a “Standard” severely eroded.  Similarly, any purported open source IP, which does not allow free modification and redistribution, has missed fulfilling several critical open source criteria.

That is why I say that “open source Standard’ is an oxymoron.

In closing, I would point out that I have not addressed the issue as to whether non-open source software can ever itself be a Standard.  I also have not discussed why/when/how long software (open source or not) ought to accompany Standards as “reference implementations”.  These will all be addressed in later releases of this blog.