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