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, and is believed to be clean.Received on Wed May 5 07:18:25 2010
This archive was generated by hypermail 2.1.8 : Wed May 05 2010 - 07:18:27 PDT