From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Sun Aug 18 2002 - 23:20:04 PDT
Precedence: bulk
The following reply was made to PR errata/82; it has been noted by GNATS.
From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/82: Section 9.7.5: Description of @*, @(*) incomplete
Date: Mon, 19 Aug 2002 09:13:00 +0300
I'm changing the subject of this subject to errata/82, because it really belongs
there.
Now that I am back at work, I have had a chance to look at the standard,
and Steven is correct (not that he needed my confirmation).
In fact, Example 2 shows exactly this case:
always @* begin // equivalent to @(a or b or c or d or tmp1 or tmp2)
tmp1 = a & b ;
tmp2 = c & d ;
y = tmp1 | tmp2 ;
end
As one of my action items, I looked at the
IEEE-SA Standards Board Operations Manual
and the IEEE Standards Companion.
Briefly, in addition to "Errata" and "Corrigenda",
there is in the middle something called "Interpretations".
The key rule about Interpretations is that they cannot change what
is written (except for fixing an erratum). That is, you cannot say in an
Interpretation that "red" means "green".
So, since Example 2 explicitly shows that intermediate values are
included
Steven Sharp wrote:
> > > There is no such exception in the standard.
> >
> > Really? Are you sure?
> > I was sure I had read it.
> > I don't have it with me to check.
>
> I have the print copy in front of me. Section 9.7.5 is less than a page
> long, so it would be hard to miss.
>
> > Not in the general case.
> > But there are cases where it is trivial.
>
> It is not as trivial as you think. And how much analysis should a tool do?
> You either have to provide a precise algorithm for all tools to use, or a
> general statement that tools can eliminate variables from the list if they
> can guarantee that they never read a value set by any other process. The
> latter would allow for optional optimization, at the cost of differences
> in the behavior of different tools.
>
> Of course, if the code is purely combinational, there should be no visible
> differences. But I've wasted a lot of time trying to track down race
> conditions in designs and trying to explain to customers that the standard
> allows different behavior in different simulators in those cases. Stating
> in the standard that differences are legal and usually indicate faulty Verilog
> code does not mean that those differences don't cause problems.
>
> > E.g.,
> > always @*
> > begin
> > a = b ;
> > c = a ;
> > end
> >
> > It is trivial to see that a is always assigned before being used.
>
> And you are incorrect in seeing that. What if a is forced or
> quasi-continuous-assigned somewhere else? Then the assignment to a has
> no effect and c will be set to the value forced/assigned. Perhaps you
> would never do that, but the fact is that a is not guaranteed to be
> assigned before being used, even in such a trivial case.
>
> Steven Sharp
> sharp@cadence.com
>
--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478
"The devil is in the details."
This archive was generated by hypermail 2.1.4
: Thu Oct 10 2002 - 09:24:28 PDT
and
sponsored by Boyd Technology, Inc.