From: Steven Sharp (sharp@cadence.com)
Date: Wed Aug 08 2001 - 11:59:23 PDT
>1. In the context of a for-generate statement is this snippet
>of verilog a valid usage of parameter-override ???
>
>module flop(input in, clk, output reg out);
>parameter xyz = 1; // dummy, not used
>
>always @(posedge clk)
>begin
> out <= in;
>end
>
>endmodule
>
>module simple(input [7:0] in, in1, output [7:0] out1);
>
> genvar i;
>
> generate for(i=0; i < 8; i = i+1)
> begin : somename
> flop my_flop(in[i], in1[i], out1[i]);
> defparam somename[2].my_flop.xyz = 2; // <----- is this the correct
>usage ???
> end endgenerate
>
>endmodule
If you are going to override the parameter at the instantiation, you
should use a module instance parameter value assignment, not a defparam.
Examples:
flop #(2) my_flop(...)
or
flop #(.xyz(2)) my_flop(...)
Use of defparams is not good practice. And your example is rather
strange, since it defparams the same parameter 8 times. It is not
a good example of how a defparam inside a generate could be useful.
However, you are presumably asking what is legal and needs to be
implemented in tools.
Your example appears to be legal syntax. However, it looks illegal
semantically. A defparam inside a generate is not allowed to
redefine a parameter that is not in the hierarchy under that generate.
The defparam that is generated inside somename[1] may not be allowed
to modify a parameter inside somename[2], since that is not in the
hierarchy under somename[1]. Only the instance of the defparam inside
somename[2] is clearly legal. This is a little uncertain, since both
instances of somename are inside the same generate loop, though
different iterations of it.
Shalom's example of
defparam somename[i].my_flop.xyz = i ;
should be legal.
<p>>2. If yes, the LRM says that the generated instances names should be :
>
> somename[0].myflop
> somename[1].myfop ...etc.
>
> However, the defparam usage has added an extra dot to the above
>generated instance names, which can be mistaken by the tools
>as a hierarchical name of depth 3 ( the association is left to
>right ).
There is no confusion. It *is* a hierarchical name of depth 3. The
named block "somename" is a level of hierarchy. It acts similarly to a
named block in procedural code, which also adds a level of hierarchy and
an extra dot to the names of any objects declared inside it.
>In this case though, the depth is just 2 and my opinion
>is the association should be done right to left. How can we
>differentiate
>**clearly** which is which ??
We don't need to; they are not different. Associating left to right
works just fine. We look at the name "somename" and find it in the current
scope. There must be only one, or there is a duplicate declaration of the
same name in the current scope, which is an error. Then we look at the
subscript and insist that it be an object that can be indexed. If it is
a scope, we require the index to be constant. Then we see the next dot,
and insist that "somename" must be a scope. At this point it could legally
be an instance array or a named block inside a generate loop. Then we look
for the next name component in that scope. It works pretty much the same
way as any hierarchical name, except for the handling of the index.
> What if the user really has an instance
>name called somename[1] ??
If they declared a named block named "somename" in the same scope as an
instance array named "somename", then they have declared a duplicate
identifier in the same scope. This is illegal. Try the following
similar case without generates in your favorite Verilog-1995 compliant tool.
module top;
flop somename();
initial begin: somename
parameter xyz = 0;
end
endmodule
> How do we flag this error ???
Verilog-XL flags the similar case with
Error! Block name (somename) previously declared [Verilog-BNAPD]
NC-Verilog flags it with
initial begin: somename
|
ncvlog: *E,DUPIDN (test.v,3|23): identifier 'somename' previously declared
[12.5(IEEE)].
Once you realize that the extra component of the name really is a level of
hierarchy, not some new thing with the same syntax, you should see that
there is no problem.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:43 PDT
and
sponsored by Boyd Technology, Inc.