At a purely technical level, Process Design Kits are fairly innocuous. They are used to enable custom IC design flows. A Process Design Kit (PDK) includes device models, schematic symbols, netlisting procedures and parameterizable cell layout generators. Physical verification rule decks and a parasitic extraction technology file are usually included in the kit. Quite a few of the tools used in custom IC, such as placers and routers, need information about the process technology but not in as much detail as exists in the design rule manual. So the PDK also incorporates a technology file with this information in a form that can be more easily used by these tools.
PDKs often receive short thrift from the EDA cognoscenti. They tend to be considered a little mundane and, dare I say it, a bit boring. After all, they are not in the public eye like energy efficiency and low power. They are not on the cusp of the next big wave like RF and mixed-signal. They are just infrastructure. But that’s exactly it. They’re infrastructure. And infrastructure is a powerful competitive advantage.
One of the reasons why infrastructure is so potent is that it is largely invisible, especially if it is intertwined with a business process. Add a new feature to a product, and competitors will see it and be able to respond. Embed it in the infrastructure and no one knows it’s there or how it works. When the iPhone was launched, it was the first of its kind but within a very short space of time, others had produced similar looking products. However, no one has been able to replicate its user experience and delight. Its secret lies beneath its surface where no one can quite place their finger.
Infrastructure also exerts a hold on customers because it can be massively expensive to displace. Once ecosystems get built around a kernel, it becomes very expensive to move customers to something new because it takes a huge amount of energy to introduce and proliferate the new base. It can be done, but you need deep pockets and even more patient shareholders. Take a look at Verizon. To compete head-on with cable, Verizon has invested close to $20 billion1 this decade to lay fiber to the home.
There has been a buzz over the last year or so about re-implementing parts of a PDK in open languages to make them interoperable between different vendors’ solutions. At first glance, the notion has a certain appeal but on reflection one has to wonder whether taking a successful solution, fine tuned through years of extensive usage, and recasting it in a new language is really transformational.
If we want to create breakthroughs for our customers, our thinking has to be bolder, more expansive and more ambitious. What if PDKs were to become smarter? Suppose they could truly link process development, design, manufacturing and test. What could the new opportunities be for optimizing the supply chain and compressing time to market? Infrastructure is too valuable a resource to be relegated to a format. More than just interoperable PDKs, we should really be thinking about intelligent PDKs.
1 – Foust, Dean. “The BusinessWeek 50.” BusinessWeek, 6 Apr. 2009: 37-63.
It is the zeitgeist of our time to perceive open standards/interoperability as the way to go. Although, I agree with you that under most circumstances, this is the right approach, there are exceptions.
A very relatable example is the iTunes-ipod ecosystem where the end to end experience is managed by Apple and it is as you know a completely closed system. So innovation and a closed ecosystem are not mutually exclusive.
In case of PDKs (PCells in particular), tight integration to the target tool(s) is very important to ensure maximum flexibility, functionality and productivity. The designer can focus on innovation and not get bogged down on stitching tools/flows together. This level of integration/ flexibility is not possible if you use iPDK(pycells) designed to be used with multiple vendor tools. It might achieve interoperability at the expense of features and functionality.
So the actual choice in this case is between a proven, state of the art and complete system vs a new, unproven system built on pycells which are in essence designed to be the lowest common denominator of all the competing tools.
Thanks for your interest in my blog!
I view PDKs as infrastructure because they include foundation IP and enablement for custom IC tools and flows.
There are two levels at which PDKs can be interoperable. The first is interoperability between different EDA vendors’ solutions. TSMC’s iPDK initiative is an excellent example of this, in which the idea is that a single PDK enables design with different vendors’ tools. The second is interoperability between different foundries. The Common Platform, comprising IBM, Chartered and Samsung, is a great example here, where the goal is to use the same PDK to enable tape-out at different foundries.
All of the customers I have spoken to are very interested in the second type of interoperability because it really helps them plan their capacity requirements and how they can get to market economically.
I'm not sure your characterization of pdk's as *infrastructure* fits. Infrastructure *should* be based on open standards so that various companies can use it. This is true of physical and technological infrastructure - even phone cables you cited as an example.
PDK's containing design data in *proprietary* file formats of *PCells* limit the ability of the designer to use new tools and new design methods. PCells limit innovation.
iPDK will use open *non-proprietary* formats such as Python and OpenAccess (a Cadence database format).
Users will be able to use the iPDK without changing their tools or processes. OR, they can explore new opportunities to increase their productivity. Choice -> innovation.