OA does not work well for high-transaction processes like IC routers,
DRC, layout vs. schematic, and extraction tools. At the moment, no
commercially available IC routers are fully “native” on OA. Many read
their initial problem space from OA and then write their results to OA,
but the internal transacting takes place on an optimized database. The
read/write to OA is a conversion process.
In addition, the
commitment by Cadence and Si2 to OA’s support of scripting languages is
unclear: specifically, for TCL and Python. TCL support in OA has always
been problematic, and EDA providers who use OA have had to modify the
code themselves before delivering their product. In addition, Python
support in OA currently must be supplied by the EDA vendors themselves.
It looks as though the potential advantage of using OA as a universal
scripting environment to control multiple tools will not become a
reality for those not based firmly on Cadence’s SKILL language.
bottom line is that OA is a mixed bag. For the Cadence tool user, OA
assures that Cadence tools are interoperable with other Cadence tools.
EDA tool vendors who want to adopt OA as a native foundation turn over
control of the underlying framework of their product to another company.
the larger companies with internal CAD groups building custom EDA
tools, OA saves their engineers the drudgery of having to devise and
maintain their own database. There is little downside in using OA for
these internal CAD groups unless the run-time parameters of the OA
framework do not provide the performance and functionality they require.
For those who use commercial IC design and implementation tools, OA is
at best another interchange format.
Unfortunately, a decade
after its inception, the idea of a grand unifying open-source database
providing interoperability without translation between all IC
implementation tools has yet to be realized.
eventually we will come to the realization, as did the RCA team in the
early 1980s, that the idea of the great unifying database must naturally
succumb to the more compelling realities of the technical database
needs of EDA tools as they evolve to meet the ever more difficult
requirements of the next generation of IC designs.
About the author: Linda Prowse Fosler is director of marketing, Deep Submicron Division, Mentor Graphics Corp.
Fosler is a seasoned professional providing marketing and operations
management expertise for a diverse group of technologies and industries
including computer systems, semiconductors, embedded systems and
software and hardware design and verification tools. Linda is currently
the director of marketing for the deep submicron (DSM) division of
Prior to this Linda was Vice President of
Marketing and Business Development for VaST Systems, Esterel
Technologies and IKOS Systems, as well as Vice President of Software
Quality at Cadence Design Systems. Past accomplishments also include
working as an independent consultant for a host of electronics related
Linda makes some great observations about the practical realities of Silicon Realization—I think we all agree on the problem although I think there are some misconceptions about the OpenAccess program and progress to date. Cadence believes strongly that a common database is important to the industry and has remained steadfastly committed for the past eight years. Since 2002, Cadence has contributed and maintained more than 90 engineer-years of code at our own expense. We actively participate in the community and provide input to architectural and priority decisions. The community owns OA content. Cadence has no IP rights other than those granted to us by the community. The community leadership is comprised of other major EDA players as well as heavyweight product companies. Cadence works in this community for the good of the industry which in turn benefits Cadence.
The community is releasing 22.41, due by the end of 2010, which supports multi-threading. The community has recently released new scripting language bindings for Tcl, Python, and Ruby which are available for beta now. The binding code is designed to be easy for the community to download and support. There are many companies both on the EDA side and the design side that depend on OA every day. These companies are all very well aware of the continued improvements in database capability. The community sees this through the evidence of continued and accelerating adoption.
OA was never envisioned to optimally support every algorithm known to EDA. OA’s primary goal is interoperability. There are some applications that will work well with an in-memory model and some that don’t. The point is to have a common place to store and access design data so it can be shared across applications and design teams. OA delivers a common repository to store data and access it either through C++ APIs or various scripting languages built on top of OA…a huge improvement compared to what the industry has had in the past.
The OpenAccess Coalition Scripting Languages Working Group has Perl, Python, Ruby and Tcl ready for action:
Synopsys did the Tcl binding. I might do C#. Which scripting language did Mentor want?
I have made two code contributions to OpenAccess. It's possible but difficult because only Cadence is allowed to change the core database code. To get even a production tested bug fix into OpenAccess, it took well over a year plus pressure from a powerful OpenAccess Coalition member.
Magma seems to have done okay with a central database strategy.
While most agree that OA has failed in universal acceptance it still has the potential to be leveraged as an Open database standard. In part it depends on Cadence relinquishing some of it's IP rights and others taking up OA and adding to it to make it really unified. Or left to itself the industry will gravitate towards two or three camps of database technologies and face insurmountable problems in the long run.
For a start the top EDA companies should come together and come out with some kind of a compromise and hand it over to Accellera or another such independent entity to take it forward.