RE: [sv-cc] Clarifications

Vitaly,

    Some comments below with ARNAB prefix.

-Arnab

From: Vitaly Yankelevich [mailto:vitaly@cadence.com]
Sent: Tuesday, August 09, 2011 6:33 AM
To: Saha, Arnab; Jim Vellenga; sv-cc@eda.org
Subject: 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.

ARNAB: I was told that there was a long discussion about this when DPI-C
was proposed and the final outcome was biased towards a more hardware
centric view of enums, which is why it is

represented as an integer. The same arguments will be valid for C++ as
well since C does not have any inherent limitation with enums that C++
enhances. For structs the only difference is how

packed dimensions are represented in the C++ intermediate layer. Again
there is no inherent limitation in C to not do the same, so why wasn't
it done this was for DPI-C. I did not participate in

the DPI-C discussions, so I don't have all the history but would like to
understand the motivation behind the DPI-C approach and why it wasn't
done the way it is being proposed for DPI-OO.

* 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.

ARNAB: I can understand the class methods have an implied context "this"
and does not need any context settings, but a DPI-OO sub-routine which
takes a class argument may need the context. It may be too limiting to
only allow them inside packages and not allowing a context to be
specified for them.

* 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.

ARNAB: I am not sure if it is within the scope of this LRM to define how
other language like SystemC and e will communicate with each other. To
define the intermediate layer for SystemVerilog, since the export or
import is with respect to SystemVerilog, I don't see why we can't use
the name "sv" in the types used in the intermediate layer since after
all one end of the layer(import or export) will always be SystemVerilog.

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.

ARNAB: I had seen some differences in the earlier versions of the
proposal. It looks like that all is cleared in the new version 1.0.2.
The use of STL is probably another concern here. There are definite
drawbacks for using STL. I am not totally opposed to the use of STL, but
this is something that should probably be discussed.

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.