Process Design Kits: PDKs, iPDKs, openPDKs

One of the first things that needs to be created when bringing up a new process is the Process Design Kit, or PDK. Years ago, back when I was running the custom IC business line at Cadence, we had a dominant position with the Virtuoso layout editor and so creating a PDK really meant creating a Virtuoso PDK, and it was a fairly straightforward task for those process generations.

The PDK contains descriptions of the basic building blocks of the process: transistors, contacts etc and are expressed algorithmically as PCells so that they automatically adjust depending on their parameters. For example, as a contacted area gets larger, additional contact openings will be created (and perhaps even removed, depending on the design rules).

Two things have changed. Firstly, Virtuoso is no longer the only game in town. All the major EDA companies have their own serious offerings in the custom layout space, plus there are others. But none of these other editors can read a Virtuoso PDK which is based on Cadence’s SKILL language. The second thing that has changed is that design rules are so much more complex that creating the PDK is a significant investment. Creating multiple PDKs for each layout editor is more work still, and work that doesn”t really bring a lot of value to either the foundry or the user.

Since Cadence isn’t about to put its PDKs (and PCells) into the public domain as a standard everyone can use, a new standard was needed. The Interoperable PDK Libraries Alliance (IPL), working with TSMC, standardized on using Ciranova’s PyCell approach (based on Python rather than SKILL) and created the iPDK which is supported by all the layout editors (even Virtuoso, at least unofficially).

But if one standard is good, two is even better right? Well, no. But there is a second portable PDK standard anyway called OpenPDK, being done under the umbrella of Si2, although the work just started last year and hasn’t yet delivered actual PDKs.

There is a lot of suspicion around the control of these standards. iPDK is seen as a TSMC standard and, as a result, Global Foundries won’t support it. They only support the Virtuoso PDK, which seems a curious strategy for a #2 player wanting to steal business from TSMC and its customers. Their Virtuoso-only strategy makes it unnecessarily hard for layout vendors to support customers who have picked other layout systems.

Si2 is perceived by other EDA vendors as being too close to Cadence (they also nurture OpenAccess and CPF, which both started off internally inside Cadence) and so there is a suspicion that it is in Cadence’s interests to have an open standard but one that is less powerful than the Virtuoso PDK. Naturally, Cadence would like to continue to be the leader in the layout space for as long as possible.

It remains to be seen how this will all play out. It would seem to be in the foundries interests to have a level playing field in layout systems, instead of a de facto Cadence monopoly. TSMC clearly thinks so. However, right now Global seems to be doing what it can to prop up the monopoly, at least until OpenPDK delivers.

lang: en_US