[sv-cc] FW: Jim's 3 context scenarios

My apologies; I didn't realize Jim had CC'ed SV-CC.  Here's my response 
to him, which is sometimes informal as a personal email.

Ralph

-----Original Message-----
From: Duncan, Ralph 
Sent: Tuesday, June 06, 2006 1:45 PM
To: Jim Vellenga
Subject: Jim's 3 context scenarios

Hi, Jim,

Thanks for the scenarios below; it let's me know someone's reading 
this material ;) 

Here is a mini-rant on the overall scene as I see it.
The 'std. DPI' approach envisioned an SV executable calling into C.  The

'undefined behavior' scenarios are largely a consequence of people
wanting 
to used SystemVerilog and/or DPI when starting from C, Vera, e, etc.
For 
now, we're just admitting we can't control these scenarios.  From the
LRM's
pt. of view the behavior is "undefined" but that gives all the
simulators 
the freedom to support these alternatives in an intuitive way.  However,
we're not forcing anyone to support these.
Hence, we've got 3 possibilities:
1. call exports/contextUtilities from a context DPI import chain --
works 
   as we've defined.
2. call exports/contextUtilities from a non-context DPI import chain --
   Get an error (else there's no point in having "context" keyword).
3. call exports/contextUtilities from something other than a DPI import 
   chain -- undefined (as Steve might say 'outside our purview').

Well, the rest of the rant/remarks are embedded below.

-----Original Message-----
From: Jim Vellenga [mailto:vellenga@cadence.com] 
Sent: Tuesday, June 06, 2006 1:02 PM
To: Duncan, Ralph; sv-cc@verilog.org
Subject: RE: [sv-cc] Context items: (1456,1488 mods), C setjmp/longjmp,
pure/context

Ralph,

The description is certainly becoming less and less ambiguous.

I do, however, want to make sure we agree on what happens in certain 
combinations of call chains.

To set up the base situation, let's say that in module top.foo1 there 
is a call to a DPI-C import context function f1.  For convenience we 
can refer to the context of the call to f1 as "top.foo1".  Let's say 
the simulation calls f1 from top.foo1, and f1 or one of its 
subordinates uses the svGetScope function to save off "top.foo1" to a 
global variable savedScope1.  The function f1 then returns control to 
top.foo1.  Let's call this point in the simulation "Point 1".

As I read the description now, the following are true:

-- If after "Point 1" one enters the C code via a VPI call back or 
user-defined system task, and the C code executes a function called 
(for example) "my_vpi", then if "my_vpi" tries to use svSetScope to 
restore the context "top.foo1" from savedScope1, the results are 
undefined.  That is,

  VPI call back
     -->  my_vpi
        --> svSetScope("top.foo1")
  ==> Results are undefine

and

  User-defined system task
     -->  my_vpi
        --> svSetScope("top.foo1")
  ==> Results are undefine

Is this correct?


RESPONSE: Yes, undefined from the LRM perspective. If the simulator
chooses to support these, presumably, the context is successfully set =
top.foo1.

-- Similarly, if after "Point 1" one enters the C code because 
SystemVerilog has invoked a non-context DPI-C import function f2, then 
if f2 tries to use svSetScope to restore the context "top.foo1" from 
savedScope1, the results are also undefined.  That is,

  top.foo2.f2 (non-context)
     --> svSetScope("top.foo1")
  ==> Results are undefined

Is this also correct?

RESPONSE: The result should be an error, rather than undefined.  We're
within a DPI import call-chain, so we can dictate what 'std' behavior
is. 
If we can't forbid this, there's little point in having the "context"
keyword ;)

-- As a third scenario, let's assume that the module top.foo3 calls the 
DPI-C context import function f3 -- again, this happens sometimes after 
"Point 1", when the context "top.foo1" has already been saved in 
savedScope1.  This time, according to our text, the behavior when one 
calls svSetScope is no longer undefined.  What happens when f3 or one 
of its subordinates uses svSetScope to set the context "top.foo1"?  

RESPONSE: Since f3 is part of an import context call-chain, the call to 
svSetScope works as spec'd in the LRM and its context becomes top.foo1
(otherwise there'd probably be no usefulness in a set-scope utility).

Let's assume that f3 or one of its subordinates calls the DPI-C export 
function fexp4 after changing the context.  What will the context for 
fexp4 be?  Is this clear from the text?

RESPONSE: The context for fexp4 is whatever the current context is for 
the import chain.

RESPONSE:(to is it clear?) Not for me to say (as the author ;)) In
general, the utility of this system is that even the most convoluted
call chains can be handled by a very small collection of rules.  Those
are:
1. When one moves from an SV call-chain to a DPI import call chain, the
latter's context is the SV context where the import is declared.
2. The context of an import context call-chain can only be changed by a
call
to svSetScope.  When such a call forces a new context, that context
stays in force for the call-chain until another call svSetScope changes
it.
3. When control moves from an import context call-chain to SV via a call
to an SV export, the context for that export is whatever context is in
effect for the import chain when the export is invoked.
4. When an export SV chain unwinds, the context for the caller (import
context call chain) is restored to whatever it was at the time the
export chain was entered.
<Just these rules are enough and, mercifully, they are simple to
implement>.

That is, if

  top.foo3.f3 (a DPI-C context import function)
     --> svSetScope("top.foo1")
  and then
     --> fexp4 (a DPI-C export function

What will the context for fexp4 be?  Will it be "top.foo1" or 
"top.foo3"?

ADDED RESPONSE FOR SV-CC BROADCAST: In your example it will be top.foo1.

Regards,
Jim Vellenga


--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Engineering Director                   (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd 
Chelmsford, MA 01824-4179 
"We all work with partial information." 
---------------------------------------------------------- 
  
 

] -----Original Message-----
] From: owner-sv-cc@verilog.org 
] [mailto:owner-sv-cc@verilog.org] On Behalf Of Duncan, Ralph
] Sent: Tuesday, June 06, 2006 1:17 PM
] To: sv-cc@verilog.org
] Subject: [sv-cc] Context items: (1456,1488 mods), C 
] setjmp/longjmp, pure/context
] 
] There have been slight changes to Mantis items:
] 
]  
] 
] . 1456 (behavior of context operations outside the DPI std. scheme).
] 
] . 1488 clarify context mechanics, esp. with regard to call chains.
] 
]  
] 
]  
] 
] The status of two related issues raised during the last meeting:
] 
]  
] 
] . Use of C setjmp/longjmp makes context behavior 
] unpredicatable (undefined).
] 
]             .. both 1456 and 1488 have additions that state this.
] 
]  
] 
] . Relation of 'pure' and 'context' concepts
] 
]  
] 
]             .. Since there was no clear group consensus for 
] change on these points,
] 
]                I haven't altered 1456 or 1488 to address this.
] 
]             .. If anyone feels strongly about this issue, 
] they might best 
] 
]                create a new Mantis item devoted solely to it.
] 
]  
] 
] Ralph
] 
]  
] 
] Ralph Duncan
] 
] Mentor Graphics
] 
] San Jose, CA
] 
]