Subject: RE: [sv-cc] RE: Version 2 of DPI LRM
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Mar 12 2003 - 12:00:53 PST
Andrzej,
Agree on all points. We can modify the LRM as per
your suggestions. That was quick!
Team, quick poll from Andrzej and me for renaming svHandle:
svArrayHandle
svOpenArrayHandle
svArrHandle
<your suggestion here>
Thanks and regards,
Doug
> -----Original Message-----
> From: Andrzej Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> Sent: Wednesday, March 12, 2003 11:54 AM
> To: Warmke, Doug
> Cc: Andrzej.Litwiniuk@synopsys.COM; sv-cc@eda.org
> Subject: Re: [sv-cc] RE: Version 2 of DPI LRM
>
>
> 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 - 12:01:48 PST