From: Steven Sharp (sharp@cadence.com)
Date: Wed May 01 2002 - 13:33:08 PDT
Precedence: bulk
I don't have the address any more for the person who was asking about the
semantics of the @* construct. Perhaps someone else can forward this.
I now have my official IEEE 1364-2001 standard to consult for the "letter
of the law."
The big ambiguity seems to be what to put into the event control for an
expression like foo[0] or foo[i], particularly when this is an array
reference rather than a bit select.
Let me first address the situation where foo is a vector and this is a
bit select. The standard specifies that net and variable identifiers
will be added to the event expression. So for foo[0], that would be
@(foo). For foo[i], that would be @(foo or i). It would not be
@(foo[0]) or @(foo[i]), because that would be adding bit selects when
the standard specifies adding identifiers.
Note that this may involve waking up even when it would not have been
strictly necessary for combinational evaluation (e.g. foo changed, but
bit 0 of foo did not). However, the way that the standard is defined
requires sensitivity to all of foo. If an implementation did not wake
up the event control, and this had an observable effect (e.g. there was
a $display in the block), the implementation would not be compliant.
It could restrict the sensitivity as an optimization only if it could
guarantee that there would never be an observable difference in behavior.
Now for the more difficult situation of an array reference. I can see
several possible approaches in this case:
1. The standard specifies that "net and variable identifiers" should be
added to the event control. The terminology is a bit fuzzy, but variables
are introduced as a distinct thing from arrays earlier in the standard.
Therefore, this could be interpreted as not including array identifiers
(though I suspect the intent was to exclude things like block names).
With this interpretation, array identifiers would not be added to the
event control. The problem with this is that it violates the intent of
the @*, and could result in pre/post-synthesis differences. In this
case, there should at least be a warning issued.
2. If "net and variable identifiers" is interpreted as including arrays,
then the array identifier should be added to the event control list. The
problem is that array identifiers are illegal in event control lists.
If the resulting event control list is illegal, then the @* that was a
"convenient shorthand" for that list must be illegal. So an @* would not
be legal on any statement that reads an array element. An implementation
should issue an error in this situation.
3. An implementation could try to extrapolate the intent of the @* by
creating a non-standard event control that waits on an entire array.
The meaning of this is not defined by the standard, so I would consider
it to be a non-standard extension. The most obvious definition has
potential efficiency problems (which is part of why it was not allowed),
so different implementations might handle it differently. As a result,
issuing a warning might be a good idea.
I personally like interpretation 2. It is simple and presumably matches
the behavior of the editor macro that I believe this extension was based
on. I can see 3 as a reasonable but non-standard extension, which could
lead to portability problems.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:36 PDT
and
sponsored by Boyd Technology, Inc.