Re: minutes of: V-AMS DevModeling meeting April 20

Geoffrey.Coram wrote:

>V-AMS Compact Modeling Extensions subcommittee
>Minutes of April 20, 2004
>....
>
>3) M-factor in Verilog netlists
>
>This item also requires action by the main AMS committee, which
>plans to discuss it on May 3.
>
>Last time, we had decided to handle mfactor automatically
>for contributions, but allow the module to get the value
>through the call $mfactor for tricky things like mismatch
>and rmin.
>
>Laurent made a new suggestion: if a module accesses $mfactor,
>then the compiler should issue a warning and expect the
>model writer to explicitly handle the mfactor for
>contributions and elsewhere. If a module does not access
>$mfactor, then the simulator handles the contribution rules
>automatically.
>
I would avoid using $mfactor since anything that is $<name> is a system
task that can be replaced by the user, and isn't really something you
can use at elaboration time (which is when you want to handle the
multiplier). I'd prefer to use an explicit "multiplier" syntax as I
suggested previously (or possibly something on top of the regular
parameter mechanism) which will work at elaboration time.

>This will make Colin's life difficult, since he'll use
>$mfactor for mismatch and then be compelled to code it
>explicitly for current contributions.
>
>Marek pointed out that, for hierarchical instantiations
>within a module that accesses $mfactor, we need to provide
>a way to pass the mfactor to the instances, which goes
>back to the need to provide a way to specify the mfactor
>in a Verilog netlist.
>....
>
A number in curly brackets in the instance probably wouldn't clash with
existing syntax: e.g.:

   foo foo1 (*...*) {1.5} (a,b,c...);

For AMS you need to be able to handle multipliers on digital blocks as
well as analog blocks, and the multipliers may need to extend into the
A/D convertors (which is another reason for instantiating A/Ds under the
module where the drivers are rather than in the level above).

Multiplying a digital gate by a real number wouldn't change it's
function in a pure digital context, so having a module instantiated with
a multiplier of 1.5 is functionaly the same as having it once. However,
if it does have a multiplier of 1.5, then in a MS context where a driver
is being relayed to an analog context and a D2A is being inserted then
the D2A has to be multiplied (i.e. currents scaled by 1.5) - the same
goes for A2Ds on inputs.

Kev.

-- 
Kevin Cameron, CPU Technology, CA 94588, Tel.: (925) 225 4862