RE: Process Control Extensions

I believe we should not touch CTHREADs without consulting the SWG. I think there are definitely synthesis implications to that.

One thought I had is that the reset_signal_is is limited to a an sc_signal<bool> which is a very low level and design oriented view of signaling reset. To me a solution that raises the abstraction level slightly would be appealing. The use of other interfaces to signal information, such as the SignalSocket that GreenSocs has created is a higher level method of modeling these kind of interfaces and should be equally applicable for specifying reset signals. I'm not sure what the exact answer is here, but intuitively it would be nice not to just use a single bit input signal.

The notion of process priorities is interesting, and I expect that would provide a method for generating a partial order of process executions in each delta cycle (high priority before low priority). I think many may think that feature useful. However, this would have an impact on the scheduler and may increase overhead. The exact semantics need to be understood.

Best regards,

Tor Jeremiassen

---
Tor Jeremiassen, Ph.D.
Simulation and Modeling CTO
SDO Foundational Tools
Texas Instruments                    Ph:    281 274 3483
P.O. Box 1443, MS 730                Fax:   281 274 2703
Houston, TX 77251-1443               Email: tor@ti.com<mailto:tor@ti.com>
________________________________
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Wednesday, May 05, 2010 7:48 PM
To: systemc-p1666-technical@eda.org
Subject: Process Control Extensions
All,
At the last P1666 telecon, the suggestion was made that we should start considering the Process Control Extensions proposed by Cadence sooner rather than later, since this topic could be a time-consuming.
For those that are not familiar with the process control extensions, I will give a very brief overview here. The idea is to add the ability to suspend and resume processes, and also to allow a process to have several synchronous and asynchronous resets. The main new methods are:
void sc_process_handle::suspend(sc_descendant_inclusion_info include_descendants = SC_NO_DESCENDANTS );
void sc_process_handle::resume (sc_descendant_inclusion_info include_descendants = SC_NO_DESCENDANTS );
void sc_process_handle::disable(sc_descendant_inclusion_info include_descendants = SC_NO_DESCENDANTS );
void sc_process_handle::enable (sc_descendant_inclusion_info include_descendants = SC_NO_DESCENDANTS );
void sc_process_handle::kill   (sc_descendant_inclusion_info include_descendants = SC_NO_DESCENDANTS );
void sc_process_handle::reset  (sc_descendant_inclusion_info include_descendants = SC_NO_DESCENDANTS );
void sc_process_handle::sync_reset_on (sc_descendant_inclusion_info include_descendants = SC_NO_DESCENDANTS );
void sc_process_handle::sync_reset_off(sc_descendant_inclusion_info include_descendants = SC_NO_DESCENDANTS );
void sc_module::reset_signal_is      (const sc_signal<bool>& sig, bool level);
void sc_module::async_reset_signal_is(const sc_signal<bool>& sig, bool level);
template <typename T>
void sc_process_handle::throw_it(const T& user_defined_exception,
                                 sc_descendant_inclusion_info include_descendants = C_NO_DESCENDANTS);
The difference between suspend/resume and disable/enable is that resume will cause a process to resume if an event (or timeout) to which it is sensitive occurred while it was suspended, whereas following enable a process will always wait for the next trigger before resuming.
The difference between kill and reset is that following kill a process can never run again, whereas reset causes a process to execute again from the beginning.
The reset semantics are generalized to work with thread as well as clocked thread processes, making SC_CTHREAD redundant.
Issues/Questions
* Should we now deprecate SC_CTHREAD or keep SC_CTHREAD as a first-class feature of SystemC, or something else?
* Should we invite input from the members of the OSCI Synthesis WG on the subject of clocked threads and synchronous and asynchronous resets?
* ST (Jerome) has proposed that we add process priorities. Does this P1666 WG wish to pursue that proposal? If so, how do process priorities interact with the process control extensions?
* Is include_descendants intended to find descendents of intermediate processes that have already terminated, i.e. children of dead children?
* Do we need to try out these ideas in a proof-of-concept implementation, particularly given that the process control extensions are already (at least partially) implemented in the OSCI POC simulator? I will volunteer to create a set of regression tests.
John A
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.