Is the following type incompatible assignment

[parag_paul@hotmail.com]

module M1;
integer a[4];
bit [31:0] b[4];
initial begin
a[0] = 1; a[1] = 2; a[2] = 3; a[3] = 4;
b = a;
end
endmodule


but the following is allowed

module M1;
int a;
bit [31:0] b;
initial begin
a[0] = 1; a[1] = 2; a[2] = 3; a[3] = 4;
b = a;
end
endmodule


Is the first error, wrong?

 

[Jonathan Bromley]

On Mon, 16 Jun 2008 01:18:37 -0700 (PDT),
<parag_paul@hotmail.com> wrote:

[the following is an error]

module M1;
integer a[4];
bit [31:0] b[4];
initial begin
a[0] = 1; a[1] = 2; a[2] = 3; a[3] = 4;
b = a;
end
endmodule

but the following is allowed

module M1;
int a;
bit [31:0] b;
initial begin
a[0] = 1; a[1] = 2; a[2] = 3; a[3] = 4;
b = a;
end
endmodule


Is the first error, wrong?

No, it's correct; there IS an error. This slightly surprising
issue has caused some problems for me in the past.

Your second example is plainly OK, although this line of code
is silly:

= 4;

because a[0], etc, are single bits! 'a' is an int and 'b' is
a simple vector, so you can obviously copy one to the other.

First, let's be clear: your first example is SystemVerilog, right?
If it's meant to be standard Verilog, then it's definitely
illegal because you cannot copy one Verilog "memory" (unpacked
array) onto another.

In SystemVerilog you *can* copy one unpacked array on to another,
provided they are arrays of the same shape and their elements
are of EQUIVALENT type. So let's analyze your example:

; // ok, unpacked array of four integers
bit [31:0] b[4]; // ok, unpacked array of four bit[31:0]
initial begin
a = '{1,2,3,4}; // put some values in a[]
b = a; // here's the problem

So, does the copy operation b=a; meet the criteria? b[] and a[]
are indeed the same shape; they are unpacked arrays with one
dimension, and there are 4 elements in that dimension. So far,
so good. But the element type of b[] is 32 bits, whereas the
element type of a[] is at least 32 logics. So it fails the
equivalent-types test on two counts: (1) one of the types is
2-state, the other is 4-state; (2) there is no guarantee that
the two types have the same number of bits.

Obviously, this rule is much stricter than the usual rule for
copying one vector (packed array) on to another. For example,
it would be completely OK to do

b[0] = a[0];

because all vector types are ASSIGNMENT COMPATIBLE. But the
elements of unpacked arrays must be of EQUIVALENT types in order
to make the two arrays assignment-compatible.

The obvious solution is to use a loop:

foreach (b) b = a;

Interestingly, if your example were changed like this:

; // unpacked array of four ints, NOT integers
bit [31:0] b[4];
initial begin
a = '{1,2,3,4};
b = a; // this copy is OK

the two types "int" and "bit[31:0]" are indeed equivalent, because
they are both vectors of 32 "bit" elements and have identical
memory footprints (even though one is signed and the other unsigned).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The rule that unpacked array elements must be of equivalent type
if the arrays are to be assignment compatible provides an
important implementation benefit: copying of one array onto
another can be done by a simple memory block-copy, because
the two arrays' memory footprints are sure to be identical.

Personally I think this is unfortunate; I believe the rule
should be that the arrays' element types must be assignment
compatible. If the two types are indeed equivalent then
tools could work that out for themselves and perform the
block-copy optimization; if not, the tools would be obliged
to implement the copy as a loop, sparing a human programmer
the error-prone business of hand coding the loop.

Anyhow, there's a proposed change to SystemVerilog - "unpacked
array concatenation" - which, if it gets through the IEEE
balloting process, will provide a straightforward workaround.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

 

[Jonathan Bromley]

On Mon, 16 Jun 2008 03:54:54 -0700 (PDT),
<parag_paul@hotmail.com> wrote:

Now there is some more confusion, since it is clear from the LRM that
when there is a assignement between two arrays of fixed size and
unpacked nature, the equivalence is again in doubt since the signed
ness of the int and unsigned ness of bit is clearly mentioned as a
source of non equivalence in the LRM.

That's my error. You are right. So

int a[4];
bit [31:0] b[4];
int unsigned u[4]; // make signedness the same as b[]!!!!

b = a; // error, different signedness of elements
u = a; // OK, equivalent

Apologies!

all vector types are ASSIGNMENT COMPATIBLE.

but the Assignment compatibility is only possible in case of implicit
cast being available

LRM 6.9.3 notes that "all integral types are assignment compatible".
That is, of course, required to fit with regular Verilog.
LRM 4.3.2 covers this and specifies the usual Verilog resizing
on assignment.

What about an packed array of bits to int, is the int considered to be
a packed stream of bits

In effect, yes. LRM 4.3.1: "The packed vector types of Verilog
are simple bit vector types, as are the integral types with
predefined widths".

Thanks for the correction.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

 

[parag_paul@hotmail.com]

On Jun 16, 2:22 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Mon, 16 Jun 2008 01:18:37 -0700 (PDT),

parag_p...@hotmail.com> wrote:

[the following is an error]





module M1;
       integer  a[4];
       bit  [31:0] b[4];
       initial begin
               a[0] = 1; a[1] = 2; a[2] = 3; a[3] = 4;
               b = a;
       end
endmodule
but the following is allowed

module M1;
       int  a;
       bit [31:0] b;
       initial begin
               a[0] = 1; a[1] = 2; a[2] = 3; a[3] = 4;
               b = a;
       end
endmodule

Is the first error, wrong?

No, it's correct; there IS an error.  This slightly surprising
issue has caused some problems for me in the past.

Your second example is plainly OK, although this line of code
is silly:

 a[0] = 1; a[1] = 2; a[2] = 3; a[3] = 4;

because a[0], etc, are single bits!  'a' is an int and 'b' is
a simple vector, so you can obviously copy one to the other.

First, let's be clear: your first example is SystemVerilog, right?
If it's meant to be standard Verilog, then it's definitely
illegal because you cannot copy one Verilog "memory" (unpacked
array) onto another.

In SystemVerilog you *can* copy one unpacked array on to another,
provided they are arrays of the same shape and their elements
are of EQUIVALENT type.  So let's analyze your example:

 integer  a[4];      // ok, unpacked array of four integers
 bit  [31:0] b[4];   // ok, unpacked array of four bit[31:0]
 initial begin
   a = '{1,2,3,4};   // put some values in a[]
   b = a;            // here's the problem

So, does the copy operation b=a; meet the criteria?  b[] and a[]
are indeed the same shape; they are unpacked arrays with one
dimension, and there are 4 elements in that dimension.  So far,
so good.  But the element type of b[] is 32 bits, whereas the
element type of a[] is at least 32 logics.  So it fails the
equivalent-types test on two counts: (1) one of the types is
2-state, the other is 4-state; (2) there is no guarantee that
the two types have the same number of bits.

Obviously, this rule is much stricter than the usual rule for
copying one vector (packed array) on to another.  For example,
it would be completely OK to do

  b[0] = a[0];

because all vector types are ASSIGNMENT COMPATIBLE.  But the
elements of unpacked arrays must be of EQUIVALENT types in order
to make the two arrays assignment-compatible.

The obvious solution is to use a loop:

  foreach (b) b = a;

Interestingly, if your example were changed like this:

 int  a[4];          // unpacked array of four ints, NOT integers
 bit  [31:0] b[4];
 initial begin
   a = '{1,2,3,4};
   b = a;            // this copy is OK

the two types "int" and "bit[31:0]" are indeed equivalent, because
they are both vectors of 32 "bit" elements and have identical
memory footprints (even though one is signed and the other unsigned).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The rule that unpacked array elements must be of equivalent type
if the arrays are to be assignment compatible provides an
important implementation benefit: copying of one array onto
another can be done by a simple memory block-copy, because
the two arrays' memory footprints are sure to be identical.

Personally I think this is unfortunate; I believe the rule
should be that the arrays' element types must be assignment
compatible.  If the two types are indeed equivalent then
tools could work that out for themselves and perform the
block-copy optimization; if not, the tools would be obliged
to implement the copy as a loop, sparing a human programmer
the error-prone business of hand coding the loop.

Anyhow, there's a proposed change to SystemVerilog - "unpacked
array concatenation" - which, if it gets through the IEEE
balloting process, will provide a straightforward workaround.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

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

hi Jonathan
Thanks for the comprehensive reply,
Now there is some more confusion, since it is clear from the LRM that
when there is a assignement between two arrays of fixed size and
unpacked nature, the equivalence is again in doubt since the signed
ness of the int and unsigned ness of bit is clearly mentioned as a
source of non equivalence in the LRM.

If you are looking at P 1800-, you will find this in 6.9.2


Also, one more thing,
you said
because all vector types are ASSIGNMENT COMPATIBLE. But the
elements of unpacked arrays must be of EQUIVALENT types in order
to make the two arrays assignment-compatible


but the Assignment compatibility is only possible in case of implicit
cast being available, Could you please help me with that. From a
strict implementation point of view I did not see any implicit casting
rules in the LRM and the one available for the packed arrays and
String data types

What about an packed array of bits to int, is the int considered to be
a packed stream of bits

 

[Jonathan Bromley]

On Mon, 16 Jun 2008 12:33:24 +0100,
Jonathan Bromley wrote:

sheesh, ANOTHER mistake!

I said...

;
bit [31:0] b[4];
int unsigned u[4]; // make signedness the same as b[]!!!!

b = a; // error, different signedness of elements
u = a; // OK, equivalent

And, of course, the last line of that SHOULD have said

u = b; // OK, equivalent
// (elements of both u and b are unsigned 32 bit)

Apologies again for the slips.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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