Subject: V-AMS DevModeling meeting Oct 21, plus old minutes
From: Geoffrey.Coram (Geoffrey.Coram@analog.com)
Date: Fri Oct 17 2003 - 14:38:43 PDT
Greetings -
The device modeling extensions subcommittee will be meeting
Tuesday, October 21, at 11 AM Eastern (8 AM Pacific).
The dial-in information is below; thanks again to Ilya
and Cadence for sponsoring it.
> Toll-Free Number: 888-454-9810
> Toll Number: 1-415-228-4715
>
> PASSCODE: 92821
Below are the minutes for the two previous meetings;
apologies for not sending them earlier, and for the
fact that I was unable to set up a speakerphone for
the post-BMAS meeting.
-Geoffrey
-----September 23---------------------
Attendees:
Geoffrey Coram, Analog Devices
Ilya Yusim, Cadence
Jeroen Paasschens, Philips
John Moore, Agilent
Laurent Lemaitre, Motorola
David Zweidinger, Texas Instruments
Marek Mierzwinski, Tiburon
Peter Liebmann, Xpedion
1) Previous minutes (Sept 9) approved
2) Multiplicity factor
Peter mentioned that OOMRs can *contribute* to things in
other modules, eg a mutual inductor can contribute to the
branches of the inductors it couples. Exactly how this
works for m-factor (of the Ks and the Ls) needs to be
thought through.
3) Optional terminals
We considered proposing terminal defaults, in addition to
the $connected feature, for cases such as a multi-input
dependent sources, where explicitly coding the default
would be cumbersome.
4) Limiting
There was general agreement that we need some method of
specifying limiting functions beyond limexp, and the
proposed syntax seems to be general enough.
5) Model cards
Peter offered to compose a spice-compatible example,
essentially instantiating the basic compact model
inside a module that hard-codes the "model parameters"
and has the instance parameters as its parameters.
He said this setup could be recognized and optimized
by the simulator.
It was noted that Silvaco is apparently following Tiburon's
example, allowing any Verilog-A parameter to be a model
parameter, and any instance can override parameters
specified on its model card.
6) ADMS
ADMS is now available on SourceForge at
http://sourceforge.net/projects/mot-adms
-----October 8-------------------------
Attendees:
Geoffrey Coram, Analog Devices
Ken Kundert, Cadence
Ilya Yusim, Cadence
Jonathan David, Cadence
Colin McAndrew, Motorola
Boris Troyanovsky, Tiburon
Peter Liebmann, Xpedion
Al Davis, Kettering University
Jim Barby, University of Waterloo
1) Model cards
Note that resistor tc1, tc2 can be model or instance param
in many spice-like simulators; there is precedence for
ability of instance to override parameter from model card.
Al talked about his GNUCAP simulator, which introduces yet
another level of parameter: common, which goes between
model and instance. A circuit that has lots of devices
with the same W and L will share a common and his simulator
will benefit from some further optimization.
It was suggested that we build the idea of paramset, a
syntax for a Verilog-A netlist to handle what a Spice model
card does (and then some); and we should also suggest how
simulators might read a .model card in a standard Spice
netlist and map it to their implementation of paramset.
This would allow maximum use of existing model cards.
The paramset proposal should be on the web shortly, at
http://www.designers-guide.com/private/vams-extensions/compact-modeling/
2) Inheritance
Al asked about the concept of inheritance. In GNUCAP, he
has a basic mos model that defines the topology (eg, four
terminals), and then the various mos models inherit from
the base class, sometimes through other lower-level models.
Ken suggested that this might be useful for the case that
one takes a standard model like BSIM3 but adds a substrate
resistance. Using inheritance, an update to the BSIM3
model will be automatically included in the BSIM3_RF model.
One could do this hierarchically (build a module with the
BSIM3 and Rsub in it), but then one has to re-declare all
the BSIM3 parameters for the new module.
3) M factor
Someone noted that the m-factor might not be appropriate
for a system-level module. If the m-factor is an implicit
parameter to all modules, we might need a way to say that
it is not allowed for some.
-- 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
This archive was generated by hypermail 2b28 : Fri Oct 17 2003 - 14:39:53 PDT