[sv-cc] Subdividing 205... Recounting specifics

Jim,

Thanks for the detailed analysis. I agree with the general notions of trade-off and subdivision.
However, I don't believe that several significant specifics in the recounting are accurate.
I would like to respond to those below.

If I'm working Outlook correctly (and your email tool reads html), the responses should appear in maroon.

Subissues of Issue 205:

My apologies for being unable to attend the 10/29 meeting.

I have talked with some people here and remotely with Ralph to understand what Issue 205 is all about. I'm hearing a number of subissues emerging, and it will help me to clarify them separately.

(1) In the first place, I'd like to see if we agree on what DPI is supposed to accomplish.

  (a) Do we agree that one reason is to eliminate the overhead associated with PLI -- callbacks, registering, an abstract data model, etc.?

RD: This seems reasonable, speaking only for myself.

  (b) Secondly, some of us want to be able to compile at least some C code with some version of a C compiler so that it can run without modification under multiple simulators on the same hardware and OS.
This is the intent of "binary compatibility," but not of "source-level compatibility". Is this correct?

RD: Yes: again, speaking solely for myself.

  (c) Finally, no one seems to be concerned about the performance of DPI, although someone needing performance, for example, might object to marshaling argument data. Does everyone agree that performance is not an issue?

RD: One could argue that there is a spectrum of performance emphasis, ranging from performance-is-everything-hang-usability to
usability-is-everything-hang-performance. The existing scheme in the LRM consistently puts run-time performance ahead of portability/usability.
The proposal is arguing for better balance by making some features more usable and portable.

(2) Ralph's example referenced a new type named svBitActual32. I gather there's some concern about how svBitVec32 was defined, and that it is inconsistent with the PLI definition of "a" and "b" bits. Is this just what is recorded in Issue 50, or is there something more?

RD: No, svBitActual32 and the cval/dval order debate are two different things.
a. svBitActual32 is just a renaming to make explicit that we are talking about the actual and not the canonical format.
b. cval/dval debate involves whether the order of declaring the control vs. digit words within a typedef for 4-state vectors matches the aval/bval order.

(3) The next subissue seems to be: "How do we represent SystemVerilog packed arrays in C"? The LRM has two different solutions.

RD: See conclusion at bottom on whether these are "different solutions."

In the binary compatibility solution, any packed arrays passed as arguments have a simulator-specific implementation that is invisible to the user. The canonical types, svBitVec32 and svLogicVec32 in both scalar and array forms, are used only in the body of the C code. The C code uses predefined functions to transfer data between the canonical types and the simulator-specific argument types.

RD: One caveat -- the packed types that appear directly or indirectly in C formal argument lists are described in terms of the macros in
svdpi_src.h; the vendor-specific implementation is not literally "invisible" to the user, since the vendor-supplied element types, etc.
must be visible to the C compiler and can be inspected in svdpi_src.h. The details are masked by using macro SV_BIT_PACKED_ARRAY, et al.

In the source-level compatibility solution, the vendor provides svdpi_src.h to say how the packed array arguments are represented, and provides the macros SV_BIT_PACKED_ARRAY and SV_LOGIC_PACKED_ARRAY to declare the representation. The example shows that the element type of these arrays still depends on the simulators and is denoted by the (void *) types svBitPackedArrRef and svLogicPackedArrRef.

RD: the element type depends on the simulators and is defined by SV_BIT/LOGIC_PACKED_ARRAY. Thus, the element types are not pointers
(like svBitPackedArrRef). An unpacked array of packed array is an array of elements defined by an svdpi_src.h macro, rather than an array of pointers.
Note also that the LRM example in E.9.4 casts the field offset of a packed array field to such a pointer (it does not cast the field's contents).

If I understand the one primary thing that Ralph is trying to change, it is to replace the SV_BIT_PACKED_ARRAY and SV_LOGIC_PACKED_ARRAY macros by an explicit declaration of how the packed arrays themselves are passed. He's proposing a particular representation in terms of arrays of svBitVec32 or svLogicVec32 (or whatever we replace them by, subissue 2). This means that the structure of argument arrays (packed and unpacked) no longer depends on the simulator -- although it can still depend on the compiler or platform. Ralph, is this correct?

RD: I am not really proposing something about argument "passing" mechanics, or proposing a "particular implementation" (the distinction is significant).
Esp. with 4-state, one could implement the internals in a variety of ways. I am proposing that, regardless of the internal representation of embedded packed types, they
adhere to a vendor-independent size and alignment behavior. With C 'natural alignment' and an appropriate dummy data type, we might achieve platform and compiler
independence as well.

(4) Finally, it sounds like there were a lot of questions -- in the area of alignment, field ordering, and so on -- related to assuming that the SystemVerilog structures match those of the C compiler.
People have already noted that this is not necessarily so. (Section
3.11 does say that "An unpacked structure has an implementation- dependent packing, normally matching the C compiler." But notice that this is only "normally" and is explicitly "implementation-dependent.")

RD: The proposal is to find a usable C standard and make the size/alignment of SystemVerilog structures that are crossing the DPI boundary match it.
This does not dictate how SV structures are implemented or behave on the SV side of the boundary.

Subissues (4) and (3) do share a common concern. Namely, to what extent do we want to constrain the form in which simulators pass non- small arguments back and forth to DPI routines? We don't have to answer this question in the same way for both subissues. Perhaps we could resolve (2) and (3) separately, before burrowing down into this one, so that we're concentrating on a smaller set of issues. Does that sound like a good idea?

RD: Regarding subdivision, (2) conflates the cval/dval order issue with proposed mechanics for making embedded packed type arguments
      binary compatible. Thus, (2) has no independent existence from issue (3) and the 2/3 are not really a viable basis for subdivision.

The LRM does, indeed, supply two representation schemes and compatibility schemes for packed arrays.
Each scheme is applicable only to certain ways in which packed types can be used in C formal arguments.
     i. if they are stand-alone arguments, they are binary compatible and passed by reference (with the exception of 2-state vectors that are 32 or
       fewer bits (these are passed in canonical form - E.7.7).
     ii. If they are the element types of an unpacked array or are fields in a struct/union, then they are defined by source-compatible, vendor-specific
        macros in svdpi_src.h as data, rather than as pointers to that data.

If we can declare that a 2-state vector of 32 or fewer bits is passed by value in canonical form, why can't we declare that embedded packed types
are merely passed with the same _size/alignment_ as their corresponding canonical form?

Jim, in any case, thanks for bringing up a host of significant issues.

Ralph

Ralph Duncan
Staff Engineer
Mentor Graphics
San Jose, Ca
408-487-7414
Received on Mon Oct 4 15:48:30 2004