Subject: Re: $sv-cc - defining memory layout for SV data types
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Oct 22 2002 - 06:59:59 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.
Very good point. Will compiler 'know' which internal SV data objects
may be accessed by C code and when? What about VPI & PLI?
If C code may access only those pieces of SV data that have been explicitly
passed as arguments to a particular call then a compiler may provide on-the-fly
translatation from one layout to another.
If, however, an arbitrary piece of SV data might be accessed at any arbitrary
moment, then on-the-fly trranslation is automatically ruled out and compiler
is bound by the mandatory layout.
So, shall the (future) extensions of VPI & PLI be taken into consideration
when deciding whether to mandate any particular layout?
Andrzej
> Andrzej Litwiniuk writes:
> > 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.
This archive was generated by hypermail 2b28 : Tue Oct 22 2002 - 07:04:04 PDT