Subject: Re: [sv-cc] Disables and DPI interaction
From: Swapnajit Mittra (mittra@juno.com)
Date: Fri Oct 17 2003 - 13:55:16 PDT
I am assigning an issue number 1.1 to track this better.
-- Swapnajit Mittra Project VeriPage ::: http://www.angelfire.com/ca/verilog-- "Joao Geada" <Joao.Geada@synopsys.com> wrote: So as to summarize the various points people have made so far:
1- the issue arises whenever some SV code "X" invokes a C function/task "Y" which then invokes an exported SV function/task "Z" which, through one some means or another causes "X" to be disabled.
As an alternate way of stating the same thing, the issue arises whenever a SV call chain containing DPI calls is disabled.
2- this is not a new issue: the problem exists already in SV 3.1 (Y and Z are constrained to be functions, and Z disables X)
3- this was not an issue in Verilog 2001, as up to SV 3.1 C code could never give control back to Verilog code without returing. Thus it was not possible to be in a state where a callchain could be disabled *and* contained C functions in the call chain (BECAUSE the only means to disable are the disable stmts in Verilog itself)
4- the problem is simply to figure out how to "disable" the C portion of the call stack, which has two primary components: a) unwinding the C stack back to its SystemVerilog root b) providing a mechanism to enable C code to cleanup any resources it possessed in that call stack
Disable usage notes: In Verilog, disables were primarily used to effect exception control jumps. (note: there were other uses of disable, but such uses were rarer) In SV 3.1 that purpose of disable is largely superceded by the provision of additional control constructs (break, continue, return, etc); However, due to all the testbench process control constructs it is possible that disables will be used to control "transactions" within the testbench.
In terms of purely high level terms, the solution space is quite constrained:
I) we make this an unsupported feature. ie causing the disable of a callstack containing C tasks/functions is an error II) we define some protocol such that users that must implement and so cause items 4a and 4b above to occur It would be an error to disable a C task/function that did not implement the protocol III) we automatically cause 4a to occur and provide some means to inform the user code that this unwinding has occurred. Users are not required to do 3b unless their code has consumed non-stack resources that must be released or finalized Doug's and Michael's proposals are all variants on II, though neither addresses the behavior when both Y and Z are purely functions and not tasks (as in such a case return codes cannot be used)
Personally I have concerns on relying on or trusting users to accomplish 4a, and I believe this can be effected completely automatically within the simulator, by harnessing the internal, simulator specific knowledge of how multiple C functions are permitted to be "in progress" at a single time; note that this is itself a side-effect of the task donation, regardless of the technology used to implement the mechanism (doesn't matter if using threads, co-routines, continuations or any other alternative: the simulator *must* have a mechanism to suspend and resume the execution of arbitrary C code. However, solving 4a still, clearly, leaves the 4b issue. During the meeting I suggested a "protocol" mechanism to address 4b using a callback functions.
OK, I think this is a full summary. On to the discussions and proposals ;-)
Joao ============================================================================== Joao Geada, PhD Principal Engineer Verif Tech Group Synopsys, Inc TEL: (508) 263-8083 377 Simarano Drive, Suite 300, FAX: (508) 263-8069 Marlboro, MA 01752, USA ==============================================================================
________________________________________________________________ The best thing to hit the internet in years - Juno SpeedBand! Surf the web up to FIVE TIMES FASTER! Only $14.95/ month - visit www.juno.com to sign up today!
This archive was generated by hypermail 2b28 : Fri Oct 17 2003 - 14:22:13 PDT