From: Steven Sharp (sharp@cadence.com)
Date: Thu Feb 10 2000 - 14:44:22 PST
> I still like restricting constant functions to only using localparams for
> the simple reason that the creator of the function knows for certain that
> no one else can modify the value. Localparams allows the function creator
> to remove all ambiguity. If the creator assigns parameter values to the
> localparams, then he is making a conscious decision to allow someone else
> to affect his constant function.
Yes, the creator can do this. They can do it regardless of whether constant
functions are restricted to using localparams. The restriction does not force
them to do it, and the lack of a restriction does not prevent them from doing
it. The restriction serves no purpose. In fact, the only real reason for
using a constant function is to compute a function of a parameter. This means
that all meaningful uses will require bypassing this restriction.
> Whether you permit parameters with constant functions or not, I too prefer
> the simple rule that parameter redefinition introduces some ambiguity into
> the function return value.
The BTF has asked me to come up with some verbiage to that effect.
> Finally, I am surprised that you said in-line parameter redefinition is not
> a problem. To me, it only makes it more obvious to an elaborator that a
> redefinition is occurring, but the effects, and side effects, of
> redefinition are still the same.
No. It is possible that an implementation might have a problem with this,
but there is no inherent problem the way there is with defparams. The
instantiation process can be done with a top-down traversal creating the
design hierarchy (or at least it could before arrays of instances and
generates). Parameter overrides attached to instantiations can be evaluated
and passed down during the traversal. Defparams allow instantiation to
change the values of parameters elsewhere in the hierarchy, even if those
parts of the hierarchy have already been instantiated using other values.
In fact, they can affect parameters in ancestors in the hierarchy, which must
have already been instantiated. They can even affect the values of parameters
that were passed down to their own instantiation. Defparams are evil.
> If (big IF, for you and the BTF to resolve) constant functions can utilize
> parameters that are re-assigned using in-line redefinition (with
> predictable results) then that needs to be very explicitly stated in the
> constant function rules. The way I read the rules in draft 4, any type of
> parameter redefinition voids the constant function. Rules that explicitly
> state what type of redefinition is predictable and what type is
> unpredictable (i.e.: defparam) would eliminate my preference for only
> allowing localparams.
I think you are reading your own preconceptions, rather than what is written
in the text. The restriction is clearly stated to be on defparams, not on
parameter overrides in general. Any vagueness is inherent in the fact that
the steps in the Verilog elaboration process are not well defined, which is
what makes many of these extensions problematic.
The only purpose for constant functions is to compute functions of parameter
values passed in from outside. If they could only use constant values
specified locally, the user could just compute the function themself and
specify that value also. So if the BTF doesn't allow this, then constant
functions might as well be removed. I'm in favor.
BTW, passing in parameters as arguments to the function is only a small part
of the problem. The real mess is if a function uses a parameter directly,
especially to control something structural like the width of the input
arguments. This means that changing a parameter value would not only require
the function to be re-evaluated, but re-instantiated before it could be
re-evaluated.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:11 PDT
and
sponsored by Boyd Technology, Inc.