Subject: Re: [sv-cc] representation of SystemVerilog data types
From: Kevin Cameron (sv-xx@grfx.com)
Date: Tue Mar 04 2003 - 18:28:36 PST
> From - Tue Mar 4 17:49:19 PST 2003
>
> [Caveat: the following expresses my personal opinion which is not neccessarily
> same as the opinion/views of sv-cc.]
>
> SystemVerilog LRM generally does NOT specify the representation of SystemVerilog
> data types.
>
> The only sentence that addresses the isssue of representation can be found
> on the page 20 (LRM draft 3):
>
> "An unpacked structure has an implementation-dependent packing, normally
> matching the C compiler".
> (unless I overlooked something ...)
>
I complained about the lack of detail on packing and alignment a number
of times during 3.0 but didn't get agreement that the description was
inadequate.
I suggest you file an amendment of the text with the EC that can be voted
on for the final draft - I don't think anyone would object to something
like:
"An unpacked structure has an platform-dependent packing which
matches a C compiler for types that are directly supported in C."
[and add a cross ref to the table of matching types]
I don't think you'll get agreement on much more than that.
Kev.
>
> The second part of the above sentence is criticial yet ambiguous.
> What does it mean "normally"? Anyway, in sv-cc we interpreted this as
> the requirement that unpacked structures must be represented in the same
> way as used by C compiler for the analogous structures.
>
> Please note that the issue of representing other types: unpacked arrays, packed
> arrays, 4-state values, has not been addressed anywhere in LRM.
>
> The actual representation of SystemVerilog data types seems to be irrelevant
> and transparent for SV semantics.
> Sure, it matters for API (though it can be overcome via the use of canonical
> representation and on-the-fly translation), but definitely not for plain SV
> users.
>
> Therefore I think that the remarks on data representation should be removed
> from the core LRM.
>
> There should be, however, an annex (or a small section) dedicated solely to
> the representation of SystemVerilog data types, regrdless how small it will be.
> Such an annex could be ignored and skipped by SV programmers,
> yet it will be extremely important for the implementors.
>
> IMO:
> - LRM should not specify the representation of packed data types.
> The statement that any packed data type is eventually equivalent to
> a packed array refers to the semantics; it says nothing about the layout
> in memory. And this is right.
>
> - LRM should specify the representation of the basic types: int, longint, etc.
>
> - LRM should specify the representation of unpacked structures as C compatible.
> "The representation of unpacked structure is implementation- and platform-
> dependent. It shall match C compiler, i.e. should be same as the
> representation used by C compiler for a compatible C structure."
>
> Unfortunately, this is a bit tricky.
> If an unpacked structure contains a packed type, then what?
> Whatever is the representation of that packed type, defined in C,
> the structure shall be represented identically as C structure with
> equivalent fields. (This can be decently defined in an inductive manner.)
>
> - LRM should specify the representation of unpacked arrays of unpacked types
> as C compatible.
> "The representation of unpacked array of any unpacked type shall match C
> compiler."
>
> - I'm very hesitating whether the representation of unpacked arrays
> of =packed= types should be defined.
> Whatever is the decision, it should be clearly stated.
> I'm rather biased towards opinion that the representation of unpacked arrays
> of =packed= types should be left to compiler.
> Compiler may decide to use different representation for array elements
> than for a single element of the same type.
> For example, single value of type 'bit[18:1]' may be represented as 'int',
> while 3 bytes may be used for each element of that type in an unpacked array.
>
>
> Regards,
> Andrzej
>
This archive was generated by hypermail 2b28 : Wed Mar 05 2003 - 00:07:09 PST