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

Attendees:
Geoffrey Coram, Analog Devices
Ilya Yusim, Cadence
Srikanth Chandrasekaran, Freescale
Jim Barby, U Waterloo

1) Approval of previous minutes (July 13)

2) Ilya's proposal to disable automatic m-factor scaling:
Ilya conceded that it was a bad idea to use a compiler
directive for this, since compiler directives are supposed
to be in effect until turned off by another `directive,
and as such could not be restricted to the analog block.

One possibility would be to leave automatic m-factor scaling
if the reference to $mfactor is only in a conditional test:
  if (rd/$mfactor > rmin)
    I(rd) <+ V(rd)/rd; // auto-scaled by mfactor
  else
    V(rd) <+ 0;
whereas a reference to $mfactor in an assignment (specifically
one used in a contribution) would turn off the auto-scaling:
  IS_final = IS * $mfactor;
  I(dio) <+ IS_final * (limexp(V(dio)/$vt()) -1);

The issue of turning off auto-scaling was brought up by
Jeroen of Philips, who pointed out that the currents and
derivatives have to be scaled on each iteration of each
timepoint.

However, our feeling is that:
1) only a small fraction of devices in the circuit use mfactor!=1
  and the simulator should know to skip the scaling if mfactor=1
2) the number of operations is either small in an absolute sense
  (scaling the resistor current and conductance, instead of the
   effective resistance, doubles the work, but it's still not a
   lot of operations), or is small relative to the work in the
   module (eg, in Mextram, where a few calls to pow() or exp()
   wash out the effect of the extra multiplies).

Hence, we are leaning towards *never* turning off the automatic
m-factor scaling.  If Philips can provide some benchmark info
to say it does make a significant difference for some circuit,
we would be open to a new proposal.

The simulator shall issue a warning if it detects misuse of
the mfactor (ie, double-scaling).

3) The system parameters (mfactor, hflip, etc) need to have
their allowed values specified in Table 10-6.  Also, add a
note that $angle is in degrees, but trig functions are in
radians.  Common $angles are 30,45,60,90 -- designers can't
use `M_PI_2 in the schematic environment, but anyone
sophisticated enough to be writing a paramset with $angle
can be taught to use `M_TWO_PI.

4) Comments from last night's main AMS committee meeting:
The main issue from last night is the use of variables
(from a paramset or a constants module) for setting
parameters.  The current specifications of $random and
$rdist_* says they are not constant_expressions, so
their values have to be assigned to variables.  However,
it is a major language issue to specify that these
variables, even in special contexts, be allowed to be used
to initialize parameters.  On the other hand, the $rdist_
functions require the seed to be an inout argument, so it's
also hard to make them allowed as constant_expressions.

Sri will check with the compiler folks at his company.


5) Next meeting: August 10, 9AM ET.

The main AMS committee will be meeting on August 2, 4:30PM PT;
we are running out of time to submit the LRM to the Accellera
board for the September meeting.