V-AMS Compact Modeling Extensions subcommittee Minutes of July 15 Attendees: Geoffrey Coram, Analog Devices Ilya Yusim, Cadence John Moore, Agilent Laurent Lemaitre, Motorola Colin McAndrew, Motorola Srikanth Chandrasekaran, Motorola David Zweidinger, Texas Instruments Marek Mierzwinski, Tiburon Patrick O'Halloran, Tiburon ------- 1) Thanks to Cadence for sponsoring 2) Approval of previous minutes (June 10) 3) Depending on how we progress through the summer, we might want to consider a face-to-face meeting at the conference, "Behavioral Modeling and Simulation" (BMAS 2003) in San Jose, Oct 7-8. Accellera technical committee guidelines recommend periodic face-to-face meetings, but I'm hoping we're essentially finished by then so we can just go out for a drink or something. Colin, Laurent, Marek, and I are planning to be there. 4) Continuation of discussion of proposed extensions 3.0 Terminals and Nodes 3.1 optional terminals The subcommittee agreed that "$connected" would be useful for bypassing calculations. We need further research to see if unconnected terminals are mentioned specifically in the Verilog standard. I was led to believe that they are "defaulted" to ground, that is, any terminal not connected to a node in the netlist is automatically and implicitly connected to ground. Along with $connected, this works fine for the BJT substrate. However, Colin pointed out that, if you don't connect the thermal terminal for a BJT with self-heating, the model does *not* want it connected to ground. If the standard allows the addition, we would like to have syntax to select default to ground or open. Laurent suggested that terminals be allowed a default like parameters, e.g., electrical s=c; The simulator would then be expected to realize that V(s,c) is always identically 0 and it should thus skip the calculation of substrate current, without requiring the model-writer to use the $connected function. However, again, the self-heating terminal is problematic; its default would have to be an internal node that wouldn't otherwise exist. We also discussed what happens if a model has more than one optional terminal; some simulators would have trouble determining whether the fourth terminal for a BJT is the substrate or the thermal terminal. However, this is a simulator issue that we need not address; Sri noted that AMS already gives the option of specifying terminals by name rather than order (just like for parameters, which are perhaps more commonly done by name rather than order): named_port_connection ::= .port_identifier ( net_expression ) 3.2 descriptions The subcommittee liked the example as presented; trying to compress the declarations into something like inout electrical c -- "collector", b --- "base", e --- "emitter"; would avoid re-typing "electrical" but Colin noted there won't be that many terminals and one per line is better for clarity. 4.0 Simulation 4.1 non-repetitive warnings In a previous draft, I had suggested an argument to @cross for dc; I discarded this in favor of using Cadence's @above event, which can trigger in dc (including time=0). The subcommittee agreed that this was a better idea. 4.2 global simulator parameter access The syntax for this was not completely clear from my examples. $simparam("string", is_error, default_value) where "string" is an arbitrary string is_error = 0 or 1; 1 means simulator should generate an error if the string is not recognized; 0 means no error and function should return default_value Sri mentioned that I should give complete syntax for this. The AMS committee can help with writing the BNF (Backus-Naur Format) for the LRM. What sort of value does $simparam return? (I had an example in the next section that returned a string, but we agreed it should return a real value.) What if you don't give default_value? etc. Patrick suggested that it might be preferable to define functions like $gmin, $source_scale_factor, etc., for the commonly-used parameters -- as is already done for $temperature, rather than allowing an arbitrary string. This would help keep Verilog-A simulator-independent, but is not as flexible. I modeled $simparam after analysis(), which takes an arbitrary string; this is much more flexible than $dc, $ac, etc. would have been: one shouldn't have to write `ifdef SPECTRE if (analysis("pss")) to prevent NanoSim from seeing "pss" because the LRM says that unsupported type names are assumed not to be a match. We need to define a table of the parameters that are commonly used, similar to analysis, to standardize the strings. The list of strings can be updated in the LRM if new ones need to be added. We'll start with: gmin, source_scale_factor Who has some others? I'd rather not see the archaic defad, defas but maybe they're needed for old MOS models. I don't expect that a compact model will need things like itl1, lvltim, method and the tolerances abstol, reltol, chgtol should be obtained from the discipline. Should it be possible to get $abstime and $temperature from $simparam? One deficiency of the above syntax is that it is hard to find out if a parameter is not recognized if the parameter could have any real value; one needs an invalid default_value (eg, gmin=-1) as a flag for undefined. All the above parameters are non-negative; we could not think of one that could be any real. If one is found, one could use two calls: val1 = $simparam("var", 0, 1); val2 = $simparam("var", 0, -1); So, if (val1 != val2), then "var" was not recognized. We think this is a reasonable work-around, and preferable to defining the whole syntax for "unknown" so it could be used as the value returned for unknown parameters. We also like the ability to force a simulator error with is_error, rather than detecting the unknown parameter and generating some sort of model error message and using $stop. 4.3 simulator specificity We just briefly touched on this section, long enough for Sri to say that $simulator and $simparam should be separate; I had an example in which $simparam("simulator_name") would be used instead of $simulator. Laurent will start to write BNF (Backus-Naur Format) for the proposed extensions, for inclusion in the draft proposal. Sri mentioned that it is important to put proper thought into the BNF so that, when the LRM is updated, it really does reflect our intentions. The next meeting will be July 29 at 11 AM Eastern.