Subject: Re: [sv-cc] RE: Version 2 of DPI LRM
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Mar 12 2003 - 11:54:01 PST
Doug,
My feedback embedded. It looks like by and large we have an agreement.
> 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
>
> > From: Andrzej Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> > Sent: Tuesday, March 11, 2003 5:53 PM
> >
> > 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).
Yeah, I didn't remember about user data to be associated with an instance.
What about "Some DPI external functions or other interface functions called from
them require that the context of their call is known".
> > --------------------------------------------
> > 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.
If not the length, I'd opt for svOpenArrayHandle. I'm ok with either version.
And agree, svHandle is overly generic.
Team, your preferences?
> > --------------------------------------------
> > 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.
My point was that sometimes external functions are used for implementing
something that cannot be expressed or implemented in plain SV and thus they
extend the expressiveness of SV (so they are not proxies).
"DPI external functions often may be treated as proxies for native SystemVerilog
functions". - how about that?
Regards,
Andrzej
This archive was generated by hypermail 2b28 : Wed Mar 12 2003 - 11:55:05 PST