Subject: [sv-cc] representation of SystemVerilog data types
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Mar 04 2003 - 16:57:46 PST
[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 ...)
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 : Tue Mar 04 2003 - 16:58:51 PST