RE: [sv-cc] Clarifications

Arnab,

I think that full compatibility with DPI-C does not justify loss of power and expressiveness which are important when talking about interoperability of object-oriented languages.
Specifically, concerning the incompatibilities between DPI-C and DPI-OO you are mentioning:

* Mapping of SystemVerilog enumerations to C++ enumerations adds additional power which does not exist in DPI-C. Specifically, once we are adding support for user-defined types,
such as classes, it is reasonable to expect adding also support for other user-defined types: enumerations and structs. DPI-C maps enum's to integers. IMO it's insufficiently expressive
to enable only one language to operate with enumerations and structures.

* I'm not sure about importance of compatibility between DPI-C and DPI-OO in general. There is, for example, one basic difference between them anyway: DPI-C subroutines require explicit context to be specified, while DPI-OO does not refer and doesn't require explicit setting of context. So the proposal is not building DPI-OO on top of DPI-C - it only re-uses it as much as possible without loss of features.

* Introducing new C++ type names for 2 and 4 state arrays allows to export, for example, SystemC sc_logic argument or field as LogicVecValT rather than svLogicVecVal. The implementation of the types is the same, so casting between the types (if necessary) should be pretty straightforward. The benefit of using a language-enutral name is that the same C++ proxy can be seamlessly used if a SystemC is exported to SystemVerilog or to e language.

Could you please elaborate on your concern regarding open arrays of reference and copy classes? The proposal is to use std::vector for all kinds of open arrays - only the elemnt types are different.

Thanks,
Vitaly

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Saha, Arnab
Sent: Tuesday, August 09, 2011 8:39 AM
To: Jim Vellenga; sv-cc@eda.org
Subject: RE: [sv-cc] Clarifications

Jim,

   I am not convinced of the benefits of keeping the C++ intermediate layer language neutral at the cost
of introducing new C++ types for 2 and 4 state, open arrays, structs, union and enum arguments.
Basing DPI-OO completely on top of DPI-C does have the benefit of ease of use as you don't have to
learn two different interfaces besides what is new. I am also not in favor of having different representation
of the same type in a copy vs a ref class. For example in C++, an open array or a 2-state member of a copy
class will have a different type than an method argument of a ref class.

-Arnab

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Jim Vellenga
Sent: Monday, August 08, 2011 8:54 AM
To: SystemVerilog CC DWG (sv-cc@eda.org)
Subject: [sv-cc] Clarifications

Arnab and Arturo, we're working on responses to the concerns voiced at the last SV-CC meeting. I'm not sure which one of you was raising the questions about argument types, but could you help us out by reclarifying your concerns about

-- open arrays

-- 2-state and 4-state arguments

Thanks,
Jim Vellenga

Jim Vellenga | Senior Member of Technical 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<http://www.mailscanner.info/>, and is
believed to be clean.
--
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.