RE: [sv-bc] @* vs. always_comb

In an explicit event control list, you cannot list an aggregate
expression that is not a singular value, true.

But regarding always_comb, it says in 11.2.1,
"The implicit sensitivity list of an always_comb includes the EXPANSIONS
of the longest static prefix of each
variable or select expression that is read within the block or within
any function called within the block".

I have understood that to mean the list of all the elements included in
the longest static prefix, efficient or not.

Otherwise, the whole point of using the longest static prefix breaks
down.

Side point: "expansion" is not formally described. 6.7 says,
"See 8.11 for the definition of the expansion of a longest static
prefix". Actually, while 8.11 defines a longest static prefix (in a way
which is difficult to understand), it does not define what is the
expansion of such a prefix.

Shalom

>-----Original Message-----
>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
>Behalf Of Rich, Dave
>Sent: Sunday, December 11, 2005 1:58 AM
>To: sv-bc@eda.org
>Subject: RE: [sv-bc] @* vs. always_comb
>
>
>I don't think of it as ugly; I think of it as correct. :)
>
>The static prefix of a bit vector is no different then. If you
>have a
>constant bit select, then you only need to be sensitive to that
>bit. If
>you're going to have a variable bit select, you have to be
>sensitive to
>the entire vector. And if you are using an entire aggregate in
>an
>expression, then the static prefix defines that you are
>sensitive to a
>change on any element.
>
>The only reason the committee disallowed aggregates in an event
>expressions was not because it couldn't be defined, but because
>the
>implementers in the committee thought it would cause a lot of
>performance issues.
>
>Dave
>
>
>> -----Original Message-----
>> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
>Behalf Of
>Steven
>> Sharp
>> Sent: Friday, December 09, 2005 4:19 PM
>> To: cliffc@sunburst-design.com; shalom.bresticker@intel.com
>> Cc: sv-bc@eda.org
>> Subject: RE: [sv-bc] @* vs. always_comb
>>
>>
>> >[Shalom: ] Again, not quite. There are a couple of
>differences.
>> >One is that always @* has a problem with arrays referenced
>inside.
>>
>> In my opinion. always_comb still has a problem with them too.
>That
>ugly
>> "longest static prefix" rule can result in sensitivity to an
>entire
>> unpacked array, or part of an array.  But in SystemVerilog,
>it is
>still
>> illegal to wait on an entire aggregate value, so the meaning
>of this
>is
>> still not well defined.
>>
>> Steven Sharp
>> sharp@cadence.com
>