[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, and is
believed to be clean.