Is the following type incompatible assignment
parag...@hotmail.com
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
<parag...@hotmail.com> wrote:
[the following is an error]
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[i]) b[i] = a[i];
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...@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...@hotmail.com
wrote:
> On Mon, 16 Jun 2008 01:18:37 -0700 (PDT),
>
>
> 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
<parag...@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!
>Also, one more thing, you said [...]
> 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...@MYCOMPANY.com
Jonathan Bromley
Jonathan Bromley wrote:
sheesh, ANOTHER mistake!
I said...
> 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
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.