[sv-cc] 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.

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

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

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

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.