I think it is enough to only check the parameterization of parent constructs (module foo() in this example), not the inner constructs. All the relevant parameters should be defined in the parent constructs. If the parameterizations of parent constructs are different, the two compared types are not compatible; if the parameterizations are the same, the types may be compatible. I.e. the set of rules may be: go up the hierarchy until the "innermost instantiated entity" (module foo()) is found, and check whether the names and parameterizations of the scopes are the same. Still, the hierarchy above the "innermost instantiated entity" may be ignored. But maybe this point is not worth discussing; I've just asked :-) --Yulik. ________________________________ From: owner-sv-bc@server.eda-stds.org [mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Rich, Dave Sent: Tuesday, June 20, 2006 4:13 PM To: Feldman, Yulik; Brad Pierce; sv-bc@server.eda-stds.org Subject: RE: FW: [sv-bc] parameterized structures Suppose we added another level of type hierarchy to my example module #(int I = 1) foo(); typedef struct {int A[I];} AA_t; typedef struct { int A; AA_t B; } BB_t; BB_t BB_i; endmodule There are no visible parameters in the definition BB_t. We would have to have a much more complex set of rules, and we would need to look inside the struct to check its type. The point I was making with the last example was that they are "named" types, not an anonymous types. We use the fact that is name is different and nothing else to say that they are incompatible, and we do not consider the fact that the types on the inside match. Even if they were anonymous types, they would have different internal names, which would not match. Dave ________________________________ From: Feldman, Yulik [mailto:yulik.feldman@intel.com] Sent: Tuesday, June 20, 2006 5:40 AM To: Rich, Dave; Brad Pierce; sv-bc@server.eda-stds.org Subject: 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.comReceived on Wed Jun 21 01:10:24 2006
This archive was generated by hypermail 2.1.8 : Wed Jun 21 2006 - 01:10:43 PDT