V-AMS Compact Modeling Extensions subcommittee
Minutes of July 13, 2004

Attendees:
Geoffrey Coram, Analog Devices
Ilya Yusim, Cadence
Colin McAndrew, Freescale
Jim Barby, U Waterloo

1) Approval of previous minutes (June 1)

2) Comments from last night's main AMS committee meeting:
The main issue holding up LRM 2.2 (CM extensions) is the
question of how to specify an override of the mfactor in
a verilog-style netlist.  The use of attributes (even
the "system attributes" proposed in the 1364-btf comm)
is not acceptable, because atttributes may not affect
the simulation results.  Thus, it was concluded that the
most reasonable approach would be to create "system
parameters" for mfactor as well as the other layout-
related quantities (xpos, ypos, hflip, vflip, angle).
These will be specified as
nmos #(.vth(0.6), .$mfactor(3), .$xpos(1u), .$ypos(-1u)) ...

The CM subcommittee needs to investigate the specific
names (x vs xpos vs xposition) and propose a method of
accessing the values in a module.  Using "$identifier"
is probably the right thing (just like "identifier" is
used for regular parameters); we have to watch out for
conflicts with system tasks if we choose short names.

We omitted $nfactor (series multiplicity) because the
concept is not defined for modules with more than two
terminals.  Colin also mentioned that he'd had trouble
implementing $nfactor correctly even for a two-terminal
device, when nonlinearity and/or mismatch was present,
though he did not recall the details.

3) Overloading modules, paramsets, generate
We briefly discussed the "overloading.pdf" document.
Jim moved that we use paramsets as the method of
implementing Spice model cards and other features.
Ilya second.  None opposed, none abstained.  The
motion passes.  

For the record, using the Accellera TCC guidelines,
the subcommittee had 6 members who had attended 3 of the
last 4 meetings and were thus eligible to vote; all four
attendees to this meeting met this guideline.

4) Disabling automatic $mfactor
Background: Verilog-AMS simulators shall handle mfactor rules
automatically, as discussed in the draft proposal.
http://www.eda.org/verilog-ams/htmlpages/public-docs/Verilog-A_Compact_Model_Extensions.pdf
Some modules may reference the $mfactor directly, to handle
mismatch or rmin, or possibly to pre-scale key parameters by
$mfactor (which is more efficient than scaling currents and 
derivatives on every iteration of every timepoint).  In the
latter case, if the simulator also applies the $mfactor rules,
then the results will be wrong.
In the April 6 meeting, Laurent suggested that the automatic
$mfactor rules be disabled by any use of $mfactor in the module.

Current issue: Ilya believes this is a bad idea, because his
modules will make frequent use of $mfactor for the purposes
of rmin (eliminiting parasitic resistors when r/$mfactor < rmin),
and thus he will be forced to code in the $mfactor for all the
current and noise contribs.

One work-around would be to place the parasitic resistors in
a separate module, instantiated a few times in the main MOS
module, and only reference $mfactor in the resistor module,
leaving the simulator to handle $mfactor in the main MOS
module.  However, this hierarchical structure may be hard
to optimize (Ilya mentioned disjointed memory blocks).

Ilya would like a directive to disable the automatic mfactor
rules for a module.  He will create a proposal for syntax
and semantics (eg, that the simulator may issue a warning
if it believes you haven't done the scaling properly).

5) Statistics and Monte-Carlo
Colin expressed a few reservations with the Monte Carlo
section of the paramsets proposal.
a) it's tied specifically to one kind of simulation/analysis,
which seems inappropriate for a hardware description language
b) process parameters aren't the only thing that varies;
supply voltage and external components also need consideration
c) mismatch is generally only applied to a list of specific
devices, not to all devices

Colin will develop an example showing the full complexity
of the issue, which may show that it is infeasible to do
Monte Carlo in Verilog-AMS.

6) Next meeting: July 27, 9AM ET.