Subject: [sv-cc] more about import/export
From: Francoise Martinolle (fm@cadence.com)
Date: Wed Mar 05 2003 - 15:18:48 PST
Looking at Andrzej's example which illustrates where and how import
declarations to
extern function can occur, I have more questions and potential issues.
1) place of declaration for import/export
It looks like the import declaration can appear anywhere a declaration can
appear.
right?
in SV3.0, the import/export are strictly for interfaces and must be
declared in a modport.
If we allow the import declaration to appear in any declarative scope, and
the C function is a "context"
function, what is the meaning for the context? Is it the current instance?
or the current scope?
SV 3.0 has the ability to declare variables in unnamed blocks; this is
currently discussed in the bc committee as an issue for hierarchical
references and VPI name look up.
Do we want to allow to have import/export declarations in unnamed blocks?
2) Context passing for exported SV functions
I think the way we have it set up is complex.
The export declaration must be in the same declarative scope as the
function SV declaration.
If there are multiple instantiations of the same function and
therefore multiple instantiations of the
export declaration, since the export declaration does not have any instance
information,
how does the C function knows which exported SV function to call?
The answer was that there will be a default context which would be
inherited from the current context of the C call which is calling the SV
function.
If you don't want to use the current context, there is a C library
function provided: set_context
which would be used to set the context prior to the SV call.
I see some problems with that, you would have to hardcode in the C
function the hierarchical path to
the export SV function you want to call if different from the current
context. The C wrapper code
which calls the SV function is now dependent on the hierarchical name too,
since the SV function arguments can be instance specific (width of the
ranges can be dependent on a verilog parameter).
Note that every C function which calls SV would have to be qualified as
"context".
I think it is simpler to provide the full hierarchical name in the export
declaration. The context
is contained in the hierarchical path to the function and the wrapper code
can be generated more
easily.
Allow the export declaration to be outside of a module definition or in $root.
The syntax :export cname = hierarchical_path_to_SVfunction...
would allow to have different C functions calling different instances of
the SV function. The C function
does not need to know or set the context.
Example
========= start of SV code ========
module top
mod u1#(15)(); //instance of mod parameter size is overridden with 15
mod u2 (); // instance of mod uses default parameter size value of 7
other u3();
endmodule
module mod
parameter size = 7;
export SVf;
function SVf (reg [size :0] arg1 )
...
endfunction
endmodule
mod other
initial
begin
import extern context B = void foo(int i = 5);
foo; // calling B(5), B is calling SVf, which SVf to call?
end
endmodule
========= end of SV code ========
Let's assume in the above example that foo is context sensitive and calls
SVf exported function.
How do you specify which SVf to call if you have only one export declaration?
If you instead use:
export C = top.u1.SVf();
export D = top.u2.SVf().
the C code for function foo can be simple, no need to get and set the context
function foo (int arg1)
{
if (arg1 == 5)
C(...); // calls C
else D( ...); // or calls D
}
This archive was generated by hypermail 2b28 : Wed Mar 05 2003 - 15:20:12 PST