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

From: Surrendra Dudani <Surrendra.Dudani@synopsys.com>
Date: Tue Nov 16 2004 - 09:32:47 PST

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
(2) is legal, since each element is equivalent and the array lengths are equal

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?

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
(2) is legal, since each element is equivalent and the array lengths are equal


Surrendra

At 03:26 PM 11/15/2004 -0800, you wrote:

Hi Surrendra,

 

I believe you are wrong on all counts

 

A bit stream cast is an expression, and the destination type is the explicitly named type of the cast, not what appears on the LHS of the assignment. So both assignments are illegal because the LHS type is not equivalent to the RHS. Unpacked struct types are equivalent by name (with their scope) alone.

 

By our definition (the SV-BC s), an explicit cast is *always* legal if the implicit cast is legal. I believe this is the way C is defined also.

 

Dave

 

 

 

 

---

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Surrendra Dudani
Sent: Monday, November 15, 2004 6:49 PM
To: sv-bc@eda.org; sv-ec@eda.org
Subject: RE: [sv-bc] SV-BC 291 is uploaded and ready

 

Hi Dave,
This principle seems to break down in some cases, such as the example below.

typedef struct {bit [4:0] t1;} name

typedef struct {string s1 ;} dest_t;
typedef struct {string s2 ;} source_t;

dest_t a;
source_t b;
a.s1 = "abc";
b.s2 = "de"
a = source_t'(b); (1)
a = b; (2)
(1) is will generate a runtime error because according to the bit-stream cast rules, the bit lengths are not the same for a and b
(2) is legal because it abides by the equivalence of the struct members and conducts member by member assignment

Please also note that explicit cast is not always legal for all cases when implicit cast is legal.

Surrendra
At 04:28 PM 11/12/2004 -0800, you wrote:

Hi Surrendra,

 

I heard through the grapevine that my explanation was not clear enough to you.

 

Here is the reasoning behind P111

 

Assume you have two unpacked array types TypeA and TypeB, and you declare two variables:

 

TypeA A;

TypeB B;

 

If the following assignment with implicit casting is legal,

 

A = B;

 

Then the committee concurs that following assignment with explicit bitstream casting is also legal and is functional equivalent to the implicit cast

 

A = TypeA (B);

 

If the implicit cast were to use assignment compatibility for each element of the unpacked array and the elements did not contain the same number of bits, then the explicit bitstream cast would become an illegal operation.

 

SV3.1 originally had used type equivalence rules for assignments and comparisons between arrays. However, the SV-EC created its own rules for passing unpacked array arguments to tasks and functions that were in contradiction to the assignment rules for arrays. Just before the SV3.1a revision closed, the SV-BC/EC changed the rules to remove the contradiction, but made the wrong choice and created the contradiction I mention above. So P111 puts type equivalence for assigning and comparing arrays back to the way it was, and changes the argument passing rules for arrays to conform to the assignment rules

 

Dave

 

 

 

---

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Rich, Dave
Sent: Wednesday, November 10, 2004 2:26 PM
To: Surrendra Dudani; sv-bc@eda.org
Subject: RE: [sv-bc] SV-BC 291 is uploaded and ready

 

Hi Surrendra,

 

I assume you meant P254, not P245. Doug actually meant P111, not P11.

 

I think you are confusing assignment compatibility for each element of an array constructor with the allowed operations on an unpacked array, which require type equivalence. This is required by P111, which passed in April by Accellera and again in October by P1800.

 

 

Dave

 

 

---

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Surrendra Dudani
Sent: Wednesday, November 10, 2004 10:23 AM
To: sv-bc@eda.org
Subject: Re: [sv-bc] SV-BC 291 is uploaded and ready

 

Hi Doug,
Your proposal changes assignment compatible to equivalent type for elements of arrays when unpacked arrays are assigned to each other. Can you provide reasoning behind it? Proposal for 245 only requires assignment compatibility.
"When using braces the context of the braces shall also be determined by the target type. SystemVerilog extends the concatenation and replication syntax of Verilog-2001 to support the construction of unpacked arrays, as well as of SystemVerilog structures and multidimensional packed arrays (see Sections 7.13 and 7.14). In these aggregate constructors each member expression shall be assignment compatible with the type of the corresponding structure field or array element and shall be evaluated as if it were the right-hand value of an assignment to a variable of that type."

Surrendra
At 11:17 AM 11/9/2004 -0800, you wrote:

Matt, Brad, SV-BC,

I have amended SV-BC 291 to be fully compatible with 254,
which we passed yesterday.  As before, 291 supersedes 11
by incorporating its changes into 291.  (Actually, some
changes in 3.14 were incorporated into 254 already)

A new proposal has been uploaded.
See http://www.eda.org/svdb/bug_view_page.php?bug_id=0000291.

Regards,
Doug



**********************************************
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 
**********************************************

**********************************************
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 Tue Nov 16 09:36:10 2004