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