SAN JOSE, Calif. -- A rivalry in EDA has turned into a possible feud. And one group is crying foul.
The Interoperable PDK Libraries (IPL) Alliance recently released its open standard for interoperable process design kits (iPDKs). It uses a p-cell library from Ciranova's PyCell Studio.
The technology competes against Cadence’s Virtuoso tools. The problem is that when end-users call up an iPDK at a customer site, a warning message automatically pops up. It reads as follows: “WARNING* (DB-220704): The usage of non-SKILL Pcells in Virtuoso is not a supported feature.”
The IPL group claims the culprit is Cadence. The IPL group is demanding that Cadence take down and remove the message.
''IPL Alliance member companies and their customers using iPDKs have reported that Cadence Virtuoso issues a warning message indicating that non-SKILL PCells are not supported,’’ according to a statement issued by the IPL Group .
''The warning message started to appear when Virtuoso IC6.1.3 was first released. We believe this to be misleading. Our members and their customers have rigorously tested and validated that all iPDKs work in Cadence Virtuoso 6.x. The Python PCells (PyCells) in iPDK use the same OpenAccess PCell plug-in mechanism used by Cadence SKILL PCells and are completely interoperable. PyCells work correctly and yield the same results in Virtuoso, Custom Designer, Titan, and Laker,’’ according to the IPL group.
Cadence declined to comment on the matter.
The IPL Alliance was started in 2007, with five founding members: AWR, Ciranova, SpringSoft, Silicon Navigator and Synopsys. Mentor Graphics and Pulsic joined as supporting members. The newest members are the following entities: TSMC, Helic, JEDAT, Magma, Micro Magic and Virage Logic. Recently, LFoundry, TowerJazz and others joined the group.
A PDK, as defined by the IPL, is a set of technologies to enable a complete analog and mixed-signal design flow. This consists of foundry-verified data files, such as schematic symbols, component descriptions, parameterized cells (p-cells) and callbacks.
Not all are on board with IPL, however. One EDA vendor, Cadence Systems Design Inc., refuses to join IPL and views the IPL-backed flow as a competitive threat to its analog EDA tool suite, dubbed Virtuoso. Cadence dominates the custom EDA landscape. Cadence's p-cell libraries are written in a rival and proprietary language called Skill, which is said to lock customers into Virtuoso.
IPL is attempting to break Cadence's monopoly in custom design, but the group has also tried to reach out and work with the EDA vendor.
iPDK is a nice effort and should mature as an alternative.
Every single product warns you about using a third party replacement part or accessory. It's a warning. If you really want to know what is an annoying warning, try putting a non-lenovo battery in a thinkpad.
I can't figure out how to use OpenPDK today. Unless my employer wants me to spend lots of membership money and time working on developing something for 2011 and beyond, there's nothing OpenPDK seems to offer. One of my EDA reps mentioned that something called OpenDFM 1.0 is coming soon from Si2, but that doesn't do anything for pcells and callbacks AFAIK. So EDA Guy, if you have dates and details, please tell.
Good point. Obviously, Cadence thinks it is a big deal, so they are fighting it tooth and nail. I have a real hard time understanding the logic as a long time digital guy.
As the Artisan Component logic library marketing manager 15 years ago, I have to convince Synopsys, Cadence, and Avant! to provide us tools to generate .lib, LEF/DEF, and FRAM views for our library offerings. The libraries are then vendor neutral. An important point here is that there is always just 1 GDS (physical layout) view. This means no matter what tool is used to place and route the design the final layout has the same GDS view of the library. That is what gets printed in the mask set and goes to manufacturing.
Currently, in the custom flow, each vendor has to use their own PDK. PDK contains PCells. PCell is a GDS (physical view) device generator. This means each layout tool will be creating layouts with their own GDS of the same device! It is a nightmare from the foundry perspective. You can see why TSMC and other manufacturers so wanted an iPDK solution.
Perhaps this is where the industry and Cadence differs. The IPL Alliance would like to solve this PDK development/support inefficiency and offer an interoperable platform for building a heterogeneous tool flow. Yes, we are collaborating at the DB/design kit layer and will compete for tool sales beyond that. This is the only way we can continue to offer value to our designer community.
One would think that if Cadence is confident about their tool capabilities and their dominant market share status then they would support the iPDK effort but I digress.
VP of the IPL Alliance
Glad that you are paying attention to the PyCell/IPL/OpenPDK efforts. You should have read and heard the alignment declarations between the IPL and OpenPDK groups.
The reason that the iPDK format is able to gain foot hold in the market so quickly (well, it took 2.5 years) is because we are so focused on a working solution. We are able to get several major foundries to test, validate, and adopt it. Again, no small feat that anyone single vendor can achieve. It's a group effort.
If you have done your research right you should have seen that the IPL Alliance has released a reference kit for the IPL 1.0 standard earlier this year and that the complete specification is available to everyone joining the alliance.
I am glad that Si2 is putting together the OpenPDK initiative to expand the standard beyond what the IPL 1.0 standard has achieved. The IPL 1.0 standard will be part of the OpenPDK initiative and also open to anyone willing to adopt.
I am also glad that Cadence has joined the OpenPDK initiative. As they have repeatedly refused to open SKILL in the past this might actually be a sign of change. The IPL Alliance is eager to support Si2's effort.
VP of the IPL Alliance
So Cadence is still holding out on this, the sooner these parties put their heads and hearts together the better for the community.
How much $$ does Cadence think it is earning by maintaining this exclusivity?
I agree with you - PYCELLS and the IPL approach do an excellent job duplicating and exceeding most capabilities of pcells in the proprietary SKILL language. That's what makes them so attractive to analog designers who want a little choice in which tools and foundries I use. I find a number of points in your critique to be disingenuous, or specious and just plain ignorant.
- People wouldn't find it necessary to duplicate pcell capabilities in OpenAccess if those capabilities were not locked to a proprietary, single supplier language, SKILL. A couple of digital guys at my company say this sounds like the Cadence 'e' / SystemVerilog story all over again, but I don't have any history about what happened there. I do know that the only thing our guys do is SystemVerilog now because it works with tools from everybody.
- The IPL and PYCELLS approach isn't tied to any foundries, only to 2 non-proprietary languages, TCL and Python. Based on the IPL kit and PYCELLS free downloads I've created a number of devices that are not tied to any foundry or any EDA tool. My only annoyance is that Cadence sees fit to disable some TCL capabilities of OpenAccess and feign lack of support for Python capabilities in OpenAccess in Virtuoso, per the recently introduced message.
- The Si2 approach seems relevant if something were actually ready today. Looking at the information you are pointing to, I can't tell when something similarly useful will be available. When will a sample kit be ready ?
My conclusion - Actually try what's offered by PYCELLS/PYCELL Studio and by IPL today. You'll get something far more modern and interoperable than the tangled web of legacy hacks called SKILL.
Very interesting article. I decided to do some research on the topic at hand. Following are my findings/conclusions
1. All this interoperability would not have been possible without the advent of Open Access database. Interestingly, this crucial piece was developed and then opened through si2 by the market leader in the field - Cadence!!
2. Pycells themselves only duplicate functionality available in SKILL Pcells. I am told that some of the good things about Pycells (nice development/ debug environment etc) has been implemented for SKILL Pcells by Cadence in their recent releases. These are in any case only relavant to PCELL developers (typ foundries) and not the majority of end users.
3. The IPL approach makes the customer beholden to the foundry!! What is really required and invaluable is a PDK standard that is both eda vendor and foundry independent.
4. I looked and found another industry alliance; OpenPDK. This is under the auspicious of Si2 and interestingly every major eda vendor including Cadence is part of it. There are also big semiconductor companies like IBM, Intel as well. The only one missing is TSMC.
5. My conclusion: what the semiconductor user base should cheer for is OpenPDK alliance under Si2 and not IPL.
Per reader A. Thomas' question above regarding press releases:
The first press release I'm aware of regarding production tapeouts using this technology was about a year ago (discussed Silicon Clocks, now part of Silicon Labs):
An early press release regarding interoperability in a production IC design environment was also about a year ago (discussed AMD):
As of this moment I know at least 3 top-10 semiconductor companies actively using PyCells in production, including tapeouts; as well as many other companies. Excellent scalability to nanometer design and DFM rules is another reason companies adopt this technology.
I'm sure Cadence is aware of all this, and frankly we don't meet many end users who believe productivity and openness are bad. Our dream is that Cadence will one day decide to turn around and actually help lead this initiative, which would benefit everybody including Cadence.
As for our financing, Mr. Thomas is indeed correct that Synopsys is an investor in Ciranova, as are Mentor Graphics, three silicon valley VC's, and also Jim Solomon, founder of Cadence.
Every tool generates messages that can be safely ignored. After some time with a tool, you learn which messages to disregard.
Ask your experienced Virtuoso users. After seeing this warning, do they stop work because they think that nothing will go right? For additional confirmation, ask your foundry what they think.
Just add DB-220704 to that list of messages you ignore, and get on with your design.
The person at Cadence who invented this message deserves special recognition. You're driving all your competitors crazy with just a single line of code. Dude, you're a genius.
All good comments and good food for thoughts. As a founder of the IPL Alliance and the bus dev guy at Ciranova, I can tell you that Synopsys alone cannot convince TSMC, Towerjazz, LFoundry, ST and many more to adopt an "Interoperable" PDK solution. Likewise, Ciranova won't be able to do that either. Given we understand that life before iPDK is "closed" and vendor specific, the stakeholders in the industry knows how valuable an iPDK can be. It is this common vision that drives the industry to the iPDK format.
Libraries in the digital flow are all vendor neutral and best of breed tool flows are the norm. That's tremendous value for the design eco system. It is about time that the analog flow grows up if it were to keep pace.
OpenAccess gives us an interoperable DB and PyCell gives us an interoperable device generation solution. We can debate whether PyCell is viable, validated, taped out and what not but no one can deny that iPDK is the future. The fact that the aforementioned silicon manufacturers are able to adopt PyCell/iPDK format suggested certain level of success.
VP of the IPL Alliance
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.