Subject: RE: [sv-cc] RE: Version 2 of DPI LRM
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Mar 12 2003 - 18:09:01 PST
Michael,
Good and clear reasoning here.
I like either of your proposals, perhaps the first one best.
One thing to note is that we decided to change the term
"context" to "scope" when it comes to the C API functions.
It has more meaning to Verilog end-users. So I would say:
svOpaqueHandle
svOpenArrayHandle
svScopeHandle
Thanks and regards,
Doug
> -----Original Message-----
> From: Michael Rohleder [mailto:michael.rohleder@motorola.com]
> Sent: Wednesday, March 12, 2003 4:29 PM
> To: Warmke, Doug
> Cc: 'Andrzej Litwiniuk'; sv-cc@eda.org
> Subject: Re: [sv-cc] RE: Version 2 of DPI LRM
>
>
> 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 - 18:09:40 PST