RE: Process control extensions and clocked threads

Bishnupriya, All-

Here are my initial thoughts on this...

A primary goal of the new process control constructs is to unify and align
the semantics of cthreads and threads such that cthreads could, at least in
theory, be deprecated and removed from the language. (For practical reasons they
are unlikely to be deprecated).

Regarding your comment from below:

>We could allow kill/reset/throw_it/async_reset_signal_is on cthreads with some guidelines on coding
>style - essentially wait for a clock edge before executing "regular" behavior.

This is a perfectly reasonable restricton or recommendation. I believe that most/all cthread
usage out there right now follows this recommendation since the first wait() in the cthread is used
to model the reset state. So for the LRM, I think it would be fine to require this style, or say
that if this style is not followed then the behavior is unspecified.

Regarding a resume occurring on a cthread, I think I'm opposed to adding the process control
query functions you mention to work around the issue. This would mean additional complexity, and I
seriously doubt any synthesis tools would properly interpret such constructs, and this is the primary
usage of cthreads.

Instead, I suggest that we just say in the LRM that if a resume() occurs on a cthread and the invocation
of the resume() is not synchronous with respect to the clock of the target cthread then the behavior
is unspecified. If it is synchronous then the behavior is properly specified in the LRM. This seems like
a reasonable path, is potentially supportable by synthesis tools, and allows us tighten up the specification
at some point in the future if we find out that this is not a good approach.

Comments?

Thanks
Stuart

>-----Original Message-----
>From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf
>Of Bishnupriya Bhattacharya
>Sent: Tuesday, July 27, 2010 1:26 AM
>To: Philipp A. Hartmann
>Cc: john.aynsley@doulos.com; systemc-p1666-technical@eda.org
>Subject: RE: Process control extensions and clocked threads
>
>[Stuart, there is a question for you down below.]
>
>Philip,
>
>You make some good points.
>
>In my mind, it is a worthwhile objective to have equivalent behavior between a cthread sensitive to a
>clock edge, and a thread statically sensitivity to the same clock edge.
>
>Thinking more about kill, throw_it, and reset on cthreads, these are somewhat tied to the
>methodology/coding-style of how a cthread (or a thread statically sensitive to a clock edge) models
>its behavior. Conceptually kill/reset/throw_it represent exceptional circumstances that can
>legitimately make the cthread wake up asynchronously, and handle that exceptional circumstance;
>however, it should not execute "regular" behavior that is triggered by the clock edge.
>
>It works out ok if you code the cthread like below, or a similar style.
>
>void my_cthread() {
>
> // reset behavior
> ...
> while (1) {
> try {
> while (1) {
> wait(); // wait for clock edge
> // regular behavior
> ...
> } // infinite loop for regular behavior
> }
> catch (...) { // some exception has been thrown
> // handle exception and go back to waiting for clock
> ...
> }
> } // infinite loop for try-catch behavior
>}
>
>We could allow kill/reset/throw_it/async_reset_signal_is on cthreads with some guidelines on coding
>style - essentially wait for a clock edge before executing "regular" behavior.
>sync_reset_on/sync_reset_off/reset_signal_is and disable/enable make sense on cthreads anyways.
>
>That leaves suspend/resume. This is the only one that conceptually is not intended for cthreads
>(disable/enable is intended for cthreads). Also, this is the only one that really changes sensitivity
>by adding resume_event.
>
>If we disallow suspend-resume on cthreads, the perpetrator issuing the process control construct has
>to be aware whether the target is a thread or cthread, and accordingly issue suspend-resume or
>disable-enable, respectively. Does not preserve the objective that a cthread sensitive to clk edge is
>equivalent to a thread sensitive to same clk edge. The other alternative is we allow suspend-resume on
>a cthread, and put the onus on the cthread (or thread statically sensitive to clock) to do the extra
>wait() for the clock - would need to provide an API like "bool sc_process_handle::resumed()" or
>something like that - "process_control_state_t sc_process_handle::process_control_state()".
>
>Note that apart from this context, a case can be independently made for querying for the state of a
>process when it starts executing - was it reset, thrown, killed, resumed, etc, wherever it makes
>sense.
>
>I'm on the fence right now, as to which option is better.
>
>Stuart, can you comment? Should suspend-resume be an error on cthreads? If not, how does a
>cthread/thread model the fact that it does not want to execute "regular" behavior as soon as it is
>resumed?
>
>Thanks,
>-Bishnupriya
>
>-----Original Message-----
>From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
>Sent: Monday, July 26, 2010 7:58 PM
>To: Bishnupriya Bhattacharya
>Cc: john.aynsley@doulos.com; systemc-p1666-technical@eda.org
>Subject: Re: Process control extensions and clocked threads
>
>Bishnupriya, John, All,
>
>AFAIUI, the Process Control extensions are a step towards unifying threads and clocked threads (e.g.
>by adding reset semantics to threads).
> On the other hand, clocked threads are certainly intended for synthesis, which requires stricter
>semantics.
>
> For consistency reasons (and e.g. teachability), I would like to reduce the set of special cases for
>clocked threads, though. Please find some comments below.
>
>On 26/07/10 08:42, Bishnupriya Bhattacharya wrote:
>>
>> Good question about clocked threads. The intent is certainly not to
>> allow clocked threads to have regular static sensitivity in addition
>> to a single clock.
>
>Except for asynchronous resets, I agree (see below).
>
>> Is that being implied by allowing a process control construct on
>> clocked threads?
>
> When supporting sync_reset_on/off, reset, throw_it, etc., there is an implicit additional
>sensitivity (or rather triggering). IMHO, we should allow this (for simulation purposes), and the
>OSCI Synthesis WG could restrict the supported subset for synthesis.
>
>> suspend-resume can techncially apply, but the recommendation would be
>> to use disable/enable, as it is intended clocked threads only run on a
>> clock edge; is it better to make suspend-resume an error? Are there
>> any use cases where one might want to suspend/resume a clocked thread?
>> I'm inlcined to make it be an error
>
> I don't see an immediate use case for suspend/resume of clocked threads. But to me, the following
>should be as equivalent as possible:
>
>SC_THREAD(thread);
> sensitive << clk.pos();
> /* async_ */ reset_signal_is( rst, true );
>
>SC_CTHREAD(thread, clk.pos() );
> /* async_ */ reset_signal_is( rst, true );
>
> There may be common testbenches used for both higher-level and synthesisable variants, that require
>explicit control of (clocked) threads. If synthesis only supports SC_CTHREAD constructs, this would
>require additional changes.
>
>> * disable-enable certainly appleis, as these constructs were invented
>> for clocked threads only
>> * kill applies
>
>Agreed. throw_it should be supported as well (which is otherwise questionable as well).
>
>> *reset is questionable - can make the thread run in between clock
>> edges, which is not intended; should be error?
>
> I think, this is the same as with suspend/resume. I would vote for allowing this, if the user asks
>for it (since you could still use the equivalent process definition).
>
> We could consider to issue a warning, if suspend/resume/reset/kill/throw_it leads to an activation
>different from the correct clock edge.
>
>> * sync_reset_on() and sync_reset_off() applies
>> * reset_signal_is() applies; async_reset_signal_is() is not intended
>> for the same reason as reset(); error?
>
> To me, asynchronous resets of clocked threads are a valuable extension of SystemC's expressiveness.
>This should even be supportable for synthesis in most cases. Processes with asynchronous resets can
>be modelled in (synthesisable) SystemC only via SC_METHODs at the moment:
>
>SC_METHOD(method)
> sensitive
> << clk.pos()
> << rst;
>
>void method() {
> if( rst.read() == true )
> { /* reset block */ }
> else if ( clk.read() && clk.event() ) // rising_edge(clk)
> { /* main block */ }
>}
>
>Having the abstraction of implicit FSMs in SC_CTHREADs combined with asynchronous resets would be nice
>to have for synthesis. Am I missing something here?
>
> We may want to define the behaviour in case of de-asserting the reset to not trigger the process
>until the next clock edge (as ensured by the
>clk.event() check in the method example above).
>
>Thanks and greetings from Oldenburg,
>Philipp
>
>--
>Philipp A. Hartmann
>Hardware/Software Design Methodology Group
>
>OFFIS
>R&D Division Transportation | FuE-Bereich Verkehr Escherweg 2 * 26121 Oldenburg * Germany
>Phone/Fax: +49-441-9722-420/282 * PGP: 0x9161A5C0 * http://www.offis.de/
>
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.