RE: [sv-ec] RE: [sv-bc] SV-BC 291 is uploaded and ready

Surrendra,

For a string, the possible bit lengths are 0,8,16,24,...

So

string s1 = string'(16'h1234); // is legal
string s2 = string'(17'h11234); // is not legal

Also,

typedef struct {bit A; string s; bit B) unpk_t
unpk_t s3 = unpk_t'(18'h34567); // s3 two bytes are allocated for s3.s
const string s4 = "hello"
unpk_t s5;
s5 = unpk_t'(s4); // illegal. This must be either be a compile time
error or a run time error, because there is no valid size of s4 that
would be equal to a valid size of s5.

The problem you mention with b = integer'(a); is not correct because
both the sourt_t or dest_t need to be an unpacked type. SV-BC 170
proposes that at least one of the types need to be unpacked, but that
would not effect the discussion so far. (The assignment to s2 would
become legal because the integral value would get filled to match the
size.

Dave

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Surrendra Dudani
Sent: Thursday, November 18, 2004 4:17 PM
To: sv-bc@eda.org; sv-ec@eda.org
Subject: RE: [sv-ec] RE: [sv-bc] SV-BC 291 is uploaded and ready

Hi Doug,
Please see my answers.
Surrendra

At 01:43 PM 11/17/2004 -0800, you wrote:
>Surrendra,
>
>Is it possible there is some misinterpretation of "source_t" and
>"dest_t"?
>The correct interpretation is that "dest_t" refers to a TYPE to which a
>cast should convert a value. There is no particular object associated
>with "dest_t", for example the lhs of an assignment or comparison.
>"source_t" is the TYPE of the object which is being cast.
>
>Legality of assignment or comparison operations should be determined
>*after* any cast has been performed, not during the cast operation.

Yes. That would be the correct interpretation. However, for dynamic
types,
there is no way to determine the bit length of a type, and bit-stream
casting(explicit casting) requires bit lengths to be equal for the two
types, even for types containing dynamic types. I don't not see how it
can
work, unless there are two actual objects associated with the types.

>One other point in this debate is that I haven't seen any viable
>alternatives to the changes SV-BC approved for #111. If you can
>come up with a viable alternative that guarantees 100% consistent
>behavior between implicit and explicit casts, I think everyone who
>voted to pass 111 would take a serious look at such a proposal.

The problem arises because bit-stream cast has been made to be the
explicit
cast form. Implicit cast does not follow bit-streaming rules. This
breaks
even in the simple case

bit [3:0] a;
integer b;

b = a; // legal
b = integer'(a); // illegal when bit-streaming rules applied, bit
lengths
do match between [3:0] and integer

One solution is do nothing with the LRM in these points. LRM should not
make the assertion that explict cast form is equivalent to the implict
cast
performed for operations such as assignments and equality. Following
this
reasoning, there is no need to make the equivalence requirement between
elements of arrays when two slices of those arrays are assigned. We can
stick with what is in the LRM already, which is the assignment
compatibility rule.

The other solution is to remove the explicit cast form until it is
better
defined. Users already have the bit-streaming operators to accomplish
all
the bit-streaming conversions and checking.

Surrendra

>Regards,
>Doug
>
>
>________________________________
>
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
Behalf
>Of Rich, Dave
> Sent: Wednesday, November 17, 2004 9:29 AM
> To: Surrendra Dudani; sv-bc@eda.org; sv-ec@eda.org
> Subject: RE: [sv-ec] RE: [sv-bc] SV-BC 291 is uploaded and
ready
>
>
> Surrendra,
>
> What about this case where type_A has a dynamic type)
>
> if (var_of_type_A == type_A'(var_of_type_B) )...
>
> There is no LHS to use in a size comparison.
>
>
> The sizes in the text you quoted are referring to possible
sizes
>that the type will allow. i.e. is there an allocated size for the type
>that would exactly match the number of bits in the source expression.
In
>the LRM example at the end of the section, Stream is initially an empty
>queue of bits.
>
> Again 291 has nothing to do with the type equivalence
>requirements.
>
> Dave
> ________________________________
>
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]
>On Behalf Of Surrendra Dudani
> Sent: Wednesday, November 17, 2004 5:26 PM
> To: sv-bc@eda.org; sv-ec@eda.org
> Subject: RE: [sv-ec] RE: [sv-bc] SV-BC 291 is uploaded and
ready
>
>
>
> Hi Dave,
> My reasoning is based on a strong statement from the LRM as
>follows:
>
> "If both source_t and dest_t are fixed sized unpacked types of
>different sizes then a cast generates a compile-
> time error. If source_t or dest_t contain dynamically-sized
>types then a difference in their sizes will
> generate an error either at compile time or run time, as soon
as
>it is possible to determine the size mismatch."
>
> This leads me to believe that, at least when dynamic types are
>involved, bit stream casting is not just an expression as the bit
length
>of any type containing a dynamic type is undefined. The actual value of
>the LHS of the assignment has to be considered to make it work.
>
> There are additional differences between type equivalence
>consideration and bit-stream cast. The former does not permit
>2-state/4-state differences, while bit-stream cast does conversion. Two
>dynamic types may be equivalent, but not bit-stream castable.
Bit-stream
>cast is not defined for some data types such as real and class.
>
> Therefore, I agree with Mark that bit-stream casting is very
>different than the casting used for type conversion in assignments.
>
> The restrictions in 291 force users to think of unpacked
arrays
>as packed arrays. Type equivalence requirement for elements is too
>severe for assignments of unpacked types.
> Surrendra
>
>
>
> At 04:05 PM 11/16/2004 -0800, Rich, Dave wrote:
>
>
>
>
> Hi Surrendra,
>
>
>
> The behaviors you are describing have to do the greedy nature
of
>bit stream casting. I admit this may be an issue, but 291 has nothing
to
>do with it. And to address MarkH concerns, voting down 291 does not
>repeal 111, and neither changes the greedy nature of bit-stream
casting.
>Away to change this would be to say that casting to an equivalent type
>was not greedy, but instead preserved the dynamic sizes.
>
>
>
> Also, a bit-stream cast, or any cast for that matter, is just
an
>expression. The type or the contents of the LHS of an assignment have
no
>effect on the cast. I don t think the previous contents of the LHS have
>any effect on any assignment. (Except in determining whether an element
>an associative array already exists). See more comments below
>
>
>
> ________________________________
>
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]
>On Behalf Of Surrendra Dudani
> Sent: Tuesday, November 16, 2004 6:33 PM
> To: sv-bc@eda.org; sv-ec@eda.org
> Subject: Re: [sv-ec] RE: [sv-bc] SV-BC 291 is uploaded and
ready
>
>
>
> Hi Dave,
> I apologize for making a typo in the example. It should have
>been
> a = dest_t'(b); (1)
>
> Since the rules of unpacked structure assignment are not
clearly
>stated, let me give some examples of unpacked array assignment with
>string as the type of the element. The elements of the lhs and rhs
>arrays are of equivalent type, but of different lengths.
>
> typedef string source_t[2];
> typedef source_t dest_t;
>
> source_t a;
> dest_t b;
>
> a[0] = "ab";
> a[1] = "c";
> b[0] = "defg";
> b[1] = "hijk";
>
> b = dest_t'(a); (1)
> b = a; (2)
> (1) is illegal, as the lhs bit length is different than rhs
bit
>length
>
> This is legal. b[0] = abc ; b[1]= ;
> (2) is legal, since each element is equivalent and the array
>lengths are equal
>
> Yes. b[0] and b[1] will be resized.
>
>
>
> And, in the simple case
>
> string s1 = "ab";
> string s2 = "cde"
> s1 = s2; (3)
> s1 = string'(s2); (4)
> (3) is legal, but, would (4) produce a run time error?
>
> (3) and (4) are both legal. The previous size of s1 is
>irrelevant.
>
>
>
> And, in a more complicated case,
>
> typedef string source_t1[2];
> typedef string dest_t1[];
>
> source_t1 a1;
> dest_t1 b1 = new[2];
>
> a1[0] = "ab";
> a1[1] = "c";
> b1[0] = "defg";
> b1[1] = "hijk";
>
> b1 = dest_t1'(a1); (1)
> b1 = a1; (2)
> (1) is illegal, as the lhs bit length is different than rhs
bit
>length
>
> I think this case, a nested dynamic type, is undefined in the
>LRM. I would be OK with making this type of cast illegal. But I would
>also be OK with
>
> b1[0] = abc ;.
>
>
> (2) is legal, since each element is equivalent and the array
>lengths are equal
>
> I agree.
>
>
>
>
> Surrendra
>
>
>
> **********************************************
> Surrendra A. Dudani
> Synopsys, Inc.
> 377 Simarano Drive, Suite 300
> Marlboro, MA 01752
>
> Tel: 508-263-8072
> Fax: 508-263-8123
> email: Surrendra.Dudani@synopsys.com
> **********************************************

**********************************************
Surrendra A. Dudani
Synopsys, Inc.
377 Simarano Drive, Suite 300
Marlboro, MA 01752

Tel: 508-263-8072
Fax: 508-263-8123
email: Surrendra.Dudani@synopsys.com
**********************************************
Received on Thu Nov 18 07:54:51 2004