Subject: Re: [sv-cc] Updated extern/export proposal
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Mar 07 2003 - 15:19:24 PST
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:20:42 PST