Re: [sv-cc] Idea about getting the DPI-OO import info directly from the header files

Hi Jim,

You can check my posts from around 02/11/2003 (e.g. http://www.eda.org/sv-cc/hm/0786.html) where I asked for that, and there's some other posts on how to interface into C++ code from different compilers for DPI.

Really the whole DPI/VPI thing was largely unnecessary, you could just make the handles used in PLI pointers to C++ objects with the appropriate virtual functions. That works nicely because you don't need link much, particularly if you mix different simulator libraries.

The question in my mind at this point (8 years on) is why did anyone invent all this extra language (i.e. SV) when most of it could have been done directly in C++ or Java which have real compilers and link level support. As I said in my last post the Java guys seem to have solved a chunk of the multi-language cross-calling in Java 7.

Kev.

PS: the C++ parser in my SV replacement project is open source if anyone needs one - http://parallel.cc - and it handles SystemC ;-)

PPS: http://en.wikipedia.org/wiki/Reinventing_the_wheel

On 09/01/2011 07:03 AM, Jim Vellenga wrote:
>
> This is in response to the suggestion that we eliminate the need for import DPI-OO declarations and just have SystemVerilog read the C++ header files directly.
>
>
>
> This is an attractive idea, and we may want to add something like this as an enhancement later. It has an appeal because, with a few additions, it could eliminate the need for "two copies of the truth." Two copies of the truth always run the danger, of course, of getting out of synch.
>
>
>
> But for now, I think the idea would require too many additions to get it ready in time for the current PAR for the following reasons.
>
>
>
> 1) The import DPI-OO declarations contain a lot of information that the header files do not. There is in fact a many-to-one relationship between the SystemVerilog constructs and the corresponding constructs in the proxy layer. For example
>
>
>
> -- Among the basic types in Table H.1, both "bit" and "logic" types map to unsigned char. A SystemVerilog compiler finding an unsigned char argument in a header file would not know which SystemVerilog type to map it to.
>
>
>
> -- Multidimensional packed types, or for that matter packed structs, map to "svBitVecVal *" and "svLogicVecVal *" arrays in C, with no information about type, dimensionality, or even number of elements.
>
>
>
> 2) The present proposal allows import classes to inherit from non-import classes, without information about the non-import classes being included in the proxy class declarations. Along with this is the ability to call a dpi_initialize() in the imported class to perform set up for the local version of the class object (proposed subclause 35.14); this dpi_initialize() function is not declared by the proxy class. (As I understand it, allowing import classes to inherit from non-import classes is for Cadence an essential element.)
>
>
>
> 3) The present proposal also allows import classes to have nonimported methods of their own that can call imported methods and reference inherited data. Again, these would be declared in SystemVerilog and not available to other languages importing the same proxy-based class. Hence, they will not have been declared in the C++ proxy header file.
>
>
>
> 3) The present proposal allows an importing language (SystemVerilog) to import a proper subset of the proxy class methods.
>
>
>
> For these reasons, I believe we need to keep the import declarations as part of the present proposal. In the future, we could have SystemVerilog compile less complex import classes directly from the proxy class header files, but given the time constraints, I'd like to focus on our other issues and leave this one alone for now.
>
>
>
> Regards,
>
> Jim
>
>
>
> http://www.cadence.com/mail/footer_gray_640.gif
>
>
>
>
>
>
>
> *Jim Vellenga* | Member of Consulting Staff | Cadence
>
> P: 978.262.6015 F: 978.262.6636 www.cadence.com <http://www.cadence.com>
>
>
>
> http://www.cadence.com/mail/footer_gray_640.gif
>
>
>
>
>
>
>
>
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.