[Fwd: ISAC IR2123 discussion - copy to chuck]

I am attaching the response of John Shields to this issue. Email from 
VHPI (or any non-isac member) to isac bounces to me and is not
sent to the isac.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

attached mail follows:

Several ISAC members are concerned that the callback triggers are
optional under optimized implementations. This implies that when an
application receives such a callback, the condition may or may not be
true. Also, when the condition is false, the callback may or may not
be executed. This double indeterminacy makes such a callback
potentially non portable and less useful.

The phrase "double indeterminacy" is provocative.  The LRM language for process resumption contains an implicit non-determinism for simulators.  The boundary between kernel and the process code in determining when a suspended wait statement conditions will be satisified is an implementation matter.  It is a space for optimization and improved performance.  There is a single point at which the process code resumes execution and that is the point for the vhpiResume callback, but it may occur somewhere within the execution of the wait stmt.  The issue of the process possibly suspending again is irrelevant.  A robust implementation has to be oblivious to how quickly this might happen.  Calling this potentially "less useful" is also provocative and naive and reflects a lack of understanding of the intent.

Despite that, it is fine if you wish to record a contrary opinion like this.  It expresses enough truth not to be dismissed and will, no doubt, strike some other people the same way.  What would satisfy me is adding the balanced information about the intent of the callback, consistency with related callbacks, and its usefulness.  (What I've written above is the 3rd time I've tried to get this across).  It would make more sense to fold this into the IR analysis, but I don't care.  If you are not interested in balancing Chuck's addendum, then throwing it out entirely would satisfy me also.

-----
In the IR analysis, I lightly objected to this paragraph:

In summary, the VHPI Task Force recommended that a process be
considered to resume from a wait statement when an event occurs on any
of the signals in the sensitivity set of the wait statement. If the
wait statement has a condition clause, the condition is evaluated. If
the condition is false, the process suspends again, and will resume
again on a subsequent event on any signal in the sensitivity set.

I do not think we made the recommendation this way at all. We said we preferred the language definition of resume expressed the non-determinism and that vphiResume occurred at the LRM defined resume point.  We said that if the LRM language doesn't want to express it this way, it is fine if an alternate description is used. I am OK with it because the analysis goes on to acknowledge what we really (though not just initially) said.  It does not say anything about the callback intent or rationale we had for the decision, except to point at a very convoluted email thread. I know what I am looking for in terms of message and I had trouble finding it in that thread.  (Please insert Chuck's addendum in the middle of that ;)
----

Finally in the LRM text, we get what we asked for.  As I said, it could have strengthened the reasoning in one of the notes:

In 8.1, add the following note:

  If an implementation optimizes execution of a wait statement by
  obviating certain process resumptions, the corresponding trigger
  events of vhpiCbResume and vhpiCbSuspend callbacks associated with
  the process do not occur.


The note in 8.1 could have reflected that VHPI callbacks match the optimized behavior (which is the intent and has value), but instead it is just cast as fact and left to perceive whether that is a flaw. It is OK, but not great.  I don't really want to change the note.  I didn't really want to change the analysis either.  Both are weak on expressing intent and aiding understanding of the VHPI rationale.  Chuck's final set of comments tipped the balance far enough to set me off.  I have to object and ask that our rationale be more fairly expressed and I fear that the ISAC did not fully understand the decision we made.

----
One last thing.  I finally got to see the text of Ajay's original concerns as he expressed them today.  I think we would have been happy to respond directly to that.  Unfortunately, it was only sent to me as an attachment behind the original draft ISAC resolution.  I still am willing to do that, but a phone conversation would be better and I definitely have written enough on this subject for one email.


I hope this helps.

Regards, John