Subject: RE: [sv-cc] Updated extern/exports proposal
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Wed Mar 12 2003 - 09:10:07 PST
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 - 09:12:05 PST