parameter declarations and hierarchical references - verilog

Mike wrote:
>
> In the 1364-1995 spec, it specifically states that if the RHS of a
> defparam statement contains references to parameters, then those
> parameters must be declared in the same module as the defparam
> statement.

The RHS of a defparam and the default value of a parameter are both
required to be "constant expressions" (as are some other expressions
in the language, such as the ranges in vector declarations).
Hierarchical
identifiers are not allowed in constant expressions. So parameter
values
cannot be set using a hierarchical reference to a parameter.

> I am guessing that this is to simplfy parameter value resolution during
> elaboration?

Not only does it simplify things, it helps prevent circular
definitions. Those
could result in multiple different self-consistent values for the
parameters,
or self-contradictory values for the parameters. Consider the case:

parameter p1 = thismodule.p2;
parameter p2 = p1 + 1;

Now what are the values of p1 and p2?

Thanks for clarifying the hierarchical name reference stuff for me.

It is also true that upwards name references are not allowed in a
parameter declaration (or more generally, not allowed in a constant
expression)?

Mike wrote:
>
> It is also true that upwards name references are not allowed in a
> parameter declaration (or more generally, not allowed in a constant
> expression)?

I am not sure what you mean by "upward name references". To me, the
term implies an upward hierarchical reference, i.e. a hierarchical
reference that is resolved by searching upward in the design hierarchy
until the name is found. But we have already established that no
hierachical references are allowed in constant expressions.

Perhaps you meant a "forward name reference", a reference to a
parameter that is declared later in the module than the reference.
These are not allowed either. Note that allowing them would allow
circular definitions.

> I am not sure what you mean by "upward name references". To me, the
> term implies an upward hierarchical reference, i.e. a hierarchical
> reference that is resolved by searching upward in the design hierarchy
> until the name is found. But we have already established that no
> hierachical references are allowed in constant expressions.

Yes, I meant a reference that is resolved by searching upward the
design hierarchy, terminating when either the name is found or a
module boundary is encountered. For instance, the following seems
to work because in the parameter declaration for p1, the reference
for p0 is found not in the scope of t, but in the scope of m. The
identifier "p0" is not explicitly hierarchical (i.e. does not contain
any '.' characters), but only exists one level up the hierarchy tree.

module m;
parameter p0 = 2'h1;
initial t;

task t;
parameter p1 = p0 + 1'h1;
$display("%b, %b", p0, p1);
endtask
endmodule
------------------------------------------------
Compiling source file "hparam2.v"
Highest level modules:
m

01, 10
0 simulation events (use +profile or +listcounts option to count)
CPU time: 0.0 secs to compile + 0.0 secs to link + 0.0 secs in
simulation
End of Tool: VERILOG-XL 05.30.002-s Jul 11, 2006 12:50:49

Mike wrote:
> The
> identifier "p0" is not explicitly hierarchical (i.e. does not contain
> any '.' characters), but only exists one level up the hierarchy tree.

And since it is not a hierarchical reference, it is legal in a constant
expression. This is just nested scope rules, not actually hierarchical
name resolution. While both do involve an upward search, they are not
the same thing. The scope rules just involve static nesting of the
scopes, do not use hierarchical names, and can always be resolved at
parse time. They still do not allow forward references, so the
references are always to something earlier in the file. Since all
references are in one direction, that prevents any circularities or
other problems.