RE: Discussion of IR 2123: Process resumption and callbacks

Peter,

I would be happy with your suggested changes.

Regards,

-ajay 

-----Original Message-----
From: owner-isac@eda.org [mailto:owner-isac@eda.org] On Behalf Of Peter
Ashenden
Sent: Monday, April 07, 2008 6:47 AM
To: isac@eda.org; vhpi-pilot@eda.org
Subject: 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.



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