Does anybody use foundry PDK for production chip design?

[DReynolds]

I am a consultant and I have been working with a client who is using a
foundry supplied process design kit (PDK) .... and we hav had our fair
share of ups and downs with tit. Because these kits are encrypted,
even small problems become amplified, if only because you can't go in
and fix the problem even if you know what to do. This leads me to my
question: does anyone use these foundry supplied PDKs for real
production work, or does everyone still make their own like in the
days before these kits existed?



David

 

[Edward J Kalenda]

On Sat, 22 Oct 2005 11:10:07 -0500,
david.reynolds@ieee-dot-org.no-spam.invalid (DReynolds) wrote:

I am a consultant and I have been working with a client who is using a
foundry supplied process design kit (PDK) .... and we hav had our fair
share of ups and downs with tit. Because these kits are encrypted,
even small problems become amplified, if only because you can't go in
and fix the problem even if you know what to do. This leads me to my
question: does anyone use these foundry supplied PDKs for real
production work, or does everyone still make their own like in the
days before these kits existed?

David

I have not been part of a production chip design in years, but as a EDA
tool developer I can say that most of the customer test cases I get are
based on PDKs. Even the customers who have their own fabs use PDKs built
by the fab group, not the designers. Including the encryption of rule
decks, PCells, and such.

They seem to be trying to avoid problems created by design groups
tweaking things and getting it wrong. I've heard of a few cases where
the design was sent to the fab after passing all DRC and LVS runs, only
to fail when the fab runs them again. The fab and the customer went
around and around pointing fingers at each other until it is discovered
that some bright person had cracked the PDK open and modified it.

The hiding of so much stuff does make fixing problems in the PDK a real
pain, as you have seen. Debugging tool problems is even worse, but you
learn to deal with it. But it means that even when I find a workaround,
they can't use it and have to wait for the code fix to get to them. Or a
PDK fix when the problem is discovered to be there and not in the code.

 

[Bernd Fischer]

As a small fabless semi we use our own PDK rather than the
foundry supplied ones.
The reasons are:
1.) Most of the time if a process is pretty new
the foundry still has no PDK available, so as a customer
you have to start building up your on.
And later on if the foundry can supply you with a PDK for this process
it's to late for you to switch to the foundries PDK because you might have
done some tapeouts already, also it's to difficult or even impossible
to merge your PDK and the foundries PDK because of to much differences
between them.
2.) If you want to do some customization which might be an extra device,
(with is possible in the process but not implemented in the standard foundry
PDK) or some specific command rules, advanced PCells etc.
this is more difficult to implement in the foundries PDK than in your own PDK.
This happens very often if you do analog design, based on my experience.

Nevertheless we done some design work and even tapeouts with foundry
supplied PDKs with different quality.
So the quality of the PDK is more or less the main criteria. But most of the
time you only figure out the real quality when your are at a point in your
design phase were there is no way back.
Quality validation can be, easy to use (plug in) in your existing flow,
correctness of simulation models, correctness of physical verification rules
and number and functionality of existing PCells etc..

But anyhow with your own PDK you always have to be on track to the foundries
process updates and changes. This might be depended on how good you'll get
informed form them.

My thoughts,

Bernd



DReynolds wrote:

I am a consultant and I have been working with a client who is using a
foundry supplied process design kit (PDK) .... and we hav had our fair
share of ups and downs with tit. Because these kits are encrypted,
even small problems become amplified, if only because you can't go in
and fix the problem even if you know what to do. This leads me to my
question: does anyone use these foundry supplied PDKs for real
production work, or does everyone still make their own like in the
days before these kits existed?



David

 

[Tim]

We use the foundry PDK for production design. Any modifications to the
PDK, for custom devices for example, is done by our internal EDA/R&D
departments with approval from the foundry.

For some of the complex Bicmos processes it is to time comsumming and
costly to develope your own PDK.

We have used our own PDKs but those were on Bipolar processes.

Tim

 

[Trevor Bowen]

As a tools/meth person, I typically do the following, when a customer
moves to a new PDK:

1) Hack/condense the initialization shell script to load the necessary
global variables, which enables the next step...
2) Setup the SKILL (.cdsinit) environment to first load their tools,
libraries, form data, etc - second, load our tools, pcell libraries, env
vars (.cdsenv), etc on top of the foundry's stuff
3) Tweak a process independent pcell library to work with the new pdk

Besides hacking the foundry's initial shell script, I never touch their
other stuff, because of the reasons already mentioned (although I do
play with some of the code that preloads forms). However, I do
encourage the use of our pcell library to maintain process portability.
Also, we have several helper tools that are context sensitive, which
we access through banner menus. These ride on top of the PDK, and they
are process independent.

Tweaking their DRC/LVS decks is simply too dangerous, IMHO.

What else could be tweaked?

DReynolds wrote:

I am a consultant and I have been working with a client who is using a
foundry supplied process design kit (PDK) .... and we hav had our fair
share of ups and downs with tit. Because these kits are encrypted,
even small problems become amplified, if only because you can't go in
and fix the problem even if you know what to do. This leads me to my
question: does anyone use these foundry supplied PDKs for real
production work, or does everyone still make their own like in the
days before these kits existed?



David

 

[Trevor Bowen]

All of the PDK's which we used have encrypted skill files, and their
functions are private. Sometimes they are even write-protected,
although it is still possible to redefine them, I have never figured out
a way to tweak the existing function to work around such "silliness".

fogh wrote:

Some CDF and callbacks are just too silly. For instance PDKs still bear
float fields where you can not use design variables.
I am grateful that most PDKs still have no password on the callbacks.

 

[fogh]

Trevor,
should I use your gmail box to answer ?

Trevor Bowen wrote:

All of the PDK's which we used have encrypted skill files, and their
functions are private. Sometimes they are even write-protected,
although it is still possible to redefine them, I have never figured out
a way to tweak the existing function to work around such "silliness".

fogh wrote:

Some CDF and callbacks are just too silly. For instance PDKs still
bear float fields where you can not use design variables.
I am grateful that most PDKs still have no password on the callbacks.

 

[Trevor Bowen]

Should work fine...

 

[fogh]

Trevor Bowen wrote:

As a tools/meth person, I typically do the following, when a customer
moves to a new PDK:

1) Hack/condense the initialization shell script to load the necessary
global variables, which enables the next step...
2) Setup the SKILL (.cdsinit) environment to first load their tools,
libraries, form data, etc - second, load our tools, pcell libraries, env
vars (.cdsenv), etc on top of the foundry's stuff
3) Tweak a process independent pcell library to work with the new pdk

Besides hacking the foundry's initial shell script, I never touch their
other stuff, because of the reasons already mentioned (although I do
play with some of the code that preloads forms). However, I do
encourage the use of our pcell library to maintain process portability.
Also, we have several helper tools that are context sensitive, which we
access through banner menus. These ride on top of the PDK, and they are
process independent.

Tweaking their DRC/LVS decks is simply too dangerous, IMHO.

What else could be tweaked?

Trevor,
Some CDF and callbacks are just too silly. For instance PDKs still
bear float fields where you can not use design variables.
I am grateful that most PDKs still have no password on the callbacks.

DReynolds wrote:

I am a consultant and I have been working with a client who is using a
foundry supplied process design kit (PDK) .... and we hav had our fair
share of ups and downs with tit. Because these kits are encrypted,
even small problems become amplified, if only because you can't go in
and fix the problem even if you know what to do. This leads me to my
question: does anyone use these foundry supplied PDKs for real
production work, or does everyone still make their own like in the
days before these kits existed?



David