Subject: Re: $sv-cc - defining memory layout for SV data types
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Oct 21 2002 - 09:41:53 PDT
> From owner-sv-cc@server.eda.org Mon Oct 21 06:37:26 2002
> From: "Andrzej Litwiniuk" <Andrzej.Litwiniuk@synopsys.com>
> Subject: Re: $sv-cc - defining memory layout for SV data types
> To: Kevin.Cameron@nsc.com
> cc: sv-cc@server.eda.org
>
> > > 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.
Note: I'm only suggesting the memory layout matches C for new 2-state data types,
4-state types would be implementation dependent.
> 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.
Packed data types would not need to be C compatible either. C alignment
matches what is efficient for the hardware platform.
> Similarly, there is more than one way of representing 4-state vectors
> (values of type logic).
See above.
> 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.
The request is that some "useful" subset of data types (2-state unpacked) would
be memory aligned the same way as C so that data is directly shareable using
pointers or through linking.
> > 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.
It's helpful because it avoids having to describe the same data differently in
C and in Verilog. Any software engineer will tell you that any time you copy
data rather sharing it you are at higher risk of suffering errors - that's why
it's also a good idea to reuse C syntax for thing like enums etc. which SV and
C might share.
> > 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
It's partly a question of how much work folks want to do, making as much of the
data as possible directly shareable reduces the API requirements and hence makes
the SV/C interface easier to implement (and faster). Trying to re-specify everything
the C/C++ linkers do for SV will take more time than I think we have available.
Regards,
Kev.
This archive was generated by hypermail 2b28 : Mon Oct 21 2002 - 09:45:55 PDT