Re: Discussion of IR 2123: Process resumption and callbacks

Peter, to respond to your suggestions, in order:
Peter Ashenden wrote:
> 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?
>
>   
I have talked with some additional people who believe that the better 
decision is the
alternative (a process resumes when there is an event and the condition 
evaluates to TRUE).
I personally think that the alternative solution is preferable. Note 
that the optimized
execution in effect is allowed to implement the alternative solution. 
However, since the
VHPI has chosen the first interpretation I accept that.


> 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.
>
>   
I would approve moving the paragraph from 8.1 to 19.2.3.2.

As I was studying the situation it came to my attention that  a similar 
paragraph is  also
needed in clause 19.2.2.2 VhpiCbSensitivity

If we look at the example John Shields gives of
wait until clk'event and clk = '1'
I think that its pretty clear that an optimized execution, which 
recognizes this construct as
a test for posedge on clk  might well suppress an event
on clk when clk moves from 1 to 0.

It might also be needed in clause 19.2.1.1 vhpiCbValueChange
in a similar case, since one of the triggers for the value change is an 
event on a signal.
If the event is optimized away, then the value change callback is not 
called.

There may be more (perhaps lots more) situations in which differences 
between optimized
and non-optimized executions are detectable to the VHPI application. 

So I would like to see a general paragraph, perhaps in clause 19 or 
19.1.x, or, even better
in Clause 15 stating that
tool optimizations can affect VPHI results.

> 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.
>
>   
Yes,  I agree that this will help
> 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
>
>
>   
In summary, I agree with Peter's suggestions. I do think that a little 
more needs to
be done, but his proposal is acceptable.

Peter, thank you for helping to resolve this situation.

Chuck Swart

p.s. Anyone replying from vhpi-pilot@server.eda.org should make sure 
that I'm
cc'd in the reply. I'll forward the email to isac.
Email from non-isac members to isac gets bounced, and the mailer 
transforms the html in
the email in ways that are hard for me to recover.




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