From: Michael McNamara (mac@verisity.com)
Date: Tue Jun 25 2002 - 21:18:14 PDT
Precedence: bulk
Steven Sharp writes:
> 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.
The inetent was that they would create a scope. At one point it was
required that every generate key word be followed by a named block.
Note that every generate loop DOES require a named begine block.
>
> >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.