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

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