Duncan, Ralph wrote:
> ....Byte-based Allocation for Packed Types
>
> The approach would standardize the size of packed type 'actual'
> implementation formats,
> making actual format size equal to the smallest number of bytes (C
> unsigned chars) needed to represent
> .. a 2-state packed type:
> .. a 4-state packed type if cvals and dvals were carried in separate
> bytes (though they need not be).
>
> ...
>
I have a fundamental objection to the Cval/Dval approach to 4-state
values: the 4-state abstraction is a degenerate case of a 3-dimensional
value (level,certainty and strength), while that isn't relevent for some
simulation it is relevent for analog/digital mixed signal simulation -
which is something that will likely have to be supported through DPI
since there has been no movement on actually integrating AMS into SV.
> SUMMARY
> We think that the original proposal (based on allocating in 4-byte
> chunks) provides the most benefits,
> when compared to either the 1-byte approach or to the current
> binary/source compatibility scheme:
> . binary compatibility for packed types,
> . a single compatibility scheme for users to understand,
> . an intuitive macro interface that reveals data type and array
> dimensions,
> . a single base type to drive alignment behavior,
> . minimized data marshalling for the most likely uses of packed types.
>
> Ralph Duncan
>
One alternative I would suggest considering is: use the same layout as C
for any C compatible types, but any references to SV specific types be
treated as void* which can be null or a handle to the simulator's data.
E.g.:
SV: struct { DPI/C: struct {
int i; int i;
logic array[4:1]; void *array_handle;
real r; double r;
} }
If supplied the handles could be used by PLI/VPI or some other interface.
BTW, are folks expecting the SV compiler to spit out header files for
use by the DPI code?
Kev.
>
> Mentor Graphics
> San Jose, CA
>
-- Altera Corp, 101 Innovation Drv, San Jose, CA 95134. T# (408) 544 7126Received on Wed Oct 20 15:09:26 2004
This archive was generated by hypermail 2.1.8 : Wed Oct 20 2004 - 15:09:37 PDT