Re: async_reset_signal_is

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.