RE: [sv-cc] New Mantis item (274) on DPI's svBitVec32 --> open arrays 27.1.2

Andrzej,

Disagreed. Consider types 'shortint' and 'signed bit[15:0]'.
These are semantically different. They have different alignment
and endianness considerations on a per-platform basis.

Table E-1 in the LRM states that SV 'shortint' is equivalent to
C 'short int'. Similar applies to 'byte' and 'longint'.

Think about the difference in data alignment for 'shortint'
and 'signed bit[15:0]'. On big-endian platform, the 'shortint'
bits will need to be placed in one end of a 32 bit word. On a
little-endian platform, the 'shortint' bits will need to be placed
in the other end of that word. That is the way the C compiler
expects to receive the bits on each platform.

When passing 'signed bit[15:0]', the situation is different.
The data needs to be placed in canonical form (i.e. conform
to svBitVec32 stipulations) which is a machine-independent
definition. Alignment is always the same.

Thus 'signed bit[15:0]' and 'shortint' are not semantically
equivalent when used as DPI tf formal arguments. The same
applies to 'byte', 'int', and 'longint'.

This is a very important (but backwater!) part of the SV language,
and it is not well understood in my experience.

Treating 'bit[x:y]' in a uniform way for all values of x and y
will be a good simplification to the language, and not costly
in terms of performance, since for high performance interaction
with C, programmers should always be using native C types anyways.
And if they can't use a native C type, they can still declare their
DPI tf formals with native C types, and allow the SV compiler to
coerce their bit[x:y] into the formal's 2-state integral type.

Regards,
Doug

> -----Original Message-----
> From: Andrzej I. Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> Sent: Wednesday, October 27, 2004 8:37 AM
> To: Warmke, Doug
> Cc: Andrzej I. Litwiniuk; sv-cc@eda.org
> Subject: Re: [sv-cc] New Mantis item (274) on DPI's
> svBitVec32 --> open arrays 27.1.2
>
> > Please check in the "Description" field of this Mantis item.
> > In there I explicitly state that the directly-C-compatible
> > small value types (longint, int, shortint, and byte) are still
> > to be passed by value rather than by svBitPackedArrRef.
>
> Doug,
>
> Types 'int' and 'signed bit[31:0]' seem to be semantically equivalent
> and thus mutually exchangable. Yet the former is to be passed
> by value and
> the later by reference? Or I'm missing something?
>
> Consider this:
>
> import "DPI" foo = function foo1(int i);
> import "DPI" foo = function foo2(signed bit[31:0] i);
>
> I suppose that the above definitions are correct since both
> function headers
> are equivalent. Both refer to the very same function foo, so
> both should
> pass their argument using the same passing mode.
>
> Thanks,
> Andrzej
>
>
> > I totally agree with you that it's vital to continue to do so.
> >
> > The case I'm talking about here is for non-C-compatible type
> > of dimensioned, packed bit arrays "bit [y:x]".
> >
> > Regards,
> > Doug
> >
> > > -----Original Message-----
> > > From: Andrzej I. Litwiniuk
> [mailto:Andrzej.Litwiniuk@synopsys.com]=20
> > > Sent: Wednesday, October 27, 2004 7:18 AM
> > > To: Warmke, Doug
> > > Cc: sv-cc@eda.org
> > > Subject: Re: [sv-cc] New Mantis item (274) on DPI's=20
> > > svBitVec32 --> open arrays 27.1.2
> > >=20
> > > > We discovered another minor difficulty in DPI.
> > > > The crux of the matter involves the "small" packed 2-state type
> > > > modeled with svBitVec32. When a 2-state vector is <=3D 32 bits,
> > > > it is no longer passed by reference, but rather by value.
> > > > This makes it impossible for a DPI user to create a single
> > > > imported function that accepts an arbitrary width 2-state
> > > > vector as an argument.
> > >=20
> > > Doug,
> > >=20
> > > I believe that open arrays were intended exactly for what you=20
> > > want to achieve,=20
> > > i.e. to "make it possible for a DPI user to create a single=20
> > > imported function=20
> > > that accepts an arbitrary width 2-state vector as an argument."
> > >=20
> > > LRM 27.1.2: "Formal arguments of an imported function can be=20
> > > specified as open arrays.=20
> > > A formal argument is an open array when a range of one or=20
> > > more of its dimensions, packed=20
> > > or unpacked, is unspecified. [...] An actual argument shall=20
> > > match the formal one regardless=20
> > > of the range(s) for its cor-responding dimension(s), which=20
> > > facilitates writing generalized=20
> > > code that can handle SystemVerilog arrays of different sizes."
> > >=20
> > > So in my opinion we have both; generality and efficiency for=20
> > > "typical" cases.
> > > Pls. also note, that passing small values 'by value' rather=20
> > > than by a reference is consistent=20
> > > with C. If small values, like int, were not passed by value,=20
> > > then it will be impossible=20
> > > to call standard C library functions from SV.
> > >=20
> > >=20
> > > Thanks,
> > > Andrzej
> > >=20
> > >=20
> > > > Details are located at
> > > > http://www.eda.org/svdb/bug_view_page.php?bug_id=3D0000274
> > > >=20
> > > > Charles,
> > > >=20
> > > > Can you please assign me to be the owner of this item?
> > > > I will upload a proposal that basically simplifies DPI by
> > > > eliminating the exception for bit vectors <=3D 32 bits in width.
> > > >=20
> > > > Thanks and regards,
> > > > Doug
> > > >=20
> > > >=20
> > >=20
> > >=20
> >
>
>
Received on Wed Oct 27 08:54:11 2004