From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Sun Aug 18 2002 - 23:20:05 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:12:56 +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, Option 2 that Steven mentions below would seem to be a
"substantive change" which would belong to a corrigendum and require
re-balloting.
Option 3, since it does not really invalidate Example 2, might
be able to pass in an Interpretation.
I'll try to prepare fuller descriptions of errata, interpretations, and
corrigenda
for the next meeting.
Shalom
Steven Sharp wrote:
> We cannot define the behavior of the language in terms of an algorithm
> that does not and cannot exist. That leaves several choices:
>
> 1. Leave the sensitivity list independent of whether variables could
> get values from outside the block. That is how it is now.
> 2. Specify the exact algorithm to be used to approximate the computation
> of whether a variable can get its value from outside the block.
> 3. Specify that simulators can leave variables out of the sensitivity
> list if they can determine that they never get a value from outside
> the block, by whatever algorithm they like. This could result in
> different simulators producing different results if the block has
> side effects.
>
> Note that if the block has no visible side effects (which should be true
> of any truly combinational code), a simulator can already optimize the
> sensitivity list if it likes, using whatever conservative approximation
> it likes. Its behavior would be equivalent to the standard behavior and
> therefore legal. The only advantage of option 3 above is if there are a
> significant number of blocks which have side effects or which the compiler
> can't be sure don't have side effects (since this is uncomputable too).
> I don't know how common this will be.
--
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.