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

As a follow-up. I suppose I'm the one who initiated the addition
of this "feature" and I'd like to restate the intent of my request
so that the now-enabled capability is preserved. Here's my original
mail to the reflector:

http://www.eda.org/sv-bc/hm/0374.html

I'm re-attaching the presentation in hopes that it gets properly
processed
by the reflector. See the section:

  Unpacked Array Type "Mismatch"

In summary, it is most useful that these:

  wire [2:0] wiremda [1:0];
 logic [2:0] logicmda [1:0];

are assignment compatible in one easy step:

  assign logicmda = wiremda;
  assign wiremda = logicmda;

I'd prefer that type equivalence be used very carefully
in this section or ensure that a provision for the above
is maintained.

Matt
 
>-----Original Message-----
>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
>Behalf Of Jacobi, Dan
>Sent: Tuesday, March 23, 2004 1:32 PM
>To: sv-bc@eda.org
>Subject: 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
>
>
>
>
>
>