Re: Mfactor proposal

Thanks for your feedback Geoffrey. Please see my comments
embedded starting with clc>.

On Wed, 16 Jun 2004, 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."
>
clc> Sorry about the confusion. The intention is to allow
     access to the "effective" mfactor value within analog
     behavioral blocks. The specifics of how to access it in
     behavioral blocks is being defined by the Device modeling
     sub-committee.

     In proposals 6.1.2, 6.3 and 6.4, the mfactor is explicitly
     declared within the module. This declaration semantically
     allows the access of the mfactor parameter 'name' as it becomes
     a valid symbol in that scope. Therefore, the proposals also
     indicate that the use of that 'declared name' for mfactor
     in any expression is illegal. This is because, it is not clear
     what the value of that 'declared name' will represent.

     It would still be possible to define some special access mechanism
     (like $mfactor) to access the "effective" mfactor value(which
     requires special hierarchical computation) within behavioral
     blocks.

> 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.
>
clc> The issue with using $m is that it becomes a system
     function and the language does not consider it as
     a constant. So, it would not be legal to use it in
     parameter expressions.

     Is it possible to keep the value access mechanism
     seperate from the value propagation mechanism?
 
     In the value propagation mechanism we could enforce that
     the value(expression) used to propagate the mfactor value
     is always a constant.

     In the value access mechanism, looks like there are
     three types of values which the designer might be interested
     in(using the terminology in the doc):
     1. Explicit or in its absence the implicit mfactor.
        - i.e the local mfactor for that module.
     2. Effective mfactor within the module
        - i.e the product of all mfactors from top-level to that
        module.
     3. Effective mfactor of the parent module.
        - i.e the product of all mfactors from top-level to that
        parent's module.

      Are you referring to 3. as the one which the module author
      can use to manually scale the mfactor? Or is it 1.?
  
      A special value access mechanism could be used to access each
      of these components of mfactor within behavioral blocks.

> 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.
>
clc> One other concern with using '{}' is that it is already
     used as a concatenation operator in the language. In general,
     it is used to bundle nets together. With the parameter arrays
     in the language, it would be used to bundle parameters also.
     Using it to indicate special parameter processing would mean
     defining another totally different semantics to an existing
     operator.

cheers,
Shekar.

> 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 Thu Jun 17 12:40:48 2004