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:
- 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.
- 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.
- 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.
DVCon 2011 Is Open For Business
DVCon 2011, sponsored by Accellera, is now open for paper abstracts and proposals for panels/sponsored tutorials. This conference will be held in San Jose from February 28 through March 3 of next year at its usual spot in the DoubleTree Hotel very close to the airport.
DVCon has developed into the yearly gathering place for the elite in design and verification—and those who aspire to join the elite. Granted, the economy in the past few years has hampered international participation, but the roster of attendees has nonetheless been notably impressive.
The value of DVCon is not hard to discern. Attendees are typically free to attend sessions, view the vendor exhibits and to take part in impromptu technical discussions in an atmosphere that is exponentially less frenetic than, for example, DAC. Of course, the sheer size of DAC by itself reduces the chance of “running into” former colleagues with whom one can swap war stories, but, especially for senior technical people, DAC often becomes a blur of customer meetings and intelligence gathering. These activities are very valuable, but so is the ability that DVCON affords to sit in a quiet corner and discuss, for example, the prospects of UVM with a few industry cohorts.
Finally, I would like to point to a phenomenon that might have escaped general notice. DVCon is the grandchild of the HDL conferences begun by VHDL International and Open Verilog International in the 1990′s. As such it has always had a heavy HDL verification flavor. This flavor is still very evident, and there will be papers discussing, for example, the use of SystemVerilog in a comprehensive verification flow. However, in recent years I have observed more exploration at DVCon of the ESL space– especially around SystemC usage. This is not surprising since design, modeling and, yes, verification using SystemC are becoming increasingly mainstream.
This trend towards more SystemC content was especially obvious at DVCon 2010, when the OpenSystemC Initiaitve (OSCI) informally dubbed the first day of the conference as “SystemC day”. The morning of this first day was devoted to a meeting of the North American SystemC User’s Group (NASCUG), while OSCI gave a sponsored tutorial on TLM-based design in the afternoon. Both events were well attended, highlighting the point that DVCon is “not just for RTL anymore”.
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.