To develop the best silicon requires the best EDA tools. When the best tools come from different suppliers a hybrid design flow is needed. OpenAccess is an extensible API on top of a managed multi-user design database that enables the interoperability required by hybrid design flows. This API and database are constantly synchronized with other EDA tools by the OpenAccess Coalition through constant collaboration between the top EDA suppliers, IP providers, design companies, and the Integrator Company.
“OpenAccess has become an integral part of our business over the past years. Our needs get addressed through the OpenAccess Coalition and our internal developers are equipped to create the tools we need. Participating in the OpenAccess Coalition enables development of solutions to common problems through collaboration with other members. We depend on OpenAccess to develop the best silicon in the industry” – An Integrated Device Manufacturer.
OpenAccess is “open” to the members of the OpenAccess Coalition (OAC) and is constantly enhanced and maintained. Members of the OA Coalition have access to the collaborative results of the entire OAC community. OpenAccess members ensure it is stable and will be sustained so members can use it on programs with large financial investments.
To support innovation within the industry, the OpenAccess membership fee is based on member company revenue. Therefore, a start-up pays much less than a large company would.
For the Integrated Device Manufacturer and fabless businesses which are always competitive, arming Design Engineers with the ability to develop and use powerful point-of-use tools is obviously good utilization of funds. A design fix at the end of the design flow can save a product schedule from failure.
For the foundry business, where data comes to you in various forms, OpenAccess provides a means to bring the data into the foundry process. Checking and mask-prep tools are easily realized and fast enough to act upon huge datasets. Foundry technology is always proprietary so internal tool development is essential. OpenAccess provides this capability while maintaining interoperability with existing tools.
OpenAccess Coalition membership dues scale to match a member company’s revenue. This enables new companies to lower their barrier to entry to markets through OpenAccess compatibility with other EDA tool suites.
OpenAccess provides very fast market entry path as new applications are automatically able to plug into existing design flows. This lowers the barrier to entry for new companies.
For larger EDA suppliers, tools from start-up companies can easily be integrated into their design tool suites and makes acquisitions or mergers more feasible.
OpenAccess enables fast tool prototyping while ensuring compatibility with existing design flows. This shortens learning cycles and speeds research and development.
For companies working on something very proprietary, design tools may not exist yet. OpenAccess allows R&D efforts to quickly and easily create prototypes and make design modifications that are compatible most existing EDA tool flows.
Rrecent additions to OpenAccess address multi-processing for parallel execution can be utilized by an application to create a very large improvement in throughput by reducing execution time. Tests by universities have seen up to seventeen times improvement in speed for a simple case. In a cloud environment where computing resource is readily available, one could capture a huge advantage.
Enables rapid response to critical design flow problems by providing the means to quickly develop powerful custom point-of-use tools and new applications that easily plug into the existing design flow. This can save an entire project in the eleventh hour.
OpenAccess is a strongly typed, 2000+ class, extensible, C++ API on top of a managed multi-user database. This API and database are constantly synchronized with other EDA tools by the OpenAccess Coalition.
An application can be built on OpenAccess directly, or utilize the translation features available for compatibility with an existing database.
Through the OpenAccess Coalition, several extensions to the API are available to members. These extensions are collaboratively developed by the members to meet common needs. Some of these extensions provide powerful ability to the application which are just beginning to be utilized. Yes, there is new technology “on the table” for members to use.
The scripting APIs are available should you need to work in Python, Ruby, or tcl. These APIs are wrapperized versions of the C++ maintaining a one-to-one correspondence with the C++ classes to enable scripts to easily be ported to C++ later.
Most companies have a propriety process for utilizing multi-pattern technology (“coloring”) on very small feature size technologies. The oaxColor extension was recently released, providing a means to support proprietary coloring processes from within the application.
The Polygon Operators extension combines the Open Source Boost Polygon with OpenAccess, allowing for wholesale polygon manipulation within an application. Recently, this workgroup realized an extraction engine allowing the application to trace electrical connectivity between shapes without a netlist.
The OpenAccess database has independent plug-ins running to manage several additional simultaneous functions such as:
This provides additional processes even for single-threaded applications.
Developers can utilize the extensibility of the API through the use of the appDef class, which enables creating your own custom classes. Recently, jpg images have become popular. As the API is extended, the added extensions are managed along with the rest of the API. If you don’t find the classes you need in the 2000+ available, write your own.
If the application supports a unique or uncommon view (other than Verilog, VHDL, Schematic, Symbol, and Layout), you can create your own view.
EDA developers have the option to build their application directly on top of the database (“native OpenAccess”) or adjacent to an existing database with data translation provided. If an application is built on OpenAccess, huge execution speed and throughput advantages can be realized by eliminating transfer of very large data files within the design flow.
All of this “overhead” is done for your application when you utilize OpenAccess. Should a member realize an application with OpenAccess, they have redistribution rights allowing an executable copy of OpenAccess to be redistributed with the application.
Participating in the OpenAccess Coalition ensures that compatibility will be sustained while you enhance your applications.
Over the last two decades, enhancements and new capabilities have been added to keep pace with the EDA industry changes. For example, the OpenAccess Coalition is presently working to support for multi-process deployment in various forms like containers. This was enabled initially by an architectural change driving the Data Model Six introduction where a user can persistently partition the design to enable simultaneous processing without risk of data collision.
The OpenAccess API is easy to integrate into an existing design flow. Most tools support OpenAccess even if they are not running natively on OpenAccess. This means your application can be used with most other tools immediately providing exceptionally fast market adoption.
The Design Engineer may be working in any or all of several areas, from analog design to mask preparation. The common need of these areas is the ability to respond to constant reinvention and change. Developing point-of-use tools is a requirement for the Engineer as both the design and the technology are constantly changing. Fast applications and prototype tools can more easily be developed in scripting languages using the oaScript extension to OpenAccess.
If the design is innovative and proprietary, then the EDA tools to support it may not exist yet. In that case existing tools can be augmented using OpenAccess to support the new, innovative, design, providing a better path to the end result.
The OpenAccess appDef class can be used to extend the API while still being a managed class. An application can add values to existing database objects, or create new objects. The objects and added values will be persistent in the database for later use. The OpenAccess Coalition workgroups are constantly innovating through creation of new API extensions.
Example: Polygon Operators
Our Polygon Operators extension combines the Open Source Boost Polygon with OpenAccess to yield a host of additional capability, such as bulk polygon manipulation. The team even realized a physical connectivity extraction tool to trace electrical connectivity with no knowledge of the netlist. This demonstrates an integration of an Open Source project with a commercial EDA API and shows the ease of extending OpenAccess while still maintaining the core code integrity.
Example: Coloring
At the onset, Multi-Pattern Technology designs had to be marked as to which shapes went on which mask (called “coloring”). All companies patented their methodology, creating a barrier to standardization. The brilliant minds in the OpenAccess Coalition developed an extension to enable easy implementation of the various methodologies. This provides some standardization within the applications, if not within the methodologies. Now, members have function to add their own coloring methodology to their application.
Example: Scripting
The oaScript extension wraps the C++ API in Python, Ruby, and tcl at present. Previously Perl and C# were wrapped and MATLAB script was once considered. Most new extensions are written in C++ and also wrapped in Python, Ruby, and tcl in support of the oaScript extension. The most popular language being Python.
Example: Translators
To get data into and out of the OpenAccess database, a set of independent data translators are available that will convert various common types of data files to and from OpenAccess. The present list is oa2verilog – verilog2oa, oa2spef – spef2oa, oa2lef – lef2oa, oa2def – def2oa, and oa2stream – stream2oa for GDSII. The Translator Workgroup has decided a text-like format is needed, so they are developing oa2JSON – JSON2oa. All are available with OpenAccess Coalition membership.
Fast solutions can be invaluable if a problem is found late in the design cycle. With the oaScript API changes can be made from scripts or even directly from a shell. It is possible to remaster a design instance or modify a shape from the shell without an editor.
OpenAccess is constantly improving and being modified to support the present EDA industry needs. The OpenAccess Board of Directors oversees the operation of the Coalition. The Change Team ensures changes to the reference implementation work and may propose new changes as needed. The Extension Steering Group oversees the prioritization and co-development of extensions.
The Change Team has two architects: the integrator company (Cadence) and a non-EDA member company. The remaining members are made up of top EDA suppliers, Foundries, Device Manufactures, and Fabless companies. Each release of the OpenAccess Reference Implementation is scrutinized by the team.
Changes are carried forward not only within OpenAccess, but required changes are also made in member’s EDA tool suites. As a result, each EDA tool is compatible with some version of OpenAccess. This produces software that interoperates with all the member’s tool suites.
OpenAccess is not simply a design database, but a 2000+ class C++ API (Application Program Interface). The API has been maintained by the OpenAccess Coalition over the last two decades to stay compatible with vendor tool sets and meet the changing needs of the EDA industry.
When members participate in the OpenAccess Coalition, they can influence the direction of OpenAccess with their vote as well as by developing new extensions to the API within Si2 working groups. The workgroups are autonomous, though the Extension Steering Group provides guidance and standardization from a central entity.
Extensions extend the capability of OpenAccess, providing new features for the API. The extensions are don through the Coalition workgroups. Any member can propose an extension given sufficient support from the membership.
Since the OpenAccess API is extensible, the workgroups can collaborate on a solution to a common problem that may require extending the OpenAccess database. Collaborating with other companies to develop a single solution provides a 1/N cost advantage for each member.
The Value of an Extensible API:
James Masters, Intel, the Chair of the OpenAccess Extensions Steering Group, shows the value of an extensible API using examples of previous extensions
The oaxPop Connectivity Extraction Engine:
James Masters, Intel, shows the new oaxPop Connectivity Extraction Engine
Ben Bowers discusses a way to deliver a library without storing binary
An Analog IP Business using OpenAccess:
Agile Analog provides insight into their analog IP Business using OpenAccess
Multi-Pattern Technology has been implemented as an Extension to the OpenAccess API. It is available to use in your OpenAccess application and realize your own coloring tools for you company’s process. The extension is available in C++, Python, Ruby, and tcl.
Using oaPartitions for Parallel Execution:
Example showing the power of using oaPartitions for parallel execution.
A powerful new extension to the OpenAccess API enabling bulk (wholesale) manipulation of shapes. AND all poly with active and the resulting array is your device count. AND the result with Nwell and you know how many P channel and N channel devices you have.. All in a few lines of code.
Examples Using oaScript and oaxPop:
EDA Scripting Unleashed: Real-Life Examples Using oaScript and oaxPop.
Support for Parallel Process Applications:
2018 introduction of OpenAccess support for parallel process applications.
