Subject: Minutes of: Verilog-AMS LRM Device Modeling: June 10
From: Geoffrey.Coram (Geoffrey.Coram@analog.com)
Date: Tue Jun 10 2003 - 11:16:46 PDT
Attendance:
Geoffrey Coram, Analog Devices
Ilya Yusim, Cadence
Jeroen Paasschens, Philips
Laurent Lemaitre, Motorola
Colin McAndrew, Motorola
Srikanth Chandrasekaran, Motorola
David Zweidinger, Texas Instruments
Marek Mierzwinski, Tiburon
Boris Troyanovsky, Tiburon
Wei-Dong Liu, Synopsys
Carl Gu, Synopsys
1) Approval of previous minutes (May 20)
2) Comments from DAC
Kevin presented slides, including one on our subcommittee,
but was not on the call to tell us the reactions.
Sri mentioned that Verilog-AMS LRM 2.1 was accepted by
Accellera
3) Proposed extensions
Document on web site
http://www.designers-guide.com/private/vams-extensions/compact-modeling/index.html
breaks extensions into three main categories:
a) No extensions (Sec 5)
There were no major objections to the items that I categorized
as not needing extensions. There was some discussion about how
the simulator should recognize and collapse optional internal
nodes; the main point being that this collapsing will only
happen for linear resistors where the simulator at elaboration
time detects that a resistance parameter is zero and thus an
internal node can be removed.
Boris - toughest issue for the simulator: what to do if a
swept resistor value changes from 0 to non-zero
Formulation must have V(a,b) <+ 0; (zero may actually come
from an expression with a parameter); Simulator is not
expected to recognize I=V/R or other formulations as
resistors that need to be shorted when R=0.
Boris - Tiburon has experience detecting this automatically;
notes that a good dependency tree helps detect R is not R(V)
and thus R is candidate for shorting.
b) More research (Sec 6)
Some issues are not yet fully resolved as to what the compact
modeling needs are, nor what we should do. I asked for
volunteers to do more research on these items.
Jeroen - for the noise extensions, a basic problem [that is
not specific to Verilog-A] is that behavior of frequency-
dependent noise is ill-defined for transient simulations;
perhaps we will need extensions when we know what the
"right" thing to do is.
Boris - Tiburon hasn't done MOS11 noise yet, so he doesn't
know if if the freq-dep or the correlated noise are easy
or hard with current support in Verilog-A
c) Actual proposals (Secs 1 - 4)
For these items, actual proposals were put forth.
1.0 Parameters and variables
1.1 Descriptions and units
Jeroen - what units are allowed? are they just text tags?
Geoffrey - disciplines have units; can we piggy-back off
those units (all MKS?) that are allowed for disciplines?
some simulators could use units to check a model (are
you contributing Amps to I() ).
Colin - only real importance of actual units is for
Spectre's "scalem", which is strange (value is specified
separately from model card, so can get the wrong answer);
some noise params, where frequency exponent is a parameter,
have "Hz**0.3321" as units, so it's bizarre/difficult to
specify them; hence, units should just be text tags
Ilya - noted that $simparam (see 4.2) can be used to get
scalem and process parameters appropriately for those
models that want to use it
Later, in discussion of 1.6, Ilya asked if variables have
units, and the subcommittee agreed that they should. We
need to consider the syntax for that, in conjunction with
1.9 (initializing variables when declared).
1.2 Detecting whether a parameter was specified
Colin - prefers $param_given to $given, because more
descriptive keywords are less ambiguous, easier to read
David - found my section on optional terminals confusing,
since I mentioned using $given for terminals, but was not
actually proposing that $given be used for parameters;
I'll rewrite this
1.3 Parameter aliases
David - pointed out that I was inconsistent in choice of
which name was the alias and which the "real thing"
Subcommittee agreed that model equations should only be
allowed to use the "real" parameter name; aliases only
used for parameter processing
1.4 Required parameters
Geoffrey - could have a param that is not given, but its
lack is not noticed until 2ms into sim
Colin - missing param should be tested at start of sim
[however, if a param is only used if an effect is turned on,
it shouldn't be an error if this "required" param is missing
at start of sim]
Boris - efficiency problem if you have to test all the time
Sri - if not specified explicitly, type (int/real) obtained
from default expression; what if there isn't a default value?
Boris - add requirement to specify int or real if no default?
Geoffrey - does anyone really want this?
(no response)
-> will move it to Sec 5, "No extensions"; use of $param_given
allows model writer more flexibility than we can implement for
whether non-given param should be error at start or only if used.
1.5 Infinity as valid parameter value
Geoffrey - expect pushback from full committee, which removed
inf in OVI-2.0.
Boris, David, Colin - mentioned various difficulties with
re-allowing it, and were not sufficiently convinced of
its necessity to fight for its re-inclusion
Colin - designers are used to "0 means infinity" or at least
"0 means disabled" for BJT models (vaf=0 is used that way),
so it's not confusing
Geoffrey - are there params where 0 and inf are both valid
values?
Ilya - pointed out that an ideal switch could have R=0 and
R=inf as valid parameter values, but there are other
(better) ways to implement a switch
Geoffrey - this item also gets moved to Sec 5, "No extensions"
unless someone comes up with a better example of its need.
Subcommittee agrees.
1.6 Output, operating point parameters
Geoffrey - anyone have a case where variables should not be
"public" but must be declared at top level? Eg, for use
in main analog block and analog functions? (Does this
even make sense?)
No one had run into such a case, so having all top-level
variables be "public" seems fine.
Parameters are declared at top level, and hence are "public"; is
this a concern?
Laurent - some parameters change values, so we have param
and param_at_new_temp; might want to hide tnom value
Colin - felt it was good to specify what things are public so the
model writer has control
We stopped at 1.6 because the hour had run out; we will pick up
on 1.7 and continue through section 4.
Next meeting: June 24, same time.
-- Geoffrey J. Coram, Ph.D. Senior CAD Engineer Analog Devices, Inc. Geoffrey.Coram@analog.com 804 Woburn St., MS-422, Tel (781) 937-1924 Wilmington, MA 01887 Fax (781) 937-1014
This archive was generated by hypermail 2b28 : Tue Jun 10 2003 - 11:21:31 PDT