Subject: Re: [sv-cc] RE: Version 2 of DPI LRM
From: Stickley, John (john_stickley@mentorg.com)
Date: Wed Mar 12 2003 - 14:22:48 PST
My preference is svArrayHandle.
-- johnS
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
>>
>
>
--This email may contain material that is confidential, privileged and/or attorney work product for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. __ ______ | \ ______________________/ \__ / \ \ H Dome ___/ | John Stickley E | a __ ___/ / \____ Principal Engineer l | l | \ / Verification Solutions Group | f | \/ ____ Mentor Graphics Corp. - MED C \ -- / / 17 E. Cedar Place a \ __/ / / Ramsey, NJ 07446 p | / ___/ | / / mailto:John_Stickley@mentor.com \ / Phone: (201)818-2585 \ / ---------
This archive was generated by hypermail 2b28 : Wed Mar 12 2003 - 14:24:47 PST