[sv-cc] DPI-OO: Open arrays as handles or STL vectors ?

From: Vitaly Yankelevich <vitaly@cadence.com>
Date: Fri Aug 19 2011 - 13:12:20 PDT

Arnab,

You wrote:

"Pros for STL vector:
               More aligned with C++ and OO
Cons:
               Extremely slow to copy as every bit of the data needs to be copied to the vector.

IMO using handles for open arrays will be far more efficient here. If possible C++ operators can be provided to convert
open array handles to STL vectors."

There are additional pros for STL vectors and cons for DPI-C-like API:

1) We are not convinced that STL vectors will make the interface much slower.
                On one hand, SystemVerilog and C++ layouts are different anyway, hence it is impossible to copy data using memcpy() anyway.

                On the other hand, STL provides pretty efficient mechanisms of filling and copying vectors. For example, if they need to copy a C-like array to a vector
               they can write it as follows:

               vector<int> myvector (myint_array, myint_array + sizeof(myint_array) / sizeof(int) );

               Moreover, they can even use memcpy as follows:

     myvector.resize(number-of-elements);
     memcpy(&myvector[0], arr, sizeof arr)

2) Operating with open array handles is complicated. Currently DPI-C defines the following API functions for querying and accessing open arrays:
     /* h= handle to open array, d=dimension */
int svLeft(const svOpenArrayHandle h, int d);
int svRight(const svOpenArrayHandle h, int d);
int svLow(const svOpenArrayHandle h, int d);
int svHigh(const svOpenArrayHandle h, int d);
int svIncrement(const svOpenArrayHandle h, int d);
int svSize(const svOpenArrayHandle h, int d);
int svDimensions(const svOpenArrayHandle h);

void *svGetArrayPtr(const svOpenArrayHandle);
int svSizeOfArray(const svOpenArrayHandle);
void *svGetArrElemPtr(const svOpenArrayHandle, int indx1, ...);
void *svGetArrElemPtr1(const svOpenArrayHandle, int indx1);
void *svGetArrElemPtr2(const svOpenArrayHandle, int indx1, int indx2);
void *svGetArrElemPtr3(const svOpenArrayHandle, int indx1, int indx2, int indx3);
 ...
and many more

                Automated generation of C++ proxies to operate with this huge API will be very complex. Calling those access functions will be slower than accessing a vector.

3) The DPI-C API for open arrays comes with limitations (for example a number of dimensions (indexes) is limited to 3. Those limitations originate from the limitations of the C language, which do not exist in C++. Using STL vectors they can map any number of dimensions.

4) Uisng sv-centric API is good only for SystemVerilog part of the interface, which is always mixed-language. The end user on the SystemC/C++ side will likely to use std::vectors anyway (or they will use just row pointers). The SV-centric API for accessing subroutine arguments coming from C++/SystemC/e will not be applicable. That means, proxies for import classes will look different from proxies for export classes. It contradicts the goal of defining DPI-OO as a truly multi-language API.

       Given all of the above I feel strongly in favor using of STL vectors.

Regards,
Vitaly

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Aug 19 13:12:57 2011

This archive was generated by hypermail 2.1.8 : Fri Aug 19 2011 - 13:12:58 PDT