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