spectremdl and measuring in ac

Hi,

I am having a bit trouble with an ac simulation on an NMOS transistor.

ac1 ac param=vgs freq=100k start=-0.5 stop=1.0 step=0.05
ac1Info info what=all where=rawfile

In the mdl file I now specify my measurement as:
alias measurement cvmeas {
export real cv = im(NMOS:d)
run ac1
}

But I get an error message telling me that
Error found by spectre.
NMOS: Undefined parameter name `d'.
line `6': MDL expression for identifier 'cv' can not be evaluated
due to previous
errors.

When I use the result browser in wavescan I can see that there is a
variable called NMOS:d in the cvsmeas-foreach folder and the calculator
function im(NMOS:d) give me a result that I can use. I run wavescan in
mdl mode.

I also have a
save NMOS:all
in my spectre netlist.

I wonder what I am missing here....

 

Svenn,

Without knowing your exact netlist, it is difficult to give you an
answer.

However, if you are after a node voltage, then your MDL syntax should
be:
im(V(NMOS:d))

If you are after a terminal current then:
im(I(NMOS:d))

Hope this helps,
-scott

 

As an aside, it is not necessary to save the signals you are interested
in to the
raw data file.

SpectreMDL works with the simulator and has access to all the internal
signals
in Spectre.

-scott

 

This is what I want, and spectremdl reports
Error found by spectre.
line `6': Unable to validate access function 'I( NMOS:d )' with
specified parameters
line `6': Operand 'I' of function 'im' has not been bound.
line 6: The function 'im' contains no arguments
line `6': Operand 'im' of function '/' has not been bound.
line 6: The function '/' contains no arguments

And this also happens if I change I with V.

 

Ok, that sounds reasonable. I save all the signals to the raw data in
order to be able to inspect them with wavescan during the debugging of
the script.

 

Svenn,

Is "NMOS" a valid instance in your netlist?
Not a model, but an instance of a NMOS.

-scott

 

Hi Scott,
yes, NMOS is the instance name and nch is the model name. I am making a
script that iterates over several models of N- and PMOS models and
simulate them. I should maybe have called it DUT instead.

 

Sometimes it pays off to read the manuals carefully to the end or to
use less as a pager (spectre -h bsim3 |less) to be able to just jump to
the end and read backwards on all the nice parameters that the bsim3
model includes. Not that that would not hide the embarrasing fact that
it should have been NMOS:ids instead of NMOS:d.

 

I realize that the manuals on spectremdl are pretty thin. There are a
lot of words, of course, but info on how to do ac and measurements are
very sparse. I looked through the new tutorial in mmsim 6.1 only to
find that dc and tran simulations are quite often used.

I hoped that I could do a workaround by doing all the simulations with
spectre and then script the wavescan calculator in order to have that
one dump some tabular data to disk, but it seems that there is no such
feature as "load script" in wavescan. I guess that I can load any skill
script, but I was trying to do something _easy_ here and not start off
with a 5000+ function functional programming language that nobody but
cadence use.

You bet I am frustrated right now.

 

And I managed to solve it.
Since I couldn't find a complete example on an AC simulation, I typed
one myself. I didn't pay notice to the fact that I used the access
function _before_ I had run the simulation.

run ac1
export cv = im(DUT:d)

makes a big change.

 

How does one do this, ie. prevent the writing of the tran rawfile? If
I have saveOptions options save=selected in my input.scs, then I get a
..tran file with just the selected signals. If I comment out this
saveOptions line, then the .tran file is huge. I'd really like no
..tran file at all, to save disk space on large simulations.

Thanks.

 

Rachel,

Use:

saveOptions options save=none

This is a recent enhancement that will reduce your rawfile size.

-scott

 

I think I read in the manual that spectre save one random signal even
if all saving has been turned off. Maybe this has been improved, but I
don't think so as I see this behaviour with the latest version of MMSIM
spectre.

It is indeed very difficult to get an overview over how to use
spectremdl as the info is spread across at least two manuals and a
tutorial.

Because of a limitation in mdl I have been working with wavescan in
skill mode for some days. This version of wavescan (IC6.1) carry a
full-blown skill CIW with access to all functions. My experience so far
is that I have full access to the results from a stand-alone spectremdl
runs via ocean in wavescan CIW. With a bit of skill code I can iterate
over all my simulations and extract all the data I need as the
measurements defined in spectremdl are saved as also saved as
waveforms.

I find the skill interpreter in IC6.1 a lightyear better than the one I
experienced in IC5.1 For those who have been playing with Tcl and know
TkCon, this is basically the way the new CIW works. You can go back in
history and change code and reinterpret it, the famous unix command
line history command ! works like on the command line. I like these
improvements and look forward to test IC61 for design. I hope that some
of the ocean functions will be improved to create mdl in the background
which will improve the performance. As an example: The batch run take
2h to run with ocean. The same batch run coded to run with spectremdl
takes 2m. It takes some more "engineering" to do it with mdl as ADE
give a lot of startup help in ocean with the script saving
functionality, but the loss in simulation time is enormous.

 

Maybe you should capture these experiences and present them at CDNlive
or
BMAS (www.bmas-conf.org) .
I'd love to see the Cadence white paper "functional Verification of a
differential operational amplifier" extended with an MDL example.. I
think MDL was just in development when that was written.

jdv

 

I have used that whitepaper as a template for some other work that I
have done, and in my opinion it is really about time that the
generation of testbenches like these can be simplified by coding them
textually, or even better, through a flow diagram so that for each
simulation case the operator will only see the elements that are in
use. There are some schematic catpure tools that can "disable" elements
depending on viewpoint. This is a different topic though.