V-AMS Compact Modeling Extensions subcommittee Minutes of June 10, 2003 Attendees: Geoffrey Coram, Analog Devices Ilya Yusim, Cadence Jeroen Paasschens, Philips Laurent Lemaitre, Motorola Colin McAndrew, Motorola Srikanth Chandrasekaran, Motorola David Zweidinger, Texas Instruments Marek Mierzwinski, Tiburon Boris Troyanovsky, Tiburon Wei-Dong Liu, Synopsys Carl Gu, Synopsys 1) Approval of previous minutes (May 20) 2) Comments from DAC Kevin presented slides, including one on our subcommittee, but was not on the call to tell us the reactions. Sri mentioned that Verilog-AMS LRM 2.1 was accepted by Accellera 3) Proposed extensions Document on web site http://www.designers-guide.com/private/vams-extensions/compact-modeling/index.ht ml breaks extensions into three main categories: a) No extensions (Sec 5) There were no major objections to the items that I categorized as not needing extensions. There was some discussion about how the simulator should recognize and collapse optional internal nodes; the main point being that this collapsing will only happen for linear resistors where the simulator at elaboration time detects that a resistance parameter is zero and thus an internal node can be removed. Boris - toughest issue for the simulator: what to do if a swept resistor value changes from 0 to non-zero Formulation must have V(a,b) <+ 0; (zero may actually come from an expression with a parameter); Simulator is not expected to recognize I=V/R or other formulations as resistors that need to be shorted when R=0. Boris - Tiburon has experience detecting this automatically; notes that a good dependency tree helps detect R is not R(V) and thus R is candidate for shorting. b) More research (Sec 6) Some issues are not yet fully resolved as to what the compact modeling needs are, nor what we should do. I asked for volunteers to do more research on these items. Jeroen - for the noise extensions, a basic problem [that is not specific to Verilog-A] is that behavior of frequency- dependent noise is ill-defined for transient simulations; perhaps we will need extensions when we know what the "right" thing to do is. Boris - Tiburon hasn't done MOS11 noise yet, so he doesn't know if if the freq-dep or the correlated noise are easy or hard with current support in Verilog-A c) Actual proposals (Secs 1 - 4) For these items, actual proposals were put forth. 1.0 Parameters and variables 1.1 Descriptions and units Jeroen - what units are allowed? are they just text tags? Geoffrey - disciplines have units; can we piggy-back off those units (all MKS?) that are allowed for disciplines? some simulators could use units to check a model (are you contributing Amps to I() ). Colin - only real importance of actual units is for Spectre's "scalem", which is strange (value is specified separately from model card, so can get the wrong answer); some noise params, where frequency exponent is a parameter, have "Hz**0.3321" as units, so it's bizarre/difficult to specify them; hence, units should just be text tags Ilya - noted that $simparam (see 4.2) can be used to get scalem and process parameters appropriately for those models that want to use it Later, in discussion of 1.6, Ilya asked if variables have units, and the subcommittee agreed that they should. We need to consider the syntax for that, in conjunction with 1.9 (initializing variables when declared). 1.2 Detecting whether a parameter was specified Colin - prefers $param_given to $given, because more descriptive keywords are less ambiguous, easier to read David - found my section on optional terminals confusing, since I mentioned using $given for terminals, but was not actually proposing that $given be used for parameters; I'll rewrite this 1.3 Parameter aliases David - pointed out that I was inconsistent in choice of which name was the alias and which the "real thing" Subcommittee agreed that model equations should only be allowed to use the "real" parameter name; aliases only used for parameter processing 1.4 Required parameters Geoffrey - could have a param that is not given, but its lack is not noticed until 2ms into sim Colin - missing param should be tested at start of sim [however, if a param is only used if an effect is turned on, it shouldn't be an error if this "required" param is missing at start of sim] Boris - efficiency problem if you have to test all the time Sri - if not specified explicitly, type (int/real) obtained from default expression; what if there isn't a default value? Boris - add requirement to specify int or real if no default? Geoffrey - does anyone really want this? (no response) -> will move it to Sec 5, "No extensions"; use of $param_given allows model writer more flexibility than we can implement for whether non-given param should be error at start or only if used. 1.5 Infinity as valid parameter value Geoffrey - expect pushback from full committee, which removed inf in OVI-2.0. Boris, David, Colin - mentioned various difficulties with re-allowing it, and were not sufficiently convinced of its necessity to fight for its re-inclusion Colin - designers are used to "0 means infinity" or at least "0 means disabled" for BJT models (vaf=0 is used that way), so it's not confusing Geoffrey - are there params where 0 and inf are both valid values? Ilya - pointed out that an ideal switch could have R=0 and R=inf as valid parameter values, but there are other (better) ways to implement a switch Geoffrey - this item also gets moved to Sec 5, "No extensions" unless someone comes up with a better example of its need. Subcommittee agrees. 1.6 Output, operating point parameters Geoffrey - anyone have a case where variables should not be "public" but must be declared at top level? Eg, for use in main analog block and analog functions? (Does this even make sense?) No one had run into such a case, so having all top-level variables be "public" seems fine. Parameters are declared at top level, and hence are "public"; is this a concern? Laurent - some parameters change values, so we have param and param_at_new_temp; might want to hide tnom value Colin - felt it was good to specify what things are public so the model writer has control We stopped at 1.6 because the hour had run out; we will pick up on 1.7 and continue through section 4. Next meeting: June 24, same time. [subsequently cancelled]