[sv-cc] RE: DPI_OO: Summary of issues

Hi Arnab,

Thanks a lot for your comments.

I'll send responses to each of the issues separately so we can discuss them with the rest of the participants on reflector.

Regards,
Vitaly

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Saha, Arnab
Sent: Thursday, August 18, 2011 3:12 AM
To: sv-cc@eda.org
Subject: [sv-cc] DPI_OO: Summary of issues

All,

Here is the summary of issues I raised in today's SV-CC meeting:

(1) Should copy classes be represented as structs or classes in the intermediate layer ?

Pros of using struct:
Assumptions can be made about the data layout of a struct which might provide faster copy
              Can be used with a C interface
Cons of using struct:
              Copy classes cannot be parameterized
              Inheritance relationship is lost

IMO, the cons outweigh the pros, so we should think about representing copy classes as classes in the intermediate layer instead of structs. There was some discussion today about the need for copy classes at all due to performance overhead and if ref classes are sufficient. I think it is important to have both the capabilities and leave it up to the user to decide if they want to use copy classes and take the overhead of copying.

(2) Open arrays as handles or STL vectors ?

Pros for STL vector:

               More aligned with C++ and OO

Cons:

               Extremely slow to copy as every bit of the data needs to be copied to the vector.

IMO using handles for open arrays will be far more efficient here. If possible C++ operators can be provided to convert

open array handles to STL vectors.

(3) Enums

Need to understand the motivation for how enums are represented in DPI-C. Mapping them directly to C++ enums is convenient as the symbolic names can be used in the foreign language instead of just values but 4 state enums are not supported. A compromise would be to map enum of base type int to C++ enums and represent all other types of enums

as values of the base type. IMO this should be extended in DPI-C and not DPI-OO if possible.

(4) unit32_t and DPI_OO::LogicVecValT

Keeping the intermediate layer language neutral has been the motivation for these new types. As I have mentioned before one side of the layer is going to be SV, so I don't have much motivation to changes the type names. If we decide

to go with these new type name, I would propose creating DPI_OO::BitVecValT(typedef to uint32_t) instead of directly

using uint32_t. Keeping them svBitVecVal and svLogicVecVal is still my preferred option.

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.