All of the attempts at creating electronic design automation (EDA) tools that are interoperable through the mechanism of a grand-unifying open source database have failed and are likely to continue to fail. Why?
First, a story: I have a good friend whose first full-time job out of school in the early 1980s was with RCA in the layout artwork portion of the design automation group. When he joined, the team was still recovering from an attempt to move all layout data to a common database. Even in the ‘80s, IC implementation was replete with formats—APPL from Applicon, GDS from Calma, etc. The landscape was complicated with numerous proprietary internal layout formats devised to allow for the digitization of rubylith. Other than the layout stations, most EDA tools came from an in-house design automation group, if only because there were no alternatives.
These in-house teams built all the layout manipulation and analysis tools. They wrote and supported everything from place and route, to design rule checks, extraction, plotting, and all of the low-level logical operators necessary to support those functions. The concept of a unifying database was an obvious solution to the problem of tool interoperability. The RCA unified database idea was to write all known formats to one central repository. The team would then be out of the situation where each tool had its own data format. RCA could eliminate the time spent in the onerous task of conversions.
A wonderful idea but one that failed. I remember my friend commenting that, by the time he joined in 1981, the idea of a central database was ridiculed as failed mythology of the past. The actual experience of the “central repository” was that file sizes some two years after the project was conceived and specified were much larger than the designers had expected. The database became unreasonably convoluted as each individual application attempted to cram more information into the already stretched schema. The capacity limits of what was then the IT infrastructure were strained. Read/write accesses became ever slower. A common database for all IC layout design had proven to be impractical.
RCA was certainly not the only organization with the idea to unify EDA data. Across the intervening decades, many righteous attempts have been made both within large integrated device manufacturers and by EDA vendors themselves. Still, well into the 1990s there remained no commercially viable successes in delivering a grandly unifying EDA database.
Then, Cadence contributed its Genesis database to the growing effort among the user community to create an open database standard. Genesis eventually became the Open Access database (OA) with Cadence retaining control of the source code. The OA concept was birthed during a period of great excitement over the business prospects of “open source” code development and distribution as a way to deliver a product. This new model had captivated some entrepreneurs and investors and was a darling of the dot-com boom of the ‘90s.
Cadence turned distribution of their database over to the Silicon Integration Initiative (Si2) consortium. While OA has brought some standardization benefits, it has also remained problematic. The status today is that everyone who consumes EDA tools knows what OA is, but worldwide adoption of OA as a centralized platform has not materialized. And even though OA source code is available to all members of Si2, a true open-source model for OA has never been implemented. Perhaps to avoid the resource-consuming chaos they might endure if the entire industry was indeed opened up to modify the OA source, Cadence has kept a tight control on the OA source code, thereby guaranteeing a high degree of stability and conformity while retaining control over what is the company’s intellectual property. Therein lays the problem. OA is called an “open standard” capability but code ownership rights are somewhat fuzzily maintained by Si2 and Cadence—definitely not publically owned.
That said, OA is available and it is stable and self-consistent. OA has provided a good underlying data control and storage mechanism for Cadence tool users and for the creators of a certain class of EDA tools. However, OA has serious limitations. It is not suitable for multithreaded or distributed, concurrent EDA applications; thus, it may be of increasingly limited usefulness as the next generation of EDA tools evolve to take advantage of these modern architectures.
Can OA overcome its limitations and become an extensible, high-performance, multi-threaded truly open standard with the source code owned and controlled by the industry rather than one company? Without this, many EDA vendors view moving to it natively as a risky proposition. After all, would you want the very foundation of your product to be controlled by a company that is in some, or all respects, your competitor?
The few EDA companies who have decided to depend on OA natively are now in the unenviable position of having to maneuver their product around the controls and limitations enacted by the true owners of their core architecture. These business complications are reflected in the technology itself. Unless some kind of parallel data-management techniques are developed, tools built on OA will certainly never run faster than OA, they will have no higher capacity than OA, nor will they be able to implement features that span beyond those of OA.
OA does not work well for high-transaction processes like IC routers,DRC, layout vs. schematic, and extraction tools. At the moment, nocommercially available IC routers are fully “native” on OA. Many readtheir initial problem space from OA and then write their results to OA,but the internal transacting takes place on an optimized database. Theread/write to OA is a conversion process.
In addition, thecommitment by Cadence and Si2 to OA’s support of scripting languages isunclear: specifically, for TCL and Python. TCL support in OA has alwaysbeen problematic, and EDA providers who use OA have had to modify thecode themselves before delivering their product. In addition, Pythonsupport in OA currently must be supplied by the EDA vendors themselves.It looks as though the potential advantage of using OA as a universalscripting environment to control multiple tools will not become areality for those not based firmly on Cadence’s SKILL language.
Thebottom line is that OA is a mixed bag. For the Cadence tool user, OAassures that Cadence tools are interoperable with other Cadence tools.EDA tool vendors who want to adopt OA as a native foundation turn overcontrol of the underlying framework of their product to another company.
Forthe larger companies with internal CAD groups building custom EDAtools, OA saves their engineers the drudgery of having to devise andmaintain their own database. There is little downside in using OA forthese internal CAD groups unless the run-time parameters of the OAframework do not provide the performance and functionality they require.For those who use commercial IC design and implementation tools, OA isat best another interchange format.
Unfortunately, a decadeafter its inception, the idea of a grand unifying open-source databaseproviding interoperability without translation between all ICimplementation tools has yet to be realized.
I believeeventually we will come to the realization, as did the RCA team in theearly 1980s, that the idea of the great unifying database must naturallysuccumb to the more compelling realities of the technical databaseneeds of EDA tools as they evolve to meet the ever more difficultrequirements of the next generation of IC designs.
About the author:
Linda Prowse Fosler is director of marketing, Deep Submicron Division, Mentor Graphics Corp.
LindaFosler is a seasoned professional providing marketing and operationsmanagement expertise for a diverse group of technologies and industriesincluding computer systems, semiconductors, embedded systems andsoftware and hardware design and verification tools. Linda is currentlythe director of marketing for the deep submicron (DSM) division ofMentor Graphics.
Prior to this Linda was Vice President ofMarketing and Business Development for VaST Systems, EsterelTechnologies and IKOS Systems, as well as Vice President of SoftwareQuality at Cadence Design Systems. Past accomplishments also includeworking as an independent consultant for a host of electronics relatedclients.