Subject: [sv-cc] Disables and DPI interaction
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Wed Oct 15 2003 - 13:24:23 PDT
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
==============================================================================
This archive was generated by hypermail 2b28 : Wed Oct 15 2003 - 13:26:03 PDT