[sv-cc] RE: Container class for open arrays

Arnab, I don't understand your statement that "since a use[r?] would never be calling the constructor , there is no need to create one." In my mental model of a multilanguage interface, it would certainly be possible for a subroutine exported by another language (C++, SystemC, etc.) to return an open array as an output argument. And that subroutine might well be accessed by a third language, which also does not know about SystemVerilog handles. In that case, one of the two other languages would have to create the argument structure. What am I missing?

Also, while we do not have to specify a particular implementation for open arrays, I would expect a single implementation to be shared among all the languages in any one application. I think it will be difficult to bind the appropriate open array implementations to the appropriate invocations of the exported subroutines. That could mean having separate implementations not merely between any two languages but even for each combination of languages. How do you see this happening?

Jim

From: Saha, Arnab [mailto:arnab_saha@mentor.com]
Sent: Saturday, 24 Sep 2011 5:24 PM
To: Jim Vellenga
Cc: sv-cc@eda.org
Subject: RE: Container class for open arrays

Hi Jim,

     I had no email access yesterday hence couldn't reply you back.
I think attaching the implementation of the openArrayT<> class caused
some confusion. My intention was to only show a prototype that works
with SV. The intention is to only standardize the interface of openArrayT
and not the implementation and the interface is generic and not tied to SV
except probably the constructor which can be taken out of the standard
since a use would never be calling the constructor there is no need to
create one. Although my version of the implementation works only with
SV open array, it can be extended to operate on open array handles from
any language. It can also have a DPI_OO::LanguageT field indicating which
language it came from, that again is an implementation detail and not part
of the interface. I have some more comments below with ARNAB prefix.

Thanks
Arnab

________________________________
From: Jim Vellenga [mailto:vellenga@cadence.com]
Sent: Fri 9/23/2011 8:26 AM
To: Saha, Arnab
Cc: sv-cc@eda.org
Subject: RE: Container class for open arrays
Arnab,

Thank you for getting the proposal out so quickly.

There are a number of nice features about it. You have laid out the types and methods clearly, and I like the fact that a size() method is included.

I do have a concern, however. As you must know by now, my understanding of what Cadence wants is a C++-based hub that allows multiple languages to communicate, one of which may or may not be SystemVerilog. What this means is that the mechanisms used to pass information back and forth between the languages cannot depend on SystemVerilog being present.

I am not personally opposed to having a container other than an STL vector<> as the mechanism for open arrays. I hear your argument that an STL vector<> necessarily requires the data to be copied one extra time. So if we wanted to define a container that lets the implementation pass the address of a vector without making a copy of its contents, that would be fine with me, and would fit with what I believe Cadence wants.

ARNAB: I feel the openArrayT container does that and can operate on arrays handles from other languages.

I know that Arturo has said explicitly that he doesn't need a multilanguage interface. All his customers are asking for is a way to communicate between SystemVerilog and C++. And I have to admit that your proposal allows for that. But for true multilevel communication with or without the presence of SystemVerilog, I see the following drawbacks of the openArray approach:

-- It looks like all the vector allocation gets done by SystemVerilog. I see that the sentence has been deleted that says that "The caller language shall allocate and de-allocate a vector...."

ARNAB: It can be created in another language as well. There is no need for user to crate one of these objects since open arrays cannot be passed back to SV. As long as the other languages have the same restriction, this should be fine. It is fine for SV at least.

-- The proposed openArray::size() method is implemented as a call to svSize(arrayhndl, dimension), so that size is determined soley by SystemVerilog.

ARNAB: Size can be implemented based on the source language.

-- The examples do not distinguish between the C++ intermediate layer and C++ as another language. I'll admit that, since the foreign language is responsible for implementing the subroutines and methods that SystemVerilog imports, this would be a possible implementation when C++ is the foreign language. But we also need to provide explicitly for the case where the other language is using its own native types for arrays. For example, a C++ application might be exporting a function that uses STL vectors as arguments instead of openArrays. Or a SystemC application may want to export a function with an argument declared as "sc_in<sc_uint<2> > a[4]". The C++ intermediate layer function should then be responsible for obtaining a vector made up of contents of the foreign language array and then passing the address of the pointer back to the importing language -- in this example, SystemVerilog.

ARNAB: Whatever we choose at the interface, the same issue needs to be solved. I think this is orthogonal to what we choose to represent open arrays as long as it can be converted to one of the other supported forms. For example, if open arrays are represented as std::vector<>, it still needs to handle the SystemC type sc_in<sc_uint<2> > a[4]. Also, how would the intermediate layer know what the representation is in the foreign language ? Will that be done by some kind of pragma. I didn't see anything in the proposal regarding that.

Unless I hear otherwise, I will not be able to support a proposal that does not provide this flexibility -- that is, that does not provide for multilanguage communication without SystemVerilog present.

The other possibility, of course, is to let the designer choose either the ordinary DPI-C handles or the proposed STL vectors, as selected by a compiler directive. I could also support that. Vitaly is going to write that approach up as an alternative proposal.

Regards,
Jim Vellenga

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Saha, Arnab
Sent: Thursday, 22 Sep 2011 7:23 PM
To: sv-cc@eda.org
Subject: [sv-cc] Container class for open arrays

All,

   Please review the attached proposal that defines a container class openArrayT<T> to represent
open arrays in the DPI-OO C++ intermediate layer. Also attached is a proof of concept implementation
of openArrayT<T> and its associated iterator. Note that it is not by any means complete and have
not been tried and tested for all scenarios. If openArrayT<T> is used for open arrays, there will
be no need for the compiler directive to choose between STL and C handle since openArrayT
is built on top of svOpenArrayHandle and provides an implicit cast operator to it.

Thanks
Arnab

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