RE: [sv-cc] Ref: SV-CC meeting of 4/26: IEEE1800-2005 - Invoking DPI export functions/tasks from non context import functions/tasks

Perhaps the first sentence quoted by Amit was intended to say that the context of the task and functions
needs to be known when invoked from within systemVerilog  or from within import tasks/functions.

________________________________

From: owner-sv-cc@eda.org on behalf of Amit Kohli
Sent: Mon 5/8/2006 10:43 AM
To: sv-cc@eda.org
Subject: [sv-cc] Ref: SV-CC meeting of 4/26: IEEE1800-2005 - Invoking DPI export functions/tasks from non context import functions/tasks


 

	Hi,
	 
	Further to the discussion in SV-CC meeting on 4/26, I have compiled references from the LRM related to
	invocation of export functions/tasks. Of all the references from the LRM, there is only instance which can
	be used to construe invocation of export tasks and functions fron non (context) import scope. This is the
	first of the references I present below. After that, all the references presented can be interpreted to indicate
	that export functions/tasks and utility functions can be called only from context imported tasks and functions.
	 
	Regards,
	 
	--Amit
	 
	 
	A. Reference which can be used to deduce invocation of export tasks/functions from non-import contexts
	 
	1. Section 26.4.3: Context tasks and functions - second paragraph
	 
	 "The SystemVerilog context of DPI export tasks and functions must be known when they are called, including 
	 when they are called by imports. 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. Because imports with diverse instantiated scopes can export the
	same task or function, 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. "  
	 
	Interpretation: The ending phrase for the first sentence above is the only place in the LRM where I can deduce
	                     that a DPI export task/function can be called from any place other than imports. 
	  
	 
	
	B. References supporting invocation of export tasks/functions from  context import tasks/functions
	 
	 1 : Section 26.4.3:Context tasks and functions  - second paragraph again  
	 
	     The remainder of the paragraph explains the requirement of a context and how it is set from a context
	     import task/function. This gives the explanation for presence of a context when DPI export tasks/functions  
	     are invoked. 
	 
	 
	      " The SystemVerilog context of DPI export tasks and functions must be known when they are called, 
	         including when they are called by imports. 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. Because imports with diverse instantiated scopes can export 
	         the same task or function, 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."
	 
	      Interpretation:
	      A context's presence is essential as when a  SystemVerilog function corresponding to a function is to be executed, 
	      it s  associated scope/context should be available. In case a design unit containing an import task/function
	      has been instantiated multiple times then svSetScope() allows setting the context to a particular instance
	      of the task/function that needs to be executed. In the absence of an explicit call to svSetScope() since there
	      is a default scope (that of the called import function/task) already available, there are no serious
	      consequences (crash?).
	     
	      In case a call to an export task/function is made without a context then the simulation tool does not have 
	      any scope/context in which the function should be executed and thus the restriction. Further in the same
	      vein, this section IEEE26.4.3, states,
	 
	2 :  Section 26.4.3: Context tasks and functions  : fourth paragraph
	 
	      " 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 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..."
	 
	        Interpretation:
	        >From the above I understand that invocation of export tasks and even VPI/PLI API from import tasks/functions
	        requires the  import  tasks/functions to be specified as context.  
	 
	3. Annexure F.8 : Context tasks and functions : second paragraph
	 
	       States unambiguously that  calling  scope related utility functions from non context import tasks functions  will
	       be a  system  error
	 
	      "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. " 
	 
	       Interpretation: 
	       This paragraph precludes all C functions except context import tasks and functions from calling DPI scope utility
	       functions. The only other way a scope for an export function is set is the scope set of  the executing context
	       import task/function. This along with item 1, in this section, in my belief states that export tasks and functions cannot 
	       be executed from any C function other than context import tasks and functions.

	4. Annexure F.8.3: Working with DPI context tasks and functions in C code  : second paragraph 

	     "There are functions that allow the user to retrieve and manipulate the current operational scope. It is an error
	       to use these functions with any C code that is not executing under a call to a DPI context imported task or  function."  
	  
	       Interpretation:
	       This paragraph is effectively saying the same thing as in item 3 above. Should be sufficient to conclude that export
	       tasks and functions cannot be executed from  any C function other than context import tasks and functions.