From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Wed May 01 2002 - 13:41:56 PDT
Precedence: bulk
Steven,
Very thorough job. Thanks! The original question came from Dennis Marsa
of Xilinx. I've copied him on this response.
Stu
At 01:33 PM 5/1/2002, Steven Sharp wrote:
>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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:36 PDT
and
sponsored by Boyd Technology, Inc.