V-AMS Compact Modeling Extensions subcommittee
Minutes of Jan. 27, 2004

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 (noon pacific)