From: Michael McNamara (mac@verisity.com)
Date: Fri Jun 21 2002 - 10:58:19 PDT
Precedence: bulk
Indeed. I met with the IEEE owners :-) of our standard and now know
the operating rules by which we can clarify the 1364-2001 standard.
We actually have fairly wide lattitude in makeing our corrections;
even to the extent that we can sate that, for example:
The sentence at the end of paragraph 5 of Section 12.4 that
reads:
The sky is blue.
Should be interpreted as if it said:
The sky is red.
We have a large number of errata to work though, and I would like to
call a Kick off conference call at noon pacific time, either next week
(perhaps Wednesday June 26th?), or two weeks from then (Wednesday July
10th) to start this effort.
AGENDA
1) Welcome
2) Define Roadmap for the 1364 Working Group
3) Construct Task Forces as appropriate
4) Begin work on Errata process
5) Sent time/place of next meeting
6) Adjourn
Please all, let me know your availability, suggest alternate dates,
and so on.
Stuart Sutherland writes:
> 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.