Subject: [sv-cc] DPI tasks and function interaction with disable statements
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Fri Oct 03 2003 - 18:33:17 PDT
Hi Team,
Here is an exposition of the problem with disabling a task
on an import call chain. Imagine a chain of three tasks
originating in an initial block:
initial begin
taskA()
-> taskB()
-> taskC()
<-
<-
more code here;
end
If all tasks are native Verilog, and taskA() is disabled with
a disable statement (either from within say, taskC(), or perhaps
from some totally different part of the design hierarchy) then the
behavior is that the "more code here" will start executing right
away in the current time unit. Whatever taskA() was doing at the
time of the disable should promptly be stopped, and control
returned to the first statement following the call to taskA().
Now imagine that taskA() and taskC() are SV tasks, and that taskB()
is an imported DPI task. There are three cases to consider:
1) taskC() is the target of a disable statement
2) taskA() is the target of a disable statement
3) taskB() is the target of a disable statement
The following describes "ideal" operation:
Case 1) If taskC() is disabled, the C code in taskB() need not
even know about this disable. taskC() will return to taskB()
and taskB()'s C code can proceed forward as normal.
Case 2) If taskA() is disabled, and control happens to be in
taskC() at the time, then the Verilog simulator will start
unwinding the call chain that leads down to taskC. The imported
C code in taskB() should know that taskC() returned due to a
disable. It should perform any necessary resource cleanups,
then return right away to taskA() without calling any further
exported SV tasks or functions.
Case 3) Same as case 2).
*****
How can we achieve "ideal" operation?
What we propose is to change the operation of DPI tasks so
that from C's point of view they are int-returning functions.
An exported task would return a 0 if control returns to C due
to a normal return, and it would return a 1 if C gained control
due to a task disable. Similarly, if the C imported task detects
a disable event when calling an exported task, it would return a 1
to indicate this fact. It would return a 0 otherwise.
One problem with this technique is that some users may forget to
check the return status of exported tasks. In that case the system
would have unreliable behavior that may be difficult for users to
debug. Precautions may be taken by simulator vendors to help catch
this kind of user error. For example, the simulator could realize
that a disable event has occurred on the call chain. When C returns
control to it, the simulator would check the imported task's return
status for value 1. If a 1 was not received, the simulator would
error out, informing the user that their DPI imported task had
misbehaved during a disable event.
Another problem with this technique concerns exported functions
that themselves call a disable statement targetting a task
near the origin of the call chain. Exported functions
already return values. Thus there is no good way for a user's
DPI import function or import task to check for a disable event.
A costly API call would be needed for this functionality.
An interesting point about this last problem is that it exists in
DPI today, purely through context imported functions making calls
to exported functions. An exported function could call a disable
statement on some task down its call chain, and the same issues
all occur with the unwinding through the user's C code.
One solution to this last problem is simply to make this illegal.
We should probably do this as an errata, even if for some reason
the committee decides not to put DPI tasks into SV 3.1a.
*****
What can we do that is "non-ideal"?
One thought is that we simply make it illegal for a disable statement
to target a task which is currently on a chain containing DPI import
functions or task. This isn't that hard for simulators to detect,
and correct functionality couldn't possibly be compromised by user
error in their C code. The problem with this is that the "Golden
Rule of DPI" would not be followed: Imported tasks and functions
would not be treated the same as native tasks and functions.
This could be highly inconvenient in user environments which
routinely disable high level task enables as a way of controlling
test flow. Those engineers doing the high level test flow may
have no idea some other engineer wrote low level DPI code on a call
chain. Depending where the call chain is at the time of the disable,
all the sudden the disable statements might become illegal and cause
surprising errors.
*****
We propose going for the int-returning function C view of
imported and exported tasks described above. However, we recognize
that some debate will be needed within SV-CC, and thus we won't be
sending out another edition of the MTI donation at this time.
Once that debate is had and a decision is made, we can update the
donation document with the results of the debate.
Thanks for reading this long mail.
Imported and Exported tasks obviously have some complexities,
but nothing insurmountable. User demand for them is high
and they have real value in many modeling applications.
Thanks and Regards,
Doug
This archive was generated by hypermail 2b28 : Fri Oct 03 2003 - 18:42:34 PDT