From: Steven Sharp (sharp@cadence.com)
Date: Tue Jul 30 2002 - 15:36:41 PDT
Precedence: bulk
Since we have an implementation of this in NC-Verilog for the next release,
I can give the interpretation that we used, for whatever that is worth.
>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?
We used the entire vector identifier, since that is what the standard says
to do.
> What if a non-constant bit is selected?
>
> always @* /* @(vector) or @(vector[i]) or @(vector or i)?
> out = vector[i];
We used the entire vector identifier, plus any identifiers that occur in
the bit select expression. Again, that matches what the standard says.
>2) How are array references handled within an @*?
>
> reg [31:0] array[1:100];
>
> always @* // @(array) or @(array[10])
> out = array[10];
>
> and, what if the index is non-constant?
>
> always @* // @(array) or @(array[i]) or @(array or i)?
> out = array[i]
We expand to @(array or i). Then we produce an error, since it is not
legal to use an array identifier in an event control. I won't claim
that the standard is clear about this, but it seems like a reasonable
interpretation.
> Can an event control be sensitive *any* change
> to an array??
It is not possible in Verilog to write an explicit event control that is
sensitive to an entire array. It would cause implementation problems
in some situations.
>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 @*?
We included them, since that seemed like the most reasonable interpretation
and it was not difficult to implement.
>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?
We allowed it and interpreted it as including identifiers referenced in
the RHS expression. I would be just as happy to make it illegal instead.
>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 '@' '(' '*)'
We went ahead and handled all the combinations of spacings, though it was
painful.
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.