Subject: [sv-cc] Re: representation of SV data types - updated version
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Thu Mar 13 2003 - 16:58:05 PST
> 2. Representation of SV data types
>
> Passed [7Y-0N-1A].
>
> Joao and Andrzej, please make a final rev of your respective
> proposals with any clean-up you want to do and send that to
> me/team. I will fwd them to sv-[e,b]c tomorrow.
>
> - Swapnajit.
Swapnajit and team,
Enclosed is the updated version of the section describing the representation
of SV data types.
Regards,
Andrzej
===================================================================
Data Representation
-------------------
The representation of SystemVerilog data types is transparent for SystemVerilog
semantics. Thus, what is the actual representation of data types and their layout in memory used by a simulator, shall be irrelevant for SystemVerilog
users.
The representation used by a simulator may matter, however, for applications
that communicate and interchange data with SystemVerilog code via APIs.
Specifically, it is desirable for the sake of interoperability, that SystemVerilog data types that are C compatible have their memory layout and representation compatible with C compiler.
On the other hand, the representation of SystemVerilog data types should be best
suited for simulation performance.
The optimal representation may differ depending on the platform, simulator's
architecture and on compiler optimizations.
Therefore language definition should impose as little restrictions on the data
representation, as possible, in order not to impair the simulation performance.
The following rules define the representation of SystemVerilog data types:
1. The representation of basic types is defined in LRM Section 3.
2. The representation of all packed types is implementation dependent.
Specifically, the representation of packed arrays of type bit or logic is
implementation dependent. Recall that every packed type is eventually equivalent
to a packed array of a type bit or logic.
3. The representation of an enumeration type shall be that of the type associated with an enumeration type
4. The representation of unpacked structures and unions shall be compatible
with C compiler.
5. The representation of unpacked arrays of unpacked types shall be compatible
with C compiler.
6. The representation of unpacked arrays of packed types may depend on their
position in a hierachy of types:
6a) an unpacked array of a packed type embedded in a structure or union
shall have the representation compatible with C compiler.
Specifically, individual elements of such an array must have the same
representation as a single value of the same type.
6b) The representation of a standalone unpacked array of a packed type,
i.e. an array that is not embedded in any structure or union,
is implementation dependent.
Specifically, for a standalone array, individual elements of such an
array may have different representation than a single value of the
same type.
For example, an unpacked array declared as bit [1:8] arr [1024*1024:1]
may use 1 byte or 4 bytes for representing each of its elements and thus take
1 MB or 4 MB of space.
Note that as a consequence of 6), the representation of two values of the same
type may be different.
================================================================================
From: Andrzej Litwiniuk <Andrzej.Litwiniuk@synopsys.COM>
Subject: [sv-cc] representation of SV data - imposed restrictions
To: sv-cc@eda.org
Date: Wed, 12 Mar 2003 12:02:34 -0500 (EST)
Team,
The representation of an unpacked array of a packed type is still an open
issue.
Let's recall the rules seemingly agreed upon:
- all packed types are amorphous from the C side perspective and seen as linear
packed arrays; therefore no other packed types exist on the C side but linear
arrays
- representation of packed arrays is implementation dependent;
there are macros for defining variables of such types
- unpacked structures must have C layout
- unpacked arrays of unpacked types must have C layout
- the representation of basic types (int, handle, shortreal, etc) is well
defined
- enumeration types are interpreted as the types associated with enum,
only the values are passable, the names are not available on C side
[I'm not sure this issue has been explictly discussed.]
- C type definition matching SV definition shall be constructed in
a compositional way, following the way SV type definition has been
constructed. This is a inductive definition.
Open issue: what about unpacked arrays of packed types? This is a tough call!
By and large - although with one exception - I tend to leave it to
implementors.
Vendors may want to decide how to implement an array even on the base of
individual objects, say, small arrays may use the same representation of each
element as individual values of same type, while huge arrays may use more
space-efficient representation.
Example: bit [1:8] arr [100000:1]; // one or four bytes per element?
There are two troublesome scenarios, however:
1) an unpacked array of a packed type embedded in a structure
2) an unpacked array of a packed type as an actual argument for a sized array
For 1) I see no other solution than to require an exception: an embedded array
must use C layout.
Note however, that this leads to nasty inconsequenses: a value of the same
type (an unpacked array of a packed type) may have different layout if embedded
in a structure and in standing alone.
For 2) there are two sub-cases: extern and export.
For extern we have already addressed this issue, implementation is allowed
to not accept specific arrays as actual arguments for sized formals.
Same rule may be proposed for exported functions. The C caller will have no
clue what representation is expected by the exported function and therefore
what to allocate and pass to SV as an actual argument.
Therefore we may prohibit exporting such functions. Will it be too restrictive?
Regards,
Andrzej
This archive was generated by hypermail 2b28 : Thu Mar 13 2003 - 16:58:54 PST