V-AMS Compact Modeling Extensions subcommittee
Minutes of July 29, 2003

Attendees:
Geoffrey Coram, Analog Devices
Ilya Yusim, Cadence
Jeroen Paasschens, Philips
John Moore, Agilent
Laurent Lemaitre, Motorola
Colin McAndrew, Motorola
Patrick O'Halloran, Tiburon
Peter Liebmann, Xpedion


0) pre-discussion of m factor
Peter said Cadence and Antrim have ways to handle $m in their
simulators; he and someone from Cadence (Ilya?) should write
this up so we can see if it's useful.

Colin says mismatch has to be handled explicitly by model-writer.
Mismatch goes as sqrt(m), but might be some other rule; model-writer
needs the $m factor to get a hold on this factor.  Several on
subcommittee disagree.

Geoffrey found $m problems in Mextram (and Philips caught some of
their own); Laurent found $m problems in SP.  Given these mistakes
in the basic code, is it reasonable to expect model-writers to do
mismatch correctly?

Colin will talk with Ken about paramsets and mismatch/Monte-Carlo.

1) Approval of minutes (July 15)

2) Continued discussion of proposals

4.2 Global simulator parameter access

We are still looking for things to go on the list of "standard"
strings for $simparam.


4.3 Simulator specificity

The current syntax asks for $simulator("cadence_spectre")

Colin asked about the version number.  Should that be part of
this request: $simulator("cadence_spectre_4.4.6.031103") ?

We believe that model-writers will not really want the actual
version string -- and have to keep track of the list of
acceptable version strings; we/they need a way to test if the
current version is later than a version where a bug was fixed.
Unfortunately, many simulators have a version string, which
makes comparison difficult.  (We don't want to add string
inequalities to Sec 1.6 on string variables.)

Colin proposed that we add "version" and "subversion" as arguments
to $simparam (4.3, above), and leave it to the simulator to
determine how the (real) values are constructed from their strings.
Eg, Cadence uses "4.4.6.031103" as its sub-version string;
they could decide that
  $simparam("version") = 446 or 44.6 or 4.46
  $simparam("subversion") = 31103 or 0.031103
but this choice should be documented for the user.  We want to be
clear that the use is to test "version > good_version" and thus
these numbers should increase monotonically and not change format.

The proposal also calls for a token to be `defined by the simulator,
similar to how C compilers pre-define things like -DSUN5 or -DSYSVR4
Cadence also has `ifdef __VAMS_ENABLE__ to distinguish OVI
Verilog-AMS 2.0 from Verilog-A 1.0.

So, we should be able to test
  `ifdef CADENCE_SPECTRE
      @(above(..))
  `endif
because other simulators won't be able to parse the non-standard
above event (until it becomes standard).

Jeroen asked: do we really need $simulator, if we have `ifdef?
We couldn't come up with a reason; we should be able to do
everything with the `define.  We need `define for the non-standard
syntax to be skipped.


4.4 $limit

I (Geoffrey) would love never to have to write limiting for another model,
but I think it's a long way off before the simulator will be able to
do it automatically.  The subcommittee agreed with the sentiment.
Further, there are many nonlinear functions that don't look like exp()
and thus can't be done with limexp, particularly in self-heating BJT
models.

There was some concern that the proposal says the simulator is free
to ignore the $limit function, or use it as a hint that it should
do something (some other limiting?) with the quantity given as the
first argument.  This freedom is present so that simulators may
move towards the ideal of automatically doing the right limiting
for their algorithms; though I may have a great limiting function
for ADICE, it might hinder convergence in Spectre, so Spectre
should be allowed to ignore my function and try to converge.
Also, the simulator may need to skip $limit on the last iteration
to guard against false convergence.

Peter thought that the thing being limited has to be a branch
voltage.  However, the SPICE pnjlim function limits the quantity
vd/(n vt), I'm not sure we understood what he was trying to say.

We will discuss this further next time.



The next meeting will be August 12 at 11 AM Eastern