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

Joao,

Yes I am familiar with that section.
In pure SystemVerilog coding, of course they are equivalent types.
However that doesn't change the facts of my presentation below.
There is no way that 'bit[15:0]' and 'shortint' can be uniformly
equivalent on all platforms.

Also note that in section E.6.4, there is precedent for the fact
that these 2-state types are not strictly equivalent:

   Note that input mode arguments of type byte unsigned and
   shortint unsigned are not equivalent to bit[7:0] or bit[15:0],
   respectively, since the former are passed as C types unsigned char
   and unsigned short and the latter are passed as C unsigned int
   (i.e., svBitVec32). A similar lack of equivalence applies to
   passing such parameters by reference for output and inout modes.

Regards,
Doug

> -----Original Message-----
> From: Joao Geada [mailto:Joao.Geada@synopsys.com]
> Sent: Wednesday, October 27, 2004 9:10 AM
> To: Warmke, Doug; 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
>
> 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:29:07 2004