Subject: Minutes of: Verilog-AMS LRM Device Modeling: May 20
From: Geoffrey.Coram (Geoffrey.Coram@analog.com)
Date: Tue May 20 2003 - 09:11:20 PDT
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
- 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).
-- 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 : Tue May 20 2003 - 09:12:19 PDT