Process technology independent pcells

Hi all,

I have been able to code some layout pcells recently. What I did is
create a library, attached it to CMOS180 tech file, and load the code
in.

However, if I tried to call these pcells in a CMOS130 library (where
the cds.lib does not include the CMOS180 libraries), the pcells
evaluation failed, giving the message that it could not find the
"poly" layer. I managed to circumvent this issue by creating another
pcell library and attaching it to the CMOS180 tech file.

My guess is that dbCreateRect or some of the rodCreateRect could not
find the appropriate layer definition.

I would like to seek advice on how I can create a process independent
layout pcells. Which section of the reference could I refer to?

Thanks!

Shu Teng

 

wolfpack wrote, on 01/11/09 05:43:

It's quite possible to write pcells that are technology independent. Normally
you need to have some properties somewhere (either as library properties, cell
properties, techFile params, or even just a SKILL data structure loaded in the
library's libInit.il) which defines the mapping of:

a) layer names
b) design rule information

It's a little hard to advise a good way of doing this without knowing how you
wrote your pcells in the first place, or how your technology files are set up.
But in general, the idea is that you try to avoid hard coding any specific
technology information in the pcell code itself, and always look that up from
some central data which can be shared amongst all the pcells.

Regards,

Andrew.

 

Shu Teng,

One way to write process-portable PCells is with PyCells. The
Interoperable PCell Library, at www.iplnow.com, is an open-source
PCell set containing a variety of basic and advanced devices, and
compatible with any OpenAccess tool. At Ciranova we have a variation
of this library running in over a dozen different process technologies
from quarter micron to sub-45nm, and we maintain all this with about
one and a half engineer-equivalents.

As Andrew points out, the principle is not to have process-specific
information in the PCell code itself. However, how you write your
PCells and set up your tech files covers a very large span of
territory. Building a general, scalable solution to this problem took
us tens of engineer-years.

If you’re doing it from scratch, one way to simplify the problem is to
limit your focus a couple of closely-related process nodes; 130 and
90nm for example. Also, advanced nodes introduce DFM-related
structures such as fixed pitches and conditional rules which require
more sophisticated methods than older geometries.

If you want to use PyCells, the development environment and API are a
free download from www.ciranova.com. There’s also a white paper,
“Using Ciranova Python API to Develop Process Portable PyCells,”
posted at http://www.ciranova.com/documents/process_portable_pycells.pdf.

Regards, Eric

 

Dear Shu Teng,

I used to develop technology independent Skill Pcells without any
problem.
As explained by Andrew, I was mainly having 3 skill files. A main
technology independent, using generic DRC rules/layers, skill file
that draws the whole geometry + technology dependent file that
contains the rules and layers for that particular technology + a 3rd
file that contains the rules and layers for that particular device.
The latter is handy for super-Pcells, like misbalance MOS
transistors ... etc. The whole lot works with a UNIX makefile that
would generate a final technology-dependent Pcell code upon the target
you have specified.

Making techno-independent Skill Pcells is something commonly used
indeed. Each company has it's specific flow for handling this though.
As said by Andrew, each foundry, PDK provider has it's own ways of
making techfiles and other files that might affect the final pcell-
making flow.

Best Regards,
Riad.

 

There is another system available from cadence called EPM which lets
you write
PCells in technology independent ways using object oriented
techniques however
technology independence only goes so far. things like layer mappings
and spacing
rules are quite easy to represent tech-independently. but different
technologies also
have very different selections of devices and often very different
toplogical
considerations.