From: Steven Sharp (sharp@cadence.com)
Date: Thu Jun 20 2002 - 19:29:46 PDT
Precedence: bulk
>I am actually at least as interested in having some
>of this move forward to Accellera as an "adopted interpretation"
>that is recommended to the next IEEE committee. If there is no
>interest in looking at new 1364-2001 issues until the next
>major round, that is fine. I'm just trying to be a good citizen
>but am certainly willing to do my own thing.
Suggesting revisions for the future is fine; I think Shalom has
already submitted a proposal that the restriction on negative values
for genvars be completely removed. I don't know what the exact
process is for making these kinds of proposals at this time. I just
wanted to avoid any misunderstandings about revising the current
standard.
And there is also the possibility of discussing general adoption of
non-standard extensions, correcting issues found during implementation.
If the major vendors can agree on a solution, we can get a de facto
standard without waiting for the next official standard. This forum
may be a reasonable place to discuss such things, especially if we
propose them as revisions for the next standard. It has the advantage
of being a centralized and openly available forum.
>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.
>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. 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.
>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.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:37 PDT
and
sponsored by Boyd Technology, Inc.