Using ~variable as index to multidimensional arrays in Syste

[chewkean]

Hi,

Does anybody know if the following is allowed?

module tmp ();
bit sig_a [1:0][1:0];
bit b, c;
initial begin
sig_a[0][0] = 1'b0;
sig_a[0][1] = 1'b0;
sig_a[1][0] = 1'b1;
sig_a[1][1] = 1'b1;
c = 1'b0;
end
assign b = sig_a[0][~c];
endmodule

My simulation seems to be encountering issues with ~c as the second
dimension. It works fine when it assign ~c to an intermediate variable
and use that as the index. Its probably a bug with the software. I just
want to confirm my understanding that ~c is allowed as an index. Thanks.

 

[Jonathan Bromley]

On 11 Oct 2005 23:52:57 -0700, "chewkean" <chewkean@hotmail.com>
wrote:

module tmp ();
bit sig_a [1:0][1:0];
bit b, c;
initial begin
sig_a[0][0] = 1'b0;
sig_a[0][1] = 1'b0;
sig_a[1][0] = 1'b1;
sig_a[1][1] = 1'b1;

You may wish to try
sig_a = '{'{0,0}, '{1,1}};
(Questa already supports the assignment patterns syntax;
I think VCS is still using an older version of the syntax)

c = 1'b0;
end
assign b = sig_a[0][~c];
endmodule

My simulation seems to be encountering issues with ~c as the second
dimension. It works fine when it assign ~c to an intermediate variable
and use that as the index. Its probably a bug with the software. I just
want to confirm my understanding that ~c is allowed as an index. Thanks.

I agree with you; ~c is a perfectly good 'bit' expression.
You might also like to try [1-c] instead, to get a feel for
whether the tool is having problems with *any* expression in
the subscript, or just something weird about ~.

Is the problem at compilation, or at runtime?
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

Should be fine. Perhaps your simulator is not evaluating ~c with a
self-determined width of 1 bit wide. If it did something wrong like
evaluating it with a 32-bit width, then all those inverted upper bits
would be ones, which would put the index out of range.

 

[chewkean]

Actually, I tried several combinations of expressions (1'b1 - ~c) being
one of them but the problem still persists. I think its something weird
with ~.

Although, I didn't try sig_a = '{'{0,0}, '{1,1}}; yet. I'll go give
that a go. Thanks.

 

[chewkean]

That sounds like a very good reason. It might be treating the index as
an int instead of single bit logic. I created another testcase with
$display to print out results...

module tmplogic ();
logic arr [1:0] [1:0];
logic a, b, c, d, e;
initial begin
arr[0][0] = 1'b0;
arr[0][1] = 1'b1;
arr[1][0] = 1'b1;
arr[1][1] = 1'b0;
a = 1'b0;
$display("...logic...\na = %b\n~a = %b\nb = %b\nc = %b\nd = %b\ne =
%b\narr[0][0] = %b\narr[0][1] = %b\narr[0][~a] = %b\narr[1][0] =
%b\narr[1][1] = %b\narr[1][~a] = %b\n", a, ~a, b, c, d, e, arr[0][0],
arr[0][1], arr[0][~a], arr[1][0], arr[1][1], arr[1][~a]);
end
assign b = arr[0][a];
assign c = arr[0][~a];
assign d = arr[1][a];
assign e = arr[1][~a];
endmodule

And it displayed:

...logic...
a = 0
~a = 1
b = 0
c = x
d = 1
e = 1
arr[0][0] = 0
arr[0][1] = 1
arr[0][~a] = x
arr[1][0] = 1
arr[1][1] = 0
arr[1][~a] = 1

Do you know of another way I can see what ~a resolves to when I use it
in the index?

 

[chewkean]

Its a runtime problem. I tried sig_a = {{0,0}, {1,1}}; but same issue.
Anyway, I think this is a real bug. I'm going to forward this to the
vendor. Thanks for the help anyway guys.

 

OK, that testcase alters my theory slightly. I would have expected ~a
to be treated as out-of-range and produce an x in both cases. Now I
suspect that they are also doing the range checking incorrectly for
multi-dimensional arrays. They should be detecting whether any
individual index is out of range for that dimension. They may instead
be doing the entire indexing calculation and then checking whether the
result is outside the array. In other words, if the second index is
out-of-range of its row, it wraps onto the next or previous row.

If ~a is being evaluated as 32 bits and signed, and a=0, then ~a is -1.
So arr[0][-1] would be outside the array and produce x. But if
arr[1][-1] were evaluated without proper range checking of each
dimension, it would come out to the same element as arr[0][1]. And it
seems to be getting the same value for arr[1][~a] as arr[0][1]. You
could test it further by putting a different value in that element from
the rest of the array. You could also test it with a=1, so that ~a
would be treated as -2. In that case, arr[1][-2] would map to
arr[0][0], which could also be checked by putting a unique value into
that element.

I probably shouldn't be helping a competitor debug their product,
though they seem to need the help . If my theory is correct, they
have at least two separate bugs in this same area.