[sv-cc] RE: DPI-OO: enums

Arnab,

I'm not sure what aspect of DPI-C enumeration types most concerns you. It's been quite awhile but if I recall the general gist of
SV-CC discussions, the main interest involved the 4-state items. Working from a very old Language Spec. we produced one paragraph
devoted to enum representation, which at the time read:

                Enumeration types are represented by C base types that correspond to the enumeration types' SystemVerilog base types (see Table I.1). integer and
time base types are represented as 4-state packed arrays. The base type determines whether an enumeration type is considered a small value
(see 34.5.5). DPI supports all the SystemVerilog enumeration base types (see 6.19 and A.2.2.1).

Since we had coalesced on standard utilities & representations for 4-state arrays, I suppose that provided a natural way to handle the
integer and time types. I don't recall any other aspect that commanded special interest, although Jim Vellenga and Francoise Martinolle may
remember the discussions in more detail.

Hope this helps. Regardless, good luck, Arnab and crew in further DPI efforts.

Ralph Duncan
CloudShield Technologies

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Warmke, Doug
Sent: Wednesday, August 24, 2011 9:49 AM
To: SystemVerilog CC DWG (sv-cc@eda.org)
Subject: [sv-cc] RE: DPI-OO: enums

Hi Vitaly and team,

A little historical background here.

The main driver of the SV enum type discussion in the old days was the SV-BC group.
There was debate about "hardware oriented" vs. "software oriented" enum type initialization.
i.e. should an enum initialize to its left-most enum literal, or should it initialize to the natural
initial value of its base type. In the end the hardware-side won out. It was a difficult philosophical
debate since enum types are used both in hardware descriptions (DUT) and software descriptions (TB).

SV-CC followed suit by considering enum types as their equivalent basetype. (See 35.5.6 in P1800-2012 D2).

That is the motivation in DPI-C. I don't believe anything regarding enums in DPI-C should or needs to be
changed at this point.

Thanks,
Doug

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Vitaly Yankelevich
Sent: Wednesday, August 24, 2011 9:39 AM
To: Saha, Arnab
Cc: sv-cc@eda.org
Subject: [sv-cc] DPI-OO: enums

Hi Arnab,

In your summary of DPI-OO issues you wrote:

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

I didn't take part in the DPI-C discussions - hence I cannot provide any comments concerning the motivation there. Your comment concerning the 4-state base types is very valid. IMO we need to update the proposal, based on your comment, so that it will specify that the enumerated types which base type is 2-state shall be mapped to enumerations in the C++ intermediate layer. The enumerated types which base type is 4-state shall be mapped in the same way as in DPI-C.

We think that changing DPI-C is beyond our scope, however we would like to comment that DPI-C doesn't export user-defined types at all.

Regards,

Vitaly

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