minutes of: V-AMS DevModeling meeting April 20

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

Attendees:
Geoffrey Coram, Analog Devices
Ilya Yusim, Cadence
Laurent Lemaitre, Motorola
Colin McAndrew, Motorola
Srikanth Chandrasekaran, Motorola
Marek Mierzwinski, Tiburon
Jim Barby, U Waterloo
Al Davis, Kettering U

1) Approval of previous minutes (Apr 6)

2) DC Sweep
The dc sweep proposal was discussed last night by the main AMS
committee. Since compact modeling makes significant use of
dc sweeps, I was hoping to include this proposal in the LRM
revision for compact modeling.

However, significant questions persist about the specification
of a dc sweep for mixed-signal simulation. Hopefully, this
will be addressed soon; otherwise, we will define the behavior
for analog-only systems and include the mixed-signal questions
in Annex G (open issues);

3) M-factor in Verilog netlists

This item also requires action by the main AMS committee, which
plans to discuss it on May 3.

Last time, we had decided to handle mfactor automatically
for contributions, but allow the module to get the value
through the call $mfactor for tricky things like mismatch
and rmin.

Laurent made a new suggestion: if a module accesses $mfactor,
then the compiler should issue a warning and expect the
model writer to explicitly handle the mfactor for
contributions and elsewhere. If a module does not access
$mfactor, then the simulator handles the contribution rules
automatically.

This will make Colin's life difficult, since he'll use
$mfactor for mismatch and then be compelled to code it
explicitly for current contributions.

Marek pointed out that, for hierarchical instantiations
within a module that accesses $mfactor, we need to provide
a way to pass the mfactor to the instances, which goes
back to the need to provide a way to specify the mfactor
in a Verilog netlist.

4) Limiting syntax

Sri wanted to know about the syntax for the limiting function's name,
ie, the second argument to $limit; let's call it limit_fn_identifier.

Option 1:
limit_fn_identifier
                        : spice_identifier
                        | analog_fn_identifier

spice_identifier : pnjlim
                       | fetlim
                       | simulator_specific_lim

Option 2:
limit_fn_identifier:
                         string_identifier
                        | analog_fn_identifier

Option 3:
limit_fn_identifier:
                         string_identifier
                        | "analog_fn_identifier"

We dislike option 1, because it introduces pnjlim and fetlim
as keywords. In option 3, if you misspell "analog_fn_identifier",
then the simulator treats it as unknown (and applies some default
limiting), rather than giving a syntax error at compilation time.
Option 2 would give that error if it did not find the definition
of the analog function.

However, option 2 makes it more difficult to switch between a
UDF and a built-in limiting algorithm. There are two scenarios here:
 a) Models (particularly for BJTs with self-heating) define templim as
    a UDF; simulators start building in a templim that is tuned for
    their algorithms; now, model-writers have to replace
    templim with "templim" to access the built-in.
 b) A model wants to provide a basic pnjlim for use in a simulator
    that does not have it, but wants to use the built-in otherwise.

Marek suggested the syntax
   $limit(V(a,c), "pnjlim", mypnjlim, vcrit)
where "pnjlim" is used if available, else mypnjlim is used.
This solves (b). (It has the side effect of shifting the
arguments, so that the 4th and subsequent arguments to $limit
become the 3rd and subsequent arguments to mypnjlim.)

Ilya cautioned against giving the user the impression that he/she
has final say; the simulator should be in charge of determining
which limiting algorithm is actually used. We've mentioned before
that the simulator can choose to ignore $limit, or just use it as
a flag to do something to the branch. Hence, Ilya suggested,
the model could call
   $limit(V(a,c), pnjlim, vcrit)
where pnjlim is a UDF, but the simulator could decide to call its
internal "pnjlim" instead. Sri felt that it should be obvious
from reading the module code what algorithm is being used.
However, I don't think it's necessary to provide that
transparency for $limit.

5) Noise

I've had some trouble trying to implement the MOS11 noise model
in Verilog-A, despite our claim that an extension was not needed.
Part of the problem is that the C code from Philips does not
implement the model equations as written, but uses one expression
for "low" frequencies and another for "high." This can't be done
without explicit access to the frequency; however, it's not
really physically correct, either.

6) Next meeting: May 18 at 9AM ET
at which point I plan to have the LRM updated with what we have
agreed on, leaving the mfactor and dc sweep details until the
main AMS committee comes to some conclusion

-Geoffrey

-- 
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