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