Site Map     
NOTICE 02-06-2016:
As of today, Si2 is now using Single-Sign-On logins to support our members who are involved in Si2 Bloomfire communities.
All non-sso login sessions were deleted prior to the change-over. You will need to re-login to your user account.

Thank you for you patience.

features 1

OpenAccess Coalition Active Groups

Access to group areas is only available to official coalition participants from coalition member companies.
OA Roadmap WG
OA Track Pattern ESG Working Group
OAC ChangeTeam
     The Change Team manages the evolution of the Open Access Information Model, API, and accompanying reference implementation. It is made up of representatives of twelve elected member companies with two year staggered terms and is guided by two chief architects from different industry segments. The Change Team manages the OpenAccess development and release roadmap and all contributions that make up the rich set of functionality that is OpenAccess. The Change Team also manages the formation, work specification, and disbanding of all working groups that are established to target specific technical areas. At any time, the current set of operational working groups are described on this web site.
     The Debug Working Group specifies and guides the development of tools and strategies to help users identify and resolve OpenAccess application, implementation, and data problems. Under WG direction, Si2 engineering is developing a number of prototype applications including Si2oad and Si2oaDff.
     This group is chartered to increase the pace of adding OpenAccess functionality without affecting the consistency and stability of the core API standard and its associated Reference Implementation. The ESG will look at ways to extend OpenAccess for the benefit of silicon foundries, EDA suppliers, IP providers, and end users. The ESG is responsible for reviewing and approving new features and capabilities for the OpenAccess Standard API which are not part of the regular development process. This will allow for more flexible development in the OpenAccess environment to meet ever changing market requirements.
OAC Polygon Operations WG

Deliver an OpenAccess extension class which can manipulate OA objects using boolean operations, interaction selection, and other functions related to the detection and manipulation of various physical design patterns.

Initial list of things to work on:
  • Adding capability to meet the needs of ULM layer operations - first priority for OPDKC/DFMC ULM immediate needs
  • Naming of library
  • Analysis of existing oaFigSet contribution and boost.polygon features
  • Agree upon function prototypes (header file) including naming convention, input/output formats, etc.
  • Create a roadmap (schedule for implementation and other things like test and documentation)
  • Decoupling from oaScript and delivery as a standalone extension which can be used in both C++ and oaScript
OAC Scripting WG
     The working group is developing new OpenAccess extension bindings for five popular programming languages: Perl, Python, Ruby,Tcl, and C#. The oaScript extension bindings will enable CAD developers and chip designers alike to easily extract and manipulate design data using their favorite scripting language. The performance and usability of the new Scripting Languages Working Group bindings surpass previous open scripting language implementations. The Scripting Languages Working Group bindings are all based on the popular SWIG ( tool. This unified architecture eases maintenance and simplifies the addition of any of the many programming languages supported by SWIG.

OpenAccess Coalition Groups on Hiatus or Completed

Access to group areas and email archives is only available to official coalition participants from coalition member companies.
OA Limits WG
OAC Change Tracking WG
     Develop use cases and requirements for dynamic tracking and representation of changes made to an OA model. (2007-2008) RESULTS: A CMS (Change Management System) is now part of the OA API, with a PlugIn architecture for implementation of arbitrary tracking, export, and import modules. In addition, sdBase classes enable representation of OA schema elements and relationships.
OAC Common Execution Environment WG
     Decide requirements for an OA application component system and the scope for including single and multiple process component sharing, including perhaps data and code. Focus, particularly, on issues that are specific to having component coordination and communication. Evaluate existing, available solutions for applicability to these requirements or propose a reference implementation that would meet them. (2005-2006) STATUS: WG is on hiatus until member companies can devote the resources to further this effort.
OAC Consistent Usage Steering Group
     The purpose of the Consistent Usage Steering Group (CUSG) is to identify areas of inconsistent OpenAccess interpretation and usage, either actual or potential, that can interfere with the interoperability of applications and/or engines in design flows, study the differing models of usage, and then document the primary usage model(s) that can aid interoperation when used by cooperating OpenAccess-based modules. The CUSG will also serve as a forum where OpenAcess users can raise questions of OpenAccess usage. The CUSG will determine which issues raised are actually questions of consistent usage and which should be dealt with elsewhere. STATUS: WG is on hiatus until member companies can devote the resources to further this effort.
OAC Contributions Process WG
     Establish a process that better enables, and hopefully stimulates, OA contributions from the community.
  • A formal process for Contributions
  • OpenAccess Contributed ReUse Library, a collection of OpenAccess code snippets, techniques, and other contribution.
  • Several independent contributions projects from various sources:
    • LSI Python for OpenAccess
    • Si2 OpenAccess Tutorial
    • Si2oaD (Si2oaDebug)
    • Analog Symbol Library
    • Si2Delta
    • Ciranova PCell Caching
    • Synopsys oaViewer
    • Si2oaDff
  • Ongoing encouragement to member companies for contributions of their technology for the Coalition benefit.
     Identified those requirements which pertained to OA for providing Design Data Management capabilities. (2003-2005)
RESULTS: The oaDMObject and oaDMData API models, along with an associated DM PlugIn architecture was included in the OA release stream. Two PlugIn implementations were written an included in source to support
  • DMFileSys (the production DM system with Lib/Cell/View implemented as directory levels in the filesystem)
  • DMTurbo (a prototype DM implementation with a more compact use of inodes)
OAC ESG Procedures Working Group
OAC Extensibility DWG
     Develop sequirements and specifications for the capability to extend the OA model. Enable creation of user-defined extension attributes to native OA Types as well as user-defined "types", without requiring a change to the Standard. (2000-2003)
RESULTS: A complete API model and header specification submitted to Cadence. The oaAppDef model was proposed by Cadence to meet the requirements and functional capabilities reflected in this WG model and specification.
OAC Foundary Constraints WG
     The mission of the Foundry Constraints Working Group is to define recommendations for constraint and constraint parameter definitions required to represent physical design rules for new IC processes. The goal is to provide requirements for new built-in constraint and constraint parameter definitions as part of the core. As changes in built-in constraint definitions require work from applications to properly interpret them, a critical responsibility of the working group is to determine the stability of proposed constraint definitions before recommending that they be added as built-ins to the core. A secondary role of the FCWG will be to advise members on the semantics of existing constraint definitions, with the goal of avoiding creation of constraints with similar semantics.
OAC Golden Gate WG
     Develop specification for a bridge between Milkyway and the OpenAccess model. (2003-2005)
RESULTS: A prototype mapping between the two models was proposed, including prototype OA<->Milkyway conversion code for selected OA/MW releases. And completed beta testing with selected Coalition companies. Translators were included with OA 2.2.0-2.2.4 releases.
     Investigate support for VSIA IP Tags in OpenAccess. (2006-2007) STATUS: Several presentations, focusing especially on soft IP tagging, are available for further review. WG is on hiatus until member companies can devote the resources to further this effort.
OAC Logical/Physical Hierarchy WG
     Develop a model to support differing logical and physical hierarchies (for example, to enable fine-grained ECO application). (2002-2003)
RESULTS: The EMH (Embedded Module Hierarchy) model in OA 2.2 supports a logical Module Domain and different, "physical" Block Domain, integrated with the Occurrence Domain to support independent but related logical/physical hierarchies
OAC Occurrence WG
     Develop an Information Model and API extensions to provide a standard model for representation of unique block/net/pin occurrences. (2000-2005)
RESULTS: A complete API model and header specification submitted to Cadence
OAC Parasitics DWG
     Discuss and analyze Cadence proposal for OpenAccess parasitics model including requirements and review of preliminary headers. (2002)
RESULTS: oaParasiticNetwork (and related classes) added to OA API.
OAC Parasitics WG
     This WG is addressing enhancement of the present OpenAccess parasitic model from its SPEF origin to include
  • analog parasitics and interconnect models
  • improved parasitic/layout associations
  • arbitrary models, hierarchical parasitics and dataset constructs
  • extraction flow reduction through iteration capabilities
  • flexible process variation modeling
  • support of the new IEEE1481v2 specification for parametric SPEF
OAC Pcell
     Study interoperability concerns (such as implementation language, parameter interpretaion, etc.) involved in using the OA Pcell architecture in terms of a common development environment and language to improve the development productivity and portability of Pcells. Develop a set of recommendations to address these. RESULTS: Recommendations report delivered (
OAC Scripting Extension WG
     Review Cadence proposals for Tcl bindings for the OA API, including analysis of issues such as balancing consistency with the OA style consistency with standard Tcl conventions, coping with C++ issues, etc. (2004).
RESULTS: Beta version of oaTcl added to release stream.
     Review the proposed Technology Rules API. (2002-2004)
RESULTS: Addition of oaRule model to API releases to define persistent Layer design rules (constraints) supporting single values of different types, as well as LookupTbl values. (The oaRule API evolved eventually into the oaConstraint model.)
OAC Timing Work Group
     Develop design-specific OA timing/electrical constraints, including:
  1. constraint information (at least SDC)
  2. data model dependencies
  3. data structures
  4. interface (API)
  5. translators (import/export)
RESULTS: Completed specification and API proposal.
Copyright © 2004-2016
Silicon Integration Initiative, Inc (Si2)
All rights reserved
Site Map
How to Get an Account
Contact Si2
Contact Site Admin
Legal Notice/Disclaimer