From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Thu Jun 20 2002 - 17:31:13 PDT
Precedence: bulk
Steven Sharp wrote:
>
[...]
> Note that the standard has been passed, and is no longer subject to revision
> until the next standard. Errata can be reported, but this sounds like a
> revision, not an erratum.
Of course. 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.
> You always have the choice of implementing a non-standard extension that
> works the way you like. Personally, I don't see any reason someone would
> need to use a decrementing generate for-loop instead of an incrementing
> one anyway. Once the contents are generated, I don't see how it can
> matter what order they were generated in. Any order that produces the
> same instantiations should be equivalent.
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?
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. If you allow the
forward reference, you get into other weird issues.
And it you want to do this loop in reverse to solve
the name resolution issue, you run into the negative
genvar value problem.
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? :-)
> (In practice there might be a
> difference in something like event order in a given simulator, but that
> would be considered nondeterministic by the standard). So there is a
> simple workaround to the issue: don't use decrementing loops if you want
> a zeroeth iteration.
>
> Some prior discussion of this issue appears at:
>
> http://boyd.com/1364_btf/archive/btf_2001/
>
> starting with the question at:
>
> http://boyd.com/1364_btf/archive/btf_2001/1150.html
>
> Steven Sharp
> sharp@cadence.com
Thanks. I will peruse the archive and see if other issues that
I am concerned about have been addressed. Cliff didn't seem
to think they had; I certainly don't want to waste everyone's
time by resurrecting long-resolved issues. I have better things
to do too.
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.