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

From: Steven Sharp <sharp_at_.....>
Date: Tue Dec 13 2005 - 16:49:16 PST
>From: "Michael \(Mac\) McNamara" <mcnamara@cadence.com>

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

I don't agree that this is reasonably conservative.  It isn't
conservative enough to give the correct simulation behavior in
all cases, which should be the minimum requirement for the
construct.  After all, that is what it was designed to ensure.

If you extend the example to something like

  always @(*) begin
    for (i = 0; i < 8; i = i + 1)
      b[i] = a[i][0];
  end
  
then transforming this into

  always @( i or a[i][0]) begin
    for (i = 0; i < 4; i = i + 1)
      b[i] = a[i][0];
  end
  
is clearly wrong.  It is sensitive to a[4][0], which probably is a
constant x, since it is probably out-of-range.  It fails to be
sensitive to a[0][0], a[1][0], a[2][0] and a[3][0], which are
the actual inputs to the combinational logic.

I believe that there are better choices than the static prefix rule,
but any rule chosen needs to be conservative enough to guarantee
correct behavior, or the construct fails in its intent.

Steven Sharp
sharp@cadence.com
Received on Tue Dec 13 16:49:29 2005

This archive was generated by hypermail 2.1.8 : Tue Dec 13 2005 - 16:50:26 PST