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

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
**********************************************
Received on Mon Nov 15 15:27:14 2004