Subject: RE: [sv-cc] Updated extern/export proposal
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Fri Mar 07 2003 - 15:21:08 PST
Thanks for the corrections
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: Francoise Martinolle [mailto:fm@cadence.com]
Sent: Friday, March 07, 2003 6:19 PM
To: Joao.Geada@synopsys.COM; sv-cc
Subject: Re: [sv-cc] Updated extern/export proposal
At 05:36 PM 3/5/2003 -0500, Joao Geada wrote:
========================================
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;
"DPI" for the export.
I can admit that there will be some advantages in adding a qualifier. The
advantage will be in outputting a better error message if a function name
was mistyped and allow the error to
be caught at elaboration rather than waiting for simulation.
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.
export "DPI"
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)
typo Should be MyDistance(2,)
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()'
I believe it should be genPacket();
...
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
...
Should be drivePacket(x, y, z);
}
---- 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 : Fri Mar 07 2003 - 15:22:36 PST