Conflicted description in 35.5.3 Context tasks and functions as to how a context is defined

SystemVerilog
1

I have a ticket in Accellera mantis: 0007168: conflicted description in 35.5.3 Context tasks and functions as to how a context is defined - Accellera Mantis. Below are the detials:

In the first paragraph, it is said “Some DPI imported subroutines require that the context of their call be known. It takes special
instrumentation of their call instances to provide such context”. Here the context is related to the call or call instance of an import function.

Then in the second paragraph, it is said " When an import invokes the svSetScope utility prior to calling the export, it sets the context explicitly. Otherwise, the context will be the context of the instantiated scope where the import declaration is located.". Here it seems to mean that default context is the instantiated scope of the import declaration, rather than where the call to import is made.

See below code:

package pkg;
import "DPI-C" context function void show_context();
endpackage

module test;
import pkg::*;
initial show_context();
endmodule

void show_context()
{
vpi_printf("scope = %s\n", svGetNameFromScope(svGetScope()));
}

should it print “test”, or “pkg”?

2

In reply to robert.liu:

The proper context should be pkg. The DPI is supposed to behave as if you never left SystemVerilog. If you had

package pkg;
//import "DPI-C" context function void show_context();
function void show_context();
   print();
endfunction
function void print;
  $display("%m");
endfunction

endpackage
 
module test;
import pkg::*;
initial show_context();
function void print;
  $display("%m");
endfunction
endmodule

You would expect pkg::print to be called.

3

In reply to dave_59:

Thanks Dave. Now I understand that based on your nice example as well as more related text from the LRM. This was a little beyond the intuition originally though.

H.9.1 Overview of DPI and VPI context
Both DPI subroutines and VPI functions might need to understand their context. However, the meaning of
the term is different for the two categories of subroutines.
DPI imported tasks and functions are essentially proxies for native SystemVerilog tasks and functions.
Native SystemVerilog tasks and functions always operate in the scope of their declaration site. For example,
a native SystemVerilog function f() can be declared in a module m, which is instantiated as top.i1_m. The
top.i1_m instance of f() can be called via hierarchical reference from code in a distant design region.
Function f() is said to execute in the context (i.e., instantiated scope) of top.i1_m because it has
unqualified visibility only for variables local to that specific instance of m. Function f() does not have
unqualified visibility for any variables in the calling code’s scope.
DPI imported tasks and functions follow the same model as native SystemVerilog tasks and functions. They
execute in the context of their surrounding declarative scope, rather than the context of their call sites. This
type of context is termed DPI context.
This is in contrast to VPI functions. Such functions execute in a context associated with their call sites. The
VPI programming model relies on C code’s ability to retrieve a context handle associated with the
associated system task’s call site and then to work with the context handle to glean information about
arguments, items in the call site’s surrounding declarative scope, etc. This type of context is termed VPI
context.

4

In reply to dave_59:

Hi Dave, one more question.

Because imports with diverse instantiated scopes can export the same subroutine, multiple instances of such an export can exist after elaboration. Prior to any invocations of svSetScope, these export instances would have different contexts, which would reflect their imported caller’s instantiated scope.

Here it is clear that if users don’t call svSetScope, the context used for call to exported subroutine should be the context of imported subroutine.

What does “imports with diverse instantiated scopes can export the same subroutine” mean? This sentence appears exactly the same in the LRM multiple times.

5

In reply to robert.liu:

It means if you define and export a function inside a module, that module can be instantiated in multiple places with the overall hierarchy. And depending on the location of each instance, parameterization and upward reference will effect the behavior of each export.