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.