[sv-cc] Breaking down 205 into smaller issues

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

  (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?

  (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?

(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?

(3) The next subissue seems to be: "How do we represent SystemVerilog
packed arrays in C"? The LRM has two 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.

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.

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?

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

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?

Regards,
Jim Vellenga

---------------------------------------------------------
James H. Vellenga 978-262-6381
Engineering Director (FAX) 978-262-6636
Cadence Design Systems, Inc. vellenga@cadence.com
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information."
----------------------------------------------------------
  
Received on Mon Oct 4 12:12:06 2004