Subject: Minutes of: V-AMS DevModeling meeting July 15
From: Geoffrey.Coram (Geoffrey.Coram@analog.com)
Date: Tue Jul 15 2003 - 11:16:14 PDT
Attendees:
Geoffrey Coram, Analog Devices
Ilya Yusim, Cadence
John Moore, Agilent
Laurent Lemaitre, Motorola
Colin McAndrew, Motorola
Srikanth Chandrasekaran, Motorola
David Zweidinger, Texas Instruments
Marek Mierzwinski, Tiburon
Patrick O'Halloran, Tiburon
-------
1) Thanks to Cadence for sponsoring
2) Approval of previous minutes (June 10)
3) Depending on how we progress through the summer, we
might want to consider a face-to-face meeting at the
conference, "Behavioral Modeling and Simulation"
(BMAS 2003) in San Jose, Oct 7-8. Accellera technical
committee guidelines recommend periodic face-to-face
meetings, but I'm hoping we're essentially finished
by then so we can just go out for a drink or something.
Colin, Laurent, Marek, and I are planning to be there.
4) Continuation of discussion of proposed extensions
3.0 Terminals and Nodes
3.1 optional terminals
The subcommittee agreed that "$connected" would be useful for
bypassing calculations.
We need further research to see if unconnected terminals are
mentioned specifically in the Verilog standard. I was led to
believe that they are "defaulted" to ground, that is, any
terminal not connected to a node in the netlist is automatically
and implicitly connected to ground. Along with $connected, this
works fine for the BJT substrate.
However, Colin pointed out that, if you don't connect the
thermal terminal for a BJT with self-heating, the model does
*not* want it connected to ground. If the standard allows
the addition, we would like to have syntax to select default
to ground or open.
Laurent suggested that terminals be allowed a default like
parameters, e.g.,
electrical s=c;
The simulator would then be expected to realize that V(s,c) is
always identically 0 and it should thus skip the calculation of
substrate current, without requiring the model-writer to use
the $connected function. However, again, the self-heating
terminal is problematic; its default would have to be an
internal node that wouldn't otherwise exist.
We also discussed what happens if a model has more than one
optional terminal; some simulators would have trouble
determining whether the fourth terminal for a BJT is the
substrate or the thermal terminal. However, this is a
simulator issue that we need not address; Sri noted that AMS
already gives the option of specifying terminals by name
rather than order (just like for parameters, which are
perhaps more commonly done by name rather than order):
named_port_connection ::=
.port_identifier ( net_expression )
3.2 descriptions
The subcommittee liked the example as presented; trying to compress
the declarations into something like
inout electrical c -- "collector", b --- "base", e --- "emitter";
would avoid re-typing "electrical" but Colin noted there won't be
that many terminals and one per line is better for clarity.
4.0 Simulation
4.1 non-repetitive warnings
In a previous draft, I had suggested an argument to @cross for dc;
I discarded this in favor of using Cadence's @above event, which
can trigger in dc (including time=0). The subcommittee agreed
that this was a better idea.
4.2 global simulator parameter access
The syntax for this was not completely clear from my examples.
$simparam("string", is_error, default_value)
where
"string" is an arbitrary string
is_error = 0 or 1; 1 means simulator should generate an error
if the string is not recognized; 0 means no error and
function should return default_value
Sri mentioned that I should give complete syntax for this.
The AMS committee can help with writing the BNF (Backus-Naur
Format) for the LRM. What sort of value does $simparam return?
(I had an example in the next section that returned a string,
but we agreed it should return a real value.) What if you
don't give default_value? etc.
Patrick suggested that it might be preferable to define
functions like $gmin, $source_scale_factor, etc., for the
commonly-used parameters -- as is already done for $temperature,
rather than allowing an arbitrary string. This would help keep
Verilog-A simulator-independent, but is not as flexible. I
modeled $simparam after analysis(), which takes an arbitrary
string; this is much more flexible than $dc, $ac, etc. would
have been: one shouldn't have to write
`ifdef SPECTRE
if (analysis("pss"))
to prevent NanoSim from seeing "pss" because the LRM says that
unsupported type names are assumed not to be a match.
We need to define a table of the parameters that are
commonly used, similar to analysis, to standardize the
strings. The list of strings can be updated in the LRM
if new ones need to be added. We'll start with:
gmin, source_scale_factor
Who has some others? I'd rather not see the archaic
defad, defas
but maybe they're needed for old MOS models.
I don't expect that a compact model will need things like
itl1, lvltim, method
and the tolerances
abstol, reltol, chgtol
should be obtained from the discipline. Should it be
possible to get $abstime and $temperature from $simparam?
One deficiency of the above syntax is that it is hard to
find out if a parameter is not recognized if the parameter
could have any real value; one needs an invalid default_value
(eg, gmin=-1) as a flag for undefined. All the above
parameters are non-negative; we could not think of one that
could be any real. If one is found, one could use two calls:
val1 = $simparam("var", 0, 1);
val2 = $simparam("var", 0, -1);
So, if (val1 != val2), then "var" was not recognized.
We think this is a reasonable work-around, and preferable
to defining the whole syntax for "unknown" so it could be
used as the value returned for unknown parameters. We also
like the ability to force a simulator error with is_error,
rather than detecting the unknown parameter and generating
some sort of model error message and using $stop.
4.3 simulator specificity
We just briefly touched on this section, long enough for
Sri to say that $simulator and $simparam should be separate;
I had an example in which $simparam("simulator_name")
would be used instead of $simulator.
Laurent will start to write BNF (Backus-Naur Format)
for the proposed extensions, for inclusion in the
draft proposal.
Sri mentioned that it is important to put proper thought
into the BNF so that, when the LRM is updated, it really
does reflect our intentions.
The next meeting will be July 29 at 11 AM Eastern.
-- 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 Jul 15 2003 - 11:16:55 PDT