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

Doug,

have a look at the LRM, section 4.2, page 33 (printed) [page 49 PDF], top of
the page.

It states that
        byte c2;
and
        bit [7:0] c2;
are to be the same as far as SV is concerned. It even states the order of the
indexes etc.

Joao
==============================================================================
Joao Geada, PhD Principal Engineer Verification Group
Synopsys, Inc TEL: (508) 263-8083
377 Simarano Drive, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================

> -----Original Message-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org]On Behalf Of
> Warmke, Doug
> Sent: Wednesday, October 27, 2004 11:54 AM
> To: Andrzej I. Litwiniuk
> Cc: sv-cc@eda.org
> Subject: 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 09:09:45 2004