Re: Mfactor proposal

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.

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.

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?

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.

-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 Mon May 24 22:42:16 2004