spectre data not saved for schematic pcell

I have a transistor wrapper pcell consisting of the following views:

- our symbol (pcell)
- our schematic with PDK's transistor instantiated inside, tied directly
to pins - just a transistor (using pPar's and form callbacks to sync
instance with parent data)
- our layout (pcell)

It simulates just fine; however, I am experiencing trouble plotting the
terminal currents. I get an error complaining that the data is not
available; however, I checked "Save all terminal currents". This works
for the PDK's pcells, but it does not work for mine...

Any guesses what I would be missing during the symbol or schematic
creation to enable plotting/saving of terminal current data?

 

I remember "long time ago" that the standard mosfet terminals have code that
works in
generating current. But when we customized them, we had to write special
hooks to
get the current on non-standard nodes ( Sorry I do not remember the cdf code
.... )

 

Trevor,
You need to have termMapping and termOrder properties set.
See what this returns,

cdfGetUserCellCDF(ddGetObj(<libName> <cellName>))->simInfo->spectre->??

You may cross check with analogLib to see what they have that your
custom elements do not have, since I am sure they work.

There is also a solution note in sourcelink on how to access internal
nodes in a subcircuit

Partha

 

I have opened up an SR with Sourcelink to get help on solving this. I
am hopeful for a solution, but it is a difficult problem I think. I
have since learned that termMapping is indeed the key to solving the
problem, but we are having trouble getting the syntax exactly correct.

Here's a rough diagram of my schematic hierarchy:

top level test bench schematic
/ | | | ... \
(instances of wrapper cell around PDK's nmos transistor) pins=(D G S B)
N0 N1 N2 N3 ... NX
| | | | |
(single instance of PDK's nmos transistor prim) pins=(D G S B)
N0 N0 N0 N0 ... N0
| | | | |
(SPECTRE model "inline subckt") pins=(d g s b)
modnm modnm modnm modnm modnm
| | | | ... |
(SPECTRE model - primitive of bsim3v3)
mosinsub mosinsub mosinsub mosinsub ... mosinsub


Hopefully this will explain my schematic hierarchy, but just for
clarity, here is the relevant snippet from the models definition file,
which is included in the spectre netlist:

....
inline subckt modnm ( d g s b )
parameters w=1.0e-6 l=1.0e-6 nrd=0.0 nrs=0.0 ad=0.0 as=0.0 pd=0.0 \
ps=0.0 ng=1
modnm ( d g s b ) mosinsub w=w l=l nrd=nrd nrs=nrs ad=ad as=as \
pd=pd ps=ps m=ng
model mosinsub bsim3v3 version=3.1 type=n ...


Anybody have any guesses as to the exact syntax for the termMapping
statement for this case? I have read the appendix in the CDF user guide
for accessing sub-circuit data, but I'm having trouble applying the
presented principles and examples to my exact case.

thanks!

Trevor

 

The solution had nothing to do with termMapping, at least in recent
versions of CADENCE. Instead, I needed to enable subcircuit data probe
level underneath the "Outputs" -> "Save All..." form. It should be set
to some integer value, indicating how many levels of hierarchy should be
saved. Setting it to 32 is good for all levels of hierarchy.

The following entry in my .cdsenv file set the value for all future
sessions:

spectre.outputs subcktprobelvl string "32"

 

Hi Trevor,

That is one solution, but I would be very wary of setting subcktprobelvl to
large numbers. What happens is that it ends up putting an "iprobe" in series
with every subckt pin - which is computationally very expensive - because it
makes the matrix a lot bigger - look at the increase in the number of equations
you get (2 for every iprobe) - which can slow the simulation down significantly,
and cause convergence difficulty - with PSS I've seen big memory increases
too. I had one customer have a PSS simulation which went from 27 hours down
to 30 minutes when getting rid of an unnecessary subcktprobelvl.

I'd have thought this would require either termMapping information - perhaps on
the underlying level, but most likely it might require things like the
opParamExprList and similar (it's not opParamExprList - but covered in the same
part of the documentation as that). This would allow expressions to be added to
find the terminal currents from a lower level of hierarchy. You'll be saving
them anyway, because the lower level of hierarchy has them saved if it's
a promitive device or an inline subckt.

Note I didn't read through very carefully your description of the situation due
to time constraints at the moment - but wanted to give you some thoughts as to
possible alternative solutions.

Regards,

Andrew.

 

I was afraid that it would add undue overhead to the simulation.

If you, or anybody else has other suggestions, using termMapping, etc. I
would greatly appreciate it, because extending the subcktprobelvl is all
that I have, which works.

I read up on the appendix, "Accessing subcircuit Data", but the material
is very sketchy. I think I am supposed to read a lot between the lines.
I tried several things (combinations of termMapping, FUNCTION, root,
.., \ statements...), but I could not figure out how to make it work. :-(

FYI, the underlying pcell seems to be setup correctly, because I am able
to plot terminal currents for these, just by doing a "Save all ...
device currents". The only problem occurs on my wrapper pcell, which I
described previously.

Thanks!

Trevor

 

Just for reference, here are the variations that I tried using
termMapping, which did not work:

cdf->simInfo->spectre = list(nil
'opParamExprList list(
list("betaeff" strcat("OP(root(\"" upperCase(chType) "0\")
\"betaeff\")"))
...
list("vth" strcat("OP(root(\"" upperCase(chType) "0\") \"vth\")"))
)
'modelParamExprList list(
list("vto" strcat("MP(root(\"" upperCase(chType) "0\") \"vto\")"))
...
list("eta" strcat("MP(root(\"" upperCase(chType) "0\") \"eta\")"))
)
'termOrder list("D" "G" "S" "B")
;; Attempt #0:
;; following line is for primitive - not my sub-circuit, wrapper cell
;; 'termMapping '(nil D \:d G \:g S \:s B \:b )

;; Attempt #1:
'termMapping '(nil D \:1 G \:2 S \:3 B \:4 )
;; Attempt #2:
'termMapping '(nil D ":1" G ":2" S ":3" B ":4" )
;; Attempt #3
'termMapping list(nil
'D strcat("FUNCTION(mappedRoot(\"." upperCase(chType) "0\"))")
'G strcat("FUNCTION(mappedRoot(\"." upperCase(chType) "0:G\"))")
'S strcat("FUNCTION(mappedRoot(\"." upperCase(chType) "0:S\"))")
'B strcat("FUNCTION(mappedRoot(\"." upperCase(chType) "0:B\"))")
)
;; Attempt #4 - same as #3, but with lowercase term names
'termMapping list(nil
'D strcat("FUNCTION(mappedRoot(\"." upperCase(chType) "0:d\"))")
'G strcat("FUNCTION(mappedRoot(\"." upperCase(chType) "0:g\"))")
'S strcat("FUNCTION(mappedRoot(\"." upperCase(chType) "0:s\"))")
'B strcat("FUNCTION(mappedRoot(\"." upperCase(chType) "0:b\"))")
)
;; Attempt #5 - try 'root' instead of 'mappedRoot', because I
;; don't understand the difference
'termMapping list(nil
'D strcat("FUNCTION(root(\"" upperCase(chType) "0\"))")
'G strcat("FUNCTION(root(\"" upperCase(chType) "0:G\"))")
'S strcat("FUNCTION(root(\"" upperCase(chType) "0:S\"))")
'B strcat("FUNCTION(root(\"" upperCase(chType) "0:B\"))")
)
;; Attempt #6 - same as #5, but with lowercase term names
'termMapping list(nil
'D strcat("FUNCTION(root(\"" upperCase(chType) "0:d\"))")
'G strcat("FUNCTION(root(\"" upperCase(chType) "0:g\"))")
'S strcat("FUNCTION(root(\"" upperCase(chType) "0:s\"))")
'B strcat("FUNCTION(root(\"" upperCase(chType) "0:b\"))")
)
)


FYI#1, "chType" evaluates to "n" or "p" depending on the channel type
being processed (I have a foreach loop around this code...) FYI#2, I
have other stuff included just for reference, so you can see where I am
already using similar techniques to access the child's op and model
parameters for label display.
FYI#3, I didn't try this all at once, but hopefully it will communicate
the different things I tried to get the termMapping correct.

In addition to trying all these things, and not being able to get any of
them to work, I found the following things to be confusing:

- What is the difference between 'root' and 'mappedRoot'? When should I
use each one?
- The CADENCE docs (doc/cdfuser/appB.html) say that the Attempt #1
should work, but they use #2 in an example near the bottom of the page;
however, neither work. What is the difference in the two formats? And,
when should I use each one?
- Also I do not understand the case issue. When do I use lowercase or
uppercase?
- When is specifying the _termOrder_ important? The examples in the
CADENCE doc that I cited were confusing... No explanation in the doc.

 

Trevor,

Last I adventured in this CDF annotation question, I had to experiment
a lot too. There are many PDKs around that don t get this right either,
and resort to the use of inline subcircuits. This makes the job much
easier especially in case of the many modelparameters. Bottom line is
that if you can find the data somewhere in the result browser, you
should be able to get it right. You can go faster if you work directly
on the siminfo of your instance, rather then modify and reload a CDF
dump (and then have to refresh or re-instance). You can try at first to
make it work with ad-hoc fixed strings that correspond to the instance
name, instead of the dedicated functions root() and such. And you can
try to instrument the code too (put printfs or global var assignments).
Also, there were differences between spectreS and spectre.

If I understood well, you are building an "encapsulating PDK" that can
handle any sub-PDK of specific technology. That would make retargetting
of an analog design much easier to automate. That would be a building
block for analog synthesis. It would be a big plus if the encapsulating
PDK plays nice with the neo products. I am curious. Please tell me (us)
more !