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

>I don't think of it as ugly; I think of it as correct. :)

I don't know how you got that wrong idea.  It is not correct, it is
just a conservative approximation.  It is less conservative than
some possible alternatives, and more conservative than others.  It
isn't even the least conservative rule of its general type.  It
is a rather arbitrary choice, and a bad one in several ways.


>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.

And if you use an expression like a[i][0], then the static prefix
rule defines that you are sensitive to a change on any element,
including ones that do not have a second index of 0.  It is not
"correct", and doesn't even take advantage of all the static information
in the expression.  Compared to a rule using sensitivity to the entire
object, it doesn't fully solve any problem.


>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.

And those exact same problems occur with the similar sensitivity
that can be produced by the static prefix rule.  If the sensitivity
is the same, why would you expect it to magically work better because
it was produced by the static prefix rule instead of explicitly
specified by the user?

There are many different rules that could have been used that produce
adequate sensitivity for combinational behavior.  There are trade-offs
in making the approximation more or less conservative.  Some of the
factors to consider are:

1. Ease of explanation
2. Practicality and efficiency of implementation

The static prefix rule fails on both of these counts.

Steven Sharp
sharp@cadence.com