Re: More draft 4 errata (about constant functions)

From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Tue Feb 08 2000 - 22:21:56 PST


BTF,

Based on Steve's response regarding constant function rules:
>The rule does not forbid using a parameter value that could be redefined.
>It forbids using a parameter value that *is* redefined. There is no defparam
>statement in the example, therefore the rule is not broken.

[the full context is listed below]

Could I at least beg for a restriction that only localparams be allowed to
be passed to or used in constant functions?

I'm not sure localparams had been created when the constant function was
created. Using localparams would be less ambiguous than allowing
parameters only if the parameter had not been redefined. The creator of
the constant function would have no way to know if someday, somewhere, when
he least expected it, someone redefines the parameter. Using localparams
would at least self-document the intent that the constant passed to the
constant function cannot be redefined.

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
rule would put less burden on elaborators than checking to see if a
defparam or # redefinition exists anywhere in the entire design structure.

Just my $0.02, with a sugar coated "please".

Stu

At 02:57 PM 2/7/00, Steven Sharp wrote:
>Responses to Stu:
>
>> ----------------
>> The example for a constant function violates the rules for constant
>> functions. Either the example is wrong, or one of the rules is wrong. I
>> suspect it is the latter.
>>
>> Section 10.3.5, 7th bullet says:
>>
>> "They shall not use any parameter value that is affected directly or
>> indirectly by a defparam statement (see 12.2.1)"
>>
>> But the example that follows passes a redefinable parameter as an input to
>> the function:
>>
>> parameter ram_depth = 256;
>> localparam adder_width = clogb2(ram_depth);
>> input [adder_width - 1:0] address;
>>
>
>The rule does not forbid using a parameter value that could be redefined.
>It forbids using a parameter value that *is* redefined. There is no defparam
>statement in the example, therefore the rule is not broken.
>
>If the rule seems like a kludge, it is because trying to execute Verilog
>code partway through the Verilog elaboration is inherently a kludge. These
>functions can be used to control instantiation. Instantiation can affect
>parameter values. Functions can be affected by parameter values. This leads
>to a cyclical dependency that needs to be avoided.
>
>It would be simpler to avoid it by forbidding the use of parameter values
>in constant functions. However, this would reduce their usefulness, so I
>tried to specify something less restrictive.
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.