V-AMS Compact Modeling Extensions subcommittee
Minutes of May 20, 2003

Attendees:
Geoffrey Coram, Analog Devices
Ilya Yusim, Cadence
Jeroen Paasschens, Philips
John Moore, Agilent
Laurent Lemaitre, Motorola
Colin McAndrew, Motorola
David Zweidinger, Texas Instruments
Marek Mierzwinski, Tiburon
Boris Troyanovsky, Tiburon
Patrick O'Halloran, Tiburon
Kevin Cameron, National Semiconductor


1. Approval of previous minutes (May 6)
- no objections


2. Kevin's comments on SystemVerilog, from AMS reflector
- will get some requests automatically if V-AMS LRM is sync'ed up with SV
- Cadence didn't like SV 3.1, may slow acceptance
- don't know when the sync up will occur, in Verilog-AMS
  committee, under Accellera, or not until IEEE standard


3. Update on ADMS: Colin and Laurent
- signed off for release yesterday!
- will be on www.SourceForge.com soon
- still deciding on license for release (GPL or BSD)
- compiles VA to C code for use with CMIs
  (such as are available for MICA, Spectre, ADS)
- you need to write an XML script to describe the C interface
  to your simulator
- we can evaluate the extensions implemented in ADMS for
  possible inclusion in our proposed extensions


4. Continuing to build the list of extensions:
- committee felt the list was complete


5. Attributes vs syntax: can attributes be standardized, or do
  we need to define a syntax for our extensions?  Eg, units
  of parameters could be specified as (* units="Hz/V" *)
  or as a string in a special location in the parameter
  declaration line
Kevin pointed out that parameters could perhaps have disciplines,
  and get their units that way; also, some disciplines do have
  standardized attributes
Colin pointed out that units are mainly for documentation,
  but may interact with Spectre's "scale_m" to scale units
Jeroen didn't like the ability to add features on the fly;
  we agreed that this subcommittee should implement extensions
  so that this is not necessary for compact models
Geoffrey noted that attributes are somewhat long-winded to
  accomplish what we want; attributes can be ignored, but
  many extensions should not be ignored for reliable
  cross-simulator implementations of models


6. Chicken and egg: will we see models developed in Verilog-AMS,
  since there is no generally-available and reliable simulator?
  Will EDA vendors improve their simulators, since there are no
  V-AMS models that their customers are demanding to have work?
Kevin noted that National worked around some HICUM BJT model
  problems with VerilogAMS, showing V-AMS's usefulness
Colin is considering releasing a few Verilog-AMS models (diffused
  resistor, mos capacitor) to spur implementation/use of Verilog-AMS
Marek said Tiburon has similar plans with their V-AMS models,
  releasing eg BSIM3 in V-AMS back to the BSIM developers so they
  can see the power and ease of using V-AMS; he feels the real problem
  will be to get folks to standardize on V-AMS implementations, given
  that C code exists
Boris noted that the BSIM folks would like to work in VerilogA
Marek pointed out that the CMC requires C code; we need to get it
  to accept V-AMS model descriptions.
David(?) said his company recommends Verilog-AMS for use in university
  research projects it sponsors
Geoffrey noted that while eg Mextram is available in Verilog-AMS,
  the code is not complete (no noise, as of the last version I saw),
  similar incompleteness with the publicly-available MOS EKV model;
Colin said that the Penn State "SP" mos model is complete with noise, etc.
  and that someone at U Wash guy will work to generate Spice3 interface
  for ADMS once ADMS is released


7. Other comments
Ilya - ADMS allows "this is initialization, this is evaluation"
  why not do dependency tree?
Colin - separation enforces discipline in writing the code
We agreed, though, that dependency tree is preferable for keeping
the language clean -- and because model writers may not do the
partitioning correctly


8. Next step
Geoffrey: since we have what we believe is a complete list of
  extensions, I think the next phase is for a small group
  (maybe just me) to start refining the Designer's Guide
  document and propose a few methods for implementing the
  extensions; then the subcommittee can review them and
  decide which method is best, or whether the method is too
  ugly or difficult for the importance of the problem we
  are trying to solve.


9. Next meeting: DAC is the first week of June, and Colin said there
is an SRC review and a CMC meeting the third week, so we agreed on
our next meeting on June 10 at 11AM US Eastern (8 AM PT).