Process Control Extensions

From: <john.aynsley@doulos.com>
Date: Wed May 05 2010 - 07:17:59 PDT

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