Site Map     

  Features
Standards and Beyond
Blog
ST Announces 20x Savings Using OpenPDK At DAC
July 2, 2014


Blog Archives

features 1
OpenAccess

Coalition Responsibilities

Table of Contents

I. Si2 Responsibilities
II. Coalition Responsibilities
III. Cadence Responsibilities
IV. Change Team Responsibilities



I. Si2 Responsibilities

Program Facilitation, including:
Provision of logistical support for the OAC and development working groups as necessary, including arrangement of meeting locations, agenda development, notification of meeting to attendees, minutes, and meeting moderators. This shall also include meeting facility expenses, travel expenses for Si2 personnel and contractors. Additional support shall include conference calls associated with status reporting, status meetings, development and other special meetings.

Interaction with OAC members to develop evaluation and analysis plans for proposed OpenAccess developments.

Documentation of Project plan and track and report status against plan.

Development, documentation and administration of processes for all Project activities and oversee adherence to these processes.

Preparation of Project plans and Project status reports for Project members; such reports to include "Accomplishments", "Activities", "Problems", and "Milestones for Next Month".

Announcement and distribution of project deliverables as required.


Technical Support, including:
Responsible to promote the OpenAccess API as an industry standard including applying best efforts to achieve its adoption by an accredited standards body. Maintenance and publication of the OpenAccess API language reference manual (certain rights in which having been granted to Si2, pursuant to the Technology Standardization Agreement signed by and between Si2 and Cadence January 8, 2002), until such time it becomes transferred to an accredited standards body.

Development and administration of an open issue tracking system process for the OpenAccess specifications, including provision of an automated facility to log incoming requests for project information and necessary actions to honor such requests including direct reply, or forwarding the request as appropriate.

Provision of a web-based facility for code downloads, license administration, code and specification management, forums, issues and other Project communications.

Provision of facilities for a library of OpenAccess-related test cases and scripts that can be openly used.

To the extent authorized by OAC members, provision of a test lab facility with an installation of the OpenAccess reference database software and derivative applications for test or evaluation purposes.

Apply best efforts to act as liaison to major universities and associated consortia (such as SRC and the Gigascale Silicon Research Center) to obtain their active participation in the Program.


Development Efforts, including:
Provision of technical consultation to the OpenAccess Change Team (as described in Appendix A) and development work groups as required or requested.

Provision of engineering support to develop and execute test scenarios to evaluate and measure OpenAccess advantages and develop meaningful reports from resulting metrics.

Provision of support or consultation to, or development of OpenAccess training materials and toolkits as required.


Marketing and Administrative Efforts, including:
Providing marketing/promotional support including collateral development, www site maintenance, technical conference presence, press releases, promotion in Si2 publications, and interactions with Si2 member companies. Such support shall include, when appropriate, white papers, flyers, article reprints, and presentations as well as preparation and distribution of press releases and press conferences related to the Project.

Providing financial and legal services and contract administration, including preparation, negotiation and execution of subcontracts for development and support, as required; preparation and management of required non-disclosure agreements (NDA), licenses, purchase orders, invoices and payments to subcontractors and OAC members, as required.

Si2 will make good faith attempts to solicit additional leading edge companies as OAC members.

Providing space on Si2 ftp and WWW server for Project information and specifications, distribution and collection of project development files, and released specifications. This will additionally include systems administration support to post and maintain information on the server and provision of e-mail reflector services, as necessary.

Coordination of OpenAccess with other relevant industry programs to assure consistent direction and strategy. Back to Table of Contents


II. Coalition Membership Responsibilities

The OpenAccess Coalition will promote interoperability of EDA application on a standard API in order to enable greater consumer choice of EDA applications. Coalition membership is on a company or organization (i.e. it is possible for a bona fide industry organization such as a not-for-profit industry consortium or university to become a member) basis. Although many employees of a company or organization may participate in Coalition activity, no more than one vote per member (company or bona fide industry organization) is allowed on any decision.

Any company or bona fide industry organization may become a member of the Coalition. However in order to do so, that company or organization must first commit in writing to be an active member of the Coalition by assignment of resources (engineering and financial) to each of the following three (3) areas:


Development
At least one (1) of the following:

  • Develop, port, support, or use for commercial electronics design, a production-level EDA application(s) that relies on the OpenAccess API as the primary access to design data.
  • Develop, port, support, or use for commercial electronics design, a production-level database (including the OpenAccess reference database) that supports the OpenAccess API.
  • [Bona fide organizations only] Organize, coordinate and actively participate in development or research that leads to: significant enhancement to the OpenAccess standard or reference database; or, its adoption and use in areas of the IC supply-chain beyond that of chip design.

Coalition members are not restricted from developing, selling, using or marketing any alternative to the OpenAccess API.


Active Participation

Active participation within the Coalition on matters concerning its operations and promotion of its goals to include: voting on decisions by the Coalition, participating in events or other efforts that promote OpenAccess adoption, assigning personnel to relevant Development Work Groups, and (where permitted) submit reference designs to Si2 that aid in regression testing.


Shared Funding

Execute and abide by the OpenAccess Service Purchase Agreement terms, including the joint funding in equal shares for development and facilitation of the OpenAccess Project proposed from among and approved by 75% of voting Coalition members.
Back to Table of Contents


III. Cadence Responsibilities

Development

Technology Cadence Responsibilities Coalition/Change Team Responsibilities
Through 1/1/2003 Until January 1, 2003, Cadence will be responsible for critical bug fixes (defined as those errors that are fatal and have no workaround and do not alter the behavior of the API.)

After the above date, Cadence may cede this responsibility to Si2
. The Coalition will limit the support of the Version 1 (C-Level) API specification to maintenance of its delivered state except for bug fixes or ports that do not alter the API behavior, so long as Cadence is complying with this Agreement.
Version 2 (C++ Level) API and reference database Cadence will be solely responsible for all Version 2 development decisions through 2002.

On December 31, 2002, Cadence shall provide to the Coalition an API Specification for planned code enhancements that shall be completed by June 30, 2003.

Until June 30, 2003, Cadence will be responsible only to; (a) fix critical bugs, (b) correct interoperability problems between tools that are API compliant (applies only to commercially-available EDA tools or Coalition- internal tools made available to Si2) and (c) make compliant any delivered code that does not meet the accepted specifications.
Starting January 1, 2003, Si2 will put in place a compliance program to validate: (a) critical bug reports, (b) interoperability problems between tools that are API compliant and (c) compliance of delivered code to the accepted specifications. Si2 will maintain this program. Si2 will supply a draft version of such program to Cadence on or prior to May 2002.

Between July 1, 2003 and June 30 2004 Cadence will also implement changes proposed by the Change Team provided that Cadence agrees with the proposed changes. Additionally, Cadence will propose to the Change Team any changes that it wishes to make and will not make those changes unless the Change Team agrees.

Beginning July 1, 2004, all OpenAccess Capabilities will be subject to full Change Team decision-making.
All Other OpenAccess Capability
Beginning January 1, 2003, Cadence will respond to Change Team requirements for capability implementation to be delivered no earlier than July 1, 2003.
Change Team will manage decisions effecting new or changed functionality and features.


Integration Services
Cadence serve as the integrator of all OpenAccess database software. Once a set of changes has been approved by the Change Team, Cadence has the first right of refusal to provide a just Cost/Time estimate within 15 business days for integrating the changes to the reference implementation. The Coalition has the option to having the changes integrated through a Coalition member third party company if one of the following conditions is true:

  • Cadence decides not to accept this particular job
  • Cadence doesn't respond within 15 business days
  • The estimate is proved to be unjust by the Change Team
  • If the Statement of Work is terminated as a result of a breach by Cadence

The job will commence after the Coalition and Cadence reach agreement on a signed work order and agreed upon delivery schedule. The project will be considered complete when the new reference code has passed a set of acceptance tests specified by the Coalition to ensure functionality and interoperability.

New versions of OpenAccess will be made available by Si2 through its OpenEDA www site.

Notwithstanding the above, in the event that the Coalition (or one or more of its members, on the Coalition's behalf) makes a bug fix, Cadence will make such change (or a functionally equivalent change) by the next regularly scheduled release. Such obligation will continue until the 12, 2002 source code release.
Back to Table of Contents



IV. Change Team

The Change Team shall be the approving body for any modifications to the OpenAccess API Specification and reference database implementation by the Community, and oversight of the OpenAccess technical roadmap.


Composition

The Change Team shall be comprised of not more than 12 members, with a maximum of five (5) representing EDA companies. The Change Team shall be led by two (2) architects, both of whom shall be members of the Change Team. As long as Cadence is a member of the Coalition, Cadence will have the right to appoint one of its employees as one of the architects to serve on the Change Team. The other architect shall be appointed by the Change Team and shall not be an employee of a commercial EDA company.


Requirements for Membership
The purpose of the Eligibility Requirements is to ensure that only those OpenAccess Community organizations with a demonstrable vested interest in the future of OpenAccess are permitted to make decisions regarding any changes to the API specification and reference database implementation.

Change Team membership is by majority election from among Coalition members for those candidate companies meeting the above qualifications plus the following:

  • A Change team member must be an employee of a Coalition member in good standing with significant EDA application development and/or integration experience with API based design flows.
  • A Change Team member should be able to devote the effort necessary to review and test database source code changes upon mutual agreement with the Change Team.

If any Change Team member can show substantial and reasonable cause that another Change Team member is not in compliance with the terms of the Coalition Participation Agreement and Change Team requirements, that member may propose that the cited Change Team member be removed from the Change Team. In such event, the Change Team shall vote on such proposal; the Change Team member will be removed from the Change Team upon an affirmative vote of at least nine (9) members. Should a Change Team member be removed in such fashion without breaching its obligations to Si2, that member may seek reelection to the Change Team for future terms.

Notwithstanding the above, in the event an individual ceases to be a Change Team member for any reason, including, that their company is found to be in violation of the license agreement, participation agreement or any other agreements relative to the participation agreement, then Si2 will facilitate the selection of a replacement by nomination and majority ballot among the voting members of the Coalition for the remainder of the term of the removed Change Team member. Until such time that a replacement is elected by the Coalition, the voting privileges of the removed member shall be ceded to the Change Team architects.


Change Team Voting Process
Decisions of the Change Team shall require a concurring vote of at least 9 of the Change Team members. If the Change Team temporarily has less than 12 members, and a proposal receives a 75% majority approval but not 9 votes, then the Architects (by unanimous vote) will make up the missing votes. Votes by a Change Team member may be made during attendance at the voting event, by electronic mail, by telephone, or through delegated proxy to an architect. If any Change Team member neglects to vote, such position shall be recorded as a "no" vote. Should the Change Team so vote, the Change Team may collectively delegate its proxy to the elected architects. If both architects agree to make a change, for which they have been granted decision authority by proxy, the change shall thereby be approved. If both architects agree not to make the change, or, if the architects disagree on whether to make the change, the change shall thereby be rejected. Rejected changes may be implemented through the OpenAccess Extensibility API.
Back to Table of Contents


 
Copyright © 2004-2014
Silicon Integration Initiative, Inc (Si2)
All rights reserved
Site Map
How to Get an Account
Contact Si2
Contact Site Admin
Legal Notice/Disclaimer