Subject: RE: [sv-cc] Updated extern/export proposal
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Fri Mar 07 2003 - 15:10:21 PST
John,
a) yes, it was a typo. "DPI" must be quoted in both the extern and the export sides
b) yes I agree. extern function prototype has to be the same as SV function prototype
with the only required change being the addition of support for open arrays.
c) yes, there are only restrictions on the SV fname (to be legal C name) iff
there is no given cname. If the cname is given, then it is the cname and not
the SV fname that has to pass the restrictions
d) (answering Doug's question): yes, all exported functions have a context.
The context is (conceptually) the fully qualified path up to (but excluding)
the name of the function.
Specifically, every function definition in SV has a unique fully qualified
name that refers to that function specifically. The context is the path to
that "place". Note that this is true of all functions in SV, though it is
not true of methods (but DPI has no access to methods, so that is OK)
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: Stickley, John [mailto:john_stickley@mentorg.com]
Sent: Friday, March 07, 2003 5:25 PM
To: Joao.Geada@synopsys.COM
Cc: 'sv-cc@server.eda.org'
Subject: Re: [sv-cc] Updated extern/export proposal
Joao,
This looks really good. A few minor comments embedded.
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;
johnS:
I'm assuming this is a typo and DPI needs to be quoted for the export as well ?
>
> 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.
johnS:
But nonetheless if it is not supported for SV function, then we should
not support it. Conversely they do support it then we should support it.
External functions should be almost exactly consistent with SV function
symantics. The exception being open arrays as you mention.
>
> 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.
johnS:
One suggested alteration to this: If cname *is* used then fname need
not have such a restriction right ? Of course cname will always
have this restriction.
If cname *is not* used, then fname must also have the restriction.
Do you agree ?
>
> 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
> ...
> }
johnS:
Very nice. I like the way this is turning out. I would also
like to see examples where the exported SV function is being
called "out of the blue" from the C side using svGetInstanceByName().
I suppose the example in Doug's DATE slides will be suitable for that.
-- johnS
__
______ | \
______________________/ \__ / \
\ H Dome ___/ |
John Stickley E | a __ ___/ / \____
Principal Engineer l | l | \ /
Verification Solutions Group | f | \/ ____
Mentor Graphics Corp. - MED C \ -- / /
17 E. Cedar Place a \ __/ / /
Ramsey, NJ 07446 p | / ___/
| / /
mailto:John_Stickley@mentor.com \ /
Phone: (201)818-2585 \ /
---------
This archive was generated by hypermail 2b28 : Fri Mar 07 2003 - 15:12:01 PST