Subject: RE: [sv-cc] Polls on extern/export and representation of SV data types
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Mon Mar 10 2003 - 10:26:23 PST
Joao,
Not clear on why you feel so strongly about prohibiting
extern functions from being called at elab time.
Mechanically, non-context elab-time DPI functions should
be easy enough to support, and theoretically 100% safe
(provided the user didn't do crazy stuff, as they can
always do almost anywhere).
My feeling is that if we disallow any external function
from being called at elab time, usability will decrease.
Because it's not clear to users exactly *when* elaboration
is occuring. So a function call at one site will produce
a system error, whereas in at another site it will be OK.
Do we want to explicitly list out all call sites that would
be considered "elaboration time"?
If we allow any non-context function to be called, the
incidence of users getting compile errors will decrease.
I am open to restricting to pure as well.
Thanks and regards,
Doug
> -----Original Message-----
> From: Joao Geada [mailto:Joao.Geada@synopsys.com]
> Sent: Monday, March 10, 2003 7:53 AM
> To: Michael.Rohleder@motorola.com
> Cc: sv-cc
> Subject: RE: [sv-cc] Polls on extern/export and
> representation of SV data types
>
>
> 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
> 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)
>
> 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 archive was generated by hypermail 2b28 : Mon Mar 10 2003 - 10:27:25 PST