From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Fri Jun 21 2002 - 07:41:22 PDT
Precedence: bulk
Steven Sharp wrote:
>
> >That depends on how you deal with generated wires and cascaded
> >connections from one iteration of a loop to another. I have another
> >clarification issue that is related. Consider the following:
> >
> > generate
> > genvar i;
> > for (i = 0; i <= LAST; i = i + 1) begin :block
> > wire w;
> > if (i == LAST)
> > someChild c(w, some_input);
> > else
> > someChild c(w, block[i+1].w);
> > end
> > endgenerate
> >
> >Here a connection is made in a forward manner to the "next"
> >instantiation of w in the next generated block.
> >
> >Is this valid?
>
> The intent was for this to be valid.
I agree that it should be valid in terms of "niceness of
use".
> >If one considers the "flattened equivalent" it isn't since
> >the forward reference will be an implicit net that
> >conflicts with the subsequent explicit declaration from
> >the next iteration of the loop.
>
> 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.
If one wants to treat that form of name as following
hierarchical name resolution (which I *do* want BTW), 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.
Again, I'm not saying that this shouldn't be the
interpretation, I'd just like to have some agreement
on what a vendor tool is supposed to do.
The whole issue of "scope" is pretty strange -- there is
the "pseudoscope" of the generate which applies in some
areas during elaboration and then there is the "real" module
scope into which generated items get lifted. The LRM is not
very clear in cases such as the above.
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.
> This already
> has to be handled properly for hierarchical references in Verilog.
> They don't result in implicit declarations either.
>
> > If you allow the
> >forward reference, you get into other weird issues.
>
> No more than any other hierarchical name, which may need to
> wait until instantiation is finished before it can be resolved.
>
> These names don't just accidentally look like hierarchical names.
> The named blocks "block[i]" can be treated as scopes with generated
> names, with w as the name of a wire in each scope. You could treat
> the name "block[i].w" as some kind of monolithic generated name, but
> it would be a lot tougher than treating it as a hierarchical one.
>
> Apparently this is not clear from the standard. Perhaps this is due
> to text left over from before I proposed changing it to work this way.
Ah - could be. So was the intent to follow strict static scoping
as I mention above?
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. 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 understand, and fully agree with the
motivation for doing exactly that for module instantiations,
but for declarations it becomes really ugly.
> >And it you want to do this loop in reverse to solve
> >the name resolution issue, you run into the negative
> >genvar value problem.
>
> The loop reversal would solve the name resolution problem in
> this particular case. However, it would not solve the more
> general case where there are references both forward and
> backward. I suppose this could be avoided by always declaring
> the nets in the "earlier" iteration, but so could your situation.
> It could get pretty clumsy. Fortunately, treating the name as
> a hierarchical reference solves the problem completely.
>
> >Of course all of this can be avoided through design style,
> >but if someone has a testbench generator (or similar) that
> >does something like this, I certainly hope that your
> >solution and my solution behave the same. That is
> >the purpose of a standard, right? :-)
>
> Apparently this one isn't clear enough :-).
>
> This concept of a generate-for as something that gets
> executed leads to all kinds of problems. It leads to
> concerns about the order of execution, whether execution
> will terminate, what happens on the final execution of the
> increment that isn't associated with instantiation, and
> so forth. Generate-for should never have used a Verilog
> for-loop to iteratively specify the declaration of multiple
> objects. It should have used a range to specify them, just
> like all the other declarations. This would have inherently
> avoided all of these issues.
Absolutely!
Of course, non-termination of elaboration is an issue now anyways
since one has to be concerned about non-terminating recursive
instantiations. That part is an issue in VHDL as well.
Gord.
-- ---------------------------------------------------------------------- Gord Vreugdenhil gvreugde@synopsys.com Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054 Synopsys Inc., Beaverton OR
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:37 PDT
and
sponsored by Boyd Technology, Inc.