Subject: Re: [sv-bc] Proposal for SV-BC-105 aggregate expressions vs concatenation
From: Dave Rich (David.Rich@Synopsys.COM)
Date: Sat Jan 17 2004 - 00:28:22 PST
I have attached another version with typos that people have found.
Paul,
The only reason to add type:value is when default:value won't cover all
the elements or members.
For synthsizable code, the only case is where a member of a struct is an
enumerated type. If I had:
typedef enum {yes,no,maybe} choice_t;
struct {
logic foo;
...
choice_t q1;
choice_t q2;
....
} S;
always @(posedge clk or negedge reset)
if (!reset)
S = {default:0,choice_t:no};
else
...// normal clocked code
Just writing {default:0} would be a syntax error because 0 is not
assignment compatible to q1 and q2, and they would be left un-covered.
Dave
Paul Graham wrote:
>>In specifying the behavior of "type:value", Dave has changed from requiring
>>an "exact match" between the label type and the type of a field, subarray, or
>>array element to requiring only "equivalent" types.
>>
>>
>
>In the first place I don't see the great need for type:value members in a
>struct. A struct is a heterogenous data structure. Even if two members of
>a struct have the same type, it is likely that they have different meanings.
>Use of type:value is likely to break unexpectedly as new members are added
>to the struct.
>
>If we're going to go with type:struct, I would recommend following the
>existing grammar:
>
> array_member_label ::=
> default
> | type_identifier
> | constant_expression
>
>This disallows examples like the one in section 7.14:
>
> initial s2 = {bit[31:0]:1, default:0, string:""};
>
>where a data_type is used instead of a type_identifier.
>
>However, I would extend the grammar to allow type keywords such as "int",
>"bit", etc as array_member_labels :-)
>
>I would recommend limiting the array_member_label to a type_identifier, and
>define "exact match" in terms of matching type identifiers (or type
>keywords). This makes it clear to the user what is meant.
>
>A problem with using type equivalence for matching is that types are
>typically parameterized, and changing the parameter values can make
>different types become equivalent and non-equivalent. As Greg has just
>pointed out, this is a source of maintenance problems.
>
>Paul
>
>
>
>
-- -- David.Rich@Synopsys.com Technical Marketing Consultant http://www.SystemVerilog.org tele: 650-584-4026 cell: 510-589-2625
This archive was generated by hypermail 2b28 : Mon Jan 19 2004 - 12:31:07 PST