Re: async_reset_signal_is

John,

Your explanation help me to understand. It looks ok to me.

Thanks,
Hiroshi Imai

At 07 Sep 2010 10:52:11 +0100 john.aynsley@doulos.com wrote:
> Hiroshi San,
>
> I think the specific answer to your question is (1), yes.
>
> "Reset the sensitivity" refers to the behavior of the "immediate reset" as
> performed by the reset() method of sc_process_handle and when the reset
> signal specified by asynch_reset_signal_is gets asserted. This involves
>
> - Removing any dynamic sensitivity associated with the method process
> (which could only have been created by a previous call to next_trigger)
> - Restoring the static sensitivity of the method process (as specified
> using sensitive << or async_reset_signal_is)
>
> In other words, the only effect of reset() or async_reset_signal_is for a
> method process would be to undo the effect of a next_trigger() on that
> method process, and as such it is probably irrelevant to synthesis anyway.
>
> Hope this helps,
>
> John A
>
>
>
>
> From:
> Hiroshi Imai <hiroshi3.imai@toshiba.co.jp>
> To:
> john.aynsley@doulos.com
> Cc:
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>,
> Bishnupriya Bhattacharya <bpriya@cadence.com>
> Date:
> 07/09/2010 01:44
> Subject:
> Re: async_reset_signal_is
>
>
>
> John,
>
> I don't understand what "reset the sensitivity" exactly means. In the
> current SystemC, a reset on SC_THREAD or SC_CTHREAD changes values of
> signals. Then their changes start SC_METHOD which has those signals as
> sensitivity. Are these behavior the same?
>
> (1) If yes, I'd like to know the purpose to set reset_signal_is or
> async_reset_signal on SC_METHOD.
>
> (2) If no, could you tell me the difference? From the behavioral
> synthesis view, I'm wondering that its semantics has difficulty in
> synthesizing it.
>
> Hiroshi Imai
> Chair of SystemC WG, JEITA
>
> At 06 Sep 2010 13:18:14 +0100 john.aynsley@doulos.com wrote:
> > Bishnupriya,
> >
> > I think we should do this, i.e. make reset_signal_is and
> > async_reset_signal legal for method processes. In either case the effect
>
> > would be to "reset the sensitivity" only, because there cannot be any
> call
> > stack to unwind.
> >
> > This approach seems consistent with allowing sync_reset_on and throw_it
> on
> > method processes.
> >
> > Is everyone okay with that?
> >
> > John A
> >
> >
> >
> >
> > From:
> > Bishnupriya Bhattacharya <bpriya@cadence.com>
> > To:
> > "john.aynsley@doulos.com" <john.aynsley@doulos.com>
> > Cc:
> > "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> > Date:
> > 03/09/2010 11:27
> > Subject:
> > RE: async_reset_signal_is
> >
> >
> >
> > John,
> >
> > This has a historical reason. Originally, reset_signal_is() and
> > async_reset_signal_is() were not a part of the core constructs, and
> these
> > could achieve their functionality using the core constructs.
> > reset_signal_is() built upon sync_reset_on()/sync_reset_off(). Since the
>
> > latter is not allowed in methods, reset_signal_is() is also not allowed
> on
> > methods. async_reset_signal_is() built upon a combination of
> > reset()+sync_reset_on()/sync_reset_off(). Since reset() is allowed on
> > methods, async_reset_signal_is() is also allowed on methods.
> >
> > Subsequently, based on Andy Goodrich's input, it was decided that
> implicit
> > resets (via reset_signal_is() and async_reset_signal_is()) also have to
> be
> > made a part of the core constructs so that when sync_reset_off() is
> > specified on a process, it does not go back to a normal state if
> implicit
> > resets are still active on it.
> >
> > I'm ok with making reset_signal_is() legal on a method process, and have
>
> > the semantics same as that of reset() and async_reset_signal_is() - i.e.
>
> > cancel any dynamic sensitivity on the method, and restore its static
> > sensitivity. This is what you are proposing, right?
> >
> > Thanks,
> > -Bishnupriya
> >
> > From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> > Sent: Thursday, September 02, 2010 10:04 PM
> > To: Bishnupriya Bhattacharya; systemc-p1666-technical@eda.org
> > Subject: async_reset_signal_is
> >
> > Bishnupriya,
> >
> > It's me again ;-)
> >
> > Why is calling reset_signal_is for a method process an error, while
> > async_reset_signal_is is permitted? I don't get it.
> >
> > async_reset_signal_is specifies a signal and signals have delta cycle
> > semantics, so even if the method process itself writes to that signal,
> it
> > would not have any effect beyond resetting the sensitivity. But in that
> > respect, both reset_signal_is and async_reset_signal_is would cancel any
>
> > dynamic sensitivity and restore the static sensitivity, so why is only
> > async_ permitted?
> >
> > 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.