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