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

From: Surrendra Dudani <Surrendra.Dudani@synopsys.com>
Date: Mon Nov 15 2004 - 09:48:58 PST

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 
********************************************** Received on Mon Nov 15 09:48:18 2004