Subject: Re: $sv-cc - defining memory layout for SV data types
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Mon Oct 21 2002 - 06:33:53 PDT
> > 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 - 06:38:19 PDT