EDITOR’S NOTE:
The addition of “tasks and”, above, was not in the change request.
27.4.1
Required properties of imported tasks or and functions calls -
semantic constraints
An imported task or
function that is intended to call exported tasks or functions or to access
SystemVerilog data objects other then its actual arguments (e.g. via VPI or PLI
calls) must be specified as context. Calls of context tasks and functions are specially
instrumented and can impair SystemVerilog compiler optimizations; therefore
simulation performance can decrease if the context property is specified when not necessary. A task or
function not specified as context shall not read or write any data
objects from SystemVerilog other then its actual arguments. For tasks or
functions not specified as context, the effects of calling PLI, VPI, or
exported SystemVerilog tasks or functions can be unpredictable and can lead to
unexpected behavior; such calls can even crash. Section 27.4.3 details the
restrictions that must be obeyed by non-context tasks or functions.
If neither the pure nor the context attribute is used on an
imported task or function, the task or function may not access SystemVerilog
data objects, however it can perform side-effects such as writing to a file or
manipulating a global variable.
EDITOR’S NOTE:
The last sentence above refers to “non-context tasks”. Since a task can never
be declared as pure, can there ever be a non-context task? David Smith says
that a task or function that is not explicitly declared with the pure or
context modifiers is neither pure nor context, and is therefore a non-context
task or function. This is not clear in the LRM. The way I read this section
(the full section, not just this subsection), there are only two types of
functions, context and pure. If not explicitly declared, a
function defaults to pure. I get this impression of a default from the
sentence above, which used to say “A function not specified as context shall
not read or write any data objects from SystemVerilog other then its actual
arguments”. (the change to add tasks to that sentence
could indicate that what I inferred is wrong. Then again, it could indicate
that adding tasks to that sentence was an error. If there are indeed three
types of functions and two types of tasks, it should be explicitly explained. A
Table comparing the different types would help.
27.4.3
Context tasks and functions
Only calls of context imported
tasks or functions are properly instrumented and cause conservative
optimizations; therefore, only those tasks or functions can safely call all
tasks or functions from other APIs, including PLI and
VPI tasks or functions or exported SystemVerilog tasks or
functions. For imported tasks or functions not
specified as context, the effects of calling PLI, or VPI functions, or SystemVerilog tasks or functions can be unpredictable and such
calls can crash if the callee requires a context that
has not been properly set. However note that declaring an import context task
or function does not automatically make any other simulator interface
automatically available. For VPI access (or any other interface access) to be
possible, the appropriate implementation defined
mechanism must still be used to enable these interface(s). Note also that DPI
calls do not automatically create or provide any handles or any special
environment that can be needed by those other interfaces. It is the user’s
responsibility to create, manage or otherwise manipulate the required
handles/environment(s) needed by the other interfaces.
EDITOR’S NOTE:
The change request called for adding “tasks” to PLI and VPI functions. The PLI
and VPI libraries do not contain tasks, they only contain C functions. I
recommend this change be removed.
Context imported tasks or functions are always implicitly
supplied a scope representing the fully qualified instance name within which
the import declaration was present. This scope defines which exported
SystemVerilog tasks or functions can be called directly from the imported task
or function; only tasks or functions defined and exported from the same
scope as the import can be called directly. To call any other exported
SystemVerilog tasks or functions, the imported task or function shall first
have to modify its current scope, in essence performing the foreign language
equivalent of a SystemVerilog hierarchical task or function call.
EDITOR’S NOTE:
Are there DPI utility tasks, or are they all functions?
Special DPI
utility task or functions exist that allow imported task or functions to retrieve and operate
on their scope. See Annex E for more details.
EDITOR’S NOTE:
Is the sentence added to the end of the previous paragraph correct for all
possible foreign interface languages? I thought a goal of the foreign language
layer was to be implementable in languages other than
C. I don’t know many other languages, but don’t think that they all have the
void functions that this sentence requires. How about saying “...declared in
foreign code with the equivalent of a C language void function.”?
tf_proto_formal ::=
tf_input_declaration
| tf_output_declaration
| tf_inout_declaration
| tf_ref_declaration
9) dpi_function_proto return types
are restricted to small values, as per 27.4.5. //
from Annex A.10
10) Formals of dpi_function_proto and dpi_task_proto
cannot use pass by reference mode and class types cannot be passed at all; for
the complete set of restrictions see 27.4.6.
EDITOR’S NOTE:
I took the liberty of adding the productions for “named_function_proto”,
“named_task_proto” , “list_of_tf_proto_formals” and “tf_proto_formal”.
4) Once an imported task or
function enters the disabled state, it is illegal for
the current function invocation to make any further calls to exported tasks
or functions.
EDITOR’S NOTE:
I changed “will” to “shall” and “may” to “can”, per
the IEEE standards convention.