Subject: Re: [sv-cc] Polls on extern/export and representation of SV data types
From: Stickley, John (john_stickley@mentorg.com)
Date: Mon Mar 10 2003 - 11:12:53 PST
Team,
Joao Geada wrote:
> Michael,
>
> With respect to externs at top-level, the rules are no different than those
> that apply to any other SV declaration: you cannot declare the same name
> twice. Given that SV supports conditional compilation etc, I do not see a
> compelling reason to violate basic SV rules just for DPI.
> Of course, I am willing to change this if some can give a convincing reason as
> to why DPI must have this flexibility.
>
> For permitting externs in a location other than where it is declared: this
> requires new syntax for describing "definition" qualifiers, which currently is
> not present in SV. This is needed to qualify which function is being exported.
> Also note that the context of the exported function would always be its
> actual instantiation context (ie where the function really exists in SV terms)
> rather than the location of the export. This may lead to user difficulties
> (but my extern and export statements are in the same scope; how come my C function
> cannot find the exported SV function ? Well, because the SV function is actually
> in a different context, even though the export statement is in the same context
> as the extern statement ...)
> This change has a lesser impact on other parts of SV so if people feel strongly
> about this and consider the tradeoffs acceptable, we could change the export
> syntax to look like:
> export "DPI" [cname=]function [Def::]fname
johnS:
I motion that we apply the Doug Warmke rule of
"early restriction, later expansion" here.
I think by restricting export to be in the same scope of the
function being exported, we can provide a very useful feature.
If as time goes on and there is enough demand, we can expand
the syntax as necessary.
The opposite is irreversible. If we expand the syntax now,
we cannot decide later it was a bad idea and remove it.
Here again, I encourage everyone to stay as close as possible
to SV function definition symantics in their thinking.
SV functions can be defined in one and only one place.
There are no root level declaration syntaxes supporting
function declarations today in a pure SV world. Why should
we introduce ones now ?
All an export declaration is really, is an extra attribute
of sorts that merely says the singleton function definition
also happens to be callable from outside of SV. There's nothing
introduced in this simple concept that warrants a whole new level
of syntax complexity and scoping rules where none existed before
in a pure SV sense.
Just as SV code can call SV functions with instanced context
specifiers, so too can C code call exported SV functions
with instanced contexts via the use of handles and the context
set/get functions. Again, we're sticking very close to existing
SV semantics here. To do anything else is possibly asking for trouble.
> where Def is the name of the definition containing the function definition to
> be exported. Multiple :: separators possible if exporting from within a nested
> set of definitions (eg exporting a function from within a nested module defn)
johnS:
Be sure that we understand that '::' denotes declarative scope
not instanced scope (which is denoted by '.'). I'm not advocating
even supporting this syntax but if we do, I think it should be
clarified that it is declarative scoping we're talking about here
not instanced scoping.
>
> The context of exported (and extern functions) is always the fully qualified
> instance name of the instance containing the extern statement or exported SV
> function definition. NOTE this is consistent with rules SV functions follow;
> specifically, with these rules an exported SV function could be invoked as an
> extern function and have exactly the same semantics as making a SV hierarchical
> function call:
>
> module top;
> initial
> bot.DPI_foo(..); // call 1
> bot.foo(..); // call 2
> endmodule
> module bot;
> extern "DPI" foo=function DPI_foo(..);
> export "DPI" function foo;
> function foo(..);
> endfunction
> endmodule;
>
> In this contrived example, both call 1 and call 2 have the exact same effect,
> that is, invoking the SV function "foo" in the instance of module "bot". Note
> that call 1 is a DPI function call, wherease call 2 is a SV function call.
> BTW: note also that if the extern was moved to top, then the C code would have
> to explicitly change context for the call to foo to work.
>
> Note that only _functions_ can be externed/exported. Class methods are not
> covered by the DPI interface (at least not in the SV 3.1 revision ;-)
>
> extern functions (even if pure) are not ever considered to be constant functions
> and thus cannot ever be used by elaboration time constructs (specifically this
> applies to definition of parameter values, dimensions of signals/variables,
> generate controls and instance arrays etc)
>
> For the final item, yes, at least 4 additional functions are required in the
> DPI interface:
> - get context from a fully qualified name
> - get current context (automatically setup for extern "context" functions)
> - set the current context
> - get the fully qualified name of a context
>
> Joao
> ==============================================================================
> 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: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org]On Behalf Of
> Michael Rohleder
> Sent: Saturday, March 08, 2003 4:46 PM
> To: Swapnajit Mittra
> Cc: sv-cc@eda.org
> Subject: Re: [sv-cc] Polls on extern/export and representation of SV
> data types
>
>
>
>>1. Poll on acceptance of Joao's modified extern/export proposal.
>> http://www.eda.org/sv-cc/hm/0920.html
>
>
> Abstain.
>
> I very much like the overall proposal and basically most points within, but would like to see some changes in the two following
> areas:
>
> - I dislike that it is prohibited to have multiple extern declarations at $root level; this is a big inconvinience and I still
> don't understand the reasoning why it is such a big problem to permit this.
> - I would strongly request that it is _also_ permitted to 'export' a function from the $root level by fully qualifying its path.
> This is hindering reuse, because otherwise I would have to touch the Verilog code of someone else when I want to export only
> function declared within this code. Not nice.
> The current way of exporting functions is O.K., but extending it to permit also this would also be important.
>
> Also, IMHO it is still not completely clear on how the context is defined for _exported_ functions; a lot of very useful discussions
> went into the aspect of external functions, but this is also important. I believe the rule of thumb here should be that calling an
> exported function from an external function should behave exactly and (use the same context) as if the external function is an SV
> function and calls the exported (SV) function.
>
> My vote would be clearly yes, when solving all these issues (or explaining why it is such a problem)
>
> P.S.
> - I am against permitting to export class member functions. Until we support classes, this is too dangerous.
> - I am very unsure about external function calls during elaboration; if we really want to have this I would rather go for an
> additional attribute like 'pure' that explicitely requests this
> - I think we need two more service functions to retrieve the place where an external function is declared and called; this is
> needed for error handling. I am unsure whether PLI can already provide all this information after some of these discussions.
--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 : Mon Mar 10 2003 - 11:18:10 PST