Copyright © 2006 Penton Media, Inc., All rights reserved.
Printing of this document is for personal use only.
Reprints

In the age of convergence, analog and full-custom design is reasserting itself as a crucial aspect of almost all system-level designs. While analog content is growing by leaps and bounds in most IC designs, productivity for analog designers is not.

In the early days of analog design, layouts for discrete devices on ICs were created by what is colloquially referred to as "polygon pushing." Devices were put together through juxtaposing rectangular shapes on metal layers (poly) separated by diffusion layers. Subsequent extraction processes would essentially define the devices. This manual process was tedious, slow, and quite error-prone.

The construction of a single transistor could comprise the creation of dozens of geometric shapes. If your design dictated the need for another transistor with similar, but not quite exactly the same, physical characteristics, you'd have to start all over again. Want to create more variants, each with ever-so-slightly different lengths and/or widths? Again, each one would need to start from a clean slate. As circuit complexity grew, this quickly snowballed into a showstopper.

WHAT'S A PCELL
Fortunately, along came the brilliant concept known as parameterized cells, or PCells. PCells aren't a new idea, going back some 20 years. Despite the fact that they weren't necessarily invented there, PCells were what put a young EDA company called Cadence Design Systems on the map.

PCells eliminate the drudgery and inherent risks of manually creating variant after variant of the same basic device. They're really nothing more than a program written in an extension language (more on that to come). That program is, in essence, a layer of abstraction on top of polygons. "With the PCell, you have captured the concept of a transistor with all of the geometries that are required for that transistor," says Anthony Gadient, Cadence's Custom IC product marketing group director.

PCells exist on three levels: the supermaster, the submasters, and instances (Fig. 1). Once you have created an original PCell, that specific set of geometries can be considered the supermaster. That supermaster resides in the design database and contains the definitions of all the parameters that apply to the PCell geometries (the basics are length, width, and so on) and their default values, as well as the program used to create it.

"In essence, the supermaster is an image of the program itself subjected to default parameters," says George Janac, CEO and founder of Silicon Navigator.

From that single supermaster, a designer can create what's known as a process design kit (PDK) for the device. The PDK contains the program, the PCell supermaster, Spice models, schematic symbols for the device, and design-rule checking rule decks, among other items. When editing a layout in a tool such as Cadence's Virtuoso layout editor, designers can create versions of that master with non-default parameter values.

These new altered versions of the supermaster are retained in virtual memory as submasters. When designers create a new instance, and a submaster with the same parameter values already exists in virtual memory, the new instance references the existing submaster cell. The software does not generate a new submaster.

This style of design is a boon to those who craft PCells and PDKs. Early in the PCell game, Cadence took the ball and ran with it, putting together a full-custom design infrastructure that remained largely unchallenged for many years.

The basis of Cadence's approach to PCells and their construction lies in its proprietary SKILL language. SKILL is an immensely powerful language that contains all of the functions one would need to construct a library of PCells and use them effectively in analog layout. Today, some 90% of all analog design is done using PCells, and the vast majority of that is with the SKILL language and with Cadence's Virtuoso design platform.

CLOSED CIRCUIT
For some, however, the proprietary nature of the SKILL language is a stumbling block. Because the language is closed, tools from other EDA vendors that might be useful in the design flow are unable to interpret the SKILL-based PCells. So for the most part, PCell users have been locked into the SKILL language and the Cadence flow.

"This means that any layout developed using PCells over the past 15 years or more means that that legacy is locked into a prison of Cadence's proprietary technology," says Kevin Steptoe, vice president of marketing and business development at Pulsic Ltd.

It's not just the issue of a locked language, either. PCells and PDKs created using SKILL and Virtuoso support only a given foundry process. "The real issue is at the interplay between the foundry, the EDA vendor, and the customer," says Dave Millman, vice president of marketing at Ciranova Inc.

PCell consumers want a greater range of interoperable process coverage from their PDKs, with kits able to span multiple foundries, processes, and EDA tool flows. "Today, the process coverage is focused on only one EDA vendor," says Duncan Widman, senior PDK engineer at Applied Wave Research (AWR).

For the foundries, the ability to migrate PDKs among processes is a huge issue. They continue to develop new process variants for low power and low leakage current. And some of those foundries' largest customers, the large integrated device manufacturers (IDMs), work with multiple foundries. In-house PDK developers who build and maintain the kits develop most of their PDKs internally.

"PDK resources are very scarce, and good PDK developers have handcuffs on, whether they're in foundries or at IDMs or at EDA vendors," Widman says. "You can't solve this problem with more resources, or by covering every node as we do it today. The industry has to come together on an easier way to solve it."

AN ANSWER APPEARS
Solving the problem of making PDKs and PCells interoperable among tools and flows is about more than the language with which the PCells are programmed. It's intimately tied into design databases and the ways in which information is passed among the tools themselves.

Historically, EDA vendors have relied upon proprietary (and incompatible) database formats and application programming interfaces (APIs), which has left limited latitude for sharing data between tools. Generally, the only recourse has been the GDSII format, a relatively clumsy and inefficient solution. There's also the issue of persistence in PCells, which ties into philosophical issues of who really owns layouts (see "Persistent PCells Click With OpenAccess" at www.electronicdesign.com, Drill Deeper 16027).

An industry initiative dating back to 1999 provided a way around this conundrum. What began then as the Silicon Integration Initiative's (Si2's) Design API Coalition, and later became the OpenAccess Initiative, sought a means of breaking down the barriers that prevented true interoperability. One of the prime movers behind OpenAccess was Cadence, whose donation of an open API specification and reference database paved the way for tools from multiple vendors to be able to seamlessly operate on design data from a common repository.

Flash-forward to April 2007, when five EDA vendors began collaboration on an open-source interoperable PCell library (IPL) that supports the OpenAccess database. The IPL Initiative's five founding members were AWR, Ciranova, Silicon Canvas, Silicon Navigator, and Synopsys. Magma Design Automation and Virage Logic have since joined the effort.

All of the EDA vendors in the IPL Initiative share a common goal, which is to leverage the OpenAccess database and API as well as their respective underlying tools and technologies to develop and demonstrate PCell interoperability (Fig. 2).

If the fledgling IPL Initiative was to build an opensource, interoperable PCell library, then its first order of business was to choose an open-source language with which to construct them. That language was Python, chosen for a number of technical advantages compared to both SKILL (which wasn't an option anyway) and other interpreted languages such as C++ and TCL.

"SKILL, at this point, is an old, slow, clunky language," says George Janac of Silicon Navigator. "It works, but it is a LISP language with all the pros and cons of LISP. So it's fairly data-structure poor. Its execution is better than TCL but nowhere near the speed of Python or C++."

One of the motivators behind choosing Python is that it's tied well to C++, enabling programmers to easily move their code between the two languages. There's also a large, growing open-source community supporting the language, which is seeing more extensive use in the scientific community.

"Python is a very stable platform and a very clean language," says AWR's Duncan Widman. "It's really well structured, and the object-oriented part of it makes it easy to define classes. On top of that, it's scripted so there's no need to create binaries for every platform. It's also easier to learn than C++."

There have been intermittent calls in recent months for Cadence to donate its SKILL language to a standards organization such as Si2. Doing so would obviate the need for an IPL Initiative at all. But doing so is unlikely on a number of grounds.

For one thing, the SKILL language's powerful user-interface constructs comprise some of the core technology behind Cadence's Virtuoso platform. For another, those who have called for Cadence to open the subset of the SKILL language that's directly related to PCell functions are out of luck as well. Those functions, unfortunately, do not stand alone but depend on other elements of the language.

Cadence points to the longevity of SKILL as an attribute rather than a drawback. "We are not against an ‘open' language," says Steve Lewis, marketing director for Cadence's Virtuoso Product Group. "Our framework and our Virtuoso platform supports not just SKILL, but also C++, TCL, and Python."

Built on top of the core Python language is Ciranova's PyCell API. This API has functions that make it easy to create geometric objects. These objects can be grouped and treated as a single larger object and then cloned, flipped, rotated, and manipulated as they would be in a layout editor.

With a language and API in place, the mechanism begins taking shape. Ciranova's PyCell Studio, a complete, standalone environment for creation of PyCells, is at the center of that mechanism. The product includes a powerful layout-generation API designed for OpenAccess; a graphical layout viewer with integrated DRC capability; and an advanced integrated development environment (IDE).

The IPL Initiative has already created a proof-of-concept, open-source PCell library as the first milestone in its collaboration. This library includes the OpenAccess PCell library object code with many standard and complex functions bound to a generic 130-nm process. It also includes the source code for the PCell library as well as a copy of PyCell Studio with a generic 130-nm technology file. All of these are freely downloadable from www.iplnow.com/download.php

It's also interesting to note that IPL Initiative members have tested the proof-of-concept library with Cadence Virtuoso 6.1.

With regard to legacy SKILL PCells, the IPL flow provides an answer as well. PCell Xtreme caches the layout of the SKILL PCell so any OpenAccess tool can access it. It also enables tools to instantiate (place or parameterize) a SKILL PCell by doing something very clever: It sends the parameterization request back to Virtuoso to allow SKILL to interpret it, then caches the result and presents that to the third-party tool.

Another element of the IPL mechanism comes from Silicon Navigator, whose RDE Framework provides a full GUI for viewing a variety of data such as netlists, schematics, layout, floor-plans, routing, congestion, design hierarchy, PCells, and critical timing paths. The RDE Framework is designed to be compatible with other OpenAccess-based tools. Silicon Navigator has worked with Cadence, Si2, Intel, Ciranova, and others to further the Si2 standard and ensure that an investment in using RDE Framework's infrastructure will last well into the next decade.

Whether the IPL Initiative's work will ultimately succeed is yet to be determined. Foundries still need to agree that the interoperable PCells at least equal the quality of the traditional variety. The IPL library has yet to meet foundry approvals and qualifications.

"That's our next step in IPL, getting the foundries involved," says Ed Lechner, director of product marketing at Synopsys. "At a first order, it's PCell developers that experience the pain of non-standardization. That's the CAD groups in the large IDMs and the fabless semiconductor houses. The foundries experience it, and EDA vendors do, because we have to create the kits ourselves for the foundries to endorse."

"End users don't directly benefit from this," Lechner points out. "That's why it's been such a challenge to get momentum going."

The IPL Initiative's members are banking on their collective resources resulting in a flow that's "much more rich than what Cadence is providing today," as Yatin Trivedi, director of product marketing at Magma, put it. "If competition is any indication of how the tools improve, in that case, even Cadence's tools will continue to improve. And even if Cadence continues to be the dominant player in the marketplace, all the users will benefit from this effort."