From: Steven Sharp (sharp@cadence.com)
Date: Mon Feb 07 2000 - 14:57:48 PST
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.
> ----------------
> Section 10.3.5, The 4th bullet contradicts the 2th bullet. The 2nd bullet
> says:
> "Any function invoked within a constant function shall be a constant
> function local to the current module. System functions shall not be
> invoked."
> But the 4th bullet says:
> "The only system task that may be invoked is $display, and it shall be
> ignored
> when invoked at elaboration time."
> I suggest striking the 2nd sentence of the 2nd bullet.
>
This is not a contradiction. The first statement refers to system *functions*.
The second statement refers to system *tasks*.
An alternative way of writing this would be
"The only system task or function that may be invoked is $display, and it
shall be ignored when invoked at elaboration time."
I personally think that the exception for $display is a mistake, but I was
outvoted.
> ----------------
> It was not clear to me from reading section 10.3.5 where it is legal to
> call a constant function at elaboration time. The example assigns the
> return of the constant function to a localparam, and uses the localparam in
> a constant expression. Would it also have been legal to use the return of
> the constant function directly in the constant expression? That is:
>
> input [clogb2(ram_depth)-1:0] address;
Yes, this would be legal.
> Verilog part selects are also based on constant expressions. Can a
> constant function be used in this context? I hope not! Code like that
> would not be intuitive. It contexts such as a continuous assignment would
> be hard to tell that the function was called at elaboration time, and not
> during run time. For example:
>
> wire [31:0] foo;
> wire [7:0] bar = foo[myFunc(2)+8:myFunc(2)]; //assume myFunc returns 0 to
23
>
> If either or both of these are not legal, then the rules for calling
> constant functions need clarification (IMHO).
Yes, this would be legal. As you point out, it would be confusing. This is
just one of the many problems with constant functions.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:11 PDT
and
sponsored by Boyd Technology, Inc.