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

 For always @(*) begin
        b = a[i][0]
     end

I always liked the trasformation from this to:

	always @( i or a[i][0] ) begin
	   b = a[i][0];
      end

as a useful, reasonably conservative, yet efficient mapping.

If the value delivered by the expression changed (a[i][0] !=
old(a[i][0]) or i != old(i))
then schedule the block again.  I need only have a previous value temp
for the value of a[i][0], and one for each component of the expression
(in this case just the i).

You could argue that the case where i changes from one value to another,
but in each case still selects a cell that holds the same value should
not cause a schedule of the block as a further efficiency; but many
would otherwise like a change in the index to schedule an execution of
the block.  Certainly a change in the value of the expression requires
an execution of the block.  Certain a change in a value not selected by
a[i][0] does not require execution of the block.

Folks could introduce temps to select the behaviour they desire:

  assign t = a[i][0];
  always @(*)
	b = t;
  end



Michael McNamara
mcnamara@cadence.com
408-914-6808 work
408-348-7025 cell


-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Steven Sharp
Sent: Tuesday, December 13, 2005 12:49 PM
To: sv-bc@eda.org; Dave_Rich@mentor.com
Subject: 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