RE: Discussion of IR 2123: Process resumption and callbacks

Folks,

There appears to be concensus that IR2123 deals with two sub-issues: first,
that the definition of process resumption is imprecise in VHDL-2002, and
second, that the triggering of vhpiCbResume callbacks is affected by the
interpretation of the definition of resumption.

I don't see any dispute over the resolution of the first sub-issue, that
resumption be clearly defined to occur as a response to an event on a signal
in the sensitivity set, regardless of whether the condition subsequently
evaluate to false or true. Do I presume correctly that all would be happy to
see that resolution stand?

Regarding the second sub-issue: John has raised an important point, that
this is not the first place in which implementation dependent optimizations
are exposed to VHPI callbacks. He points out that the vhpiCbStmt callback is
similarly affected. 19.2.3.1 of 1076c-2007 contains the following:

  A tool may perform optimizations that render an object representing
  a statement inaccessible. It is an error if the handle in the obj
  member of the registration callback data structure refers to such
  an object. A tool may perform optimizations that alter the order
  of execution of statements in a statement part. A VHPI program that
  depends on the order of execution of vhpiStmt callbacks associated
  with statements whose execution order is so altered is erroneous.

Given this precedent, it would appear that triggering of vhpiCbResume
callbacks being affected by optimizations is not inconsistent. Perhaps it
would be more consistent to move the specification of this dependency from
8.1 to 19.2.3.2 so that it parallels the statement in 19.2.3.1.

Also, given John's explaination of the intended use of the callback, and in
particular, his description of its use for debugging under both unoptimized
and optimized scenarios, we could revise the analysis and rationale in the
IR to reflect that explaination. The reader could then take away an
understanding of the potentially different behavior under different
scenarios, not as a negative warning, but as an understanding of valid
permitted variation among implementations.

Since I wrote the original analysis, I would be happy to make that change.
The revised IR, once we've agreed on it, would then be forwarded to VASG for
consideration without any other accompanying notes.

If the above meets with your approval, please let me know. I'll then draft a
revised IR for review. Thanks.

Cheers,

PA

--
Dr. Peter J. Ashenden         peter@ashenden.com.au
Ashenden Designs Pty. Ltd.    www.ashenden.com.au
PO Box 640                    VoIP: sip://0871270078@sip.internode.on.net
Stirling, SA 5152             Phone: +61 8 7127 0078
Australia                     Mobile: +61 414 70 9106


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