Subject: Re: [sv-bc] Issues about unpacked structure and array type assignment compatibility
From: Greg Jaxon (Greg.Jaxon@synopsys.com)
Date: Mon Oct 27 2003 - 14:36:22 PST
Francoise Martinolle wrote:
> I am finding possibly conflicting or unclear statements in the 3.1 LRM
> regarding unpacked types assignment compatibility.
>
> In section 11.25: I found:
>
> 2) SystemVerilog structs are type compatible so long as their bit sizes
> are the same, thus copying structs of
> different composition but equal sizes is allowed. In contrast,
> SystemVerilog objects are strictly strongly typed.
> Copying an object of one type onto an object of another is not allowed.
>
>
> Note: is the bit size of an unpacked structure defined? Or is this
> clause (2) only pertaining to packed structs (essentially vectors).
I believe 11.25 (2) *is* a spot whose wording needs to be corrected. I think it
was written with only "packed" structs in mind. Even then, I don't think there
is a "equal bit size" requirement - truncation and (sign) extension may
also happen on packed struct assignments.
> And In section 7.14 (aggregate expressions ) I found:
>
> 7.14 Aggregate expressions
> Unpacked structures types are equivalent by the hierarchical name of its
> type alone.
> Unpacked arrays types are equivalent by having equivalent element types
> and identical shape.
> Therefore I could not assign an array of reals to an array of integers
> because their element type is not equivalent.
Correct.
> I am also guessing that
> type equivalence means same type but not the same type name.
No. It really means that the two types share a common point of definition.
Some renaming may have happened along the way to the point of reference, but
the compiler is not looking merely at "spelling" - it wants you to be using the
same type definition from the same declarative scope. Making this ideal
work for separate compilations is a further challenge, and in that realm
I think all SV asks is that the scopes and type identifier have the same spelling,
but the implication is that some extra-lingual forces should insure that
identical hierarchical names have identical definitions, just as though the
compilations were not done separately.
> Type equivalence should be defined in SystemVerilog LRM.
>
> section 11.14: what is type equivalence? It is not defined anywhere.
The definition is there - its wording should cover packed structs better,
but it says all the essential things.
> why would the rule for structure copy or
> comparison require that they have the same type? Why not just requiring
> that struct variables have struct types of the same shape but not the
> same name?
This choice aligns better with C++, and suits SV's enhanced role in verification
> typedef struct {
> int a, b;
> } struct1
>
> typedef struct {
> int x, y;
> } struct2.
>
> struct1 var1;
> struct2 var2;
>
> initial
> var1 = var2; // is this legal?
>
No.
Greg Jaxon
This archive was generated by hypermail 2b28 : Mon Oct 27 2003 - 15:13:44 PST