From: Michael McNamara (mac@verisity.com)
Date: Wed May 01 2002 - 13:48:53 PDT
Precedence: bulk
Steven Sharp writes:
> 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
>
How cutting and pasting the code from each of our simulators where we
handle the statement:
assign a = foo[i];
-mac
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:36 PDT
and
sponsored by Boyd Technology, Inc.