Subject: Re: [sv-bc] Erratum and PROPOSAL -- 3.9 -- 'complex data types' as parameters
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Wed Nov 12 2003 - 11:15:01 PST
Mark,
I wasn't suggesting that we make it illegal, just the opposite.
I agree with that the example may be of little use, but it does
complicate the parser.
Arturo
----- Original Message -----
From: "Mark Hartoog" <markh@synopsys.COM>
To: "Arturo Salz" <salz@synopsys.COM>; "Mark Hartoog" <Mark.Hartoog@synopsys.COM>;
<Brad.Pierce@synopsys.COM>; <sv-bc@eda.org>
Sent: Wednesday, November 12, 2003 10:58 AM
Subject: RE: [sv-bc] Erratum and PROPOSAL -- 3.9 -- 'complex data types' as parameters
Except for the syntax errors (struct fields must be terminated with ';', not
',') this example is legal, although I am not sure how you could instantiate
this module with the default parameter value since the port type is an anonymous
unpacked structure. Anonymous unpacked struct ports don't really make any sense,
but I don't see why we should make them illegal.
If this was a packed struct, I think you could instantiat the module.
>
> I agree with Mark's comments. But, does that mean the following syntax
> should also be allowed.
>
> module m #(parameter type T = struct { bit[7:0]a, int b, byte c } ) (input T i, output T o);
> always @(i) o = i;
> endmodule
>
> module top();
> bit [15:0] a, b;
> m #(bit [15:0]) u1(a, b);
> endmodule
>
> And the converse case where the struct definition is inlined in the instantiation.
> I bet code like the above will break many compilers.
>
> Arturo
> ----- Original Message -----
> From: "Mark Hartoog" <Mark.Hartoog@synopsys.COM>
> To: <Brad.Pierce@synopsys.COM>; <sv-bc@eda.org>
> Sent: Tuesday, November 11, 2003 8:24 PM
> Subject: RE: [sv-bc] Erratum and PROPOSAL -- 3.9 -- 'complex data types' as parameters
>
>
> What is the reason for making this BNF change? I believe that the wording in
> section 3.9 is a little unclear, but I see no reason to change the BNF.
>
> For example:
>
> module m #(parameter type T = logic [7:0) (input T i, output T o);
> always @(i) o = i;
> endmodule
>
> module top();
> bit [15:0] a, b;
> m #(bit [15:0]) u1(a, b);
> endmodule
>
> I see nothing wrong with this syntax. Why should we force users to create
> a typedef for this, and change this too:
>
> typedef logic [7:0] logic8;
> typedef bit [15:0] bit16;
>
> module m #(parameter type T = logic8) (input T i, output T o);
> always @(i) o = i;
> endmodule
>
> module top();
> bit [15:0] a, b;
> m #(bit16) u1(a, b);
> endmodule
>
> Does this really make it easier to code or understand the code?
>
> I believe that the meaning of the sentence in section 3.9 is that there are
> types that are too complex to express in either a cast or a type parameter
> value, which is true. What is left out is that the restrictions on casts
> and type parameter values are different. The cast type must be a simple
> name. A type parameter value is less restrictive, but still cannot represent
> an array type. For example, if I wanted to change the ports above to array
> ports like this:
>
> module m #(parameter type T = logic [7:0) (input T i, output T o);
> always @(i) o = i;
> endmodule
>
> module top();
> typedef bit [7:0] myarray[0:1];
> myarray a, b;
>
> m #(myarray) u1(a, b);
> endmodule
>
> Here you have to use a typedef, because an unpacked array type is "too complex"
> for the data_type BNF rule.
>
> I see no reason for making type parameter values as restrictive as cast types.
> I would rather see the sentence in 3.9 changed to something like:
>
> "User-defined type names must be used for complex data types in casting
> (see Section 3.14, below), which only allows simple type names, and
> as type parameters values when unpacked array types are used."
>
>
>
> > -----Original Message-----
> > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of Brad
> > Pierce
> > Sent: Tuesday, November 11, 2003 7:02 PM
> > To: sv-bc@eda.org
> > Subject: [sv-bc] Erratum and PROPOSAL -- 3.9 -- 'complex data types' as
> > parameters
> >
> >
> > According to 3.9,
> >
> > "User-defined type names must be used for complex data types in casting
> > (see Section 3.14, below), and as parameters."
> >
> > The BNF implements this sentence for casting, but not for parameters,
> > because
> > according to A.4.1.1, a parameter assignment can take any data_type, and
> > according to A.2.4, so can a type_assignment.
> >
> > PROPOSAL
> >
> > In A.4.1.1 and Syntax 18-3 in ordered_parameter_assignment
> > and in named_parameter_assignment, REPLACE
> >
> > data_type
> >
> > WITH
> >
> > simple_type
> >
> >
> > In A.2.4 and Syntax 20-1, in type_assignment, REPLACE
> >
> > data_type
> >
> > WITH
> > simple_type
> >
>
This archive was generated by hypermail 2b28 : Wed Nov 12 2003 - 11:15:15 PST