Re: [sv-bc] parameterized structures

In Bluespec SystemVerilog, we've had parameterized structs as an
extension for a couple of years (unions can also be parameterized).

The syntax we use is slightly different from what Yulik showed in his
first example, where we put the parameters on the type name, following
the general "Type#(params)" notation that is used for parameterized
classes and interfaces:

     typedef struct  {
             bit [SIZE-1:0] m1;
             TYPE m2;
     } parameterized_struct #(SIZE = 32, TYPE = integer);

Re. Shalom's point that this makes the parameter local, yes,
absolutely, because you want to be able to conveniently instantiate
this at different types, such as:

     parameterized_struct #(..parms1...) s1;
     parameterized_struct #(..parms2...) s2;

Further, parameters can easily be propagated into nested parameterized
structs, e.g.,:

     typedef struct {
         ...
         parameterized_struct #(S1, T1) member1;
         ...
         parameterized_struct #(S1, T2) member2;
         ...
     } another_parameterized_struct #(S1, T1, T2);

As Yulik says, there's no problem synthesizing these (because they're
elaboration time constants).

We don't have $typename or static casting in Bluespec SystemVerilog,
so haven't faced those issues.

We use such parameterized types heavily in Bluespec code.

Nikhil


Bresticker, Shalom wrote:
> 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.
>