The OpenAccess Story

When I worked for Cadence back in the early oughts, we developed a layout database called OpenAccess, usually abbreviated to OA. It had actually been designed from the ground up to be the native database that would underlay Cadence's physical design tools. Custom layout tool Virtuoso already existed—in fact this year is its 30th anniversary—but the digital design forerunner of Innovus was still called Silicon Ensemble. Having created the OpenAccess database, the reality at first was that none of these tools ran on it natively. Virtuoso had its own database, still called CDBA I think, and Silicon Ensemble ran on LEF/DEF. Designs could be moved in and out of OpenAccess into these legacy formats, so OpenAccess could be used while software was moved to run natively on it.

Some of Cadence's largest customers wanted a completely open standard database, since they had internal tools that needed to be interfaced and, shocking I know, people occasionally use design tools from other companies. As a result, in 2002, Cadence contributed OpenAccess to the Silicon Integration Initiative (Si2). It is the premier contribution we have made to the industry for the last 18 years. Cadence also contributed LEF and DEF, a de-facto standard to the industry through an Apache license. It dates back to one of Cadence's earliest acquisitions, Tangent, with their products Tancell, Tangate, and Cell3 (because it could handle a third layer of metal, unlike the other two products).

But the oldest standard in EDA has to be GDS2, which also ended up in Cadence after Cadence acquired Valid Logic, although it was originally created by Calma in the late 1970s as the backup format for their layout system Graphic Design System 2, or GDS2. For more about that story, see my post Why Do Layout Designers Say "Stream Out"?

I remember some of the early work to unify the databases since our custom/analog environment had a completely different history from our automated place and route environment. The program was called Superchip with the goal that by pulling everything together we could do true mixed-signal designs, which were then possible only with extreme care and a lot of manual work. Even the words for the same things were often different. I remember a big meeting where we had all the architects from both groups in one room. There were lots of misunderstandings and it would take many more years than initially planned to get everything working cleanly.

I set up a call with Michaela Guiney. She is formally a Senior Architect in the Virtuoso Infrastructure Group, mostly focused on OpenAccess. She is also the Cadence representative and the OA co-architect on the OA Change Team. The project is run slightly differently from many industry standards projects. The OA Change Team decides what needs to be enhanced. Coalition members can also suggest bug fixes, but the Cadence OpenAccess team is responsible for implementing the changes and ensuring that they work.  Changes to OA need to be done in an orderly fashion to make sure that new capabilities don't cause crashes in pre-existing tools, or require everything to be re-written. Cadence has the deep experience with OA and the extensive test infrastructure needed to validate changes. Si2 manages the OA Coalition and distributes the code, which is only available to coalition members.

 She told me that:

OA is basically a standard way of representing IC design from netlist to layout. A reference implementation available to members, both documentation and source code. There is a collection of  APIs that sit on top of an in-memory data model. It was intended to be useful to an application: efficient memory, high performance, object-oriented API. A lot of the value of the architecture comes from the fact that OA is production quality. It is used in commercial EDA tools, in particular by Cadence, but also by other user and EDA companies.

Some tools that already have their own in-memory data model copy in and out of OA. Others, like Virtuoso, run on top of it directly. New tools have been built on top of OA from day one. But some tools can't use OA directly due to the way the underlying algorithms work (for example, many batch DRC tools build dedicated data structures on top of OA that are more efficient for their algorithms)). But OA was always built to be extendable. Tools can annotate information onto objects, or build new objects. This part of the database is not standard, but you can put information in the right place and retrieve it later and it is just as efficient if it was all a native part of the standard.

Above is an example of the class hierarchy for part of the OpenAccess Data Model, from the OA documentation. It describes the kinds of physical objects that can be part of nets and pins, such as various kinds of shapes, routes, and vias. Because OpenAccess also supports creating schematics, instances of symbols (such as those for input and output pins) can also be associated with a pin. Diagrams like this in the documentation allow users to traverse the OpenAccess class hierarchy to find documentation on the classes and APIs, generated by doxygen from the source code. 

Things that have been a focus recently to modernize the database have been:

• Improved capacity
• Multi-threading and cloud-readiness
• Ability to compress data on disk to reduce the file-size, which is also a big performance win
• Partition data so a tool only needs to read in what is required, not the entire database
• More kinds of constraints to support advanced nodes.
• Quality improvements

There are five to six releases per year. The stability is "remarkable". You might have compiled an application in May, and linked to several versions later of OA, and the code will still run. This works because we have tens of thousands of tests that we can run, so it is relatively easy for us to make a change and see if it breaks anything.

The OpenAccess Coalition directs the Change Team, which is responsible for approving all changes. IBM shares the co-architect position with Cadence, and the architects drive the OA roadmap between the two of them.

The OA Coalition consists of about 42 companies, some small, some Cadence competitors, some semiconductor companies. The availability of a production-quality EDA database has spawned smaller companies that don't need to worry about infrastructure and can focus on their differentiated applications. This means that user companies can handle more advanced designs without having to consume a lot of their manpower chasing single-digit nanometer process nodes with all their complexity. To give you an idea of the scale, OA is about 2 million lines of code, including the translators, and it has a dedicated R&D team within Cadence. It is a major investment that has helped promote the growth of the EDA and design ecosystem.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.