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.Received on Fri Sep 3 03:28:01 2010
This archive was generated by hypermail 2.1.8 : Fri Sep 03 2010 - 03:28:01 PDT