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.
I welcome this wonderful discussion by John, Tom, Ed, Eric, & Duncan, all of whom I deeply respect and have worked closely with in the past. John rightly points out the unique richness of the Cadence SKILL development language; however, having been the driving force for the SKILL documentation effort (among many others) I must clarify his comment of 50K documented SKILL functions. John refers, for the most part, to private undocumented & unsupported SKILL functions. There are, in reality, fewer than 5K public documented & supported SKILL functions. This clarification by no means is meant to diminish his pride in the richness of the development language; it's just to state the facts more correctly.
This posting addresses one particular detail which is stated incorrectly in John's
It is possible for the iPDK to produce identical geometries for devices in design
cockpits from different EDA vendors. In fact, this is the whole point.
The "wrappers" John talks about is probably a reference to CDF. Worth noting
that OpenAcceess does not support a schema for CDF. Nevertheless, the CDF for iPDK
is made to work natively in the target design cockpit. SKILL call backs for Virtuoso,
and Tcl for Custom Designer. But the underlying logic for generating device geometries
and process rules are the same.
To expand a little on process rule representation. PyCells allow PDK developers
to choose from multiple options for representing process rules. OpenAcess TechDB
is one of the options. By design, PyCell and CDF functions can share the same
process rule information regardless of the design cockpit in which they are executed.
Furthermore, the iPDK partners performed extensive quality assurance cycles to
ensure the geometries generated in multiple design cockpits are compatible.
Some readers may be familiar with the use of the XOR Boolean function applied
to layouts as a technique for ensuring compatibility of generated geometries
down to fine granularity of shapes on layers and grid points.
The iPDK is a brilliant strategy. It allows all OpenAccess based tools to
exercise foundry IP in the one interoperable kit. Tools involved in a design
project take advantage of the foundry qualification process to give IC design
projects foundry-accurate device geometries.
The iPDK approach allows foundries to capitalize on the advent of OpenAccess to
reduce the cost of developing and maintaining PDKs and for customers to take
advantage of best in class tools.
Getting in the way of this real value proposition is the usual inter-EDA company
politics. Historically, dominant EDA companies prefer to make customer design IP
sticky to their tools to the exclusion of others. The "Open" in OpenAccess is
meant to do away with the old games of locking up customer design IP to one EDA
company's design data format. In just about every way one looks at it, the iPDK is
a fulfillment of the vision for OpenAccess.
1. TSMC iPDKs have been verified in several different custom design tools, and the interoperability has been proven. No matter how the tools use iPDK (direct access, wrapper, etc.), the results are consistent and validated by us.
2. There is ONE iPDK for each process variant. Underneath there is a package of Python pcells and Tcl callbacks for all the qualified OA-based tools. The other package is SKILL for Cadence tools. The reason iPDK including SKILL package is because Cadence doesn't not support iPDK standard.
3. The iPDK functions in Tcl and Python are open for all vendors.
4. OA is interoperable, but once customer uses vendor-specific PDK, such as Cadence SKILL-based PDK, it becames non-interoperable. If Cadence really support interoperability, why does Cadence open the proprietary PDK portion, such as SKILL?
5. High-level approaches to describe CDFs and callbacks were failed by Cadence previous product PAS (PDK Automation System).
6. The idea about foundry portability is completely absurd and naive. I don't see any foundry would want to share their foundry proprietary data in the PDK.
Thanks Richard and Rich.
I should add to Rich M's comments that Ciranova has a source code escrow agreement with Si2 such that if the PyCell API ever becomes -not- free, the source code will be released to Si2, whose membership includes most of the EDA industry leadership including Cadence.
I also second Rich's call to John. With at least four of the world's top ten semiconductor companies now actively deploying PyCells at nanometer geometries, IPL would welcome Cadence with open arms.
Thanks for this interview, it is good to hear from John again. We miss him in the IPL meetings; in fact, he should join again!
Speaking for SpringSoft, I can tell you that, as a founding member of the IPL along with Ciranova, AWR and Synopsys and an original iPDK partner with TSMC, the IPL/iPDK libraries including the CDF and callbacks are interoperable and have been tested extensively by TSMC and between SpringSoft’s various OA partners, including Synopsys, Ciranova, Magma, Mentor/Calibre, Pyxis and others.
I would like to comment on John's quote: “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.” Donating the SKILL language or even the OA SKILL plug-in would be a welcome addition to the IPL.
As for this quote “...you have to run (PyCells) 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.” Please note that OpenAccess itself is licensed and membership is not free. Ciranova’s PyCell Studio API is free. Correct me if I am wrong, but a Virtuoso, Express PCell license (required for Calibre to “see” SKILL PCells) is also not free.
Regarding lack of broad industry support, the IPL website, www.iplnow.com, has a list of members. Almost every significant player in custom IC Design is a member, not to mention TSMC.
Thank you for the opportunity to comment. John was nice enough to post a link to this post on our IPL & iPDK LinkedIn group. Those interested in this topic can also see comments there. www.linkedin.com/news
One clarification: "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". Actually the tcl and Python PDK is for IPL compliant iPDK tools, including Magma, Mentor, Springsoft, and Synopsys.