Subject: minutes of: V-AMS DevModeling Jan 27
From: Geoffrey.Coram (Geoffrey.Coram@analog.com)
Date: Tue Jan 27 2004 - 13:57:53 PST
Attendees:
Geoffrey Coram, Analog Devices
John Moore, Agilent
Laurent Lemaitre, Motorola
Colin McAndrew, Motorola
Boris Troyanovsky, Tiburon
Jim Barby, U Waterloo
1) Approval of previous minutes (Jan 13)
2) New web pages for our subcommittee
http://www.eda.org/verilog-ams/htmlpages/compact.html
3) New proposal available (on above web site).
Also, the paramset proposal (version 3) is now available there, too.
4) Questions that arose as I re-wrote the proposal and included the BNF:
- module-scope variables with units but no descriptions: are
they output parameters?
-> No. If you don't want a description, use ""
- info vs desc for description attribute?
-> desc is better, because there are a lot of things (including units)
that are information about the parameter.
- aliasparams: does the simulator need to keep track of which
one was specified when printing back the parameter list?
-> Ilya (by e-mail): no, for efficiency reasons
-> Colin: no, any confusion from the user specifying an alias
should push the user to use the "official" name
-> Jim: need to specify some way to get alias list, so you
can be sure that what you specified ended up in the right place.
Probably, the "help" option that prints the descriptions should
list the aliases. (Don't want the alias list every time you
print parameters for the device.)
- m-factor: what does it mean for a digital "always" block?
-> Jim: might mean to make 2x strength inverter
-> Colin: m in digital usually for parallel paths, bus-wise
-> Boris: m-factor only applies to contributions in the analog block,
this will make it an easier sell to the digital verilog folks
- paramset proposal says m-factor should be an attribute (* m=5 *)
but this would change simulation results, hence shouldn't
be an attribute
-> m is really passed to the elaborator/simulator, not the module,
and it's not available inside the module, so it's odd to call it
a parameter.
-> paramset also talks about x,y,z,hflip,vflip, which are important
for mismatch modeling; it would be very convenient to have these
as pre-defined attributes for modules/subcircuits/paramsets,
so that they get handled hierarchically automatically.
-> m and n are also hierarchical and we'd like them done automatically,
too
At this point, we talked a little about how we really wany paramset
to be included with the rest of the proposal. Without paramset,
there's no standard way to get .model cards handled by all simulators;
some simulators require parameters for Verilog-A simulators to be
passed as instance parameters making the netlist huge and eating
memory. As such, Verilog-A compact models wouldn't get used widely
(beyond model developers, who do single-transistor circuits), and
so the rest of the proposal loses its value.
- could use "mfactor" in Verilog netlists, and ask Spice
simulators to translate "m" to "mfactor" when instantiating
something from a Spice netlist as a Verilog-A module
- inout,output vs ref
-> Boris: OK to use inout; simulator vendors can be dumb and use
copy-in, copy-out (as specified by SystemVerilog for digital tasks)
but that's inefficient for analog functions which happen
"instantaneously"; simulators should simply implement this as
pass-by-reference and the results will be the same. "ref" is
likely to be a variable name in many modules.
- port descriptions:
electrical c (*info="coll"*), b (*info="base"*), e (*info="emit"*);
(one info per net_identifier)
versus
electrical in1, in2 (*info="nand inputs"*);
(one info per discipline identifier)
-> Laurent: parameter real a,b,c; is OK,
so parameter real "V" (*desc="what"*) a,b,c; should be OK
-> Jim: probably only get one way at the main AMS committee;
having two is a nuisance
-> Colin: how about
electrical (*info="coll"*) c, (*info="base"*) b, (*info="emit"*) e;
electrical (*info="nand inputs"*) in1, in2;
such that attribute always comes on the left of the identifier,
and it applies to everything on the line until you run into a
new definition. Note that this wouldn't have worked with our
--- syntax.
- simparam_call missing "$" in the proposal draft
- limiting is getting to be a mess
-> should we just provide access to $fetlim?
-> Colin: two approaches in simulators:
a) pnjlim and fetlim ("old way")
b) linearize exponential and do nothing for fets ("new way")
-> Colin: will the digital folks care? only use it on analog
(timestep driven side)
-> Since limexp() does pnjlim in some simulators (or linearizes
the exponential in others), we're leaning towards providing
fetlim, which would access the simulator's fetlim if it's
an "old" simulator, or do nothing if it's a new simulator.
-> We should take a lesson from limexp, which doesn't require
the detailed description I had to write for $limit;
simulators just do what they think is appropriate.
-> One missing limiting function is for temperature limiting
for self-heating bipolar models. The temperature goes
into exponentials, for which limexp can be used, but it
also is used to update parameters, and a huge step in
temperature could result in an absurd parameter value.
5) Next meeting February 10, 3PM Eastern (noon Pacific)
-- 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 Jan 27 2004 - 14:02:52 PST