Shabtay’s take 04/28 – Dependency on SV working group

Brian: Is being discussed in SV working group. Chas has promised to invite us to their next meeting.

Within the Accellera ITC, we have come across an area of the SystemVerilog specification, where there is a disagreement in the way to interpret it. This has led to completely different implementation by Cadence and Mentor in their products. It clearly needs to get resolved form that point of view, but in addition it will have a significant impact on our work in the committee as it would appear that we have defined some stuff that relies on one interpretation. If the other turns out to be true, then it would mean that we have to rethink part of our specification and would likely lead to a less efficient interface.

Please can you provide us with an answer to this issue as quickly as possible as our continued work and release depends on a resolution of this matter.

Given below are some words by various group members that I hope clarifies the issues and the difference in the interpretation. However, if more information is required, please let me know.

Best regards,

Brian Bailey – Chair of the ITC

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

"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.

-----------------------------------

“If those utility functions are used with any noncontext function, a system error shall result.”

This introduces the term `noncontext function'. It is not clear if this refers to those imported functions/tasks that are not specified as context *or* if it also includes all functions that are not imported. To me the text is quite ambiguous. At the very least it requires clarification from the SV committee.

Actually this is not the first time this term is introduced.

Of the 10 references to "non-context" that I counted in the LRM, there is only one reference to "non-context functions", namely the one in quoted paragraph. I think this was an unintentional omission of "tasks or" different from the other 9 places.

Furthermore, in section 26.4.3, 3rd paragraph:

"For the sake of simulation performance, an imported task or function call shall not block SystemVerilog compiler optimizations. An imported task or function not specified as context shall not access any data objects from SystemVerilog other than its actual arguments. Only the actual arguments can be affected (read or written) by its call.

Therefore, a call of a non-context task or function is not a barrier for optimizations. A context imported task or function, however, can access (read or write) any SystemVerilog data objects by calling PLI/VPI, or by calling an export task or function. Therefore, a call to a context task or function is a barrier for SystemVerilog compiler optimizations."

I think it is fairly clear from this paragraph what is meant by a "non-context task or function". Given that the 'context' keyword can only be applied to imported tasks or functions, I think it can be reasonably concluded that the term "non-context" specifically means an imported task or function without the keyword.