Subject: [sv-cc] RE: Version 2 of DPI LRM
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Mar 12 2003 - 10:34:56 PST
Andrzej,
Thanks for the feedback on my LRM edits.
We may have a few philosophical issues to
iron out, but things are looking good.
Please see embedded comments.
Regards,
Doug
> -----Original Message-----
> From: Andrzej Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> Sent: Tuesday, March 11, 2003 5:53 PM
> To: Warmke, Doug
> Cc: sv-cc@eda.org
> Subject: Re: Version 2 of DPI LRM
>
>
> > 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.
Sorry, disagree. See John's example for how an external
function may need to know its context so that it can interact
properly with a specific model on the C side. (no export
function is needed in the simplest cases, since the C model
can interact with SV simply by means of the extern function's
return argument).
>
> --------------------------------------------
> 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.
Agree. Looks like svScope is a better name.
I still request that we dump the genericity of svHandle used
for array access as well. It may be confusing to users who
are used to vpiHandle as a truly generic handle that can be
used for all kinds of access activities.
As before, I suggest svArrHandle or svArrayHandle for this use.
>
> --------------------------------------------
> 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.
DOUG: This looks like a philosophical disagreement point.
What you write about applications of extern functions is true.
But, one may also perceive native SV functions as an extension of
built-in arithmetic, basic new operators, etc.
The real point that I think is important (and I believe Joao agrees)
is the strong correlation between external functions and native
SV functions. Both can be used interchangeably for all aspects
of what functions do: context stuff, arith stuff, operators, etc.
>
>
> --------------------------------------------
> A.11.11 Example 7
>
> "DPI" function is missing from export and extern.
>
DOUG: Yes, good catch
>
>
> --------------------------------------------
> 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.
DOUG: I agree we need to hash this out, but I'm not sure either
my current solution nor your proposal is the correct approach.
Here are a few points to consider:
- Your (and my) desire to have the C-side Annex be useful standalone
as much as possible
- Dealing with context functions is far more involved on the C side
than on the SV side. On the SV side there is almost no visible
effect at all. It's similar to open arrays in this way.
I'm not opposed to extending the description and treatment of
context functions on the SV side document, I think it would be useful.
But we shouldn't cut it out of the C side annex, either, since that
is where programmers will really be spending their time figuring
out how to use the system.
Regarding your point about the C programmer's point of view, I don't
think the magic token will be a very useful concept without a
detailed treatment of its semantics and intended usages.
Maybe we can have a phone call to iron out our differences here?
Thanks and regards,
Doug
>
> Regards,
> Andrzej
>
This archive was generated by hypermail 2b28 : Wed Mar 12 2003 - 10:35:41 PST