RE: terminated_event()

Good question, Eric. My motivation for suggesting reset_event in the first
place was purely for consistency with terminated_event. A kill notifies a
terminated_event, so why should not a reset notify a reset_event? On the
other hand, although I can see that a process may need to wait for another
process to terminate, I cannot see why a process should need to execute
immediately after another process has been reset. Any reset-handling code
could/should be executed when catching the sc_unwind_exception.

John A

From:
"Roesler, Eric E" <eric.e.roesler@intel.com>
To:
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
28/09/2010 17:32
Subject:
RE: terminated_event()
Sent by:
owner-systemc-p1666-technical@eda.org

Hi,
 
I?ve been following the discussion on the process control extensions for a
few months now, and I think I understand the API itself. I have yet to
understand how they might be used in a real model. Can anyone throw out a
brief example (use case) of how, for example, this reset_event might be
used?
 
Thanks,
 
EricR
 
 

From: owner-systemc-p1666-technical@eda.org [
mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of David C Black
Sent: Monday, September 27, 2010 10:34 AM
To: john.aynsley@doulos.com
Cc: systemc-p1666-technical@eda.org
Subject: Re: terminated_event()
 
I believe this is very much appropriate.
 
------------------------------------------------------
David C Black, XtremeEDA ESL Practice Leader
http://www.Xtreme-EDA.com
(Consulting, Services & Training for all your ESL, verification and DFT
needs)
Voice: 512.850.4322 Skype:dcblack FAX: 888.467.4609
 
On Sep 27, 2010, at 8:39 AM, john.aynsley@doulos.com wrote:

All,

Bishnupriya and I have suggested that we add a const sc_event&
reset_event() const; similar to terminated_event. This would allow a
process to make itself sensitive to another process being reset. What does
everyone think. Is this a good idea or is it just an unnecessary overhead?

Thanks,

John A

From:
Bishnupriya Bhattacharya <bpriya@cadence.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>, "
systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
20/09/2010 07:16
Subject:
RE: terminated_event()
 

John,
  
yes, kill() notifies the terminated_event of the process, both for thread
and method.
  
Re adding reset_event(): the semantics are - for asynchronous reset(), it
triggers when proc_handle.reset() is issued, for synchronous reset, it
kicks in when effective sensitivity of the process triggers and it is
reset. The timing of the triggering happens during the resetting of the
process, but the effect (e.g. if any proces is sensitive to reset_event())
is only visible after target process has run from beginning and yielded.

  
This is fine with with me and IMO is a good idea. One subtle side effect -
if a process is reset() before sim start, the current semantics says there
is no effect on the process. That might now need changing to say - the
first time the process executes, it will be reset, but the only visible
effect will be that the reset_event() gets notified.
  
Thanks,
-Bishnupriya

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Friday, September 17, 2010 5:06 PM
To: Bishnupriya Bhattacharya; systemc-p1666-technical@eda.org
Subject: terminated_event()

Bishnipriya, All,

sc_process_handle::kill does notify the terminated_event for the
underlying process instance, right? In which case, should we consider
adding a reset_event that is notified whenever reset() is called,
explicitly or implicitly?

Thanks,

John A

-- 
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. 
-- 
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.