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