Home > Community > Blogs > Industry Insights > the case for skill pcells and pdks
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Industry Insights blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

The Case For SKILL PCells and PDKs

Comments(1)Filed under: Industry Insights, Si2, Analog, Custom IC, PDK, SKILL, PCells, Python, OpenPDK, Lisp, PDKs, custom, IPL

Controversy is continuing over the use of Cadence SKILL language PCells versus "interoperable" parameterized cells written in Python. What's getting lost in this discussion is an important question: What are the advantages of SKILL for process design kit (PDK) development and analog/custom IC design using the Cadence Virtuoso platform?

To get some answers, I talked to Ted Paone, customer engagement architect for PDK quality engineering at Cadence. It would be hard to find someone more knowledgeable about PDKs. Ted has over 30 years of experience developing device generators including PCells. He has worked on at least 8 programming languages and has developed four PDK development systems, and he prototyped netlist-driven layout for Calma in the early 1980s.

As noted in a recent blog posting, Ten Things You (Probably) Didn't Know About SKILL, we're not talking about a non-differentiating "format" here. SKILL is a full-function, LISP-based programming language that allows extensibility, supports object-oriented programming through SKILL++, and is widely used to customize Cadence Virtuoso tools. (It is also widely used within Cadence Allegro PCB tools, but there seems to be no controversy there).

Reason #1: Devices Can Be "Tool Smart"

Quick clarification: Ted notes that it's important to focus on devices, not just PCells. PDK device representations also include Component Description Format (CDF) data and callbacks, which were originally developed in SKILL, as well as schematics and symbols.

With SKILL-based PDK development, Ted noted, "you can easily tie into capabilities that are built into the [Virtuoso] design system through your PDK. You can enhance the editing capability or the data creation capability by having devices that are tool smart." For example, if a PDK is tightly linked to Virtuoso, the user can update simulation information quickly when dummy devices are added to the layout.

Reason #2: Object-Oriented Infrastructure Eases Device Development

SKILL is an extensible language, and Jim Newton of Cadence (source of the "ten things" post listed above) took advantage of that fact to build an object-oriented device development infrastructure on top of SKILL++. It's being rolled out now both within Cadence and to early external customers. Ted said the new capability helps "keep all the different pieces of a device in synch." He noted that adding a single PCell parameter may affect 5 or 6 different programs, and the new capability makes it possible to add parameters without having to modify each individual program.

Reason #3: You Can Enhance the Editing Experience

SKILL PCells make it possible to extend and enhance the editing experience, Ted said. For example, stretch handles and abutments -- since picked up by other providers -- were originally developed in SKILL. Virtuoso has a capability called "fluid objects" that makes it easier to edit objects inside a SKILL PCell.

Reason #4: If a Non-SKILL PCell Breaks, Who Do You Call?

If there's a problem with a SKILL PCell, Cadence can analyze it quickly. "If I have to deal with a foreign language PCell," Ted said, "the first thing I have to do is figure out where the problem is. Is it in the PCell, the PDK, the underlying code, or our system?" Responding to problems, he said, could involve "many levels of triage" with multiple providers.

Reason #5: The Dark Side of Interoperability

"Interoperability" is a good concept, but interoperable parameterized cells come with a cost. They are only interoperable if they support all the capabilities of a given toolset. For instance, if a toolset doesn't support fluid objects, the cells can't use that capability. The result, Ted said, is that "my PDK becomes the least common denominator of what everybody supports."

There is, however, a different kind of PDK interoperability effort that has drawn support from Cadence, Synopsys, and Mentor Graphics. It's the OpenPDK Coalition of the Silicon Integration Initiative (Si2), and I suspect the lack of controversy has limited the press coverage. As I wrote in an earlier blog, the idea is to create an open description format or database that foundries can populate. Translators then bring this data into existing data input formats, which could include SKILL or the Interoperable PDK Libraries (IPL) format. Meanwhile, Ted noted, a plug-in available through Si2 allows other vendors to read (but not change) SKILL PCells.

Even though it's over 20 years old, it appears that SKILL is as relevant and important as ever in the analog/custom IC design world.

Richard Goering



By Frank Wiedmann on October 14, 2010
For another round in this discussion, see "The case of the disappearing PCell" at www.eetimes.com/.../The-case-of-the-disappearing-PCell .

Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.