If you’re involved in analog or custom IC design, you’ve no doubt read about “interoperable” parameterized layout cells (PCells) and process design kits (PDKs). What you probably haven’t heard is a Cadence viewpoint about these developments. The following Q&A interview with John Stabenow, group director of marketing for Virtuoso, explains the concept of “interoperability” as it applies to the Cadence Virtuoso® platform and Cadence analog/custom IC design business.
Let’s start with some quick background. PCells are an essential component of the PDKs that underlie all custom IC development. The Cadence Virtuoso® custom design platform has supported PCells written in the Cadence SKILL language for almost 20 years, and they are used in thousands of production PDKs.
Recently, Python-based PyCells™ from Ciranova have become available for OpenAccess-based analog/custom tools. These are intended to be an alternative to SKILL-based PCells. In a related development, TSMC recently launched the first of its foundry proprietary iPDKs. The Interoperable PDK Libraries (IPL) organization, backed by Synopsys, claims that Python PyCells and Python/Tcl iPDKs will work with tools from any vendor, whereas SKILL PCells and PDKs are “locked” to Virtuoso, and that this relationship of a proprietary PDK and the software platform is bad for customers and the industry.
But how accurate are the claims? I recently put some pointed questions to John, and here are his answers.
Q: John, isn’t interoperability a good thing?
A: As a general statement? Of course. Customers need point tools along the design chain to be able to talk to each other, whether they are all from the same vendor or not.
We believe in interoperability. Cadence revolutionized the industry in 2001 by agreeing to contribute a database it had developed – OpenAccess – to Si2 [Silicon Integration Initiative]. OpenAccess can be used by anyone to develop flexible, interoperable design flows composed of different point tools from different suppliers. OpenAccess has been a successful industry standard for nearly a decade, governed and supported by Si2. Cadence continues to invest a tremendous amount of engineering effort into supporting and enhancing OpenAccess at no cost to the industry. The dream of a way to generate one PDK for all tools is possible only because of Cadence’s invention and contribution of OpenAccess.
With the creation and contribution of the OpenAccess database to the industry, as well as GDS2, EDIF, LEF/DEF, CPF, Verilog, and more, Cadence has demonstrated strong support of standards and while raising the bar with respect to interoperability. Ironically, Synopsys speaks strongly about the importance of openness and industry standard formats, yet their Milkyway database remains closed.
Q: What about claims that SKILL PCells lock people into Virtuoso?
A: My problem with this assertion is that it assumes that all of our customers really want to use another tool. This is not the case. My experience is that all of our customers want innovation, quality, and stability -- things that drive productivity and predictability improvements in their design flow. And with IC 6.1.3 and 6.1.4 releases, they are seeing this innovation and are adopting new and better methodologies.
However, people do leave the Virtuoso world all the time as part of their daily work. When they do this, all of the design information is stored as readily available data in the industry-standard OpenAccess database. Any tool that works with OpenAccess can use the data and operate on it as needed.
As an example, customers would like to have SKILL PCells interoperable with their physical verification tools. Working with Mentor in a true collaboration, we achieved the goal of SKILL-based PCells that can be read directly into Calibre through OpenAccess.
If Cadence wanted to use this mechanism to lock customers into Virtuoso, we would not have developed the product line on OpenAccess, or even made OpenAccess an open standard, much less collaborated with Mentor when we have a competitive product in the physical verification space.
Q: Isn’t SKILL a closed language, while Python is open?
A: This is not true. The SKILL language is derived from Lisp, which is an open language. There is no secret in how to write SKILL. What makes any language proprietary are the bindings to the functionality of the environment in which it runs. The SKILL manual documents the 50,000 SKILL bindings and their syntax, and it is true that these SKILL functional bindings to Virtuoso features are proprietary to Cadence.
But the same is true of Python and any other language. You can write all kinds of Python PyCells, but to get them to fire up and work in a tool, you have to run them through a proprietary plug-in from Ciranova. There is a license there, regardless of cost, and that license is to protect Ciranova's proprietary IP.
Q: What about the argument that Python PyCells run faster than SKILL PCells, and use fewer lines of code?
A: We haven’t seen any objective, quantifiable benchmark that says they’re faster. In fact, one major customer who evaluated PyCells for an advanced node design found that non-object oriented SKILL was faster by a large margin. We have also developed a feature named “Express PCells” in our IC 6.1 version that significantly speeds up the evaluation of SKILL PCells, and customers have been using that to gain a performance and productivity advantage ever since.
Now, there is a PyCell claim that Ciranova promotes that I agree with -- generally, PyCells use fewer lines of code than traditional SKILL PCells. The reason they [PyCells] use fewer lines of code than traditional SKILL PCells is that they use an object-oriented approach to cell development. This is not actually something new. We have been delivering PCells to customers using objected-oriented SKILL ++ as part of service engagements for a decade now, and we are productizing this capability as part of our Virtuoso 6.1 Platform. For our customers, this makes PCells easier to develop. They will have fewer lines of code, and provide the inheritance and process portability customers need -- plus the unique advantage that all legacy SKILL code enables. There will be no need for a "do over" on PCells.
Q: Can PyCells be used in Virtuoso?
A: We have heard claims they work, but the challenge is around support. PyCells are not tested or validated with Virtuoso by Cadence, and PyCell functionality is not something we can guarantee, so there is some risk to assume when you use them. To me, the risk of running into a design problem seems to me to outweigh any perceived advantage obtained with layout tool "swapability."
Q: What are the advantages of SKILL-based PCells?
There are many advantages to SKILL. It supports well-proven, production worthy PCells – over 10,000 during the past 20 years. It provides a rich set of domain-specific APIs. And it allows deep integration within the Virtuoso Layout Suite for advanced functionality.
As I speak, we are in the process of productizing real-time analysis for interconnect parasitics. This same technique can be applied to context-aware device behavior. When this is released, customers using SKILL PCells will have the ability to see the impacts of device behavior and device-to-device parasitics in real-time, as they place PCells within various contexts and connect them together. This is an example of the kinds of really important things that customers cannot do with non-native PCells.
Q: iPDKs use Tcl. Is this an advantage over SKILL?
A: The TSMC iPDK uses both Tcl and SKILL for elements such as call-backs and functions. The difference between using Tcl and SKILL is that SKILL has 50,000 commands that were custom built for manipulating data. It’s the most specifically tuned language for analog and custom design out there. Tcl is not built for this; it is a general language for generic applications. It lacks the specific purpose that SKILL possesses. For Tcl code to do something inside a tool, the tool has to interpret it somehow. That interpretation of the code creates a proprietary result. If you were to ask if you can use the same Tcl script in every EDA tool, the answer is probably no.
Q: What’s the story behind TSMC iPDKs?
A: TSMC started an initiative to develop interoperable formats for various EDA tools such as parasitic extraction (iRCX), DRC (iDRC), LVS (iLVS), and PDK (iPDK). The idea is that by doing this, TSMC would develop, validate and maintain only a single technology file or a single PDK and it would work universally for all EDA tools. Conceptually, this is a very good idea. It allows every tool to have a fully validated infrastructure ready at the same time – without any preferential treatment. And it reduces a significant resource overhead for TSMC. We support this concept.
Along this line, we are working closely with TSMC on all the interoperable formats they are defining. We are helping them with development and support with appropriate resources to enable them to realize their vision of an Open Innovation Platform (OIP).
It all sounds like motherhood and apple pie, right? The reality is that when it comes to how iPDKs actually work, it is really made of two PDKs in one. There is an all-SKILL PDK for Cadence, and there is a Tcl and Python PDK for Synopsys. So under the hood, there are actually two PDKs going on. Contrary to popular belief, any EDA vendor other than Synopsys will have to do some retooling to use an iPDK.
Digging a little deeper, the iPDK has one OpenAccess technology file for Cadence and a completely separate proprietary technology file for Python PyCells. In addition, the idea that a PyCell will magically work in two different layout tools is simply not true. A PyCell for layout tool A is wrapped in layout tool A’s wrapper, and to use that same PyCell for tool B, it must be re-wrapped in layout tool B’s wrapper. Bottom line is that even though the source of the PyCell may be the same, a customer trying to do this will actually end up with two different PyCells.
If a PyCell is wrapped in SKILL for Cadence and in Tcl for Synopsys, how do you ensure synchronization? Isn't that doubling the work?
Q: Do interoperable PDKs offer any real advantages in terms of improving design accuracy, shortening cycle times, or promoting design reuse and IP portability?
PDKs need to be well tested by customers, foundries, and EDA vendors, regardless of the specific tool they enable. There is an argument that an interoperable PDK will shorten design cycle time by enabling a faster start. This comes from the idea that the foundry doesn't have to queue PDKs for different tools on the same node in some order; they can just build one. The problem is, as I already noted, there is no such thing as one PDK for all tools.
There is also an argument that iPDKs should promote both design reuse and portability. And again, since there is no such thing as one PDK for all EDA tools, it is a false argument. Moreover, as Cadence will always use SKILL, and it is unlikely EDA vendors will retool their schematic and layout environments around a Synopsys-specific PDK (the iPDK), and there will be no benefit for reuse or portability either. The exception could be layouts using PyCells, but that assumes IP reuse is only about the layout, which it isn't.
Finally, when it comes to the claim of better design accuracy using iPDKs, this is simply not the case.
What I hear customers say they want is not layout tool swapability; it is retargeting a design from one foundry to another. We believe this is where the real benefit to customers will be, and we are exploring ways to abstract the PDK development process in a way that will enable foundry portability.
Q: Without interoperable PDKs, don't foundries have to create tool-specific PDKs for every vendor, adding to PDK development costs and time?
Yes, they do. Currently, even with the iPDK, TSMC is creating vendor specific PDKs at every node. Remember, there actually two PDKs under the hood of the iPDK. It's possible they will only do this on request at 28nm and below, but certainly in the case of SKILL PDKs, a customer only needs to ask and they will get a SKILL-only PDK. And this does put a burden on the foundry in terms of development costs.
Cadence's vision for solving this problem is to abstract the design rules and process information to create a higher level way to describe CDFs [Component Description Formats] and callbacks. A foundry can then publish the higher level information, and each vendor can use a generator to get to the final PDK. We believe it is better to have the EDA industry leverage tool-specific PDKs that are "automatically" generated from a single source, instead of trying to force a PDK implementation on everyone. We are working with key partners and foundry partners in this important area.
Q: What’s your take on the Interoperable PDK Libraries (IPL) organization that recently formed?
A: It’s a decent Synopsys marketing effort to promote their efforts in custom design and support enablement of their products. But let’s not be confused -- it’s not a standards body, nor does it have broad industry support. Do a “whois” search on the website.
Q: Does Cadence support interoperability in analog/custom design?
A: Absolutely – our customers ask for it and we support them. OpenAccess is a great enabler for interoperability -- it is the only open database in the industry. OpenAccess is a universal data store for design information enabling read and write access. We [Cadence] made the initial contribution and continue to be the primary key developer in the Si2 community.