1. $typename of the given instance of a parameterized structure is the same as $typename of a non-parameterized structure structurally similar to the given parameterized structure, with all parameters substituted to their evaluated values. 2. I'm not sure to what specific question you refer w.r.t. to static casting. Syntactically, there is no problem to cast from parameterized structure to another type. In the other direction, some special syntax may be introduced to refer to the structure (like it is done in C++), or the cast may be allowed through a typedef to the parameterized structure only. Semantically, the cast should be the same as the cast to/from an equivalent non-parameterized structure. --Yulik. ________________________________ From: Bresticker, Shalom Sent: Thursday, June 15, 2006 1:39 PM To: Feldman, Yulik; 'sv-bc@server.verilog.org' Subject: RE: [sv-bc] parameterized structures OK, now define $typename and static casting for parameterized types. Shalom ________________________________ From: Feldman, Yulik Sent: Thursday, June 15, 2006 1:34 PM To: Bresticker, Shalom; 'sv-bc@server.verilog.org' Subject: RE: [sv-bc] parameterized structures Yes, but I don't see a problem with that. It is similar to how instances of modules/classes/interfaces are determined. During the elaboration, the compiler evaluates the parameter values and determines what parameterization of the instantiated entity is used in each instance. In the same way it can determine what parameterization of the "instantiated" type is used in declaration of a variable. Technically, maintaining/handling a list of used instantiated types in the design should be no more complex than maintaining/handling a list of used module/class/interface parameterizations. Abstractly speaking, all those can be considered "types" of design objects; it just happened that "types" of variables are called "data types", while types of module instances, for example, are called "modules". --Yulik. ________________________________ From: Bresticker, Shalom Sent: Thursday, June 15, 2006 1:19 PM To: Feldman, Yulik; 'sv-bc@server.verilog.org' Subject: RE: [sv-bc] parameterized structures I did not mean parameterization at run-time. I mean that you use the same type name, 'parameterized_struct', for two different types simultaneously. You have not just instantiated the variable, you have also instantiated the type as well. Shalom ________________________________ From: Feldman, Yulik Sent: Thursday, June 15, 2006 1:13 PM To: Bresticker, Shalom; 'sv-bc@server.verilog.org' Subject: RE: [sv-bc] parameterized structures No, I didn't mean that parameterization of structures should be done at run-time. It should continue to happen at elaboration time, using constant expressions. Once I declared variables with different parameterization, like in the example below, I can easily use them all at the same place. For example, I can write "ps1.m2 = ps2.m2". If the parameterization is not local, writing a conceptually similar assignment becomes much harder and less readable. ________________________________ From: Bresticker, Shalom Sent: Thursday, June 15, 2006 1:00 PM To: Feldman, Yulik; 'sv-bc@server.verilog.org' Subject: RE: [sv-bc] parameterized structures So that is a change from now. Currently a given type may be parameterized, but those parameters have a single value fixed at elaboration time, so the type is unambiguously defined. Shalom ________________________________ From: Feldman, Yulik Sent: Thursday, June 15, 2006 12:56 PM To: Bresticker, Shalom; 'sv-bc@server.verilog.org' Subject: RE: [sv-bc] parameterized structures Yes. The locality has many advantages. For example, if my design needs several parameterized structures, the ability to specify the parameters locally to each structure makes the code more modular and readable, avoiding the need to specify the conceptually unrelated parameters in the parent construct or on the compilation unit level. Maybe even more important, the ability to override the parameters locally makes it much easier to use several parameterizations of the same structure simultaneously. --Yulik. ________________________________ From: Bresticker, Shalom Sent: Thursday, June 15, 2006 12:37 PM To: Feldman, Yulik; sv-bc@server.verilog.org Subject: RE: [sv-bc] parameterized structures Even today, a structure can be parameterized (though I still think the correct word would be 'parametric', but 'parameterized' sounds more high-techy). Your idea just makes the parameter declaration local to the structure declaration, no? Shalom ________________________________ From: owner-sv-bc@server.eda-stds.org [mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Feldman, Yulik Sent: Thursday, June 15, 2006 12:23 PM To: sv-bc@server.verilog.org Subject: [sv-bc] parameterized structures Hi, I would like to get a general opinion of forum's experts on the idea to introduce parameterized structures to SystemVerilog. Parameterized structures are similar to regular structures, but allow parameterization, like modules, classes and interfaces. The syntax currently doesn't matter, but just to give a visual example: typedef struct #(SIZE = 32, TYPE = integer) { bit [SIZE-1:0] m1; TYPE m2; } parameterized_struct; parameterized_struct ps1; // Default parameterization parameterized_struct #(.SIZE(64), .TYPE(int)) ps2; // Overridden parameterization The ability to parameterize structures may be quite useful to raise the abstraction level of the design. It is quite similar to how template classes/structs in C++ help to raise the abstraction level of C++ programs. Parameterized structures, unlike parameterized modules and interfaces, will be data types, which will allow their usage in wide spectrum of coding scenarios (for example as operands of expressions). Unlike parameterized classes, parameterized structures could be easily used in design itself (vs. testbench code), without fear to open a can of worms of object life time and scheduling semantics issues. And, on top of that, there seems to be no problem to synthesize and/or formally analyze the parameterized structures. So, please, let me know what you think about it. Thanks, Yulik.Received on Thu Jun 15 05:05:48 2006
This archive was generated by hypermail 2.1.8 : Thu Jun 15 2006 - 05:06:00 PDT