ISAC: [Fwd: Issues resolution recommendation from VHPI]

From: Chuck Swart - MTI <cswart_at_.....>
Date: Thu Mar 13 2008 - 19:37:29 PDT
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:


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:
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 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,
 
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:


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:
Message
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:


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