From: Michael McNamara (mac@verisity.com)
Date: Tue Jul 30 2002 - 10:00:09 PDT
Precedence: bulk
The following reply was made to PR errata/82; it has been noted by GNATS.
From: Michael McNamara <mac@verisity.com>
To: drm@xilinx.com
Cc: etf-bugs@boyd.com
Subject: RE: errata/82: Section 9.7.5: Description of @*, @(*) incomplete
Date: Tue, 30 Jul 2002 09:59:15 -0700
drm@xilinx.com writes:
> Precedence: bulk
>
>
> >Number: 82
> >Category: errata
> >Originator: Dennis Marsa
> >Description:
>
> The description of the behavior of @* and @(*) in section
> 9.7.5 is incomplete.
>
> Previous discussion of the issues can be found in the
> following threads from the BTF/ETF archives:
>
> http://boydtechinc.com/btf/archive/btf_2002/1739.html
> http://boydtechinc.com/btf/archive/btf_2002/1804.html
> http://boydtechinc.com/btf/archive/btf_2002/1818.html
> http://boydtechinc.com/btf/archive/btf_2002/1828.html
> http://boydtechinc.com/etf/archive/etf_2002/0012.html
>
> A detailed algorithmic description of how to compute
> the set of events that an @* is equivalent to is needed
> in this section.
>
> The description should address how *all* types of statements
> and expressions should be processed when under the control
> of an @*.
>
> Some (but probably not all) specific issues that are not
> clearly addressed in Section 9.7.5 include:
>
> 1) When a bit or part select of a vector is used within
> an @*, is the event control sensitive to just the
> bit or part selected, or the entire vector?
>
> reg [31:0] vector;
>
> 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)
> 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)
>
> 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)
>
> 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)
>
> 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;
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.
I just searched through 1364-2001 and did not find a coherent
description of this; I had thought it would be in either Section 5 or
Section 9, but I did not find this.
> 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.
>
> 6) Tokenization of @* and @(*). 1364-2001 does not
> state anywhere how @* and @(*) should be tokenized.
>
> Is @* 1 token '@*' or 2 tokens '@' '*'?
> Is @(*) 1 token '@(*)' or 4 tokens '@' '(' '*' ')'
>
> If these are to be considered multiple tokens, then
> one must also consider how the attribute tokens
> '(*' and '*)' interact. Thus, @(*) could also
> be *three* tokens:
>
> '@' '(*' ')
> or '@' '(' '*)'
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.
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
@ ( * )
@ (* )
@(*)
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, as the
only problem case is [Note '.' indicates where the parsers eye ball is
focusing right now]
@ (* . )
versus
@ (* . exp *)
which the parser can disabiguate by looking ahead one token (this is
what LALR statnds for ['L'ook'A'head 'L'eft to right scanning of
input, constructing a 'R'ight most derivation in reverse, with
lookahead limited to just '(1)' token]; ref Section 4.7 of Aho Sethi &
Ulmman 'Compilers: Principles, techniques and tools, 1988), to see if
the next token is a ')' or is part of an expression.
-mac
This archive was generated by hypermail 2.1.4
: Thu Oct 10 2002 - 09:24:26 PDT
and
sponsored by Boyd Technology, Inc.