Subject: RE: [sv-cc] Polls on extern/export and representation of SV data types
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Mon Mar 10 2003 - 07:52:32 PST
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 - 07:53:44 PST