3D glasses to lighten us up
TSMC and ST presenters
Winner of 10th annual Tensing Norgay Interoperability Award: IEEE ISTO
Overview
For the past several years I’ve seen TSMC create the iPDK standard and seen modest adoption, then along comes Si2 with OpenPDK. Are iPDK and OpenPDK complimentary, competitive, or what?
The ST speaker says complimentary, however when I talk with some CAD managers and EDA execs the two standards sound conflicting and over-lapping.
Notes
Vincent Varo (ST) – Design Kit Manager, Central CAD. Open PDK board member.
ST’s Vision on OpenPDK and iPDK concepts.
Goals – to produce openness and industry standard formats, be more efficient.
Single PDK to support and EDA vendor tool.
iPDK and OpenPDK are complementary approaches.
Adoption requires: collaboration between EDA, foundry, users
Need advanced technologies: 28nm, 20nm
Best in class tools mixed together that need standards.
ST PDK: OpenPDK & iPDK
OpenPDK: Foundries, EDA Vendors, Customers, PDK Development Team
Inputs: eDRM, eDevice spec, eModels.
Ouptuts: DRC, LVS, Tools, Libs, PEX, Spice models
iPDK: iDRC, iLVS, Tools, iLib, iPEX, Spice models
The iDeck can be interpreted by an CAD tool itself
Interoperable device library (normalized OA symbol, layout pcell generators,…)
An iPDK can be made of an OpenPDK standardized spec and recommendation.
OpenPDK from a CAD vendor viewpoint: input (eDRM, eDevice spec, eModels) -> Automatic development tools, OpenPDK, automatic validation tools, validation report.
Foundry view of OpenPDK – they create the normalized and standardized e Design Manual, e Device Spec
ST will support both OpenPDK and iPDK. Use OA as universal data storage. Not vendor specific, not foundry specific.
Priorities – eDRM definition as a reference, PDK input standardization for best in class automation flow. Make 28nm and 20nm iPDK and OpenPDK.
S.T. Juang (TSMC) – Sr Director, Design Infrastucture Marketing
TSMC Open Innovation Platform (OIP) – collaboration between, EDA, IP, services.
iPDK, iRCX, iDRC, iLVS, iPRT, iSNA, iSDK/TMI, unified DFM engine, unified IP specs
Design kit innovation –
AMS Reference flow: 28nm, 20nm
DFM Implementation flow: 40nm, 28nm
iPDK contents – SPICE, LVS, views, symbols
Tech Files Roadmap – iPDK, iRCS, iDRC, iLVS (65nm to 28nm)
Partners in each area (EDA Vendors)
Analog Base Cell (ABC) – scalaeable analog cells with optimized layout, Pycell and OA symbol, multi-vendor design flow with ABC
Analog/Mixed signal reference flow – goals
AMS Reference Flow 1.0 – used a 1.6GHz PLL
Hi Daniel, hope you had an excellent DAC.
I was referred to this blog by a member of both groups who noticed you were unsure if OpenPDK and IPL were somehow conflicting.
Please allow me to make very clear that OpenPDK and IPL are 100% complementary, with 0% conflict. The simple reason is that we are adding a value layer around and above IPL, but fully support the generation of an IPL output file set from OpenPDK inputs and interface standards. OpenPDK does not specify any output file set, but instead supports multiple file sets that are in use today – and that certainly includes IPL.
Vincent Varo (ST Micro) states it very well, and he should know: ST is one of the leading companies working to deliver production PDKs with OpenPDK, which has 14 companies (and is still growing). Many are members of both groups, and they would not permit a conflicting result. I am confident the members of OpenPDK and IPL are working hard to develop standards that will work together with a shared efficiency for industry.
Thanks for the blog! ~Steve
Steve,
I appreciate the clarification however there is some general industry education required because one CAD manager (processor company) and one EDA exec that I talked with saw conflict.
If TSMC is the only fab I work with and IPL is working then what benefit do I have by using OpenPDK?
If Cadence is my vendor of choice and the foundry supports the Cadence PDK then what benefit do I have by using OpenPDK?
I read that all the major EDA companies will support OpenPDK so clearly they see some value in adopting it.
Hi Daniel,
The IPL 1.0 standards documentation provides a validated method to develop an iPDK. This standards is adopted by TSMC and Towerjazz. We are seeing growing adoptation and you will be seeing more announcements in the coming months.
We are able to validate and publish this standards in just a couple of years because we chose to focus on several key aspects of an iPDK. Namely, PCells, CDFs, Callbacks and Symbols. The OpenPDK effort by Si2 expands on what we have accomplished and takes on the standardization at a higher level. As Steve mentioned, we are complimentary to each other.
Therefore, if TSMC is the only fab and you are using the TSMC iPDK then you can look into the other i formats in the OpenPDK effort such as iDRC, iLVS, etc.
If Cadence is your vendor of choice and the foundry supports Cadence PDK then you need to be worried because the iPDK is taking designers to a new level of analog automation. During the IPL Luncheon on Monday, TSMC mentioned that they were able to release their AMS Reference Flow 1.0 encompassing the best analog EDA tools due to the iPDK. ST also previewed their iPDK based AMS reference flow at the interoperability breakfast. Welcome to the new world of analog design automation.
Michael Ma
VP of the IPL Alliance
Michael,
Thanks for the update, I appreciate it.
One more question, when will TSMC stop supporting the Cadence PDK?
It seems to me that TSMC will have to stop supporting the Cadence PDK in order for the iPDK to really become adopted widely.
Hi Daniel
Thanks for posting the blog about the breakfast. A couple clarifications might help answer your question “when will TSMC stop supporting the Cadence format”.
First, it is a little disappointing that – in all the table pounding about “iPDK” – the fact that the TSMC’s iPDK is two PDK’s in one, never gets mentioned. iPDK is a SKILL PDK for Cadence, and an Tcl/Python PDK for Synopsys (and the others who have chosen to comply with the format).
As part of our partnership with TSMC, we felt including a SKILL PDK in the iPDK umbrella would work, so we collaborated with TSMC to support the effort by allowing an iPDK to ship with SKILL. We have a strong partnership with TSMC on many levels, and TSMC will continue to support Virtuoso’s SKILL format (as they will with Springsoft/Laker’s native format too, by the way, so it isn’t just a Cadence thing).
As to OpenPDK and iPDK, they are indeed complimentary. For those EDA vendors that want to comply to the iPDK standard (the Tcl/Python), they can continue to do so. For those EDA vendors who believe that their customers are best serviced by a PDK whose IP is tightly coupled with the application (and completely within the EDA vendor’s control), they can look to OpenPDK as the standard.
I do have to disagree with Michael Ma on “innovation”. There is incredible innovation in Virtuoso in a number of areas, including assisted automation for analog designer.
What is interesting in the PyCell debate is a risk/reward conversation seems to be lacking. I have heard industry experts say a 28/22nm project could cost between $40M and $140M. Cadence doesn’t support PyCells. So the risk is $40M to $140M, and the reward is what ….. swappable tools? Could there really be $140M worth of differentiation between Helix and Virtuoso’s rapid analog prototype flow? I don’t think there is any meaningful differentiation, but even if you take the other side, the ROI is not greater than the risk.
John
John,
Thanks for the insight, I didn’t realize that the iPDK also contained the SKILL PDK. That makes a lot of sense for TSMC to support the defacto leading flow along with an emerging flow. I did hear some chatter at DAC that TSMC would simply drop SKILL PDK in the future.
Your summary about OpenPDK and iPDK helped clarify to me the intention of each effort.
Maybe we should have you be the Emcee for next year’s interoperability breakfast, now that would be openness taken to a whole new level.
Hi John,
Very good point regarding TSMC iPDK shipping with SKILL PCells. TSMC is in a better position to confirm with their customers regarding the content of the iPDK. Taken from the spirit of the “i” in iPDK, CAN YOU PLEASE CONFIRM WHETHER THE IPDK WORKS WITH VIRTUOSO IN A HETEROGENEOUS DESIGN FLOW? If it doesn’t then why is SKILL PCell in the iPDK. Isn’t it counterlogical?
You disagreed with me regarding “innovation” in analog tools and proceeded to mention that Virtuoso have incredible innovations. Who’s complaining about innovation at Cadence? I am not. Are you?
Innovation happens when there’s competition. Do you agree? If not, then we’ve to start a separate blog on that. For that to happen there needs to have a platform (for competition). Thanks to Cadence we have OpenAccess and thanks to the IPL Alliance and TSMC (as a validator of the technology) we have the iPDK. That’s the platform for analog tool innovation in analog design.
Lastly, cost saving. You mentioned something abut cost saving. Let’s get to the point. PCell is a device layout generator. That’s what the users will send to the fab to be manufactured. You are saying that each vendor should supply its own PCells and let the fabs manufacture them. Taking the view of the foundries I definitely want to standardize on one PCell library and have everyone use the same device layout generator so that I can manage the quality of the mask. The risk and reward here is easily measureable from a foundry perspective. That reward will get passed on to the fab users which eventually are customers of the EDA industry.
Perhaps there is one thing that I don’t quite understand and you can shred some light on it is I repeatedly hear from Cadence personnel, latest being at the IPL Luncheon last week, that no Cadence customers have ever requested support for the iPDK. Are TSMC, Towerjazz, and ST Micro not your customers?
Like Daniel said, you can probably take me to a whole new level of openness if I can get all these mixed messages sorted out.
Michael Ma
VP of the IPL Alliance
Daniel,
Having done a little investigation of this for myself, I think I can help clarify with a few facts on the construction of PDKs and what makes them truly interoperable.
First off – PDK 101 – PDK is a pretty overloaded term, but there are typically two different meanings.
– iPDK-like – Everything you need to do custom or analog mixed signal design entry. From a foundry, you typically get a family of parameterized devices ranging from transistors, resistors, inductors, to more complex things like matched transistor pairs, etc. expressed via a linked set of
+ Schematic Symbols – for entering schematics and adjusting parameters
+ Parameterized cells (pcells) – that generate/regenerate layouts for the named devices based on input parameters.
+ Callbacks – that execute, evaluate and update when changes to parameters, schematic, and layout elements occur.
+ All three of these are linked via a CDF, kind of a canonical relationship for how parameters are linked between all three of these for various object types (ports, devices, etc.) within OpenAccess. Using a “standard CDF” across the industry is a necessary, but not sufficient condition for PDK interoperability between tools. More on this later.
– OpenPDK-like – is all the stuff a foundry needs to deliver to enable polygon level design and verification. This includes
+ iPDK stuff – mentioned above
+ DRC decks
+ LVS decks
+ Extraction decks
+ SPICE models for all the devices in the iPDK
+ etc.
So OpenPDK is in essence a superset of iPDK.
Unless you are TSMC (or LFoundry, or TowerJazz I guess) all this stuff today is delivered as a bunch of EDA vendor-specific and often proprietary files. If you are TSMC, you deliver it as a bunch of iXXX (iPDK, iDRC, etc.) files that all leading EDA tools have been compelled to read.
Now, to dial in on the iPDK-like flavor of PDKs. All the whining and table-thumping seems to center on which languages are supported in OpenAccess-based EDA tools for the two coded components of the PDK.
iPDK ideal TSMC iPDK OpenPDK Cadence
PCells python python any / python SKILL
Callbacks tcl tcl & SKILL any / tcl SKILL
TSMC has managed to make their iPDK work fully interoperably with a common python-based set of pCells, but was forced to offer a duplicate set of SKILL callbacks since Virtuoso has effectively blocked use of tcl for callbacks, something most people would regard as a product defect, but Cadence seems to arguably view as a product asset. BTW, based on my unscientific trials a pycell based layout seems to execute from 2 to 2.5 times faster than a corresponding SKILL pCell.
What OpenPDK seems to want to do is to offer a uber-language for capturing the intent of the pCells and callbacks, plus a translator that could generate various flavors of PDKs. To me, this seems to be a year or two out, but the existing iPDK has provided a valuable starting point.
David,
Thanks for the udpate. I’m really starting to understand the intricacies and motivations of iPDK and OpenPDK.
Hi Daniel,
Funny that you mentioned motivations.
For a standards collaboration to be successful you need motivated members. A lazer sharp and confined charter helps too. When I called the first IPL Alliance meeting in October 2006 our sole focus is to solve the PCell interoperability issue. It’s the keystone piece of the PDK that offers significant benefits to foundries, design teams, and EDA vendors alike.
Yes, I do work for an EDA company, Ciranova, that offers such a technology but it was no cake walk to get others behind it. Again, the key is in motivation. The initial group of cohorts are all motivated to establish an open innovation platform. By the way, I did send an invitation to you know who.
It took us 2.5 years from that day in 2006 to DAC 2009 for TSMC to announce a full blown, fully validated 65nm iPDK. Since then there are more foundry announcements on iPDK development projects. Thanks to everyone’s motivation we are making great strides and will only get better at it.
I do want to hear Cadence’s motivation on joining Si2’s OpenPDK Coalition.
Michael Ma
VP of the IPL Alliance
David Muncier is correct that the IPL iPDK spec does not in fact include a duplicate Skill PDK; it specifies duplicate callbacks, but a single PyCell which does indeed produce identical geometry across tools.
The larger issue is the one John Stabenow highlights in his comment about the objective of having a customer’s IP “tightly coupled with the application (and completely within the EDA vendor’s control).” Most IC designers don’t actually want their IP within an EDA vendor’s control. Creating semantic arguments otherwise calls to mind DEC’s Ken Olson’s infamous 1988 comment about Unix and snake oil. It turned out that – surprise! – engineers really did want interoperability. Well, they still want it.
The anti-interoperability, anti-open rhetoric, the infamous Cadence warning message (“WARNING DB-220704: the usage of non-SKILL PCells in Virtuoso is not a supported feature”) etc – this stuff is just dumb. Trying to lock customers into your tools by controlling their PDK IP will lead to the opposite: it manufactures a reason for your customers to look at alternatives, where they might not have had a reason before. And it casts doubt on your other IP initiatives as well.
Instead of fighting this movement, Cadence should be leading it. Virtuoso is a great tool, and iPDK’s and PyCells make it even more powerful, at a time when complex design rules and new mixed-signal architectures threaten to overwhelm existing design flows. Cadence should adopt the new foundation and build on top of it, in order to solve the new problems; this would unlock real value, and new Virtuoso business growth with it.
Eric Filseth
CEO, Ciranova
Someone pointed me to Cadence’s perspective on your website yesterday. I’m incredibly confused by the conflict between an open IP based EDA 360 and the analog group’s view, to quote:
“For those EDA vendors who believe that their customers are best serviced by a PDK whose IP is tightly coupled with the application (and completely within the EDA vendor’s control), they can look to OpenPDK as the standard.”
It’s pretty clear that any analog IP done in Cadence’s work is going to remain tightly locked to their tools, which runs absolutely counter to what John Bruggeman swore up and down would NOT be true of EDA 360. Seems like Cadence is pursuing two polar opposite strategies, but that wouldn’t the first time.