[sv-cc] DPI-OO: unit32_t and DPI_OO::LogicVecValT

Arnab you wrote:

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

We think that the making the C++ language proxies to be language-neutral is important and making the proxies to match only one side of the layer will break this language-neutrality.
Unification of the data types used in the intermediate layer for different languages will provide the following benefits:
- the proxy classes and subroutine arguments for export and import proxies will be the same, regardless of the source language
- a foreign language such as SystemC should be able to provide the same conversions between the intermediate layer and SystemC regardless whether the proxy was originated for a SystemVerilog export class, or for another C++ or e export type
- unification will improve performance because there will be no need in extra conversion between svLogicVecVal and, for example, scLogicVecVal

Talking specifically about the types in the title: we think that mapping of SystemC and e data types to DPI-OO shall be standardized after SystemVerilog as well. In particular, the SystemC template class sc_int<W> should be mapped to uint32_t * (or its typedef) in the intermediate layer - equivalently to the SystemVerilog packed 2-state array. Same should be done for e lists.
SystemC also supports 4-state value type sc_logic. It should be mapped in the intermediate layer to DPI_OO::LogicVecValT.

Concerning replacement of uint32_t with its typedef DPI_OO::BitVecValT - I would agree with this suggestion. Probably we can have a poll in sv-cc to ensure it's ok with the rest of the members?

Regards,
Vitaly

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.