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

Arnab,

If we're going with classes then, IMO, we need an interface class ArrayT<T> and derive from it two classes: SizedArray<T> and OpenArray<T> where the difference is that SizedArray does not have methods to resize it after construction.

However I need an additional round of emails:
I'm rather concerned about the accessor function - it's an extra function call per each access compared to the raw C-like access which seems to me straightforward for packed arrays.
It looks to me counter-productive when talking about performance.
I didn't participate in development of DPI-C so I didn't understand why accessing packed arrays required special API and wasn't left to the plain C access based on the known layout.

Vitaly

From: Saha, Arnab [mailto:arnab_saha@mentor.com]
Sent: Monday, September 26, 2011 10:22 PM
To: Vitaly Yankelevich; Jim Vellenga
Cc: sv-cc@eda.org
Subject: RE: Container class for open arrays

Vitaly,

   If we don't make these classes, how do you expect users to manipulate these data types ?
Are they expected to use the DPI-C accessor functions like svPutBitselLogic() and svGetBitselLogic()
or there will be a new set of functions defined in DPI_OO namespace ? This is important for
hooking up to C++. There will be some form of array representation in other OO languages,
hence it is not too much of an issue.

With respect the the size() function, my thinking was that if we make them classes, why not provide
that extra piece of info that is currently not available. In DPI-C, the C size needs to have knowledge
about the size of fixed-size arrays to operate on them and it would be useful to not have to do that.
I don't have a strong opinion about it, so I am fine if you want to keep the existing model.

With the class based approach, the consistency with DPI-C can be taken care of by providing an
implicit cast operator, similar to what is proposed for openArrayT.

-Arnab

From: Vitaly Yankelevich [mailto:vitaly@cadence.com]
Sent: Monday, September 26, 2011 12:05 PM
To: Saha, Arnab; Jim Vellenga
Cc: sv-cc@eda.org
Subject: RE: Container class for open arrays

Arnab,

We need to discuss the class representation. I'm accumulating all my responses to your comments (good ones, thanks!( and I'll upload them later today.

Back to DPI_OO::LogicVecValT and BitVecValT, CurrentIy don't think we need to make them classes.
My arguments are:
- the sized arrays definitions should be symmetrical between SystemVerilog and the foreign languages.
  That means, I don't see necessity to provide the size together with the data container.
- it makes the difference between open arrays and sized arrays fuzzy. If we use classes why to use different classes for open arrays and for sized arrays?
- it would be inconsistent with DPI-C

Vitaly

From: Saha, Arnab [mailto:arnab_saha@mentor.com]
Sent: Monday, September 26, 2011 9:46 PM
To: Vitaly Yankelevich; Jim Vellenga
Cc: sv-cc@eda.org
Subject: RE: Container class for open arrays

Vitaly,

  Do you want me to work on the class representation of DPI_OO::LogicVecValT and BitVecValT ?
Anything else I can help with ?

-Arnab

From: Vitaly Yankelevich [mailto:vitaly@cadence.com]
Sent: Monday, September 26, 2011 11:26 AM
To: Saha, Arnab; Jim Vellenga
Cc: sv-cc@eda.org
Subject: RE: Container class for open arrays

Indeed, given short time we have I'll put all the suggested changes in one version and upload it as soon as I can.
The upcoming changes include the comments you uploaded for version 1.0.3.

Regards,
Vitaly

From: Saha, Arnab [mailto:arnab_saha@mentor.com]
Sent: Monday, September 26, 2011 9:00 PM
To: Vitaly Yankelevich; Jim Vellenga
Cc: sv-cc@eda.org
Subject: RE: Container class for open arrays

Hi Vitaly,

    I like the idea of the interface class. This is in line with what I was proposing, I just didn't lay it out this way.
Thanks for coming up with it. Do you want me to make changes to my proposal and resubmit or are
you going to integrate it in your DPI-OO proposal directly ? With the amount of time we have later might be
a better option. Let me know.

Thanks
Arnab

From: Vitaly Yankelevich [mailto:vitaly@cadence.com]
Sent: Monday, September 26, 2011 7:18 AM
To: Saha, Arnab; Jim Vellenga
Cc: sv-cc@eda.org
Subject: RE: Container class for open arrays

Arnab,

I would like to suggest a modification of your proposal. I hope the suggestion below will fit your basic idea and, in parallel, will resolve the objections Jim and I have.

The proposal is to make openArrayT an abstract class and to allow different languages to pass actual argument which are fully-implemented subclasses of openArrayT.
Given such architecture, you can define a class, for example, svOpenArrayT which inherits from openArrayT and implements all the interface as you suggested via svOpenArrayHandle.
Another vendor can define, for example, a class STLOpenArrayT which implements the same interface on top of std::vector. It seems to me pretty similar to what you suggested.

So, I would like to propose to change the definition of openArrayT as follows:
namespace DPI_OO {
template <class T> class OpenArrayT {
public:
   OpenArrayT<T>() {};
   OpenArrayT<T>& operator = (const openArrayT<T>& from) = 0;
   int size() = 0;
   ... // etc
};
}

Then svOpenArrayT will look as follows:

namespace DPI_OO {
template <class T> class svOpenArrayT: public OpenArrayT {
private:
   svOpenArrayHandle handle;
public:
   svOpenArrayT<T> (svOpenArrayHandle h) { handle = h; }
   OpenArrayT<T>& operator = (const openArrayT<T>& from) { ...} ;
   int size() { return svSize(handle, 1)};
   ... // etc
};
}

Would you agree with such modification?

Regards,
Vitaly

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Saha, Arnab
Sent: Sunday, September 25, 2011 12:24 AM
To: Jim Vellenga
Cc: sv-cc@eda.org
Subject: [sv-cc] 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<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.