Subject: [sv-cc] Updated extern/export proposal
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Wed Mar 05 2003 - 14:36:05 PST
========================================
Proposed solution
========================================
At any scope where a function declaration can occur, permit the following
declarations:
extern "DPI" [pure|context] [cname=] <named_function_proto>;
export DPI [cname=] function fname;
This syntax does not require any new keywords: "DPI" is a string qualifying
the type of extern/export. For SV3.1 only the string "DPI" is valid.
Note that the <named_function_proto>, as defined in SV3.1 draft3 spec (page 233)
must be modified slightly so that the argument list permits open arrays. Only
extern DPI functions can use this argument type. We may additionally also
want to relax the prototype syntax to permit unnamed arguments, but this will
be harder to sell to sv-ec.
Semantics:
----------
in both cases, cname is the name of the C side function (extern/export),
fname is the SV name for the same function.
If cname not explicitly given, it will be the same as the SV function fname.
An error will be generated iff the SV function name has characters that are
not valid in a C function identifier.
For any given cname, all declarations, regardless of scope, *must* have exactly
the same type signature. The type signature includes the return type, the number,
order and types of each and every arguments. Type includes dimensions and bounds of
any arrays/array dimensions. Signature also includes the pure/context qualifiers
that may be associated with an extern definition.
Only 1 extern declaration (extern or export) of a given fname is permitted in
any given scope. More specifically, for an "extern", the extern must be the
sole declaration of fname in the given scope. For an "export", the function
must be declared in the scope where the "export" occurs and there must be
only one "export" of that fname in that scope.
Argument names and default values are permitted to differ between "extern"s
declared at different scopes *as long as* the type compatibility constraints are met.
For exported functions, the exported function must be declared in the same scope
that contains the "export extern" declaration.
Note that DPI functions declared this way can be invoked by hierarchical reference
the same as any normal SV function.
This:
a) uses consistent syntax with other similar SV 3.1 constructs
b) permits straightforward extension later to extern/exported tasks
c) permits all information needed by DPI coder to be put in the scope
where such usage occurs.
d) by permitting extern/export declarations to be inside module scope,
this simplifies (permits) use of DPI inside library modules using just
normal library resolution mechanisms.
e) allows for later extension of DPI to handle tasks (if such is ever necessary)
without syntax conflict with existing usage
f) permits later extension to address other interfaces (eg "extern VPI function $foobar;")
without syntax conflict with existing usage
g) use of extern/export is more symmetrical and was recommended by sv-ec and by
Friday's all-committees meeting.
NOTES:
1) do not need to put function prototype along with the export because export has to
occur in same scope as the function definition being exported.
2) extern/exports can occur anywhere where function declarations can occur. However
note that exports must be in same scope as the function being exported.
3) clarified some of the rules regarding the prohibition of multiple extern/exports
in a single scope (prohibition is only with respect to a given fname)
Example usage:
----------------------------------------
------------------- sv code --------------------
// NOTE: distance is SV name, Distance is C name
extern "DPI" pure Distance=function integer distance(input integer a, input integer b);
module top;
TB tb;
endmodule
module TB
// NOTE: MyDistance is SV name, Distance is C name. Both this function and the function at
// $root map to the same C function and therefore have to have identical type signatures
extern "DPI" pure Distance=function integer MyDistance(input integer t, input integer v=10)
DUT dut;
...
$root.distance(10, 20); // invokes the C function Distance(10, 20)
MyDistance(2); // invokes the C function Distance(2, 10)
endmodule
module DUT
...
UNIT unit1;
UNIT unit2;
...
endmodule
module UNIT
extern "DPI" context genPacket = function void genIt();
export "DPI" drivePacket = function driveIt;
function void driveIt(input l, m, n)
...
endfunction
...
genPacket; // invokes C function genPacket(), which invokes this instances driveIt
// via the C function drivePacket()'
...
endmodule
----------------------- end sv code -----------------
---- c code ----
int Distance(int a, int b)
{
return (int)(sqrt(a*a + b*b));
}
extern void drivePacket(int a, int b, int c);
/* NOTE: genPacket is context-aware function */
void genPacket()
{
...
drivePacket(); // call the drivePacket function in the instance from which genPacket invoked
...
}
---- end c code -----
==============================================================================
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
==============================================================================
This archive was generated by hypermail 2b28 : Wed Mar 05 2003 - 14:37:33 PST