Re: Mfactor proposal

Geoffrey.Coram wrote:

>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.
>
>
Hard to look up in comparison to what? NB: I suggested the {} syntax
because it is similar to the instance multiplier syntax already used in
Verilog - I'd probably document it in the same part of a (unified) LRM .

$m seems a reasonable alternative but I wouldn't make the choice on how
much work goes into fixing the parsers (since that is usually minor).
Does somebody already use/allow $<name> parameters?

>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.
>
If there is no prior use of $<name> parameters then there should be no
name clashes, so short names would be OK. Since the long names only make
sense in English and there are plenty of non-english speaking users out
there I tend to just vote for minimal typing these days.

How would all these "special" parameters work? - Do they accumulate down
through the hierarchy like m-factor?

Kev.

>
>-Geoffrey
>
>
Received on Wed Jun 16 14:46:07 2004