Subject: [sv-cc] representation of SV data - imposed restrictions
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Mar 12 2003 - 09:02:34 PST
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 : Wed Mar 12 2003 - 09:03:48 PST