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

Vitaly,

   With the DPI-C interface, you are not mandated to use the accessor
function, they

are just provided for convenience. If you want faster performance you
can always make

assumptions about the layout and write your code that way. Since we are
running out

of time, one option would be to keep them the way they are and make a
comment that

users of this interface are expected to directly manipulate the data
assuming the C layout.

The DPI-C functions will always work since the layout is the same. Then
in the next revision

we can come up with an interface if needed.

-Arnab

From: Vitaly Yankelevich [mailto:vitaly@cadence.com]
Sent: Monday, September 26, 2011 12:31 PM
To: Saha, Arnab; Jim Vellenga
Cc: sv-cc@eda.org
Subject: 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.