RE: [sv-cc] Breaking down 205 into smaller issues

Without going into all the other issues, I certainly do not agree on (c)
Performance *is* an important concern and one of the significant reasons
why DPI was created in the first place.

This is why DPI does not cause any translation or marshalling for SV types that
directly correspond to primitive C datatypes. The only time you actually have to
use accessor functions in "binary-compatible" mode is to access data types that
are not directly representable using primitive C datatypes.

Note that this point is also very important to permit existing C libraries to
be used from within SV without having to write an SV specific wrapper for those
libraries. Contrast this with the case of the PLI/VPI interfaces which made it
at least somewhat painful to reuse existing C libraries.

Joao
==============================================================================
Joao Geada, PhD Principal Engineer Verification Group
Synopsys, Inc TEL: (508) 263-8083
377 Simarano Drive, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================

> -----Original Message-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org]On Behalf Of Jim
> Vellenga
> Sent: Monday, October 04, 2004 3:12 PM
> To: SV-CC
> Subject: [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 14:04:54 2004