|
Coalition 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
|
