RE: FW: [sv-bc] parameterized structures

OK, but maybe the parameterization and the scope position should be
treated orthogonally to each other with regard to the type
compatibility, just like the templates and namespaces are treated
orthogonally in C++. I.e., it is clear that both affect the type
compatibility, but they do not necessarily need to affect each other.
Language may say that for the two given types to be compatible, they
have to have all their parameters resolved to the same value (whatever
the exact definition is) and they have to be defined (is they are
user-defined) in the same scope with the same name, but considering the
innermost entity only, and ignoring the exact instantiation path of that
entity. Requiring the same instantiation path for the type compatibility
seems to be somewhat artificial limitation, unless I miss something.

 

W.r.t. the last example, the reasoning about the "shape analysis" is
clear. Fortunately, the declarations of 'addr_type' and 'data_type'
refer to two different anonymous structures (probably having different
"internal" names), so this fact alone should make the types
incompatible, independently whether the instantiation paths of the
innermost instantiated entity are considered in type compatibility or
not.

 

--Yulik.

 

-----Original Message-----
From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
Sent: Tuesday, June 20, 2006 2:56 PM
To: Feldman, Yulik; Brad Pierce; sv-bc@server.eda-stds.org
Subject: RE: FW: [sv-bc] parameterized structures

 

You can't do that because parameterization of a module can make the

declaration of the type inside it incompatible.

 

module #(int I = 1) foo();

 

typedef struct {int A[I];} AA_t;

 

AA_t AA_i;

 

endmodule

 

module top;

 

foo #(2) i1();

foo #(3) i2();

 

initial i1.AA_ = i2.AA_i; // illegal because types are not compatible.

 

You could do something with type parameters to create other type

incompatibilities.

 

module #(type I = int) foo();

 

typedef struct {I A;} AA_t;

 

AA_t AA_i;

 

endmodule

 

We don't want to define type compatibility by checking the shape of a

structure because then we lose all of the strong type checking that an

unpacked structure type provides. We want the following two types to be

incompatible even if their widths happen to be the same:

 

typedef struct {bit [addr_width-1:0] value;} addr_type;

typedef struct {bit [data_width-1:0] value;} data_type;

 

-Dave

 

 

> -----Original Message-----

> From: owner-sv-bc@server.eda-stds.org [mailto:owner-sv-bc@server.eda-

> stds.org] On Behalf Of Feldman, Yulik

> Sent: Tuesday, June 20, 2006 2:00 AM

> To: Brad Pierce; sv-bc@server.eda-stds.org

> Subject: RE: FW: [sv-bc] parameterized structures

> 

> What is the reason for 6.9 "Type compatibility"'s "The scope of a data

> type identifier shall include the hierarchical instance scope. In

other

> words, each instance with a user-defined type declared inside the

> instance creates a unique type."?

> 

> What would happen if the "scope of a data type" would include only the

> scope hierarchy inside the innermost instantiated entity

> (module/interface/program/etc.) and would ignore the path leading to

the

> instance itself? Won't the life be just easier for everyone?

> 

> --Yulik.

> 

> -----Original Message-----

> From: owner-sv-bc@server.eda-stds.org

> [mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Brad Pierce

> Sent: Tuesday, June 20, 2006 3:04 AM

> To: sv-bc@server.eda-stds.org

> Subject: Re: FW: [sv-bc] parameterized structures

> 

> Some of theses issues were resolved by

> 

>      http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=725

> 

> See also

> 

>      http://www.eda-stds.org/sv-ec/hm/2542.html

>      http://www.eda-stds.org/sv-ec/hm/2557.html

> 

> -- Brad

> 

> -----Original Message-----

> From: owner-sv-bc@eda-stds.org [mailto:owner-sv-bc@eda-stds.org] On

> Behalf Of Gordon Vreugdenhil

> Sent: Monday, June 19, 2006 4:52 PM

> To: Greg Jaxon

> Cc: sv-bc@verilog.org

> Subject: Re: FW: [sv-bc] parameterized structures

> 

> 

> 

> Greg Jaxon wrote:

> 

> > Gordon Vreugdenhil wrote:

> >

> >> Greg,

> >>

> >> I'm not sure I understand the issue here.

> >>

> >> Let's stick with the process/scope case for a moment.

> >>

> >>   module top;

> >>     class C #(int p = 1);

> >>        static int x;

> >>     endclass

> >>

> >>     always @(clk) begin

> >>         C#(2) c_obj = new;

> >>         c_obj.x++;

> >>     end

> >>

> >>     always @(clk) begin

> >>         C#(2) c_obj = new;

> >>         c_obj.x++;

> >>     end

> >>   endmodule

> >>

> >>

> >> Are we in agreement that there is only one "x" here and that

> >> it is the one that is the member of the specialized type C#(2)?

> >

> >

> > That is also what I'd like to see the LRM specify.  However, I will

> > note that the generic class has been declared in two different

scopes,

> > neither of which is in a package context, so according the quote

(see

> > below)

> > I might expect them to be different types.

> 

> 

> I don't see this at all.  It is clear that each C#(2) is

> a *specialization*.  There is only one declaration of the

> parameterized class C -- the one in top.  C#(2) isn't

> a *declaration* of a class type at all; it is a specialization.

> 

> Gord.

> --

> --------------------------------------------------------------------

> Gordon Vreugdenhil                                503-685-0808

> Model Technology (Mentor Graphics)                gordonv@model.com