Subject: [sv-bc] Fwd: Fw: [sv-cc] Re: representation of SV data types - updated version
From: Karen Pieper (Karen.Pieper@synopsys.com)
Date: Tue Mar 18 2003 - 09:18:41 PST
Hi, all,
Here is some feedback from the CC on data layout in SV. Please
feel free to comment.
K
>To: Karen.Pieper@synopsys.COM
>Date: Mon, 17 Mar 2003 22:51:52 PST
>Subject: Fw: [sv-cc] Re: representation of SV data types - updated version
>X-Mailer: Juno 5.0.33
>From: Swapnajit Mittra <mittra@juno.com>
>
>
> Karen,
>
> This is related to the earlier email that Andrzej sent to you
> regarding representation of SV data type. Please let me know
> if you or your team has any feedback.
>
>- Swapnajit Mittra
> --------- Forwarded message ----------
>From: Andrzej Litwiniuk <Andrzej.Litwiniuk@synopsys.com>
>To: mittra@juno.com (Swapnajit Mittra)
>Cc: sv-cc@server.eda.org
>Date: Thu, 13 Mar 2003 19:58:05 -0500 (EST)
>Subject: [sv-cc] Re: representation of SV data types - updated version
>Message-ID: <200303140058.TAA06837@lem.synopsys.com>
>
> > 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
>
>________________________________________________________________
>Sign Up for Juno Platinum Internet Access Today
>Only $9.95 per month!
>Visit www.juno.com
This archive was generated by hypermail 2b28 : Tue Mar 18 2003 - 09:19:39 PST