Errata - RE : [sv-bc] A question about type casting

I believe that in this point of time this issue should be added to the
SV-BC issue/errata list.

The issue can be titled as "mismatch between implicit assignment type
casting and explicit bit stream type casting"

Issue description
=================
Section 4.7 in the LRM (Draft 5) "Array assignment" reads:

"Assigning to a fixed-size unpacked array requires that the source and
the target both be arrays with the same

number of unpacked dimensions, and the length of each dimension be the
same. Assignment is done by assigning

each element of the source array to the corresponding element of the
target array, which requires that the
source and target arrays be of compatible types. Compatible types are
types that are assignment compatible.
Assigning fixed-size unpacked arrays of unequal >>>size<<< to one
another shall result in a type check error.
...
An array of wires can be assigned to an array of variables having the
same number of unpacked dimensions
and the same length for each of those dimensions, and vice-versa."
Note the use of the word size

Section 4.8 adds the following Example
"task fun(int a[3:1][3:1]);

declares task fun that takes one argument, a two dimensional array with
each dimension of size three. A call to

fun must pass a two dimensional array and with the same dimension size 3
for all the dimensions. For example,
given the above description for fun, consider the following actuals:
...
reg b[3:1][3:1]; // OK: assignment compatible type"

Meaning that for the following RTL
      typedef logic [0:0] src_type [1:0];
        typedef logic [1:0] trg_type [1:0];
        src_type src;
        trg_type trg;
        always_comb trg = src; // legal implicit assignment cast ?

 
There is an implicit type cast between src_type and trg_type
Meaning that the always_comb process is equivalent to
        always_comb begin
      trg[0] = {1'b0, src[0]};
      trg[1] = {1'b0, src[1]};
        end

Section 3.16 "Bit-stream casting" reads:

"If both source_t and dest_t are fixed sized unpacked types of different
>>>sizes<<< then a cast generates a compile-time error."

Assuming that the phrase "different sizes" means different number of
bits then the explicit cast between the same two types should issue a
compile time error,

Or in other words the following RTL is illegal
        typedef logic [0:0] src_type [1:0];
        typedef logic [1:0] trg_type [1:0];
        src_type src;
        trg_type trg;
        always_comb trg = trg_type'(src); // illegal explicit bit-stream
cast

Now for my questions

1. Does the term different sizes in section 4.7 refer to the number of
bits, meaning the size of both src_type is 2 bits and the size of
trg_type is 4 bits, or does the word size refer the number of unpacked
element / words meaning the size of both src_type and trg_type is 2
elements. (Do we need any clarification)
2. Assuming the answer to my first quest is size == number of bits -
should we use the word size in section 4.7 and 4.16 in a different way.
3. Again assuming the same answer to the first question - does this mean
that the implicit assignment type casting between src_type and trg_type
is legal, but the explicit bit stream cast between the same two types is
not ?

Dan Jacobi, LVT
Tel : +(972)-4-8655855
INet : 465-5855

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Katz, Jacob
Sent: Tuesday, March 23, 2004 12:55 AM
To: Dave Rich
Cc: sv-bc@eda.org
Subject: RE: [sv-bc] A question about type casting

Dave,
        If equivalence of base-types, as described in 5.8.1, is used
then the following assignment would be illegal, because of the different
signing of the base types of the two arrays:

int ti [3:1][3:1];
logic [31:0] to [3:1][3:1];

assign to = ti;

Is this observation correct?

Note that section 4.8 of draft-5 contains examples similar to the above,
which will become incorrect if equivalence is used, so may need to be
updated.

____________________

Jacob M. Katz

E-mail: jacob.katz@intel.com
Phone: +972 - 4 - 865 - 5726
iNet: (8) - 465 - 5726

-----Original Message-----
From: Dave Rich [mailto:David.Rich@synopsys.com]
Sent: Monday, March 22, 2004 18:55
To: Katz, Jacob
Cc: sv-bc@eda.org
Subject: Re: [sv-bc] A question about type casting

Explicit cast behavior should match implicit cast behavior.

unpacked array assignments and argument passing should use type
equivalence, not assignment compatibility to match each element.This is
really the only change needed for the LRM.

Bit-stream casting is unmodified.

Katz, Jacob wrote:

>Dave,
> Could you, please, elaborate on how the changes you proposed
>below will resolve the discussed issue of casting? Would both explicit
>and implicit casts behave in the same way? What will be that way - as
>the today's explicit cast, or the today's implicit cast?
>
> I think bit-stream casting section will need to be updated as
>well, won't it?
>
>Thanks,
>____________________
>
>Jacob M. Katz
>
>E-mail: jacob.katz@intel.com
>Phone: +972 - 4 - 865 - 5726
>iNet: (8) - 465 - 5726
>
>
>-----Original Message-----
>From: Dave Rich [mailto:David.Rich@synopsys.com]
>Sent: Friday, March 19, 2004 23:01
>To: pgraham@cadence.com
>Cc: Katz, Jacob; sv-bc@eda.org
>Subject: Re: [sv-bc] A question about type casting
>
>I will file an erratum to change the assignment compatibility rules for

>unpacked arrays back to the way they were in SV3.1. The reason it was
>changed in the first place was because the was a conflict with the
>definition of task/function argument passing. See SV-BC-177. We should
>have changed the definition of task/function argument passing to match
>the existing assignment compatibility rules.
>
>I think it is important that an implicit cast match the functionality
of
>
>its explicit cast.
>
>Dave
>
>
>Paul Graham wrote:
>
>
>
>>> According to the current definition of casting in 3.16, the
>>>assignment in the mail below is *not* legal. This is because the
total
>>>number of bits in tx and ty is different, while explicit casting
>>>currently requires it to be equal.
>>>
>>>
>>>
>>>
>>Bit-stream casting is quite different from the kind of word-level
>>assignments I was describing. Word-level assignments require the
>>number of words (unpacked elements) be the same in the source and
>>target, but the number of bits per word can change, and the total
>>number of bits in source and target can be different. Bit-stream
>>casting loses information about the number of words in the source, but
>>preserves the number of bits. I can see a use for both kinds of
>>data conversions.
>>
>>So yes, it looks you can have unpacked array types which are
assignment
>>compatible but not cast compatible!
>>
>>Paul
>>
>>
>>
>>
>>
>>
>
>
>

-- 
--
David.Rich@Synopsys.com
Technical Marketing Consultant and/or
Principal Product Engineer
http://www.SystemVerilog.org
tele:  650-584-4026
cell:  510-589-2625