From: Michael McNamara (mac@verisity.com)
Date: Tue Jun 25 2002 - 17:36:45 PDT
Precedence: bulk
Good discussion all around; I was going to comment earlier, but you
two seemed to have found your way around the rabbit hole...
One comment I do have at the end.
Gordon Vreugdenhil writes:
> 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!
Actually, a range type declaration would not have allowed things like
triangular arrays of interconnected modules:
genvar gv_i, gv_j;
parameter TSIZE=16;
generate
for (gv_i =0; gv_i < TSIZE; gv_i = gv_i + 1) begin: idim
for (gv_j = 0; gv_j < gv_i; gv_j = gv_j + 1) begin: jdim
mod m(a[gv+i], b[gv_j], c[gv_i][gv_j]);
end
end
endgenerate
Yes, Kurt Baty really did want these, aparently for better description
of DesignWare parts.
> 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.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:38 PDT
and
sponsored by Boyd Technology, Inc.