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.