Subject: Re: [sv-bc] Erratum and PROPOSAL -- 3.9 -- 'complex data types' as parameters
From: Greg Jaxon (Greg.Jaxon@synopsys.com)
Date: Wed Nov 12 2003 - 10:43:15 PST
npacked array types are only "too complex" for these contexts
because the data declaration syntax uses the declared name to
separate and group the packed dimensions. Typedefs also separate
and group, so they offer a detour.
We could use the time-honored syntax for separating and grouping,
i.e. parentheses, to write unpacked array types as:
module m #(parameter type T = (logic[7:0])[0:255]) (...
Or we could make type parameter assignment resemble typedef
module m #(parameter type logic[7:0] T [0:255]) (...
I think the latter is probably easier to achieve in the BNF and in
most existing SV parsers.
Greg Jaxon
Mark Hartoog wrote:
> 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 - 10:45:16 PST