Subject: Re: [sv-cc] RE: Version 2 of DPI LRM
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Mar 12 2003 - 16:29:24 PST
There are three handle types that we need to distinguish:
a) the generic, opaque handle defined on the SV side
b) the handle provided when having an open array as param
c) the handle provided for the context
all three are in my eyes different and I think we need to reflect this by providing three different handle types.
IM(very H)O there are two good ways here:
A) have a base type; e.g. 'svHandle'
. derive three types from it; e.g.
svOpaqueHandle
svOpenArrayHandle
svContextHandle
B) just have three handle types
svHandle
svOpenArrayHandle
svContextHandle
I am more for the second one, which gives also my name preferences; although I really don't care here. I as many other user's will
do Cut&Paste and as such the lenght of a type name does not really count ...
-Michael
"Warmke, Doug" wrote:
> 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
> >
--NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, System Design | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( )
*** This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank you! ***
This archive was generated by hypermail 2b28 : Wed Mar 12 2003 - 16:31:50 PST