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

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

Jim Vellenga | Member of Consulting Staff | Cadence

P: 978.262.6015 F: 978.262.6636 www.cadence.com<http://www.cadence.com>

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