Subject: Re: $sv-cc - defining memory layout for SV data types
From: Michael McNamara (mac@verisity.com)
Date: Mon Oct 21 2002 - 17:19:17 PDT
It is a difficult issue. However, it is an API, and we have to at
minimum describe what the C programmer gets when she accesses a piece
of System Verilog data. One approach that could be taken is to
specify the required layout that a System Verilog simulator must use;
then specifying what the C programmers sees is very easy; they get
what the simulator uses.
Another approach is to only specify what the C programmer sees, and
leave to the creativity of the simulator implementor the decision on
how to layout data within the simulator, to perhaps serve his sense of
aesthetics; with the expense of copyin/copyout operations.
Translated, Either we mandate the layout, or we mandate a slow
interface that requires copying and conversion.
I will say that applying our creativity at Chronologic, given that the
layout of data was mandated, as well as certain persistance of access
issues, we chose to store data in memories exactly the way it was
specified by the tf_nodeinfo's memval datastructure (Figure 21-9 of
1364-1995), as while the runtime hit was not insignificant, because of
the design of the tf_nodeinfo call, a programmer could fetch a
tfnodeinfo datastructure, and then at anytime later access the data in
the memvals. Hence we could not 'know' when to copy a memory from an
efficient layout to the layout mandated by the existing interface.
At the time we did have a switch in VCS that if supplied would have
VCS store memories efficiently, at the expense that tf_nodeinfo would
not work on memories; and we saw typically a less than ten percent
improvement in runtime of the standard designs of the day (microSparc
and the like).
Andrzej Litwiniuk writes:
> > > 3. Extensions list discussion
> > >
> > > Kevin is pushing to have an agreed upon definition of memory layout.
> > > David indicated that this is the responsibility of the SV-CC to define.
>
>
> I oppose the idea of defining a memory layout of SV data types as a
> part of the language definition. It might be over-restrictive for
> the efficient implementation and compiler optimizations.
>
> In VCS implementation of Verilog, elements of memories (arrays) are
> represented differently than individual vectors; this seems to be a
> relic of old PLI specification. Such difference is a major source
> of inefficiency.
>
> Besides, an optimal representation of data may be platform
> dependent. For example, bit vectors may be represented by grouping
> bits in chunks of 8, 32 or 64 bits depending on the hardware
> platform.
>
> Similarly, there is more than one way of representing 4-state
> vectors (values of type logic).
>
> The representation of enum types may depend on the representation
> of sized values of types bit and logic.
>
> Consequently, there is no unique and obvious mapping from SV types
> to C types.
>
> This holds also for struct types, which may contain non-C values.
> Hence, I don't think that C representation of C data structures may
> serve as a reference point for SV data types used in the interface.
>
>
>
> > Is everyone that is currently implementing a SystemVerilog
> > simulator intending to implement structs and arrays that are
> > directly representable in C (i.e. unpacked 2-state data) with
> > the same memory layout as C?
>
> I'm not sure it will be very helpfull to specify that some
> structures and arrays (particularly those that contain only
> unpacked 2-state data) are represented in the same manner as in C,
> while the representation of other data types is unspecified and
> implementation dependent.
>
> > My understanding is that that is what SuperLog does, but it isn't
> > explicit in the 3.0 standard that SV works that way.
> >
> > Kev.
>
> And, IMO, it shouldn't be in the standard.
>
> Thanks,
> Andrzej
This archive was generated by hypermail 2b28 : Mon Oct 21 2002 - 17:23:00 PDT