[sv-cc] Re: Version 2 of DPI LRM


Subject: [sv-cc] Re: Version 2 of DPI LRM
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Mar 11 2003 - 17:53:25 PST


> Forwarding John's review of the C-side LRM to the reflector
> [...].

Doug,

A few minor comments on the C-layer doc in addition to those of John.

--------------------------------------------
A.5.5.
I disagree with the first sentence "Some DPI external functions require that the
context of their call is known". Actually it is exported functions or PLI (VPI?)
functions that require such a context. So external functions may need the
context only indirectly.

--------------------------------------------
A.5.5 and A.8
Type 'svHandle' is used here for representing a context, thus overloading
the originally intended use of this type, as a pointer to a descriptor
for an array passed as an actual argument for an open array.
This may be confusing and may lead to errors. I think that it would be better
to define a new type, say svContext.

--------------------------------------------
A.6.6, last sentence.
The normalized form shall have [0:31] rather than [31:0].

--------------------------------------------
A.8.1 Second paragraph.

I disagree with the sentence "DPI external functions are essentially proxies for
native SystemVerilog functions".

The postulate that native and external functions are interchangable is more
a methodological guideline than a hard request.
One may perceive external functions as an extension of the built-in arithmetic,
or, generally, as new basic operators, user defined. This as as legitimate
application as any other.

--------------------------------------------
A.11.11 Example 7

"DPI" function is missing from export and extern.

--------------------------------------------
I have also a more general comment.
IM(H)O the C layer shall contain as little SV specific information as possible.
As a C programmer I would be interested in what I can safely call from my
C code (exported functions, PLI, VPI) or what I may not call, how to access
data, etc.
The subtleties of SV context seem a bit irrelevant here. Yes, I have to
be aware of the existence of a context and of API for setting/getting it, but
how the context is determined in SV and its semantics, seem to be less relevant
here. From C programmer's point of view, a context is a kind of a magic token
to be retrieved and passed, or simply ignored. Just like a handle for open
arrays. It gets set by a caller, then it does its magic. How it works, I don't
care. I'll be just a middleman between SV and SV.
It is the SV Layer that shall provide the precise and detailed description of
the context.

Regards,
Andrzej



This archive was generated by hypermail 2b28 : Tue Mar 11 2003 - 17:57:30 PST