RE: Process control extensions and clocked threads

All,

As I understand it, the conclusion from this "thread" is that the
following are all to be allowed for clocked threads:

* suspend-resume
* disable-enable
* kill
* reset
* sync_reset_on/sync_reset_off
* reset_signal_is
* async_reset_signal_is

but with the caveat that in the case of

* suspend-resume
* kill
* reset
* async_reset_signal_is

the LRM will impose certain constraints on the coding style. Is that
right? Would someone care to spell out what these coding constraints are?
Or should the LRM just contain some vague catch-all wording that the user
is responsible for handing the synchronization issues, or that things have
been deliberately left open for future standardisation?

Thanks,

John A

From:
Bishnupriya Bhattacharya <bpriya@cadence.com>
To:
Stuart Swan <stuart@cadence.com>, "Philipp A. Hartmann"
<philipp.hartmann@offis.de>
Cc:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>,
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
28/07/2010 10:07
Subject:
RE: Process control extensions and clocked threads

Stuart,

I can live with this.

Essentially, for suspend-resume we are saying the onus is on the
perpetrator to know if the target thread is a clocked thread (either
cthread or thread statcially sensitive to clock edge), and choose to
either

1) issue disable/enable instead of suspend/resume or
2) issue suspend/resume but make sure to synchronize on same clock edge as
the target before issuing the resume - i.e. wait for the clock edge and
then issue resume()

Thanks,
-Bishnupriya

-----Original Message-----
From: Stuart Swan
Sent: Tuesday, July 27, 2010 11:27 PM
To: Bishnupriya Bhattacharya; Philipp A. Hartmann
Cc: john.aynsley@doulos.com; systemc-p1666-technical@eda.org
Subject: 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.