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