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