[sv-cc] DPI disable -- converging on fundamentals

Here's a resend of a disable essay.  My hopes are to achieve consensus
of some fundamentals before tackling requirements and implementation mechanisms.

Here's some flexible terminology to described our mixed-language 'call chains:'
	sv0i..sv0j -> ct0i..ct0j -> sv1i..sv1j

where:
. where a 'sub-chain' consists of consecutive task enables within the same language
. sv0i...sv0j is the inital SystemVerilog sub-chain in the simulator,
. ct0i..ct0j is a C sub-chain reached via a call to DPI C import task, ct0i.
. sv1i..sv1j is an SV sub-chain reached via a call to exported SV task, sv1i.

1. SV Mechanics for Disabling -- do we agree this is how it works?
   Disabling a task disables its children, so the following mechanisms should be
   capable of disabling a sub-chain both directly (by disabling the first item
   in the chain) and indirectly (disable a subsequent item via disabling the 
   sub-chain's head).

   WRT Spec. 9.6.2, an SV task in the exported sub-chain sv1i..sv1j may:
	a. disable itself or disable a predecessor task in sv1i...sv1j.
	b. disable an SV task in the pre-import sub-chain sv0i...sv0j by
		i.   disabling that task by name
		ii.  disabling a named stmt that enabled the task in the sv0i..sv0j
			sub-chain (or that enabled one of the task's predecessors).
		iii. disabling a named block that contains an invocation of one
			of the tasks in sv0i...sv0j.
		iv.  executing a 'disable fork' where the fork contains an 
			invocation of one of the executing tasks in sv0i...sv0j.

2. No Direct disabling from the C sub-chain -- is this true?

   SV does not specify a means by which a component of the C sub-chain ct0i...ct0j
	can _directly_ disable either itself or a component of sv0i...sv0j,
	i.e., there's no API to do this.  True?


3. Imports and the disabled state.  Making our wording a bit tighter (34.9).

   a. The Spec. says an imported task is "said to be in a disabled state" when
      it or a predecessor (presumably in an SV sub-chain like sv0i..sv0j) has been
      the target of a disable (presumably from an export sub-chain, like sv1i..sv1j).

   b. It also says the import "can only enter the disabled state immediately 
      after the return of a call to an exported task of function."

   c. Item 'a' probably meant to establish a necessary condition, rather than specify
	timing, so an import isn't really "in" a disabled state "when" the disable is
	executed.  Do we agree that an imported tf is in a disabled state if and only if
	(i) It has been the target (direct or not) of a disable executed by a component of
	       a successor SV sub-chain and
	(ii)Control has returned to that imported task from the exported sub-chain that 
	      (directly or not) triggered the disable? 
      If we have consensus, a slight tweak to the 34.9 wording might be helpful.

      By these rules, if an import sub-chain item ct0k is the target of a disable, its
  	successors in the subchain become disabled as the stack unwinds; for sub-chain 
 	successors ct0(k+n), n = 1..p, ct0(k+p) enters a disabled state, then 
	 ct0(k+p-1), etc..  If anyone feels this is inaccurate, please let me know.

4. Directly disabling imported C tasks -- question

   Sec. 34.9 states that imported C tasks can be the target of disable statements 
   (paragraph 2).  Since an imported C 'task' is to behave interchangably from a 
   native SV task, this makes sense: however, some questions remain.

   Given an imported C sub-chain ct0i...ct0j:
	a. An export successor sub-chain should be able to disable ct0i (the head of 
	      the sub-chain) since, by definition, an enable of ct0i occurs in SV code.
	b. Clearly, export successors can't disable components of ct0i...ct0j that
	      aren't DPI imports (they may be invisible to an SV simulator).
	c. However, can an export successor disable a C task that is known to the
	   simulator as an import but is not the head of the sub-chain (i.e. is somewhere
	   in ct0(i+1)...ct0j)?  One would think not: while some simulators may be able
	   to examine the C run-time stack, it seems one shouldn't presume that the 
	   simulator can either do this, nor can know anything about call relationships
	   that occur within the foreign C code.  True?

If we can reach consensus on these items, we should be well-positioned to tackle 
the practical requirements for our implementation mechanism.

Again, thanks for investing time in this material.

Ralph

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.