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.