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