Schematic porting

Is there an easy solution to port schematics from one PDK Library to
another (same technology , different foundry)?
A simple Library copy and rename reference library does not work
because the primitives do not have same names. Also the CDF parameters
for the primitives do not match.
Any help would be greatly appreciated.
Thanks,
Hrishikesh

 

Hrishikesh, if all your components have a 1 to one mapping in the new
library then a simple skill program is all that is needed. As long as
you know how to calculate the new parameters from the old,you can take
care of that as well in the code. If they don't map simply, then life
is more difficult: if you are lucky then there will only be a couple of
instances of the unusual primitives and you can just modify them by
hand...

David

 

hi Hrishikesh, VCAD (services group within cadence) has an extensive
flow for doing just that. converting designs between pdks. the flow
includes characterizing the two pdks, converting with respect to cell
name changes, symbol size changes, terminal adjustment or renaming, cdf
name, value, type, default changes and callback triggering.

If you'd like to find out more, please contact jens at cadence dot com
or manfred at cadence dot com and ask them about VSCH.

good luck to you in any case.

 

by the way the flow includes conversion from cadence to cadence pdks as
well as mentor to cadence pdks which is quite a bit more difficult but
quite interesting i must admit.

 

So it sounds to me like you need to decide if this is something you
will do often and between very different technologies and vendors or if
this is more of a one time thing where you are just going from say .18
to 90nm in the same foundry so hopefully the complicated stuff like
resizing symbols can be ignored.



David

 

Thanks a lot Anderson,
Yes, this is what I am doing! I am through with the first 3 steps you
have mentioned and am having some issues/problems with the fourth.
For step 4 , I am planning to use the inherent cdf callback associated
with each parameter. This seems to work , but I am not able to repeat
the same behaviour consistently. Can you elaborate a bit on how you
went about step 4?
Thanks once again,
Hrishikesh

 

I am trying to make it as generic as possible .
Currently I am not having problems with symbols, but I will like to
keep this in mind while coding.
Thanks a lot,
Hrishikesh

 

If you are porting the entire library from one process to another, why
do you need to worry about callbacks? Aren't these already defined in
the primitives in the new process, so all you should have to do is
calculate the new values....

example :
old nmos width was w and was stuffed with total width of device
new nmos width is wf and is just width of finger

callback should already exist on nmos for wf..... what am I missing?

David

 

When the parameter values are replaced through skill code , the
callbacks (CDF callbacks to be precise) are not executed. Also some of
the parameters might be calculated through this callback mechanism
(AD/AS/PD/PS for e.g.) and would not be updated, hence the porting
would not be accurate. The callbacks do exist , but they have to be
called/executed/triggered through the code .

Hrishikesh

 

Thank you for reminding me... I had forgotten about this detail. How
about something like:
foreach(inst primInstances
cdf =cdfGetInstCDF(inst)
cdfgData =cdf
evalstring(cdf->w->callback)
)

so you make a list of primitives that you know you need to trigger the
callback on then get cdf, and eval a prop that has uses the callback

David


David

 

This is what I am doing. But this is not recommeded, also I am not
getting consistent results with this approach. I would like to know if
there is a better solution to this issue or an altogether different
mechanism for callback ????
Hrishikesh

 

This is what I did.

;;To capture old properties of interest. I use a case statement to
sort through the instances. I broke up these functions based
;; on device type. Below is excerpts of my function for fets.
foreach(prop cdfGetInstCDF(inst)~>parameters
propName=prop~>name
case( propName
("wf" wf=prop~>value)
("lf" l=prop~>value)
("m" m=prop~>value)
("nf" fingers=prop~>value)
) ; end case propName
) ; end foreach prop

;;Then I swap out old instance and put in the new. I one point I just
did a replace, but all the old properties from the
;; old symbol showed up on the new one. Makes it pretty cluttered.
Also, if the symbols share the same property
;; names, the values will come over - even if the CDFprop is supposed
to be read only. This also assumes that the
;; pins are all in the same locations/orgins are the same.
;; below is one line from my case statement
('nfet dbDeleteObject(inst)
newInst=schCreateInst(objId dbOpenCellView("newLibrary"
"nfet" "symbol") name xcord:ycord orient)
)

;; To update values. Since the pdk already has the callbacks, I did
not want to re-write them. Plus I wanted to make sure
;; that the properties stayed within valid model limits. So to take
advantage of them
;; I did the following. I set the value first to a value that is less
likely to occur to trigger the callback, and then reset it
;; to the real value - so the change of value triggers the callback.
Though it uses the form so this code is a bit slower.
geDeselectAllFig(objId)
geSelectFig(newInst)
schHiObjectProperty()
schObjPropForm->wf->value="2.01u"
schObjPropForm->wf->value=wf
schObjPropForm->lf->value="501n"
schObjPropForm->lf->value=l
schObjPropForm->nf->value="23"
schObjPropForm->nf->value=fingers
schObjPropForm->m->value="23"
schObjPropForm->m->value=m
hiFormApply(schObjPropForm)
hiFormCancel(schObjPropForm)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

I also put in some basic checks for w and l to make sure they were in
range. Example, if the w from the old pdk
is too small for the new pdk, the callback would reset the value to the
min value for the new pdk, and I would add
text over the symbol alerting the designer that the value had to
change.

Tamara

I