pcell devices wont re-size

I am trying to create a pCell that will instantiates devices from the
PDK. I have the cell together
but the devices wont resize, cant change the parameters. Solution ID:
11178170 on sourceLink
states that this problem can happen if there is a datatype mismatch
which there is.

The dataTypes of the devices in the PDK has its parameters set as
floats. But the code wants strings.
I had this working on a different PDK where both were strings and it
works but when migrating the
code to a different PDK, it not longer works. I tried changing it to
strings but it then no longer compiles.

Here is the error:

e *Error* dbCreateParamInst: Invalid float - "1.00u"
\e *Error* load: error while loading file - "./pCells/mypart.il"

pCell source code:

dbCreateParamInst(cv tranId
"ntranr" 0:0 "MY" 1 list(
list("w" "string" sprintf(nil "%.2fu" nw))
list("l" "string" sprintf(nil "%.2fu" nl))
list("fingers" "string" sprintf(nil "%d" nf))

pcDefinePCell(
list(ddGetObj("rickPcell") "mypart" "layout")
(
(nw float 1.0)
(nl float 0.13)
(nf int 1)
(pw float 1.0)
(pl float 0.13)
(pf int 1)
)
InstantMyPart(pcCellView nw nl nf pw pl pf)


---------------------------------------------------------------------------------------------------------
parameter dump of the device

\i cv=dbOpenCellView("tsmc13rf" "nmos1v" "layout")
\t db:375117868
\i cv~>parameters~>value~>name
\t ("tapCntRows" "tapExtension" "rightTap" "leftTap" "bottomTap"
\t "topTap" "tap" "rightAbut" "leftAbut" "sdMtlWidth"
\t "mtlCvg" "switchSD" "connectSD" "minGateMetal" "connectGates"
\t "fingers" "l" "fw" "dnwell"

\i cv~>parameters~>value~>valueType
\t ("int" "string" "boolean" "boolean" "boolean"
\t "boolean" "string" "int" "int" "float"
\t "string" "boolean" "string" "boolean" "string"
\t "float" "float" "float" "boolean"

I cant change the PDK so what is correct method of instantiating a
device with type float?

 

When you "migrate to a different PDK", could you elaborate how exactly
are you doing it?
If the PDK is between 2 different companies (or even two different
technologies of the same foundry), the codes written may be processing
the input data in different ways.

e.g. 1
pcDefinePCell(
list(ddGetObj("tech013") "myDevice" "layout")
(
(l float 0.13)
(w int 1)
)
deviceCode_013(l w)
) ;pcDefinePCell

e.g. 2
pcDefinePCell(
list(ddGetObj("tech013LP") "myDevice" "layout")
(
(l "0.13u")
(w "1")
)
deviceCode_013LP(l w)
) ;pcDefinePCell

Compare the pcell definitions in these 2 examples - e.g. 1 has to
accept a floating type & integer type value while e.g. 2 has to accept
string type for both values.
Moreover, there is also a potential difference in magnitude (parameter
"l" uses value 0.13 for one while the other 0.13u or 0.13e-6).
How might this come about?
Perhaps one vendor created pcell codes for the foundry's 130um
library, while another vendor created the pcell codes for the same
foundry's low power library - so, the codes inside functions
deviceCode_013() & deviceCode_013LP() can be very different in nature.

Perhaps instead of using 1.00u, you might have to use the 1.00e-6
value, since function cdfParseFloatString() which normally converts
string "1.00u" to 1.00e-6 floating value, maybe is not used by one of
the codes - then again, it might be something else.

Best regards,
I-FAB

 

The PDK's are 2 different technologies and fabs. Ive changed the
device library, name are parameters
to match the names in the PDK. The code does compile with only one
syntax:

dbCreateParamInst(cv tranId
"ntranr" 0:0 "MY" 1 list(
list("fw" "string" sprintf(nil "%.2fu" nw))
list("l" "string" sprintf(nil "%.2fu" nl))
list("fingers" "string" sprintf(nil "%d" nf))
;; list("rightCnt" "string" "series")
)
)
;; close the transistor reference
dbClose(tranId)

Anything else and it fails. It looks more like the code is correct
but the callbacks are not getting fired off to
re-evaluate the device.

 

Im pretty certain that the code is correct and the devices are not
being re-evaluated. This is a pcell that instantiates
pcells . If I open the compiled cell, and force the callbacks with
the CCSinvokeCdfCallbacks.il routine on sourceLink,
it will resize. But if this cell is instantiated, then it builds
with the defaults in the CDF's. I need a way to evaluate the
pcells that are down a level in hierarchy.

top pcell
mos devices from the PDK <--these guys are using the default
values and not resizing.

 

rick wrote, on 05/18/10 23:34:

Rick,

Instantiating a device which requires CDF callbacks to be evaluated, inside a
pcell, is always a bit of a challenge.

Something like this should do the trick:

baseCDF=cdfGetBaseCellCDF(ddGetObj(sourcePDKlib sourcePDKcell))
cdf=CCScreateEffectiveCDFLookalike(baseCDF t)
cdf~>fw~>value=sprintf(nil "%.2fu" nw)
cdf~>l~>value=sprintf(nil "%.2fu" nl)
cdf~>fingers~>value=sprintf(nil "%.2fu" nf)
; cdf~>rightCnt~>value="series"
; only give the ?order if you can rely on just invoking one callback.
; doing this can make it faster if calling a single CDF callback
; is sufficient
CCSinvokeObjCdfCallbacks(cdf ?order '("fw"))
pcellParams=CCSconvertCdfToPcellParams(cdf)
dbCreateParamInst(cv tranId
"ntranr" 0:0 "MY" 1 pcellParams
)
dbClose(tranId)

This has the effect of calling the CDF callbacks prior to placement of the
instance, which avoids generating unnecessary variants if you tried to call the
callbacks after initial placement.

Note that this is only a viable option of the CDF callbacks are "pcell-safe"
(i.e. they only use SKILL functions which are legal in a pcell).

Best still is to have a PDK which avoids CDF callbacks to compute derived
values. Unfortunately these are few and far between (see my Cadence Online
Support solution, "The Dangers of CDF Callbacks").

Regards,

Andrew.

 

I have been able to get the devices resized by using the code in
solution# 11018344
but now there are 2 issues that Im not sure how to fix.

1) When compiling I get a bunch of white markers and this error
message :

\e *Error* tsmc13pas_mosUpdateMtlCvg: argument #1 should be any
user-defined (other) type (type template = "oo") - CCSeffCDF@0xf257158

2) Assura LVS passes on the newly created cell, however when I run
this cell as an instantiated
instance, then Assura DRC runs, LVS and GDS-out does not, LVS stops
with:

*WARNING* ("eval" 0 t nil ("*Error* eval: undefined function"
CCSdrawNand))
Reading the design data...
*ERROR* Incomplete layout. If you still want to continue run,
complete the layout or set '?errorOnMissingMaster nil'
Note that default value of parameter '?errorOnMissingMaster'
is 't' .
*WARNING* Error while building the VDB

Im pretty sure that this is a PDK issue when it uses the code version
to run a cell or something????
Do I need to add something to have the smarts of this cell to be
written into the property bag of
the library?

Thanks!!!!

 

rick wrote, on 05/24/10 15:35:

Hi Rick,

The challenge is that the CDF callbacks in this case have been written to
type-check their arguments, and insist that they get passed a true CDF object.

Unfortunately that means you cannot use the CCScreateEffectiveCDFLookalike()
function approach.

Instead, you have to place the instance as you were originally:

inst=dbCreateParamInst(cv tranId
"ntranr" 0:0 "MY" 1 list(
list("fw" "string" sprintf(nil "%.2fu" nw))
list("l" "string" sprintf(nil "%.2fu" nl))
list("fingers" "string" sprintf(nil "%d" nf))
;; list("rightCnt" "string" "series")
)
)

And then:

CCSinvokeInstCdfCallbacks(inst ?order '("fw") ?useInstCDF t)

Again, you might not want to use ?order (but with TSMC PDKs, generally you want
to call the callback only once). This is not as fast as running the callbacks
prior to initial placement, but if you have the callbacks doing type-checking,
you don't have much choice (except maybe with a smarter CCSinvokeCdfCallbacks
implementation which truly emulates the effective CDF).

The issue with CCSdrawNand - I'm assuming that you are using this CCSdrawNand
function somewhere? You would normally need to ensure that this function is
loaded - usually from the libInit.il file within the library containing the
pcell which uses the function. Same for CCSinvokeCdfCallbacks.il - it would need
loading from a libInit.il if it's used within that library.

Regards,

Andrew.

 

Hi Andrew - The white errors are gone!!....THANKS!!!! Please let me
know if I used the correct implementation.
I have 4 instantiations of the tsmc devices so here is a snipet of 2:


tranId = dbOpenCellViewByType("tsmc13rf" "nmos1v" "layout")
instNTL=dbCreateParamInst(cv tranId
"ntranl" 0:0 "MX" 1 list(
list("fw" "string" sprintf(nil "%.2fu" w_n_b))
list("l" "string" sprintf(nil "%.2fu" l_n_b))
list("fingers" "string" sprintf(nil "%d" f_n_b))
)
)
instNTR=dbCreateParamInst(cv tranId
"ntranr" 0:0 "R180" 1 list(
list("fw" "string" sprintf(nil "%.2fu" w_n_a))
list("l" "string" sprintf(nil "%.2fu" l_n_a))
list("fingers" "string" sprintf(nil "%d" f_n_a))
)
)
;; close the transistor reference
dbClose(tranId)

........other code, then I called each one:

CCSinvokeInstCdfCallbacks(instPTL ?order '("fw") ?useInstCDF t ?
callInitProc t)
CCSinvokeInstCdfCallbacks(instNTL ?order '("fw") ?useInstCDF t ?
callInitProc t)
CCSinvokeInstCdfCallbacks(instPTL ?order '("l") ?useInstCDF t ?
callInitProc t)
CCSinvokeInstCdfCallbacks(instPTL ?order '("fingers") ?useInstCDF t ?
callInitProc t)

and it did compile error free and even still works!!!! Assura is
still not happy.

*WARNING* ("eval" 0 t nil ("*Error* eval: undefined function"
CCSdrawNand))
*WARNING* Error kept in "errorDesc" property of the label
"pcellEvalFailed" on layer/purpose "marker/error" in the submaster.

Reading the design data...
*ERROR* Incomplete layout. If you still want to continue run,
complete the layout or set '?errorOnMissingMaster nil'
Note that default value of parameter '?errorOnMissingMaster'
is 't' .
*WARNING* Error while building the VDB

If I run the cell that the code created, it runs and passes. If
instantiated, then DRC runs and LVS does not, gives me the errors
above. CCSdrawNand is the the name of the procedure that creates the
cell. I am unable to locate the any error. BTW, if I
turn off fail on error in Assura, then the instantiated cell will run
but fails to compare with a empty layout netlest

Thanks for your help!!!!

Rick

 

I created a libInit.il and Assura runs but GDS-out does not but i
probably needs something simular. BTW is there a way
to alias or have different names appear on the edit parameters form?
I currently have the "name" and would prefer to
have the "prompt"

Thanks

 

rick wrote, on 05/24/10 22:06:

You shouldn't need to call CCSinvokeInstCdfCallbacks several times for each
component. You should just be able to do:

CCSinvokeInstCdfCallbacks(instPTL ?order '("fw" "l" "fingers") ?useInstCDF t)

In fact it's quite likely that calling it with just "fw" would be sufficient
(with TSMC PDKs, all calculations are usually done triggered by a change in any
parameter).

The CCSdrawNand must simply be because the code is not loaded in a background
session, which should be a matter of ensuring it's loaded in the libInit.il of
the correct library.

Just turning off the fail on error in Assura is never going to work in this
case. If the function is being called in your pcell, then if it gives this
error, the pcell will not be being built properly, and hence the layout that is
being verified will be wrong (presumably the nand being drawn will be missing!).

Regards,

Andrew.

 

rick wrote, on 05/24/10 23:52:

The libInit.il should get loaded by both Assura and Steam out. Perhaps you
should put some debug print messages in your libInit.il so you can observe
whether it is being loaded.

As for getting different names on the edit parameters form - you need to create
CDF for the cell in question; that allows you to define the prompt, type, and so
on for each parameter.

With no CDF, the edit properties form shows just the pcell parameter names,
because it has no additional information to show anything more.

Regards,

Andrew.