From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Wed Feb 09 2000 - 14:21:53 PST
Steve,
I didn't mean to open a can of worms. And I appreciate your patience in
explaining the issues of parameters and constant functions.
Let me throw out my last $0.02, and then I'll get back to dealing with the
PLI that only has to worry about things after elaboration has solved the
world's problems ;)
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.
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.
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.
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'll shut up now. Whatever the BTF decides, I'll live with.
Stu
<p>At 10:30 AM 2/9/00, Steven Sharp wrote:
>
>> Could I at least beg for a restriction that only localparams be allowed to
>> be passed to or used in constant functions?
>
>Why? It is an arbitrary restriction that does nothing to solve the problem.
>
>> Using localparams
>> would at least self-document the intent that the constant passed to the
>> constant function cannot be redefined.
>
>Since localparams can be redefined indirectly via parameters, I don't see
>how using them documents an intent to do otherwise.
>
>> Since a localparam can be assigned values based on parameters, I would
>> suggest also adding a caveat to the effect "If the value of a localparam
>> used by a constant function is affected by a parameter that is redefined,
>> the return value of the constant function shall be indeterminate."
>
>This just describes the same "fuzzy" restriction, with an extra complication
>that it refers to localparams affected by parameters, instead of just to the
>parameters themselves. Restricting to localparams has just made things more
>confusing.
>
>However, it may be a good idea to change the wording to state that the return
>value of a constant function is indeterminate if it refers to a parameter
>that is affected by a defparam. This would remove any implication that the
>elaborator would point out the error to the user.
>
>> This
>> rule would put less burden on elaborators than checking to see if a
>> defparam or # redefinition exists anywhere in the entire design structure.
>
>Forbidding a defparam in this situation does not require the elaborator to
>check for it. It just makes the unexpected behavior the fault of the user.
>Your approach to describing the restriction has the advantage of making this
>clearer.
>
>Also, I don't think that # redefinition is a problem, as long as there is
>not a defparam involved somewhere. In fact, allowing # redefinition is
>important to some uses.
>
>Sorry if my responses are not very sugar-coated. I was strongly opposed to
>constant functions because of these kinds of problems. I was asked to come
>up with "fixes" for the problems. I have very little patience with complaints
>about the fixes, since the only clean fix was rejected: remove constant
>functions from the standard.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:11 PDT
and
sponsored by Boyd Technology, Inc.