mapping properties to CDF parameters

Hello,
I have a weird problem which requires to have some CDF parameters
in a pCell with all letters in capital (it is important for them to be
in uppercase like WIDTH, LENGTH) but sometimes I need to attach
parameters in an instance of the pCell using dbCreateProp or
dbReplaceProp. The parameters are provided in lowercase (width,
length). So if I check the properties of the instance of the pCell I
get the parameters tab, which have the default CDF values and another
tab called properties which has the values I have attached.
I really need these properties to replace the values of the default
CDF parameters. I was wondering if there is a mapping list or
something similar in order to bypass this problem. I have checked that
if the names match exactly (Cadence is case sensitive) it works fine,
but unfortunately I need the CDF in upper and the parameters come
through a case insensitive application which lowers them.

Thank you

 

I think that the root of your problem is with the properties ...

When the pCell is created, the internal values are parameters.
The attached values are properties.

What it looks like you want is to have the default values of the paameters
set.
Note that when a pcell is created, you can code in default values.

I am confused by your comment that the parameter names are required in upper
case.

I think what you want is to modify the cdf output routine for your
netlister-of-choice.

It is somewhat straightfoward (if well hidden!) to create a custom netlister
routine
to print out "LENGTH = %g" with a parameter called length.

Note that some built in neltister routines do convert everything to lower
case.

YMMV

Gerry

 

Well I was not very clear in my last message
the situation is like this:
I have a custom netlister, which creates a netlist with the
parameters in capital (LENGTH) as they are provided by the CDF. This
netlist is passed through another application which modifies the
netlist and returns the parameters in lowercase (length). After that, I
have to read this modified netlist and modify the original cellview.
The problem is that the CDF parameters are in capital and they do not
match with the ones I have in the netlist. So when I attach the length
parameter of the netlist to the pcell, it does not replace the default
CDF parameter (LENGTH), but it just creates another one which lies in
the property section of the pcell.I cannot convert the strings to upper
case since some other pcells might not have the same naming conventions

So what I am asking is, if there is a way to map properties I am
getting from the modified netlist, to CDF parameters

 

Well, it's a case-sensitivity problem

you can loop through all the parameters and do a case-insensitive comparison in this way:
(suppose you have an instance inst)

cdf = cdfGetInstCDF(inst)
foreach( cdfParam cdf~>parameters
when( 0==strcmp(upperCase(cdfParam~>name) upperCase(myParamName))
; we have a match
dbReplaceProp( inst, cdfParam~>name, 'string, myParamValue )
) ; when
) ; foreach

hope this'll solve your problem.
cheers, stéphane

 

How do you "read" the netlist? Why do you need to modify the original
cellview?
( I assume you either want to modify your "GOLDEN" version OR you want to
modify your "TAPEOUT REFERENCE" version OR some other view. Or you only have
one schematic view and you constantly modify it (Yikes!)

??? Is the concern pcells in general, or a specific pcell?
If you "own" this pcell, you could carefully write a callback funtion that
would be
sensitive to the existance of one or both of "length" and "LENGTH" and you
could
have the behavior you require.

I recall that we had a situation on RESISTOR pcells where designers would
want to enter
Width and Value and expect the PCELL to compute the "LENGTH". They would
then create
the layout and get ready for TAPEOUT. Along would come a process file
update and they
would be mystified when (as soon as they touched anything to trigger the
callback) the PCELL
resistor would change in length. (they layout would now be wrong as the
resistor go resized!!!)

One way to "fix" this is to NEVER allow computed physical values to be
computed by callbacks
n PCELL/Layout views. (But a lot of users seem to irrationally fight this
feature!!!)

My idea was to create a property on a generic Resistor pcell that would
direct the computation of
the remaining parameters. But the callback would not modify input
parameters, but would create
secondary "computed" parameters. These would be compared to the input
parameters and warnings issued
when required.

i.e. Let is say we have a "POLY" resistor and for simplicity sake let us
ignore end effects for now.
Let us say POLY rho is 75.3 ohms/square and the user wants it to be 2u wide.
Let us also assume that
the layout input grid is .2u A callback could be written so that when the
user enters R=100 and w=2u
the length is computed to be ( from R = rho * l / w ) = 2.656... u.
This needs to be snapped to a legal grid --> A policy is needed to decide
whether to truncate, round, or roundup.
So the answer could be that computedWidth might = 2.6 OR 2.8. (Lets assume
we truncate and get 2.6u)
due to the input grid restriction. Now we can recompute R to be 97.89 ohms
.... so I would now store computedR to be 97.89ohms
and since the input w=2u is on the grid ... I compute computedR to be 2u. I
write my netlister to use the computed<value> 's as these
are "more real" .

Note that in my situation, only 2 of the 3 user input parameters can be
input. (in this case Length, Width, R)
When 1 is entered and the other 2 are unset, only it's computed complement
is created. When the second one is entered,
all 3 computed values are created. When the third value is entered, the user
gets an error and then must chose his
primary 2 input values and the other is stored in a tertiary target<value>
parameter.

So you end up with the values:
R=100
W=2.0e-6
L=<undefined>
computedR=97.89
computedW=2.0e-6
computedL=2.6

and possilby

targetL=2.6

Also the device has a few kinds of tolerance. The computed value may need to
be within 5% of the actual for a
typical resistor, but a sensitive one may need a 1% or smaller tolerance.
Clearly from the above example, we see that
with a 2u wide resistor that is targeting 100ohms we can only get to just
over 2% from 100ohms. Nothe that this is
the systematic error introduced by layout constraints. The process variation
of this resistor is totally independant from
this. (2.8ulength would give us 105.42ohms and >5% error!)

Target values are typically only used as markers for overconstrained
specifications.

Note that this device would be entered into in the scheamatic world! Once
this device is committed to layout, all of the
physical parameters really need to be "locked down". i.e. A designer would
be unhappy if a process file change that was
just before tapeout, caused the size of his physical cells to change. In the
case of the resistor, I would write code to force the
L & W to be set and the R to be moved to targetR and then set to <undefined>

Also I would carefully display only the computed values on the schematic by
default.

I have worked on a skill program for remapping properties/attributes that we
called tableRename().
It would take each symbol/instance and based on an input table / output map,
remap (or recreate) every required
cell, instance, property, and value to allow you to convert to almost any
conceived format.

-- G Vandevalk