SV utilities in non-context task/functions

Hi Brian & ITC,

 

Here is the paragraph taken from IEEE 1800-2005, that we were debating
today:

 

"To avoid any unnecessary overhead, imported task and function calls in
SystemVerilog code are not

instrumented unless the imported task or function is specified as
context in its SystemVerilog import declaration.

A small set of DPI utility functions are available to assist programmers
when working with context

tasks or functions (see F.8.3). If those utility functions are used with
any noncontext function, a system error

shall result."

 

The utility functions mentioned are:

*	svGetScope()
*	svSetScope()
*	svGetNameFromScope()
*	svGetScopeFromName()
*	svPutUserData()
*	svGetUserData()
*	svGetCallerInfo()

 

It is my interpretation of this section to mean that these utility
functions may only be called from within a context imported
task/function; meaning that calling any of these from a pure imported
function or SystemC constructor not called as a result of a context
imported function is illegal.

 

Here is an example of why I think this restriction is in the
SystemVerilog specification:

 

module top;

   reg clk;

   wire [31:0] dout;

   wire        valid;

   ...

   bfm i0(dout,valid,clk);

endmodule

 

module bfm(dout,valid,clk);

   input         clk;

   output [31:0] dout;

   output        valid;

   ...

endmodule

 

Compiler ABC wants to take advantage of any optimization possible.
Since it sees that there are no context DPI import or export
tasks/functions declared in the module "bfm", it decides to omit the
svUserData space from its internal representation of the module.  In
addition, it decides to inline the module, so its scope (top.i0) does
not even exist.  So, if I have some SystemC code for which the HDL
compiler knows nothing about, I cannot do svGetScopeFromName("top.i0"),
because the scope doesn't exist, since it has been inlined.  I also
cannot do svPutUserData() for two reasons: (1) I can't get the scope to
top.i0; (2) Storage space for svUserData has been optimized away because
there are no context task/functions declared.

 

Perhaps compiler XYZ does not make these optimizations and allows
calling the utility functions from non-context functions, but I believe
that the specification is trying to allow what compiler ABC is doing,
and maybe even some other things.

 

Also, let me draw an analogy to PLI.  Using acc_* routines, you are
supposed to do:

 

int my_pli_call() {

   acc_initialize();

   /* your stuff goes here */

   ...

   acc_close();

   return 0;

}

 

Not all simulators require that you have acc_initialize() and
acc_close() in your code, but you're supposed to do it.

 

Imagine that Simulator ABC does something like the initialize and close
when any imported context DPI function/task is called to set up the
simulation to enable use of SV utility functions.  Not all simulators
may do something like this, but it is possible that the compiler can do
some things to optimize the non-context functions/tasks to the point
where calling the SV utility functions will crash the sim.

 

Regards,

Jason