V-AMS Compact Modeling Extensions subcommittee
Minutes of April 6, 2004

Attendees:
Geoffrey Coram, Analog Devices
Ilya Yusim, Cadence
Colin McAndrew, Motorola
Srikanth Chandrasekaran, Motorola
David Zweidinger, Texas Instruments
Peter Liebmann, Xpedion
Jim Barby, U Waterloo
Chris Nicklaw, Silvaco
Al Davis, Kettering U



1) Approval of previous minutes


2) Approval process for LRM 2.2

We had a brief discussion of the process by which the proposed
extensions would be approved as AMS LRM 2.2

 - I will update LRM frame document and send it to the full
   AMS committee as well as other Accellera TCC chairs

 - May want another meeting of the main AMS committee to discuss,
   similar to the meeting in January

 - I will plan to present this at the Accellera board meeting
   that we expect will happen in June during DAC; Jim noted that
   answering the board's questions in real time will accelerate
   the process

 - Formal submission to the board will follow, after I address
   any concerns; I will not try to have the LRM ready in May
   (which would be necessary to have a vote on it at DAC)

Sri said that our subcommittee should focus on Verilog-A, and
not worry about the SystemVerilog integration; this is an
issue he has already addressed with Vassilios.


3) Limiting

Sri wants to see UDFs (user-defined functions) allowed for limiting.
I had taken it out as giving a model writer too much rope to hang
him/herself.  However, Spice does not have a temperature limiting
algorithm, and some simulators (eg, zspice that works with ADMS)
may not have any limiting algorithms built in; this would give
users a way to do the limiting.  (In e-mail after the call, but
before the minutes, Sri and I discussed that the simulator would
search for the limiting_identifier as a built-in function, then
in the module's analog functions; that way, a diode could have a
simple pnjlim UDF for distribution, but the simulator's own
(presumably enhanced) pnjlim would take precedence.)

We think that $discontinuity(-1) would be a reasonable way to signal
simulator that another iteration is required.


4) M factor

We considered pre-defining "parameter real mfactor = 1"
for every module, but Sri pointed out that this is a nuisance
for parameter overrides by ordered list.

We believe that the simulator should handle the four main rules
  - current contribs scaled by m
  - current probes scaled by 1/m
  - noise currents scaled by sqrt(m)
  - noise voltages scaled by 1/sqrt(m)

OOMRs may be handled according to rules in the proposal.

However, we think we should provide access to $mfactor in the
module, for minr, output parameters, and mismatch.

For the case of minr and output parameters, the simulator
should be able to determine that the use of $mfactor is OK;
output parameters should not affect the contributions, and
minr uses it to switch formulations entirely.

However, the simulator will probably need to generate a warning
for the use of $mfactor in mismatch equations, since it won't be
clear that the model writer isn't trying to do manual m-scaling.

Ilya mentioned a customer wanted m=0 for some reason.

Colin said we should insist that the $mfactor as seen by module 
will be > 0 (strict); simulator may choose to accept $mfactor=0,
but it should not instantiate the device.

For Spice netlists, in which an mfactor is defined, usually as
an instance parameter "m=<value>", if the device is instantiated
as a Verilog-A primitive, then the simulator should:
 a) follow the four simple rules as above
 b) set the value of $mfactor to <value> (times whatever
    hierarchical value is appropriate)

However, we got hung up trying to define a syntax for specifying
mfactor in a Verilog netlist.


5) Next meeting: 9AM Eastern (Daylight) Time, April 20

3PM Eastern is 4:30AM Australia, so we're moving back to mornings
(9AM EDT is 10:30PM for Sri).  This is great for the Europeans,
but a nuisance for West Coasters.  Sorry.