From: Steven Sharp (sharp@cadence.com)
Date: Tue Jul 30 2002 - 15:10:08 PDT
Precedence: bulk
The following reply was made to PR errata/82; it has been noted by GNATS.
From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com
Cc:
Subject: RE: errata/82: Section 9.7.5: Description of @*, @(*) incomplete
Date: Tue, 30 Jul 2002 18:04:46 -0400 (EDT)
> > always @* /* @(vector) or @(vector[5])?
> > out = vector[5];
> >
>
> --> Handle the same way as
>
> assign out = vector[5];
>
> I.E., one is sensitive just to a change in the value of the expression
> vector[5]; (See 5.6.1, 9.7.2)
I don't see where those references imply this. However, 9.7.5 clearly states
"All net and variable identifiers which appear in the statement will be
automatically added to the event expression with these exceptions:..."
Note that vector is an identifier and vector[5] is not an identifier.
Section 9.7.5 therefore says to add vector and not vector[5]. I see no
ambiguity here. Someone can claim it is wrong, but it is not unclear.
> > What if a non-constant bit is selected?
> >
> > always @* /* @(vector) or @(vector[i]) or @(vector or i)?
> > out = vector[i];
>
> --> Handle the same way as
>
> assign out = vector[i];
>
> I.E., one is sensitive just to a change in value of evaluating the
> expression vector[i]; (See 5.6.1, 9.7.2)
Again, section 9.7.5 says to add identifiers appearing in the statement.
That makes the answer @(vector or i). I see no ambiguity here.
Furthermore, as I have pointed out before, there are situations that
will not behave properly with @(vector[i]). They require @(vector or i)
in order to act like combinational logic. So not only does the letter
of the standard require it, so does the intent.
> > 2) How are array references handled within an @*?
> >
> > reg [31:0] array[1:100];
> >
> > always @* // @(array) or @(array[10])
> > out = array[10];
>
> --> Handle the same way as
>
> assign out = array[10];
>
> I.E., one is sensitive just to a change in the value of the expression
> array[10]; (See 5.6.1, 9.7.2)
Again, this doesn't match the standard.
However, expanding as specified by the standard results in being equivalent
to something illegal and undefined. My view is that this makes the user's
code illegal. Someone could take a different view, but then they will need
to define what the behavior is, since there is no legal equivalent.
> >
> > and, what if the index is non-constant?
> >
> > always @* // @(array) or @(array[i]) or @(array or i)?
> > out = array[i]
> >
> > Can an event control be sensitive *any* change
> > to an array??
>
> --> Handle the same way as
>
> assign out = array[i];
>
> I.E., one is sensitive just to a change in value of evaluating the
> expression array[i]; (See 5.6.1, 9.7.2)
Again, this is not what the standard says, nor will it give the correct
results in all cases.
> >
> > 3) How are named-begin/fork blocks handled when under
> > the control of a @*?
> >
> > always @*
> > begin : named
> > ...
> > end
> >
> > Presumably, names defined and used within the named
> > block would not be included the @*?
>
> There is no way to be sensitive to values declared inside the block
> as:
>
> 1) they have no existance outside the block;
Not true. They exist just fine, and can be read or written from outside
the block by using the hierarchical name named.variable_name.
> 2) an @(exp) statement is only 'energized' by having the flow of
> control flow to the statement @(exp). Only then is the statement
> guarded by the event control placed on a queue for execution when the
> value of exp evaluates to something other than it's current value.
Since they exist at that point, there is no reason they can't be waited on.
This one is a little sticky, since the only "equivalent" way to add the
identifier to the event list is with a hierarchical reference. But that
is a way that the identifier can be added.
You could argue that the named block is an attempt to keep the variables
local, so they shouldn't go into the list. However, hierarchical names
in Verilog mean that no variables are really local. Someone could write
to them from outside the block, and the event control would need to include
them in order to implement combinational logic.
> > 5) The syntax description of @* allows @* to be used
> > as an intra-assigment event control:
> >
> > a <= @* b;
> >
> > Section 9.7.5 does not define any semantics for this
> > contruct. Is it meaningful/useful? Should it be
> > considered a semantic error?
>
> I believe you are right. Because intraassigment delay evaluates the
> RHS, and then place the value aside, and waits for the event
> expression to fire, after which it assigns the value to the lHS, it
> makes no sense for the event expression to be derived from the value
> of the rhs expression.
You are right that this is unclear, and I don't see any reasonable
interpretation that makes sense or is useful. The easiest thing would
be to make it illegal.
> > 6) Tokenization of @* and @(*). 1364-2001 does not
> > state anywhere how @* and @(*) should be tokenized.
> > ...
>
> I believe that tokenization discussion this is outside the scope of
> the IEEE 1364-2001 specification. There is no discussion of
> tokenization of anything else in the specification, except perhaps the
> notes in the BNF that talk about making illegal the use of spaces
> between $ and display, or in general the use of spaces in a name.
Section 2, and particularly 2.1 discuss tokens.
> Inany case, where we are, the standard says that @(*) must be treated
> as the implict event control; and without any special rules, this also
> allows
>
> @ ( * )
> @ (* )
> @(*)
Not true if '(*)' is a token, which is not clear.
> I submit that there is no ambiguity that a LALR(1) parser (like Yacc &
> bison) used in conjunction with lex (or flex) could not handle
It is painful, and normally one would try to avoid it in the language.
However, it is resolvable with some extra work.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2.1.4
: Thu Oct 10 2002 - 09:24:26 PDT
and
sponsored by Boyd Technology, Inc.