"...(My) take on the whole issue of open standards versus open source? I would say this: If it doesn't have an open-source reference implementation, the term "standard" is an abuse of the language. That's still a very strong position by today's standards. But it won't be in three to five years. If it doesn't have an open-source implementation, how do you know what the standard means?"
Eric Raymond, Co-Founder of the Open Source Initiative
In this article we provide some insights into the relationship between non-code based open assets, open development processes, and open standards. The insights are based on a case study of the OpenAccess (OA) Project of the Silicon Integration Initiative. The unique relationship between the OA standard's openness, evolution and adoption is an example of how open processes could be used to enable design tool interoperability, innovation, and cooperation.
Open Access API Standard
It is widely accepted that the lack of interoperability between Electronic Design Automation (EDA) design tools is a major limitation for the cost-effective design and manufacturing of silicon integrated circuits. The OA project and OA Coalition (OAC) were proposed by the Silicon Integration Initiative (Si2) and founded by Hewlett-Packard, Intel, IBM, Motorola, Lucent, Sun, Cadence, and Mentor Graphics in late 1999 to provide an industry-accepted API-based design data standard.
The OA project comprises three building blocks: a specification of an API (Application Program Interface) standard, a reference database implementation, and an open process (called OpenEvolution) to manage the evolution of the standard. The OA API specification includes three components:
- an information model defined by a collection of entity relationship diagrams
- a data model defined by C++ header files specifying software class and public function interface details
- API header information in a readable format
The OA reference implementation (OARI) is the source code for, or linked libraries of, an implementation of the API that is publicly available as part of the OA distribution. The OARI is not a formal part of the OA API standard, but was designed to be publicly available as an adoption and critical standard development mechanism.
At the heart of the OA OpenEvolution governance structure are several groups of stakeholders controlling the evolution of OA in terms of funding as well as technical guidance, including:
- the OpenAccess Coalition (OAC)
- the ChangeTeam: a body of technical experts representing coalition member companies who serve the OAC to manage the evolution of the OA standard specification and the OARI
- the Integrator: Cadence, who is responsible for maintaining the OARI
- the Working Groups: teams of professionals from member companies that cooperate/collaborate on requirements for needed enhancements and extensions
Surrounding this core of active participants is the OA Community which includes anyone who wishes to use or contribute to OA. An open source community model was developed by sequentially enabling the main characteristics of open source software (OSS) development to benefit the OARI from a potentially large pool of support for on-going enhancements and fixes.
The OAC developed a two-layer structure of the OA project comprising the API specifications and the OARI by following three principles: i) all changes of the API must be suggested through an implementation in the current OARI; ii) the OA OARI must always comply to the OA API standard; and iii) EDA companies using the OARI as part of their commercial products must use only the officially released versions and in binary form only. Companies requiring a modification of either the OARI or the OA API to improve their commercial EDA products must get the modification approved by the ChangeTeam. These three principles, together with the benefits enabled by the open source development characteristics of the OARI, were intended to provide an efficient standard development and adoption mechanism.
OA Standard's Project Chronology
The OA standard project was developed as a continuation of the CHDStd (Chip Hierarchical Design System: Technical Data) initiative sponsored by SEMATECH in the mid 1990's. CHDStd was developed on the basis of a proven technology donated by IBM to provide a common representation of IC (integrated circuit) design data and an API to access and manipulate that data. However, CHDStd failed to gain industry acceptance, mainly because its deliverable was a paper specification with no available reference implementation code. OA Viability Phase
In late 1999 when Si2 accepted ownership of the CHDStd program, it became clear that the success of an industry standard data model would be predicated on an available database implementation compliant with the API and useful as a production vehicle in itself. Further, there was strong interest in an open source implementation of this database. This motivated Si2 to seek out a solution different from the CHDStd technology and ultimately to accept a technology contribution from Cadence Design Systems. This contribution included an API specification and source code for a reference implementation, then called Genesis.
In December 1999, Si2 formed the Design API Coalition (DAPIC), whose founding members included many large, high-end EDA user companies that were previously involved in the CHDStd initiative. Si2 made as a condition for membership in DAPIC that members must commit engineering resources on an active project making use of the reference implementation. Further, Cadence set conditions on DAPIC for its contribution, one of which was that a Working Group (WG) would be formed to address some important missing technological aspects of Genesis. The DAPIC members agreed to form a WG to define an "Extensibility" technology that would play a critical role in convincing other major EDA vendors to consider using technology from a major competitor.
In June 2001, Si2 renamed DAPIC to OAC and publicly announced its launch. The OAC released the Genesis API specifications to the public as "OA API 1.0", accompanied by the database binary code and, later, the source code. During this phase of the program, the attitude of most EDA vendors was one of "wait and see". They perceived this to be a competitive move largely driven by Cadence, and seriously doubted the OAC would ever succeed. The main goal of this phase of the program was to prove the viability of the OA goals.
During this viability phase, the OAC focused on establishing the OA technology base and the business management processes to be used to publish and support the standard. The OAC interacted heavily with industry to understand and react to fears and doubts of the "wait and see" companies. Decisions were made, and supporting policy and legal agreements were developed, to use a community source model for OA as opposed to a full open source model. The Coalition agreed to give Cadence control of a full rewrite of the API and OARI without detailed change review for three initial releases by specifying only their coverage and schedule. After this, control of the API and OARI would be turned over to the OAC ChangeTeam.
The end of this viability phase in January 2003 was marked by the public release of the Genesis rewrite, OA version 2.0, and by the introduction of the first OA compatible commercial tool, the Cadence Virtuoso custom design platform. Virtuoso, at this time, also continued to support its well established CBDA database.
Commitment to the OAC goals by the EDA users was established by the early adoption of the technology into production design flows by two OAC member companies, Hewlett-Packard and LSI Logic. These early adopters were motivated as much by an interest to advance the OAC cause by proving the viability of OA in production design flows as they were by significant technical advantages. LSI Logic also developed a complete set of extension language bindings for the OA API in the Python scripting language and contributed this technology, thus making it available to the entire OA Community. This was the first contribution to OA from a company other than Cadence.
OA Refinement Phase
The next major phase can be thought of as a refinement phase of OA that saw greater input of requirements by OAC members, the release of OA versions 2.1 and 2.2, and the beginnings of adoption by additional EDA user companies and vendors. During this phase, the number of OAC members grew significantly, although other big EDA vendors were still notably missing. Additional WGs were established to address new requirements for the technology. Cadence worked diligently to fine tune the reliability and performance of the OARI. The OAC developed formal training programs, a text book, and software providing translation utilities to aid the migration to OA from existing EDA format standards.
As planned, in July 2004 Cadence began to share control with the OAC Change Team, leading more vendors to believe that the Coalition was not just a Cadence driven project. In addition, a new multi-tiered membership was established by Si2, which especially encouraged more small vendors to join the Coalition.
The end of the refinement phase was marked by the community release of a more mature and stable version of the OA standard in November, 2004. This version was the point at which Cadence and the OAC committed to a very stable, backward compatible API standard. During this phase, there was a marked increase in the number of OA product announcements made by EDA vendors. Cadence introduced a new version of Virtuoso which supported the OARI and proclaimed the end-of-life for CBDA. By the end of 2004, there were 29 commercial and in-house design tools supporting OA. Most significantly, the top five EDA vendors, Cadence, Synopsys, Mentor Graphics, Magma and Zuken, were all members of the OAC.
OA Adoption Phase
2005 began the adoption phase of OA and the end of 2006 was marked by further growth in OA product availability of both commercial and in-house EDA tools. As the OA Project progressed into its adoption phase, there were 43 such tools. If the OA standard is to become the primary industry standard database technology for IC physical design, there will be few exceptions to its use in vendor tools and user design flows.
How Open are the OA Assets?
The OA open assets have a hybrid nature. Formally, the OA API specification provides the standard. The API, however, cannot be considered apart from the OARI, which is made accessible in two forms: binaries and source code. Access to the OARI binaries enables familiarization with the API functionality and, moreover, actual application development using the API but without the ability to suggest improvements. Access to the source code provides an innovation and development mechanism enabling full scale open source development practices and the ability to suggest improvements.
The openness of the OA assets can be described by the rights given to users. Non-Si2 members can download general releases of the OA standard specification as well as the binaries and the source code of the OARI. Academic members and Si2 members have access to member releases which are available earlier than the general releases. Si2 members can also use, reproduce, and prepare derivative works of the OA standard specification and the OARI in both source and binary code for non-commercial and internal use. In addition, OAC members can reproduce, distribute and sublicense the OA standard specification and the OARI in both source and binary code for non-commercial use, but can only include compiled binary code in the products they sell.
Any modifications to the compiled source code distributed in products outside a company's boundaries must be contributed back to the OAC within 30 days. However, if the modification is not accepted into the released OA source code, the modification may still be used in distributed products. This flexibility in the licensing terms was found to be important to OA adoption.
The description of the OA asset user rights shows that the OARI does not meet the criteria of the OSS definition provided by the Open Source Initiative. The distribution terms for OAC members do not allow anyone to distribute derivative source code of the OARI. For commercial purposes, members are only allowed to distribute compiled binary code. In addition, the rights to use and distribute the OARI differ by Si2 membership levels.
Companies wanting to distribute the unmodified version of the OARI binary code in their products must become OAC members and pay an OAC membership fee. Last but not least, the source and binary code of the OARI are not technology-neutral since they must comply with the OA API standard specifications. It must be pointed out that the main deviations between the characteristics of the OA assets and the criteria of the OSS definition were intentionally implemented by Si2 and the OAC to help the development, the integrity, and the consistency of the standard by securing the commitment of the major industry players.
How Open are the OA Development Processes?
To discuss the openness of the OA development processes we will use an approach developed by von Hippel who applied user innovation network theory to study open source technology development. Von Hippel identified five dimensions of open source development:
- Free revealing of a technology or asset
- User innovation community
- Collective invention process: a cyclic process of follow-on innovation leading to a series of incremental improvements triggering new rounds of innovation activities
- Commons-based peer production: a newly emerging mode of production in which the members of the user community collaborate on projects leading to improved or completely new versions of the released technology or asset
- User community governance and support
All these dimensions can be found in the OA OpenEvolution process: i) the founding of the OAC, the Si2 management processes and the OA IT infrastructure enabled the user community support and governance mechanism;ii) the release of Cadence's OpenAccess specifications and binary and source code as OARI 2.0 enabled a freely revealed technology; iii) public access to the OA Developer Forum, Enhancement Request Tracker and downloads of the OA 2.0 API specifications and OARI code enabled an active user innovation community; iv) the release of the OA 2.0 source code to the community enabled a collective invention process most notoriously expressed in the activity of the WGs; and v) the release of the OA 2.2 version was based on coalition member input and ChangeTeam acceptance and signified the presence of a peer-production process.
How Open is the OA Standard?
There is no clear cut definition of open standards. One of the most recent definitions was provided by Michael Tiemann who identified four levels of standard openness:
Open Standard 0: the standard is documented and can be completely implemented, used, and distributed royalty free
Open Standard 1: there is a specified OSS product that can interoperate with the standard
Open Standard 2: there is an open source implementation that provides the ability to review the actual working of the standard
Open Standard 3: the reference implementation of the standard is an open source implementation
According to this classification model, level 2 is characterized by the availability of OSS implementation(s) of the standard but no reference implementation. Level 3 is characterized by the availability of an OSS reference implementation; that is, the reference implementation of the standard is open source. The OA standard level of openness is higher than level 1. However, it has characteristics of both levels 2 and 3 since: i) there is an OA implementation that is open source (a feature of level 2) with somehow limited redistribution terms; and ii) the existing OA "quasi"-open source implementation is the reference implementation (a characteristics of level 3). The combination of OA features from both levels 2 and 3 was designed to provide a means for: i) advancing the standard over time as practices improve; and ii) providing a safeguard against fragmentation when a proprietary implementation extends the standard but the extensions have not been reincorporated into the open source reference implementation.
Insights from the OA Project
At the very early stages of the development of an open standard the major demand for open assets is driven mainly by the larger user companies.
Providing the primary technology supplier with a balanced control over the organization's governance can accelerate technology development that is consistent with the goals of the standard setting organization. However, other companies may develop a "wait and see" attitude towards the standard's adoption which may slow down the adoption process.
The development of OA's standard adoption mechanisms prevents the reference implementation code from meeting the full set of criteria for OSS. The standard adoption process requires that the reference code be distributed with no modifications in compliance with an interface implemented with a particular technology. These two requirements prevent the asset from being referred to as an open source asset. The phases of the life cycle of standard development can be identified using product-release milestones. The end of each phase of the OA standard project was marked by the release of a new version of the OA standard which was qualitatively different than the previous one. The end of the viability phase was marked by the release of OA version 2.0, the starting point of the OpenEvolution technology development process. The end of the refinement phase was marked by the introduction of OA version 2.2, a mature, production enabling and backward compatible reference implementation. The adoption phase was marked by a considerable growth in commercial OA-based EDA design tools.
Reaching the adoption phase of a standard project with the scope of OA takes many years, particularly because it is a database technology to be used at the very heart of EDA applications and systems. Replacing the RunTime Model at the core of legacy EDA software, even with excellent software strategies, is a considerable challenge.
In order to understand user innovation networks, one must understand the pedigree and user rights of the common asset being produced as well as the interactions between companies with the development project and the market. Knowing only the characteristics of the open development process is not enough.
A multiple tier membership structure can accelerate a standard project's adoption. The number of members in Si2 and OAC grew significantly when the structure was changed from a single tier to a three tier membership structure. Each membership structure targeted a particular type of member. This made it easier for companies to join a membership tier with which they felt most comfortable.
We would like to express our gratitude to Mr. Donald Cottrell for his invaluable editorial contributions and role as a reference for the timing and specific nature of the historical facts from the very beginning of this research project. Cottrell began his professional career with IBM Corporation, and during the next 28 years was a member of IBM's Corporate EDA development where he held a number of senior technical and management positions. Following his retirement from IBM in 1993, Don joined the Si2 management team where, as Vice-President of Technology, he was responsible for all Si2 engineering and service projects. In 2003, Cottrell was titled as Si2 Fellow with responsibility for investigation of new technology areas in which Si2 should engage. The Si2 Design for Manufacturing Coalition (DFMC) program, for which Cottrell was responsible, is one such example. In June 2007, Cottrell retired.
We would like also to express our gratitude to Mr. Steve Schulz, President and CEO, and Mr. Sumit DasGupta, Senior Vice President of Engineering, of the Si2 for their support and cooperation.
Last but not least, our gratitude goes to Dr. Tony Bailetti, Professor in the Technology Innovation Management Program at Carleton University and Director of the Talent First Network, an open source technology commercialization initiative funded by the Ontario Ministry of Research and Innovation, for his research cooperation and financial support.