Subject: Re: [sv-cc] Disables and DPI interaction
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Oct 21 2003 - 01:30:58 PDT
Hi all,
first of all many thanks to Joao for this great write up. This makes my work much easier, especially since the awful last week... I
will intersperse some comments; there is no need for any counter-proposal at all :-)
Please read till the end.
Just my $0.02
Regards,
-Michael
Joao Geada 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.
Just to mention this: since there are much more process control statements within SV (fork, join) we might want to look at the
effects of those as well. I am aware of one request from one of my colleagues in the sv-ec group (Michael Burns) to have the
capability to 'kill' one the resulting sub-processes. IMHO this is/will be pretty similar to the effect of a disable ...
My understanding is that it might then even happen that there is a SV code "W" running parallel to "X" that kills "X" (which might
be part of another process), at least if there is a way to terminate/kill one process by another.
> 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)
This assumes that a disable statement can not be called from a SV function ...
It also assumes that the disable is not issued by a thread/process running in parallel to "X", otherwise it might happen that the
thread starting by "X" is currently within "Y" and has called "Z" (even if this is executed in 0 simulation time).
> 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
Basically yes (I did not say that I agree to 'simply', but this is fortunately not my problem), but I would like to narrow down the
point 4b) a little bit -- because this was the heart of my thinking 'loud'. Point 4b) requires:
- notify the C code "Y" about the disable event (probably by calling/resuming the function "Y*")
- enable the notified function "Y*" to have access to any local/global/heap parameters it needs to cleanup the work started by
function "Y"
- make sure that "Y*" properly reacts on the disable event (especially inhibit illegal accesses to the SV side)
> 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.
This is very likely. Some people here told me that this is one of the main usage ...
> 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
Having talked to some of our verification gurus this is an unacceptable solution.
> 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)
Up to here I agree, although there are not two counter-proposals. Mine is just an extension of Doug's (and I believe that is the
root cause of all the misunderstandings I extracted from the mail I have seen until now). Sorry for the confusion, I try to shed now
some more light on this. But let's first continue with Joao ...
> 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.
Whole heartedly agree. Never trust a user.
I am one and therefore I at least know at least one user I would never trust :-)
> 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
O.K. Here is now the discussion. I'll try to do along the more detailed problem I had described before:
A) Notification of code "Y" that there was a disable
- I believe and am in line with Doug that it should be possible to define any SV task to be of return type int.
Return 0 says it was O.K, return 1 means it has been disabled (we might want to reserve the other values
for further events ...). So basically disabling "X" will cause "Z" to return 1 before cleaning up the stack.
- From the above trail I have to believe that it _may_ not be a problem in case "Z" is a SV function. I am
unsure about cases where a code "W" kills/terminates "X", but this might be the next discussion then.
There are some more comments about this below ...
B) Providing access to parameters in effect within code "Y"
- I think there is no problem for global parameters (of course) and to parameters in the heap (if they are
referenced by global parameters). But in case of local parameters (on the stack) and parameters in the
heap that are only referenced by such parameters we have problem.
- The most natural way to access them for a user is within the function itself. Another way may be to require
a user to define a structure holding all such parameters, which is then to be passed somewhere for later
usage. I can not say that I like this ...
C) Make sure that "Y" properly reacts on the disable event (a basic question here is "what is properly" ...)
- "Y" must not continue its normal processing (especially call further SV code, or DPI functions)
- we can not inhibit "Y" from calling any other PLI/VPI functions, because it might be needed to do the
cleanup work; on the other side I would like to make sure IT ONLY CALLS THOSE FUNCTIONS
in case of a disable call to do the cleanup work.
- makes sure that "Y" recognizes the disable event
My proposal was more or less only related to point C). Whenever "Y" receives a disable notification, must
call a function sv_whatever() to notify the SV application that it a) has recognized the disable event b) will
perform properly c) is now starting the corresponding cleanup. When "Y" terminates without calling
sv_whatever() it is an error. When "Y" calls any other SV function (be it DPI, PLI, VPI) before calling sv_whatever() it is an
error. Thus we can easily identify that "Y" is a good function that handles disables properly ... As said, I am just loud thinking
...
With respect to callbacks, as proposed by Joao. Callbacks have multiple problems IMHO: a) it is hard to provide access to the local
parameters only defined within "Y", and I don't like globals very much, especially
not when I am enforced to use them b) I am not sure they help me when "Y" is calling a function "Z" -- we can
not interrupt the C code in "Y".
It might be probably useful to discuss this even further. I believe there are several cases, which can be matrixed:
- "Z" is a SV i) function or ii) task
- execution is currently iii) within "Y" or iv) within "Z" (I think we all agree that it is not a problem within "X")
- disable is issued v) within "Z", or vi) by another SV code "W"
A) I believe we agree that i) + v) is illegal
B) In case of ii) + v), then iv) applies
C) If iii) then we only can interfere with the C code whenever a SV function is called (which is then either a task or a function -
can be mapped to iv) or when the function terminates (no problem at all).
D) This leaves vi) with iv) and i) or ii). I think we showed that we can handle the case vi) iv) + ii) and the case with i) is at
best a design glitch (do know which stuff executed first the function "Z" or the task "W" running the disable code -- how'd you tell
??? ...)
--NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, System Design | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( )
*** This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank you! ***
This archive was generated by hypermail 2b28 : Tue Oct 21 2003 - 01:37:35 PDT