Subject: Re: [sv-bc] Issues about unpacked structure and array type assignment compatibility
From: Greg Jaxon (Greg.Jaxon@synopsys.com)
Date: Tue Oct 28 2003 - 10:34:12 PST
You've noticed an ambiguity that was only partially set right in the SV "final"
document. Optimistic sentences in several spots claim that all forms of
aggregate expressions will work with any structure. The definitive sections
backed off from that - they only describe this syntax for unpacked structs.
The ambiguity directly affects concatenations and enumerated aggregates.
But {as:so, ci:ations} are guilty by association if you can excuse the pun.
Packed structs *could* unambiguously be constructed by association aggregates.
But adding this is not a pure language extension, since it goes hand-in-hand
with a change in the recursive definition of {type:val} and {default:val}.
I maintain that, when used in an unpacked struct or array aggregate, these
/do not/ descend into packed substructure - i.e. "val" becomes the packed
bit pattern of the outermost matching packed fields or packed elements.
Incompatibilities arise for {default:val} (which I think is anti-typesafe),
and for {type:val} where type is packed. Good design here needs to consider
how the matching rule between "type:val" and the field or element's type
should work when they are both packed, but not otherwise identical. These
recursive aspects induce a sort of vertigo of my inner type system. Otherwise.
I would have proposed a rewording by now.
Allowing packed aggregates to be constructed with association syntax, but NOT
with enumeration syntax would also make them even more difficult to distinguish.
Parsing - both by eye and by machine, would be far more difficult. Simple
transformations from association into enumaration would accidentally cross
over into being concatenation, and thus have different bit layouts.
I don't think anyone wants to go there.
Greg Jaxon
P.S. Similar concerns apply to packed_struct'{field:val, type:val}.
Francoise Martinolle wrote:
> Is it allow to have a structure concatenation assigned to a packed struct?
> Ex;
> typedef struct {
> int a, b;
> } struct1;
>
> struct1 var1 = {a : 0, b : 2};
This example is an unpacked struct - which is the default, so it is OK.
> I don't think it should as it would cause ambiguity with positional
> associations which is
> undistinguishable from normal old Verilog concatenations.
> The result could be different depending if you would interpret it as an
> old concatenation or as a structure concatenation.
>
> Ex:
> typedef packed struct {
> logic [1:0] a;
> logic b;
> } struct1; This is a 3 bit vector
>
> struct1 var1 = {2'b00, 3'b100}; This is an old verilog concatenation
> which result is a 5 bit truncated to the 3 bits when assigned to the
> left hand side. var1 should be assigned 3'b100.
Right.
> If this is considered as a structure concatenation, then the assignments
> (extension and truncation ) are made per field and the result of var1
> would be 3'b000
Right.
>
> Francoise
This archive was generated by hypermail 2b28 : Tue Oct 28 2003 - 10:35:55 PST