V-AMS Compact Modeling Extensions subcommittee
Minutes of Feb. 10, 2004

Attendees:
Geoffrey Coram, Analog Devices
Ilya Yusim, Cadence
Marek Mierzwinski, Tiburon
Boris Troyanovsky, Tiburon
Peter Liebmann, Xpedion
Jim Barby, U Waterloo
Al Davis, Kettering U


1) Limiting

Peter sent an e-mail to the reflector just before the meeting.
He felt that limexp is not sufficient, even for exponentials,
because it doesn't know about the saturation current Is that
scales the exponential.

He proposed Spice-like limiting that mainly corresponds with
what the current proposal says, in terms of some kind of access
to the previous value and a way to specify a value to use in
place of the current branch voltage.

One addition was the "save" function save(var,var_save) which
is necessary to exactly reproduce Spice3's fetlim.  This gives
access to the previous value of something other than the branch
voltage that's being limited.  In fetlim, this value is the
previously-calculated threshold voltage (von).

Implementing this would require an extra value to be saved
per instance per timepoint; ie, it is expensive.
Al mentioned that gnucap does keep old stored values,
despite this penalty.

Note that the Jan 23 version of the proposal (version 6) made
the $previous implicit, per suggestions from the main AMS
committee.  $limit calls to a regular analog function (not a
new kind of "limiting function") and one argument to the analog
function is the current value of a branch voltage and another
is the previous value.  Since the simulator already has to
store the v-vector, this does not require extra storage.

It was noted that Spice3's fetlim and limvds do not allow
rejection of iteration whereas pnjlim does.  If pnjlim thinks
that the limited voltage is too different from the input,
it forces an extra iteration, even if the convergence tests
would otherwise have passed.

It was mentioned in passing that Spice3 doesn't check convergence
very thoroughly.

We spent a lot of time trying to figure out how to detect if
an iteration should be rejected.
 - if the model-writer does it, then he might test (v_lim==v_in)
   and the floating-point == would frequently fail, requiring
   lots of extra iterations
 - the simulator could try to see if (v_lim-v_in) < v.abstol
   but this would also be too conservative; if you're in a
   region with small slope, a much larger tolerance could be OK
 - but the simulator doesn't really know about the slope
   (and the model-writer might not, either, if there are lots
   of extra effects in the model that change the currents,
   instead of just a single threshold voltage)

All of this complication, plus the complication of what the
"previous value" is (from previous iteration, or final iteration
of the last accepted timepoint, or ??? for the very first iteration),
is a lot of simulator/analysis-specific stuff to try to put in a
hardware description language.  And some simulators don't really
even believe in limiting, preferring to only linearize the
exponential to prevent floating-point overflow.

Another proposal would be to provide new system tasks named
$fetlim and $pnjlim that access the simulator's built-in functions,
if the simulator has them, or simply return their first argument.
(I'm not sure what to do with fetlim's von argument.)  The idea
here is that the Berkeley BSIM folks would naturally put $fetlim
into BSIM5 just like they did for BSIM4.  Simulators that use
fetlim (because they converge better with it) would already have
all the machinery for rejecting a timepoint and generating the
"previous value."  So, the AMS LRM would not need to talk about it,
just like it doesn't talk about how limexp works (is it a call to
a sort of pnjlim? is it a linearized exponential?).


2) Approval of previous minutes (Jan 27)

3) Note from last CMC meeting:
Silvaco intends to post Verilog-A versions of common models
on their web site: Gummel-Poon, Mextram, EKV, BSIM3, BSIM4,
and HiSim.

The next CMC meeting is in Boston, and I (Geoffrey) am to give a
presentation on Verilog-A for compact modeling.  Note that the
CMC is March 12, following Nanotech 2004 (March 7-11).

4) Next meeting: Feb 24, 3PM Eastern