Re: terminated_event()

I think one good application of the reset_event is for verification. If a reset is issued, a monitor may need to be made aware of this (e.g. functional coverage). This could also be useful for EDA tools that want to let the user know on a GUI to aid debug and awareness.

------------------------------------------------------
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 29, 2010, at 3:05 AM, john.aynsley@doulos.com wrote:

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

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