RE: [sv-cc] Context items: (1456,1488 mods), C setjmp/longjmp, pure/context

From: Jim Vellenga <vellenga_at_.....>
Date: Tue Jun 06 2006 - 13:01:57 PDT
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?

-- 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?

-- 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"?  
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?

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"?

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
] 
] 
Received on Tue Jun 6 13:01:32 2006

This archive was generated by hypermail 2.1.8 : Tue Jun 06 2006 - 13:01:41 PDT