From: Steven Sharp (sharp@cadence.com)
Date: Tue Jun 25 2002 - 18:20:14 PDT
Precedence: bulk
>> I disagree. The reference to block[i].w is a hierarchical name,
>> so it will not result in an implicit declaration.
>
>Actually, although it *looks* like a hierarchical name, you pretty
>much have to treat them as identifiers since they get lifted
>as declarations into the module's scope.
I disagree that they get lifted into the module scope. The named
block appears in the module scope, but creates a sub-scope. This
is admittedly not at all clear in the document. However, I can
definitely state that this is what was intended, since I am the one
who proposed this change to generated names.
>If one wants to treat that form of name as following
>hierarchical name resolution (which I *do* want BTW),
Great :-)
> then
>some forms of generated "use before declaration" are
>valid, but not others. For example:
>
> generate
> if (0) begin
> wire x;
> end
> begin
> assign x = 1;
> end
> begin
> wire x;
> end
> endgenerate
>
>
>Would assumably be invalid yet naming the second block would
>cause us to use something that looks like a hierarchical
>name in the first block and resolution would be Ok. Reversing
>the order of the blocks would assumably yield a correct
>design, but that relies on doing *identifier* resolution
>in the implied final module with no form of hierarchical name
>involved.
Yes, you are correct in all of this. Note that this is nothing new.
Consider these examples in Verilog-1995:
module top;
buf b(x, 0); // x undeclared, implicit net declaration
wire x; // duplicate declaration, invalid
endmodule
module top;
buf b(top.x, 0); // hierarchical name, resolves OK
wire x;
endmodule
module top;
buf b(foo.x, 0); // hierarchical name, resolves OK
initial begin: foo
reg x;
end
endmodule
module top
wire x;
buf b(x, 0); // identifier declared, resolves OK
endmodule
One further comment: named begin-end blocks appeared in the generate
spec before my proposal. I asked the BTF whether these were just for
documentation purposes, or whether they created scopes like named
blocks in procedural code. This question was never answered. So I
can't say whether named blocks inside generates create scopes. I can
only say that the named block that is required inside a generate-for
creates a scope. This tends to imply that the others do too, but that
may not have been the intent. All the begin-end blocks may have been
intended to disappear, names and all. Then I proposed requiring a
named block inside a generate-for and creating generated names from it,
which incidentally make it act just like a scope.
>I was going to raise the above as a separate issue and
>was going to propose that we actually follow
>hierarchical resolution rules when names *appear* to be
>in hierarchical form and to follow *static* scope rules
>otherwise. This would meant the "assign x" case above
>would result in an implicit net independent of the order
>of the blocks. In some cases such a rule would be
>surprising, but not many, and it is a consistent and
>easy to explain rule.
Maybe I don't understand what you are saying. If there is an
unconditional declaration of wire x before the assign x, then
it should be resolved, with no implicit net. The blocks are
not named, so they don't create scopes, and the declaration of
x appears in the module scope. There is no precedent for an
unnamed block to create a scope, and there is plenty of reason
for it not to. Of course, there is no precedent for a declaration
in an unnamed block either, which muddies the issue.
>Ah - could be. So was the intent to follow strict static scoping
>as I mention above?
I don't think so, unless I misunderstood you.
>In VHDL the lines are much more clean (even without the
>hierarchical names) -- *every* generated block has a tag
>and the declarations that are part of a generated block
>are restricted to the scope of the related block.
Yes. I proposed that named blocks be required in additional
places in generates, to get the same effect. The BTF rejected
this. The only reason that I was able to get the names on
for-generates was that the old approach created an ambiguity
in the generated names.
>The
>fact that you can have unnamed blocks can define the
>*same* identifier and such identifiers only cause a
>name conflict when lifted into the module scope is
>quite awkward.
I agree, which is why I tried to fix it.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:38 PDT
and
sponsored by Boyd Technology, Inc.