Re: Mfactor proposal

Hi Ken,
Thanks a lot for your feedback. Please see my comments
embedded starting with clc>.

On Mon, 24 May 2004, Ken Kundert wrote:

> Shekar,
> Thank you for investing your time in putting together this
> proposal. It provides some new ideas on how to address this problem.
>
> Here are my comments:
> 1. On page 4 you indicate that specifying an mfactor using a defparam
> should not be allowed because of a possible cycle. You give the example,
> defparam top.m = m;
> and say that top.m would depend on m, which in turn would depend on
> top.m, which is a cycle. However, it seems that in the rest of your
> proposal, one cannot explicitly use m in this way. Several times you say
> that the mfactor could not be used in an expression. This restriction
> would seem to eliminate the the possibility of a cycle and so the
> defparam restriction would not be needed.
>
clc> Yes, I will rewrite that requirement indicating that mfactor
     should not be used in an expression. Will then change the
     defparam example to demonstrate the "cycle" effect when using
     m-factor in an expression.

> The restriction that mfactor not be used in an expression is important
> to enforce anywhere an mfactor is specified, not just in defparams.
> Specifying an mfactor in terms of an mfactor would result in undesired
> behavior. Consider defining a module my_res and assume that m represents
> the mfactor parameter
> module my_res (a, b);
> parameter real r;
> resistor #(.r(r), .m(m)) R1 (a, b);
> endmodule
> Then, instantiating my_res with m=n would result not in n resistors in
> parallel, but rather n^2, thus breaking the intent of the mfactor.
>
> 2. In proposal 6.1, you suggest adding an attribute on an instance
> specifying what name of the parameter that will be used to specify the
> mfactor on the instance. I have a few comments about this.
>
> You don't really specify what happens if you choose a name of an
> existing parameter. It would be bad if someone indicated that the name
> of the mfactor on a resistor is r, and then have r used both for the
> resistance and the mfactor. So presumably in this case, r would act as
> the mfactor and the resistance of the resistor would take its default
> value. This way, one could choose the name to be used for the mfactor
> without needing to know all of the parameter names for an instance. For
> example, consider wanting to specify a multiplicity factor on an
> instance that accepted say 100 different parameters. If one had to
> choose a name that did not conflict with those parameters, then you
> would have to know the names of all of them, making the job of
> assembling the netlist quite difficult. However, if the name specified
> to represent the mfactor simply caused a module parameter of the same
> name to be defaulted, then the person assembling the netlist is free to
> use any name for the mfactor parameter other that those used to
> explicitly specify values for module parameters on that instance.
>
clc> Excellent point. This could infact be the disadvantage of allowing
     users to decide the name of the mfactor as it can result in
     undesirable parameter values. For eg, consider parameters dependent
     on one such parameter which gets overwritten as a mfactor at some
     level of hierarchy. Tracking its value is not straightforward.

     This can be another reason to consider having one standard identifier
     to denote the mfactor parameter.

> However, I'm left wondering why you chose this rather round-about
> approach to specifying the mfactor. Rather than use an attribute to
> specify the name of the mfactor parameter, and then specifying the value
> of the mfactor in that parameter, why not just specify the value of the
> mfactor in the attribute?
>
clc> By keeping the mfactor value within parameter overrides, the semantic
     checks for a parameter(like constant expression) would automatically
     apply to mfactor. Instead, if the value is specified in the
     attribute, the attribute needs additional meaning to indicate that
     it holds a constant expression, the attribute's value(expression)
     needs to be evaluated(it could be an expression of other parameters).

> My feeling is that using attributes, especially ones with such long
> names, tends to make the netlist difficult to produce and to read, which
> is undesirable.
>
> 3. In proposal 6.4 you have merely reserved a particular parameter name
> for the multiplicity factor, that name is "passed_mfactor".
> Conceptually, it is the same as declaring "m" as the name used
> everywhere to represent the multiplicity factor as Spice did. The only
> difference is that "passed_mfactor" is less likely to conflict existing
> parameter names than "m" is, but it also much less concise, making
> netlists harder to enter and harder to read.
>
> 4. Proposal 6.2 is a more extreme version of proposal 6.4. In it you
> make "mfactor" a keyword rather than just a reserved parameter name.
> Choosing "mfactor" as a keyword means that it cannot be used as a
> parameter name, or any other name for that matter. It would be less
> obtrusive if we just made "mfactor" a reserved parameter name.
>
> Now I'd like to make an observation somewhat independent of your
> proposal. The mfactor parameter could be considered as a new type of
> parameter, one that affects the instance but that is implemented by the
> simulator. Thus, you specify it on the instance but you do not
> explicitly refer to it in the module. There might be other such
> parameters. In fact, the paramset proposal gives a list of parameters
> that are of this type. It calls them "hierarchical attributes". They
> include m, n, x, y, angle, hflip, and vflip. The m and n parameters are
> multiplicity factors, m indicates a shunt multiplicity and n indicates a
> series multiplicity. x, y, angle, hflip, and vflip are used to give
> layout information that would be needed if one is to do accurate
> variational analysis. So we might want to avoid proposals that allow
> only a single "magic" parameter, and rather consider proposals that
> support a new class of parameters. One might do this by marking these
> new type of parameters with a special character or identify them using
> special syntax. For example, consider identifying them by simply adding
> a $ to the front of the name. Then you can specify multiplicity factor
> on any instance using
> resistor #(.r(50), .$m(2)) R1 (a, b);
> without risk of conflict with existing parameter names.
>

clc> Yes, the semantics/syntax should be extensible for similar class
     of parameters. One reservation though with using the '$' character
     would be that it has already been used in the language to identify
     system tasks and functions which are not considered as constant
     expressions.

     It may also collide with user-defined system tasks or functions.
     
     How about considering '$#m' or '#m' as # is frequently associated
     with constant expressions in the language?

     I'll update the document with all your feedback.
cheers,
Shekar.

> -Ken
>
> CLC Shekar wrote:
> > Hi all,
> > Please find attached a pdf document outlining the proposal for mfactor
> > support in Verilog-AMS(structural). Please let us know your comments.
> > cheers,
> > Shekar.
>
Received on Thu Jun 17 11:18:07 2004