[sv-cc] DPI 'context' mechanics (ref: item 1456)

These notes address some questions about context that arose in today's
SV-CC meeting.

 

Please exercise patience with the length and dry content but it seems
desirable to 

get all the information about context mechanics here in one place.

 

Abbreviations: (SV = SystemVerilog, tf = task/function).

C is used as the only non-SystemVerilog language throughout for brevity.

 

 

I. BASIC DPI CONTEXT AXIOMS:

 

. SV tasks or functions can only be called with an SV context in place.

 

. Calling a context import from SV establishes an SV context for that 

  C call-chain (it is the context where the import is declared).

 

. Calling the svSetSCope utility with a legitimate argument from any tf 

  in a DPI context calling-chain resets the SV scope for that chain.

 

. Behavior when calling an SV export OR a DPI set/getScope utility:

   .. from a DPI context import chain -- behavior is defined,

   .. from something other than a DPI import chain -- behavior is not
defined.

   .. from a DPI non-context import chain -- behavior erroneous (else no
point 

           in having a context keyword)

 

. Whether a C call-chain is a context chain or not is determined by
whether

  its initial tf was invoked by an SV tf, based on a context import decl
or not. 

 

. Therefore, (preceding bullet) whether a C call-chain is context or 

  non-context cannot be dynamically changed once it is entered.

 

. Although a call-chain's being 'context' or not is determined by the
import 

  declaration for the first import tf in the chain, the
context/non-context 

  quality adheres to the calling-chain, not to the individual tf.

 

 

II. Example with CALL-CHAINS

 

Let SV0 be an SV tf and let SVexp1 be an exported SV tf.

Let cc0..ccp be a chain of C calls where tf cc0 is a CONTEXT import.

Let cn0..cnp be a chain of C calls where tf cn0 is a NON-CONTEXT import.

 

Consider the following call stack situation, where 

left-to-right indicates a caller->called relation:

 

SV0 -> cc0->...ccp -> SVexp1 -> cn0->...cnp

 

. When SV0 called cc0, SV context0 was in effect (determined by the
location

  of the SV code containing the import declaration for cc0).

 

. Since cc0 is a context import, call-chain cc0..ccp is a context chain
and

  can invoke exports, like SVexp1. 

 

. When Svexp1 calls back into C via non-context import cn0, the chain
cn0..cnp 

  is non-context, since the context characteristics of C calling chains
that 

  preceded crossing back into C are irrelevant. Thus cn0..cnp can't call
exports.

 

. When the runtime stacks unwind past SVexp1, back to ccp, the chain
cc0..ccp 

  still has the SV context it possessed when SVexp1 was called.  This is
true, 

  even if a member of the chain used svSetSCope to set some scope other
than 

  the one originally created by SV0 calling cc0.

 

 

III. CALL-CHAIN DEDUCTIONS:

 

. The same C tf can appear in both context and non-context call chains.

 

. A C tf declared as a context import sets a default SV context for its
chain

  when it appears as the first C tf in the chain; however, it's
appearance in 

  any position other than the first item of a call-chain has no effect
on that

  chain's having the context characteristic or not.

 

 

IV. SUMMARY

 

Calling-chain context is stackable.

 

Many of the rules follow from the fact that SystemVerilog cannot
necessarily 'eavesdrop'

on consecutive C calls in a call chain.  Thus, the rules suppose that
critical events

for sensing or setting SV scope occur only 

   (a) at the inter-language boundary when an SV tf calls a C tf or vice
versa, 

   (b) when a C tf calls one of the special DPI scope utilities.