Re: Mfactor proposal

Shekar -
In reviewing your proposal and Ken's comments, I have a few
comments of my own.

In Section 5, bullet 6 says "It should be possible to refer
to the effective mfactor value in analog behavioral code."

But then in 6.1.2 (and several other places), you write "It will
be error to use the declared mfactor parameter in any expression
inside the module."

In the compact modeling extensions subcommittee, we believe
that there are a few cases in which one might want explicit
access to the mfactor. One of those is mismatch, in which
the statistical variation is decreased by having elements
in parallel.

In the case that the mfactor is used in a module, this turns off
automatic scaling by the simulator. Taking Ken's example and
using the $m syntax:
     module my_res (a, b);
         parameter real r;
         resistor #(.r(r), .$m($m)) R1 (a, b);
     endmodule

The fact that the module's $m is used inside the module
turns off automatic m-factor handling for the module,
meaning that R1 does not get an automatic m, only the
specified $m. Any current contributions, current probes,
noise contributions, or instantiations would need to be
scaled manually by the module author.

Ken's $m syntax extends easily to $n, $x, $y, $angle, $vflip,
$hflip. It addresses Kevin's concern that we not use
attributes, since this really does affect the simulation
results. It should be only a small change to the
instance-line parser (to accept .$identifier() as well as
.identifier() in the parameter list), in contrast to Kevin's
{} syntax. In an e-mail not sent to the reflector, Martin also
expressed a concern that {} would be hard to look up in the
documentation.

One concern is that this tries to reserve a lot of system
function names. It would probably be better to use longer
names to reduce the chance of collisions (SV in particular
has a lot of $system_tasks). $mfactor, $xposition, etc.

-Geoffrey
Received on Wed Jun 16 14:16:58 2004