These emails reflect conversations, mostly involving Peter, Francoise and John concerning IRs 2123 and 2124 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
attached mail follows:
Peter and Chuck, The VHPI committee which consists of : Steen Dovich Vishwa Raman John Shields Amit Kohli Francoise Martinolle came to the following resolutions: 1) vhpiCbResume callback. We would prefer that the LRM *NOT* be precise in whether or not the condition is evaluated as part of the process resumption. The reason is that lots of optimizations involve computing the condition to avoid scheduling of processes when the condition is false. We would like to define VHPI in a way that would work with optimizations. To that effect, we would like to specify the vhpiResume callback to occur at any point of time just prior the evaluation of the condition of the wait statement to up until just before the first statement after the wait statement be executed. Decision was 4 in favor of the above, 1 person was of the opinion that the callback should always occur after evaluation of the condition and before the first statement after the wait, being so precise would enable consistency of the VHPI callback across simulator vendors. 2)Execution of callbacks and VHDL processes We believe that the VHDL LRM should allow interleaved execution of processes and callbacks with relaxed ordering. The LRM text should be rewritten to refect this. Decision was unanimous. Francoise '
attached mail follows:
Francoise, Thanks for conveying the resolution of the group. Could I please seek one pont of clarification? I understand that the group would like it to be permissible that the callback occur prior to evaluation of the condition. Does that mean, if the callback is triggered and then the condition evaluates to false, the callback will be triggered again just before the condition is next evaluated? Or is the callback only triggered once for each time the wait statement is executed? 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 -----Original Message----- From: Francoise Martinolle [mailto:fm@cadence.com] Sent: Thursday, 6 March 2008 09:29 To: Peter Ashenden Cc: Chuck Swart - MTI; jshields@ieee.org; Steven J. Dovich; Amit Kohli; vishwa.raman@gmail.com Subject: Issues resolution recommendation from VHPI Peter and Chuck, The VHPI committee which consists of : Steen Dovich Vishwa Raman John Shields Amit Kohli Francoise Martinolle came to the following resolutions: 1) vhpiCbResume callback. We would prefer that the LRM *NOT* be precise in whether or not the condition is evaluated as part of the process resumption. The reason is that lots of optimizations involve computing the condition to avoid scheduling of processes when the condition is false. We would like to define VHPI in a way that would work with optimizations. To that effect, we would like to specify the vhpiResume callback to occur at any point of time just prior the evaluation of the condition of the wait statement to up until just before the first statement after the wait statement be executed. Decision was 4 in favor of the above, 1 person was of the opinion that the callback should always occur after evaluation of the condition and before the first statement after the wait, being so precise would enable consistency of the VHPI callback across simulator vendors. 2)Execution of callbacks and VHDL processes We believe that the VHDL LRM should allow interleaved execution of processes and callbacks with relaxed ordering. The LRM text should be rewritten to refect this. Decision was unanimous. Francoise '
attached mail follows:
Message Francoise,Thanks for conveying the resolution of the group. Could I please seek one pont of clarification?I understand that the group would like it to be permissible that the callback occur prior to evaluation of the condition. Does that mean, if the callback is triggered and then the condition evaluates to false, the callback will be triggered again just before the condition is next evaluated? Or is the callback only triggered once for each time the wait statement is executed?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
-----Original Message-----
From: Francoise Martinolle [mailto:fm@cadence.com]
Sent: Thursday, 6 March 2008 09:29
To: Peter Ashenden
Cc: Chuck Swart - MTI; jshields@ieee.org; Steven J. Dovich; Amit Kohli; vishwa.raman@gmail.com
Subject: Issues resolution recommendation from VHPI
Peter and Chuck,The VHPI committee which consists of :Steen DovichVishwa RamanJohn ShieldsAmit KohliFrancoise Martinollecame to the following resolutions:1) vhpiCbResume callback.We would prefer that the LRM *NOT* be precise in whether or not the condition is evaluatedas part of the process resumption. The reason is that lots of optimizations involve computingthe condition to avoid scheduling of processes when the condition is false. We would like to define VHPI in away that would work with optimizations.To that effect, we would like to specify the vhpiResume callback to occurat any point of time just prior the evaluation of the condition of the wait statementto up until just before the first statement after the wait statement be executed.Decision was 4 in favor of the above,1 person was of the opinion that the callback should always occur after evaluationof the condition and before the first statement after the wait, being so precise would enableconsistency of the VHPI callback across simulator vendors.2)Execution of callbacks and VHDL processesWe believe that the VHDL LRM should allow interleaved execution of processes and callbackswith relaxed ordering. The LRM text should be rewritten to refect this.Decision was unanimous.Francoise'
attached mail follows:
John, Thanks for the clarification. As it happens, the resume callback is repetitive. I interpret your response as indicating that the callback is triggered once per execution of a wait statement, but that the time of triggering may vary from one implementation to another. It may be in different simulation cycles in different implementations. The implication is that, if the callback is triggered and the condition turns out to be false, the implementation will have to remember that it has already triggered the callback and not retrigger it next time it evaluates the condition. Is that your intention? 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 -----Original Message----- From: John Shields [mailto:John_Shields@mentor.com] Sent: Thursday, 6 March 2008 10:32 To: Peter Ashenden Cc: 'Francoise Martinolle'; 'Chuck Swart - MTI'; jshields@ieee.org; 'Steven J. Dovich'; 'Amit Kohli'; vishwa.raman@gmail.com Subject: Re: Issues resolution recommendation from VHPI Peter, We are looking for the callback to be triggered once at some point between when the sensitivity of the wait statement is satisfied and when the condition is fully evaluated. If the callback is triggered and the condition turns out to be false, oh well, the process suspends again at the wait. This is not a repetitive callback, as I recall, so if it is not re-registered, it triggers once. Working well in the context of optimized tools might look a little tricky, at first. A smart VHPI debugger will do the right thing in an optimized environment. A naive one might have a missed expectation about this. A future VHPI server might add a repetitive callback, too ;) Regards, John Peter Ashenden wrote: Francoise, Thanks for conveying the resolution of the group. Could I please seek one pont of clarification? I understand that the group would like it to be permissible that the callback occur prior to evaluation of the condition. Does that mean, if the callback is triggered and then the condition evaluates to false, the callback will be triggered again just before the condition is next evaluated? Or is the callback only triggered once for each time the wait statement is executed? 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 -----Original Message----- From: Francoise Martinolle [mailto:fm@cadence.com] Sent: Thursday, 6 March 2008 09:29 To: Peter Ashenden Cc: Chuck Swart - MTI; jshields@ieee.org; Steven J. Dovich; Amit Kohli; vishwa.raman@gmail.com Subject: Issues resolution recommendation from VHPI Peter and Chuck, The VHPI committee which consists of : Steen Dovich Vishwa Raman John Shields Amit Kohli Francoise Martinolle came to the following resolutions: 1) vhpiCbResume callback. We would prefer that the LRM *NOT* be precise in whether or not the condition is evaluated as part of the process resumption. The reason is that lots of optimizations involve computing the condition to avoid scheduling of processes when the condition is false. We would like to define VHPI in a way that would work with optimizations. To that effect, we would like to specify the vhpiResume callback to occur at any point of time just prior the evaluation of the condition of the wait statement to up until just before the first statement after the wait statement be executed. Decision was 4 in favor of the above, 1 person was of the opinion that the callback should always occur after evaluation of the condition and before the first statement after the wait, being so precise would enable consistency of the VHPI callback across simulator vendors. 2)Execution of callbacks and VHDL processes We believe that the VHDL LRM should allow interleaved execution of processes and callbacks with relaxed ordering. The LRM text should be rewritten to refect this. Decision was unanimous. Francoise '
attached mail follows:
Peter is correct, vhpiCbResume is repetitive by default. I think that the callback should occur whever the process resumes to evaluate the condition, every single time whether it woke up and the condition was false before. In other word, the process resumes for whatever reason, the callback should occur. That is my opinion. An application can always put a callbck on the statement after the wait and figure out if the condition and until expression were true or false. ________________________________ From: Peter Ashenden [mailto:peter@ashenden.com.au] Sent: Wednesday, March 05, 2008 9:14 PM To: 'John Shields' Cc: Francoise Martinolle; 'Chuck Swart - MTI'; jshields@ieee.org; Steven Dovich; Amit Kohli; vishwa.raman@gmail.com Subject: RE: Issues resolution recommendation from VHPI John, Thanks for the clarification. As it happens, the resume callback is repetitive. I interpret your response as indicating that the callback is triggered once per execution of a wait statement, but that the time of triggering may vary from one implementation to another. It may be in different simulation cycles in different implementations. The implication is that, if the callback is triggered and the condition turns out to be false, the implementation will have to remember that it has already triggered the callback and not retrigger it next time it evaluates the condition. Is that your intention? 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 -----Original Message----- From: John Shields [mailto:John_Shields@mentor.com] Sent: Thursday, 6 March 2008 10:32 To: Peter Ashenden Cc: 'Francoise Martinolle'; 'Chuck Swart - MTI'; jshields@ieee.org; 'Steven J. Dovich'; 'Amit Kohli'; vishwa.raman@gmail.com Subject: Re: Issues resolution recommendation from VHPI Peter, We are looking for the callback to be triggered once at some point between when the sensitivity of the wait statement is satisfied and when the condition is fully evaluated. If the callback is triggered and the condition turns out to be false, oh well, the process suspends again at the wait. This is not a repetitive callback, as I recall, so if it is not re-registered, it triggers once. Working well in the context of optimized tools might look a little tricky, at first. A smart VHPI debugger will do the right thing in an optimized environment. A naive one might have a missed expectation about this. A future VHPI server might add a repetitive callback, too ;) Regards, John Peter Ashenden wrote: Francoise, Thanks for conveying the resolution of the group. Could I please seek one pont of clarification? I understand that the group would like it to be permissible that the callback occur prior to evaluation of the condition. Does that mean, if the callback is triggered and then the condition evaluates to false, the callback will be triggered again just before the condition is next evaluated? Or is the callback only triggered once for each time the wait statement is executed? 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 -----Original Message----- From: Francoise Martinolle [mailto:fm@cadence.com] Sent: Thursday, 6 March 2008 09:29 To: Peter Ashenden Cc: Chuck Swart - MTI; jshields@ieee.org; Steven J. Dovich; Amit Kohli; vishwa.raman@gmail.com Subject: Issues resolution recommendation from VHPI Peter and Chuck, The VHPI committee which consists of : Steen Dovich Vishwa Raman John Shields Amit Kohli Francoise Martinolle came to the following resolutions: 1) vhpiCbResume callback. We would prefer that the LRM *NOT* be precise in whether or not the condition is evaluated as part of the process resumption. The reason is that lots of optimizations involve computing the condition to avoid scheduling of processes when the condition is false. We would like to define VHPI in a way that would work with optimizations. To that effect, we would like to specify the vhpiResume callback to occur at any point of time just prior the evaluation of the condition of the wait statement to up until just before the first statement after the wait statement be executed. Decision was 4 in favor of the above, 1 person was of the opinion that the callback should always occur after evaluation of the condition and before the first statement after the wait, being so precise would enable consistency of the VHPI callback across simulator vendors. 2)Execution of callbacks and VHDL processes We believe that the VHDL LRM should allow interleaved execution of processes and callbacks with relaxed ordering. The LRM text should be rewritten to refect this. Decision was unanimous. Francoise '
attached mail follows:
Message Peter is correct, vhpiCbResume is repetitive by default. I think that the callback should occurwhever the process resumes to evaluate the condition, every single time whether it woke up and the condition was false before.In other word, the process resumes for whatever reason, the callback should occur.That is my opinion. An application can always put a callbck on the statement after the wait and figure outif the condition and until expression were true or false.
From: Peter Ashenden [mailto:peter@ashenden.com.au]
Sent: Wednesday, March 05, 2008 9:14 PM
To: 'John Shields'
Cc: Francoise Martinolle; 'Chuck Swart - MTI'; jshields@ieee.org; Steven Dovich; Amit Kohli; vishwa.raman@gmail.com
Subject: RE: Issues resolution recommendation from VHPI
John,Thanks for the clarification. As it happens, the resume callback is repetitive. I interpret your response as indicating that the callback is triggered once per execution of a wait statement, but that the time of triggering may vary from one implementation to another. It may be in different simulation cycles in different implementations. The implication is that, if the callback is triggered and the condition turns out to be false, the implementation will have to remember that it has already triggered the callback and not retrigger it next time it evaluates the condition. Is that your intention?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
-----Original Message-----Peter,
From: John Shields [mailto:John_Shields@mentor.com]
Sent: Thursday, 6 March 2008 10:32
To: Peter Ashenden
Cc: 'Francoise Martinolle'; 'Chuck Swart - MTI'; jshields@ieee.org; 'Steven J. Dovich'; 'Amit Kohli'; vishwa.raman@gmail.com
Subject: Re: Issues resolution recommendation from VHPI
We are looking for the callback to be triggered once at some point between when the sensitivity of the wait statement is satisfied and when the condition is fully evaluated. If the callback is triggered and the condition turns out to be false, oh well, the process suspends again at the wait. This is not a repetitive callback, as I recall, so if it is not re-registered, it triggers once.
Working well in the context of optimized tools might look a little tricky, at first. A smart VHPI debugger will do the right thing in an optimized environment. A naive one might have a missed expectation about this. A future VHPI server might add a repetitive callback, too ;)
Regards, John
Peter Ashenden wrote:Francoise,Thanks for conveying the resolution of the group. Could I please seek one pont of clarification?I understand that the group would like it to be permissible that the callback occur prior to evaluation of the condition. Does that mean, if the callback is triggered and then the condition evaluates to false, the callback will be triggered again just before the condition is next evaluated? Or is the callback only triggered once for each time the wait statement is executed?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
-----Original Message-----
From: Francoise Martinolle [mailto:fm@cadence.com]
Sent: Thursday, 6 March 2008 09:29
To: Peter Ashenden
Cc: Chuck Swart - MTI; jshields@ieee.org; Steven J. Dovich; Amit Kohli; vishwa.raman@gmail.com
Subject: Issues resolution recommendation from VHPI
Peter and Chuck,The VHPI committee which consists of :Steen DovichVishwa RamanJohn ShieldsAmit KohliFrancoise Martinollecame to the following resolutions:1) vhpiCbResume callback.We would prefer that the LRM *NOT* be precise in whether or not the condition is evaluatedas part of the process resumption. The reason is that lots of optimizations involve computingthe condition to avoid scheduling of processes when the condition is false. We would like to define VHPI in away that would work with optimizations.To that effect, we would like to specify the vhpiResume callback to occurat any point of time just prior the evaluation of the condition of the wait statementto up until just before the first statement after the wait statement be executed.Decision was 4 in favor of the above,1 person was of the opinion that the callback should always occur after evaluationof the condition and before the first statement after the wait, being so precise would enableconsistency of the VHPI callback across simulator vendors.2)Execution of callbacks and VHDL processesWe believe that the VHDL LRM should allow interleaved execution of processes and callbackswith relaxed ordering. The LRM text should be rewritten to refect this.Decision was unanimous.Francoise'
attached mail follows:
Let me agree with John's example. I think it is a cleaner formulation to treat the until clause as part of the process (if it needs to be evaluated), rather than as code in some form of purgatory. If the until clause needs to execute, then bracketing with Resume and Suspend would be entirely appropriate. If the tool has optimized away the until clause execution, then the "missing" resumptions will behave as if the point of callback is ambiguous with respect to the condition evaluation. At least that was my line of reasoning... /sjd John Shields wrote: > Hi, > > OK, it's repetitive. Since it is, it triggers every time the process > resumes. So yes, I agree with Francoise and that is what I meant. It > is triggered whenever the process resumes and after it suspends, it is > retriggered whenever the process resumes again. The only issue is the > variability of timing within the wait statement at which the process > is considered to resume. There is no memory of previous triggering > involved. > > Peter, I do not want to mistake your statement that it may be in > different simulation cycles, given the delta cycle semantics of the > language should never be disrespected in these optimizations. Let me > describe an example that I assume is what you meant. > > What may happen is that a wait represents an event that can be > recognized atomically in the kernel without resuming execution of code > in the process. Take a wait until clk'event and clk = '1', for > example. If so optimized, the process would only resume on positive > edges of clk and the resume callback would always occur at the end of > the wait, but only for positive edges. If it were not optimized, the > process might resume on every clk event, but for negative edges it > would immediately suspend after evaluating the until clause. In that > case, the resume callback would occur on every clk event. > > Thanks for being so careful, Peter. > > Regards, John > > Francoise Martinolle wrote: >> Peter is correct, vhpiCbResume is repetitive by default. I think that >> the callback should occur >> whever the process resumes to evaluate the condition, every single >> time whether it woke up and the condition was false before. >> In other word, the process resumes for whatever reason, the callback >> should occur. >> That is my opinion. An application can always put a callbck on the >> statement after the wait and figure out >> if the condition and until expression were true or false. >> >> >> >> ------------------------------------------------------------------------ >> *From:* Peter Ashenden [mailto:peter@ashenden.com.au] >> *Sent:* Wednesday, March 05, 2008 9:14 PM >> *To:* 'John Shields' >> *Cc:* Francoise Martinolle; 'Chuck Swart - MTI'; >> jshields@ieee.org; Steven Dovich; Amit Kohli; vishwa.raman@gmail.com >> *Subject:* RE: Issues resolution recommendation from VHPI >> >> John, >> >> Thanks for the clarification. As it happens, the resume callback >> is repetitive. I interpret your response as indicating that the >> callback is triggered once per execution of a wait statement, but >> that the time of triggering may vary from one implementation to >> another. It may be in different simulation cycles in different >> implementations. The implication is that, if the callback is >> triggered and the condition turns out to be false, the >> implementation will have to remember that it has already >> triggered the callback and not retrigger it next time it >> evaluates the condition. Is that your intention? >> >> 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 >> >> >> -----Original Message----- >> *From:* John Shields [mailto:John_Shields@mentor.com] >> *Sent:* Thursday, 6 March 2008 10:32 >> *To:* Peter Ashenden >> *Cc:* 'Francoise Martinolle'; 'Chuck Swart - MTI'; >> jshields@ieee.org; 'Steven J. Dovich'; 'Amit Kohli'; >> vishwa.raman@gmail.com >> *Subject:* Re: Issues resolution recommendation from VHPI >> >> Peter, >> >> We are looking for the callback to be triggered once at some >> point between when the sensitivity of the wait statement is >> satisfied and when the condition is fully evaluated. If the >> callback is triggered and the condition turns out to be >> false, oh well, the process suspends again at the wait. This >> is not a repetitive callback, as I recall, so if it is not >> re-registered, it triggers once. >> >> Working well in the context of optimized tools might look a >> little tricky, at first. A smart VHPI debugger will do the >> right thing in an optimized environment. A naive one might >> have a missed expectation about this. A future VHPI server >> might add a repetitive callback, too ;) >> >> Regards, John >> >> Peter Ashenden wrote: >>> Francoise, >>> >>> Thanks for conveying the resolution of the group. Could I >>> please seek one pont of clarification? >>> >>> I understand that the group would like it to be permissible >>> that the callback occur prior to evaluation of the >>> condition. Does that mean, if the callback is triggered and >>> then the condition evaluates to false, the callback will be >>> triggered again just before the condition is next evaluated? >>> Or is the callback only triggered once for each time the >>> wait statement is executed? >>> >>> 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 >>> >>> >>> -----Original Message----- >>> *From:* Francoise Martinolle [mailto:fm@cadence.com] >>> *Sent:* Thursday, 6 March 2008 09:29 >>> *To:* Peter Ashenden >>> *Cc:* Chuck Swart - MTI; jshields@ieee.org; Steven J. >>> Dovich; Amit Kohli; vishwa.raman@gmail.com >>> *Subject:* Issues resolution recommendation from VHPI >>> >>> Peter and Chuck, >>> >>> The VHPI committee which consists of : >>> Steen Dovich >>> Vishwa Raman >>> John Shields >>> Amit Kohli >>> Francoise Martinolle >>> >>> came to the following resolutions: >>> >>> 1) vhpiCbResume callback. >>> We would prefer that the LRM *NOT* be precise in whether >>> or not the condition is evaluated >>> as part of the process resumption. The reason is that >>> lots of optimizations involve computing >>> the condition to avoid scheduling of processes when the >>> condition is false. We would like to define VHPI in a >>> way that would work with optimizations. >>> To that effect, we would like to specify the vhpiResume >>> callback to occur >>> at any point of time just prior the evaluation of the >>> condition of the wait statement >>> to up until just before the first statement after the >>> wait statement be executed. >>> >>> Decision was 4 in favor of the above, >>> 1 person was of the opinion that the >>> callback should always occur after evaluation >>> of the condition and before the >>> first statement after the wait, being so precise would >>> enable >>> consistency of the VHPI callback >>> across simulator vendors. >>> >>> 2)Execution of callbacks and VHDL processes >>> We believe that the VHDL LRM should allow >>> interleaved execution of processes and callbacks >>> with relaxed ordering. The LRM text should be >>> rewritten to refect this. >>> >>> Decision was unanimous. >>> >>> Francoise >>> ' >>>
attached mail follows:
John, Your example captures precisely what I thought you meant. Thanks again for clarifying. I'm sure we can proceed now and revise the LRM wording to express that intent. As it happens, we have an ISAC meeting today, so we can discuss whether to bring the change into the current revision. 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 -----Original Message----- From: John Shields [mailto:John_Shields@mentor.com] Sent: Friday, 7 March 2008 02:10 To: Francoise Martinolle Cc: Peter Ashenden; Chuck Swart - MTI; jshields@ieee.org; Steven Dovich; Amit Kohli; vishwa.raman@gmail.com Subject: Re: Issues resolution recommendation from VHPI Hi, OK, it's repetitive. Since it is, it triggers every time the process resumes. So yes, I agree with Francoise and that is what I meant. It is triggered whenever the process resumes and after it suspends, it is retriggered whenever the process resumes again. The only issue is the variability of timing within the wait statement at which the process is considered to resume. There is no memory of previous triggering involved. Peter, I do not want to mistake your statement that it may be in different simulation cycles, given the delta cycle semantics of the language should never be disrespected in these optimizations. Let me describe an example that I assume is what you meant. What may happen is that a wait represents an event that can be recognized atomically in the kernel without resuming execution of code in the process. Take a wait until clk'event and clk = '1', for example. If so optimized, the process would only resume on positive edges of clk and the resume callback would always occur at the end of the wait, but only for positive edges. If it were not optimized, the process might resume on every clk event, but for negative edges it would immediately suspend after evaluating the until clause. In that case, the resume callback would occur on every clk event. Thanks for being so careful, Peter. Regards, John Francoise Martinolle wrote: Peter is correct, vhpiCbResume is repetitive by default. I think that the callback should occur whever the process resumes to evaluate the condition, every single time whether it woke up and the condition was false before. In other word, the process resumes for whatever reason, the callback should occur. That is my opinion. An application can always put a callbck on the statement after the wait and figure out if the condition and until expression were true or false. _____ From: Peter Ashenden [mailto:peter@ashenden.com.au] Sent: Wednesday, March 05, 2008 9:14 PM To: 'John Shields' Cc: Francoise Martinolle; 'Chuck Swart - MTI'; jshields@ieee.org; Steven Dovich; Amit Kohli; vishwa.raman@gmail.com Subject: RE: Issues resolution recommendation from VHPI John, Thanks for the clarification. As it happens, the resume callback is repetitive. I interpret your response as indicating that the callback is triggered once per execution of a wait statement, but that the time of triggering may vary from one implementation to another. It may be in different simulation cycles in different implementations. The implication is that, if the callback is triggered and the condition turns out to be false, the implementation will have to remember that it has already triggered the callback and not retrigger it next time it evaluates the condition. Is that your intention? 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 -----Original Message----- From: John Shields [mailto:John_Shields@mentor.com] Sent: Thursday, 6 March 2008 10:32 To: Peter Ashenden Cc: 'Francoise Martinolle'; 'Chuck Swart - MTI'; jshields@ieee.org; 'Steven J. Dovich'; 'Amit Kohli'; vishwa.raman@gmail.com Subject: Re: Issues resolution recommendation from VHPI Peter, We are looking for the callback to be triggered once at some point between when the sensitivity of the wait statement is satisfied and when the condition is fully evaluated. If the callback is triggered and the condition turns out to be false, oh well, the process suspends again at the wait. This is not a repetitive callback, as I recall, so if it is not re-registered, it triggers once. Working well in the context of optimized tools might look a little tricky, at first. A smart VHPI debugger will do the right thing in an optimized environment. A naive one might have a missed expectation about this. A future VHPI server might add a repetitive callback, too ;) Regards, John Peter Ashenden wrote: Francoise, Thanks for conveying the resolution of the group. Could I please seek one pont of clarification? I understand that the group would like it to be permissible that the callback occur prior to evaluation of the condition. Does that mean, if the callback is triggered and then the condition evaluates to false, the callback will be triggered again just before the condition is next evaluated? Or is the callback only triggered once for each time the wait statement is executed? 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 -----Original Message----- From: Francoise Martinolle [mailto:fm@cadence.com] Sent: Thursday, 6 March 2008 09:29 To: Peter Ashenden Cc: Chuck Swart - MTI; jshields@ieee.org; Steven J. Dovich; Amit Kohli; vishwa.raman@gmail.com Subject: Issues resolution recommendation from VHPI Peter and Chuck, The VHPI committee which consists of : Steen Dovich Vishwa Raman John Shields Amit Kohli Francoise Martinolle came to the following resolutions: 1) vhpiCbResume callback. We would prefer that the LRM *NOT* be precise in whether or not the condition is evaluated as part of the process resumption. The reason is that lots of optimizations involve computing the condition to avoid scheduling of processes when the condition is false. We would like to define VHPI in a way that would work with optimizations. To that effect, we would like to specify the vhpiResume callback to occur at any point of time just prior the evaluation of the condition of the wait statement to up until just before the first statement after the wait statement be executed. Decision was 4 in favor of the above, 1 person was of the opinion that the callback should always occur after evaluation of the condition and before the first statement after the wait, being so precise would enable consistency of the VHPI callback across simulator vendors. 2)Execution of callbacks and VHDL processes We believe that the VHDL LRM should allow interleaved execution of processes and callbacks with relaxed ordering. The LRM text should be rewritten to refect this. Decision was unanimous. Francoise 'Received on Thu Mar 13 19:43:10 2008
This archive was generated by hypermail 2.1.8 : Thu Mar 13 2008 - 19:43:12 PDT