OpenAccess

Probably everyone knows that openAccess is a layout database. It was originally developed at Cadence (called Genesis) but has since been transferred to Si2. Strictly speaking, openAccess is actually an API and the database is a reference implementation. The code is licensed under a sort of halfway to open-source: you can use it, but you can’t incorporate it into a different implementation of the API. The FAQ on openAccess on the Si2 website is here.

Cadence never really planned to make openAccess that open. When I was there it was an internal project with the long-term aim of replacing the databases underlying the digital design and custom design tools and so, eventually, unifying them. However, several large customers had internal database projects of their own and were pushing back on switching to openAccess if it remained proprietary to Cadence. Apart from the general wastefulness of every semiconductor company investing in creating their own database so that they could interface their own internal scripts and tools, Cadence realized that it would be a maintenance and business headache if, gradually, their customers stored all their design data in proprietary databases with different semantics.

So openAccess was opened by donating it to Si2, and eventually the source code was available too. Note that at this point the real purpose of openAccess was to make the interface between Cadence’s customers’ internal developments interface cleanly with Cadence’s tools. I don’t think Cadence clearly though through the implications for the EDA ecosystem.

The dirty secret of the early days of openAccess was that, despite being developed at Cadence, no Cadence tools ran on openAccesss natively. There were translators in and out of it to the other Cadence databases. Cadence, being a large company with a huge installed base was also not the nimblest and so the first tools that ran on openAccess were from smaller companies.

Today, customers and especially other EDA companies, look at openAccess as a way to interface tools from different vendors. For example, SpringSoft’s Laker layout environment supports openAccess and uses it as the means to run Mentor’s Calibre DRC incrementally and interactively behind the scenes as editing takes place.

But openAccess on its own is only a part of the problem of interfacing the Cadence layout environment to the rest of the world. A key part of Cadence’s layout system are pCells, especially those that are in the physical design kits (PDKs) supplied by the foundries. pCells are not part of openAccess and, as a result, it is not really a complete interface. Of course Cadence regards this as a competitive advantage and it is clear that they are not going to make pCells open. I ran the custom IC product division of Cadence for a year or so and, without revealing any numbers (I can’t remember them anyway), you won’t be surprised to know it was the definition of a cash cow, making a large amount of money for a relatively small engineering investment (off topic: gateEnsemble was even better, with an 8-figure revenue and only about one bug report per year. Management would regularly try and kill it in an irrational desire to reduce the breadth of the product line).

The IC layout market really splits into two halves: Cadence, and everyone else. Cadence has a closed system (think Apple) whereas everyone else (SpringSoft, Synopsys and others) is open, competing on technology, service etc and not on lock-in. To an extent, any switch away from Cadence to one of the other players is a win for all of them in the short term. Once the tipping point away from Cadence is reached, if it happens, then the game switches to a land-grab for market share on a level playing field. Open systems usually win in the end even against entrenched lock-in: Windows-NT was surpassed by Linux for internet servers despite Microsofts advantages.