RE: Process Control Extensions

John,

Excellent summary of the proposal.

Comments below.

Thanks,
-Bishnupriya

________________________________
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?
[bpriya> Agree with Stuart - say something in the LRM of the nature that SC_CTHREAD may be deprecated in the future]

* Should we invite input from the members of the OSCI Synthesis WG on the subject of clocked threads and synchronous and asynchronous resets?
[bpriya> yes]

* 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?
[bpriya> About whether process priorioties should be included, I'm ok as long as it does not MANDATE that an implementation has to change its scheduler (which it does not, as Jerome has expained).

About the interaction between process priorities and process control extensions, in its current form the process priorities proposal is orthogonal to the process control extensions. The original process control proposal also had RTOS scheduler modeling in its scope, which was later weaned out as it was felt it wasn't there yet. Conceivably, process priorities might have interacted with RTOS scheduler modeling constructs; in its current form there is no interaction.]

* Is include_descendants intended to find descendents of intermediate processes that have already terminated, i.e. children of dead children?
[bpriya> yes, it is. Note that the process on which the construct is being called can itself be terminated, then the construct applies to its descendants - the same logic holds for an intermediate process in the sub-hierarchy that has terminated.]

* 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.

 [bpriya> It will be great to have the resgression suite. Thanks!]

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.