Subject: RE: [sv-cc] DPI tasks and function interaction with disable state ments
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Oct 15 2003 - 09:09:37 PDT
Hi Michael,
Thanks for stepping up to the plate and helping brainstorm
this tough issue.
I'm actually quite in line with your "out loud" thinking.
Both of us want the user to somehow confirm that they have
properly handled the disable event on the thread.
You proposed that we require them to call an API acknowledging
the disable event. My proposal is that we require users to
return a 1 from their import task, rather than 0. This return
value is the "I'm returning due to a disable event" value.
At the moment I'm leaning towards my proposal, mainly for the
reason that it is symmetric with the return values of SV
exported tasks. Recall, those would return a 1 if they
are returning due to a disable event, and 0 otherwise.
Other than this small difference, I think we're quite in line.
Further thoughts?
Regards,
Doug
> -----Original Message-----
> From: Michael Rohleder [mailto:michael.rohleder@motorola.com]
> Sent: Tuesday, October 14, 2003 12:11 PM
> To: sv-cc@eda.org
> Subject: Re: [sv-cc] DPI tasks and function interaction with
> disable statements
>
>
> Thanks Doug,
>
> for bringing this up to us. After having spent some thought
> about this and our discussion in the last conference call, I am still
> unsure I like the idea of relying on the user to properly
> catch such situations. I was wondering how this could be made a little
> more secure.
>
> My thoughts go along the line of:
> a) we need to give the creator of a DPI task the chance to
> cleanup all memory allocations, VPI & PLI calls made as well
> as any other
> housekeeping activities
> b) a DPI task of a disabled call chain must not proceed in
> its normal operations; as such it would be good to give the simulator
> vendors the chance to block any further function calls from
> such a task. [At a first glance I thought this must be easy, just
> inhibit all further calls of such a function. BUT, since as
> stated above, we want to enable the DPI task to cleanup earlier work
> _including_VPI_and_probably_other_calls_, I see little chance
> to blindly block any subsequent calls from such a function ]
> c) on the other side, it is preferable to have a chance to
> check whether a DPI tasks is properly reacting on such an event.
>
> Now, and this just loud thinking, so please forgive any silly
> idea herein, what about the following:
> - whenever a DPI task receives a 'task disable' signal
> (let's assume we use your int return value), it _immediately_
> has to call a
> service function (e.g. disable_recognized() ), to indicate
> that it will properly react on the corresponding event. Any other call
> into SV land, after a disable signal, but before having
> called disable_recognized() is regarded as an error [and
> might be handled in
> a simulator specific way -- blocked, the task is killed, or
> whatever ...]. Also the termination of the DPI task after a 'task
> disable' without having called this function is also regarded
> as an error [with similar treatment ...]. This should catch cases
> where there are no further calls, but the disable case is not
> properly handled.
>
> I think there is not much that can be done more to assert a
> proper response on disable, and to make sure the user reacts
> on such an
> event.
>
> As said, this is just one more point to the table. Not fully
> thought through. But it is at least one idea ...
>
> Best regards,
> -Michael
>
> "Warmke, Doug" wrote:
>
> > 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
>
> --
>
> 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 : Wed Oct 15 2003 - 09:13:01 PDT