Subject: RE: [sv-cc] Updated extern/exports proposal
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Mar 12 2003 - 10:15:23 PST
Good comments, Andrzej.
Joao, you didn't respond to Andrzej's questions about
equating NULL svScope with extern declarations in $root.
I oppose using NULL for this job. There are two reasons:
1) $root is a valid scope. In the future, a concept of
"namespace" may be added to the language, in which
$root would just be the default namespace. We would
need to distinguish between external functions
implemented in such namespaces, NULL won't do.
2) NULL is convenient for users to recognize error scenarios.
Let's reserve its use for that purpose.
Can you please add clarifying text to this effect in your
proposal, Joao?
Thanks and regards,
Doug
> -----Original Message-----
> From: Joao Geada [mailto:Joao.Geada@synopsys.com]
> Sent: Wednesday, March 12, 2003 9:10 AM
> To: Andrzej Litwiniuk; Joao.Geada@synopsys.com
> Cc: sv-cc
> Subject: RE: [sv-cc] Updated extern/exports proposal
>
>
> Andrzej,
>
> thanks for the comments and corrections:
>
> 1- replacing "C" with "foreign language". I have no issue
> with this, so I'll
> make the appropriate updates if everybody concurs
> [in practice DPI only defines a C binding, so saying only
> "foreign language"
> is being unnecessarily ambigous in SV3.1, though it does
> leave room for
> later expansion of the bindings]
>
> 2- yes, type signature has to include argument direction. Good catch!
>
> 3- yes, I'll add the default value restriction as well to the
> relaxation rules
>
> 4- I'll update the definition of pure with the text from the LRM
>
> 5- I'll leave that to the final LRM editor. I think signal is
> the generic term,
> but other committees or final LRM editor is free to
> substitute any other word
>
> 6- I'll try to come up with better description for context
> function scope
>
> 7- You're welcome ;-)
> I think this text makes the rules of interface interaction
> clear without removing
> any capabilities.
>
> 8- You're welcome. scope handles *are* different from other
> handles, so a different
> type is required, IMHO
>
> 9- "if invoked from ". I like your text, I'll replace mine.
>
> 10- I'll use your text for the handling of context on return
> from a context function
>
>
>
> ==============================================================
> ================
> Joao Geada, PhD Principal Engineer
> Verif Tech Group
> Synopsys, Inc
> TEL: (508) 263-8083
> 344 Simarano Drive, Suite 300,
> FAX: (508) 263-8069
> Marlboro, MA 01752, USA
> ==============================================================
> ================
>
>
> -----Original Message-----
> From: Andrzej Litwiniuk [mailto:ail@synopsys.COM]
> Sent: Wednesday, March 12, 2003 11:02 AM
> To: Joao.Geada@synopsys.COM
> Cc: sv-cc
> Subject: Re: [sv-cc] Updated extern/exports proposal
>
>
> "Updated externexport proposal.htm"
>
>
> Joao,
>
> Here is my feedback; tiny issues mainly.
>
> - Could references to C be avoided in SV Layer? (rules for C
> style identifier
> are an exception)
> e.g. Section "Semantics': "C side function", "C callers"
>
> Specifically, could we use terms "foreign name" (in lieu of
> "cname") and
> "native SV name"? (the later not that important)
>
>
> - definition of type signature shall include a direction
> (inout, output, inout)
>
>
> - 'NOTE' condition 2) - default values must be identical, too
>
> - 'pure' -
> "function output" is confusing (output argument?), I'd prefer
> functin result.
>
> (The description of 'pure' in LRM drafts for SV and C
> layesr seems slightly
> better.)
>
> - "SV signals" in the description of (non-)context functions:
> I'm not sure about SV jargon (or official terminology);
> does "signal"
> refer to all kinds of data in SV?
>
> - "Context functions are always implicitly supplied a scope" - seems
> unclear/confusing.
>
> - Thanks for the remark that 'context' does not enable
> automatically other
> interfaces! This was really missing in the previous docs.
>
> - In the previous versions support for PLI was bundled with
> support for exported
> functions; a context function call was supposed to be
> instrumented in such
> a way that C function would be able to call PLI (or VPI).
>
> In that newest version the support for PLI calls seems
> unbundled from
> context functions and removed. (Going thru svGetScopeName
> may be an acceptable
> workaround, however, yet rather inefficient.)
> I was never enthusiastics about supporting PLI calls from
> external functions,
> nevertheless such functionality had been requested and voted for.
> Is it a change that averybody is aware of and ok with it?
> Personally I have no problem with it.
>
> - Thanks for using svScope! (draft proposals used svHandle)
> - include files document must be updated
>
> - function svGetScope() - shall return NULL also when called
> from a function
> declared in $root scope. (Or is it a context?)
>
> BTW: the scope corresponds to the declaration site of an
> external function.
> The same extern function may be declared in different
> scopes and therefore
> - though depending on an invocation site! - may
> legitimately call exported
> functions from different scopes. It is programmer's
> responsibility to
> decide whether a particular function may be called (of
> course, there will be
> a run-time error if an exported function is called from a
> wrong context).
> I have no problem with this, but we may want to warn the
> users about such
> possibilities.
>
> - "if invoked from within a non-context functions" - I know
> and understand
> the intent, but this phrase isn't precise (well, I may be
> nit-picking).
> Perhaps:
> "if it was not invoked directly or indirectly from within a
> context functions"
>
> - svSetScope() sets a new scope and returns the prior scope;
> rename to sv SwapScope() ?
>
> - is NULL(--> $root) ok as an argument for svSetScope() ?
>
> - "Note also it is not necessary to reset the context prior
> to returning from
> the extern call"
>
> What about: "The context will be automatically reset [to $root ?] at
> the return from the extern call."
>
> - names or descriptions of svGetUserData()/svSetUserData() got swapped
>
> - Shouldn't svScope be used instead of svHandle in
> svGetUserData/svSetUserData?
>
> - similarly svGetScopeName(const svHandle)
>
> - What about $root scope and NULL as svScope?
>
> - example, inside module UNIT:
> "genPacket;" - shouldn't it be "genIt();" ?
>
>
> - multiple declarations in DEFERED ISSUES: requirement that
> all names of formals
> must be identical defies the usibility & convenience.
> (Nevertheless I agree with Joao's point that a caller shouldn't care
> whether a function is declared as extern with =relaxed=
> rules for names
> and therefore not always callable with 'by name' mode, or
> as a native one.)
>
>
> If I may make a more general comment, not specifically
> related to this very
> document (although envoked by a workaround described in
> DEFERED ISSUES),
> apparently there is a need for programming tips, hints,
> guidelines, etc,
> on DPI. It may be left to intelligent readers, or to
> entrepreneurial authors
> of future publciations "DPI for dummies", "Advanced DPI for
> sophisticated designs", etc, or be attached to LRM as an
> annex with meaningful examples.
>
> Regards,
> Andrzej
>
This archive was generated by hypermail 2b28 : Wed Mar 12 2003 - 10:17:59 PST