From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Fri Jun 21 2002 - 10:21:26 PDT
Precedence: bulk
All,
I don't think Accellera is the right place for making clarifications to the
official 1364-2001 LRM. It should come from the IEEE 1364 working
group. My understanding from Mac is that the IEEE 1364 working group can
publish a list of errata, corrections, clarifications, and "official
interpretations" to the 1364-2001 LRM. I am sure putting together this
list will be high on the list when we resume meeting in a couple of months.
Stu
At 07:29 PM 6/20/2002, Steven Sharp wrote:
>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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:37 PDT
and
sponsored by Boyd Technology, Inc.