Re: Process Control Extensions

John and all,

I write our opinions and comments about the issues/questions in the
following citation:

At 05 May 2010 15:17:59 +0100 john.aynsley@doulos.com wrote:
> 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:

[snip]

>
> Issues/Questions
>
> * Should we now deprecate SC_CTHREAD or keep SC_CTHREAD as a first-class
> feature of SystemC, or something else?

SC_CTHREAD should be kept as the first-class feature:
  - We already have many models in which SC_CTHREAD are used.
  - Almost all behavior-synthesis tools can synthesize only SC_CTHREAD.
    We should discuss on this issue with OSCI Synthesis WG.
  - We can model the clocked module with SC_THREAD. Because we may need
    to define a coding style to make clear a module whether it is
    clocked or not, which signal/port is clock, and so on, a syntax,
    like SC_CTHREAD, to define a clocked module is desirable.

We, also, would like to use reset_signal_is and async_reset_signal_is
with SC_CTHREAD. And we'd like to set multiple
reset_signal_is/async_reset_signal_is to one process.

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

Yes. These issues are related with Synthesis WG.

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

Our opinion is "yes" if it does not change the current behavior of
models nor have overhead on the simulation speed even when we do not
use the process priorities.

>
> * Is include_descendants intended to find descendents of intermediate
> processes that have already terminated, i.e. children of dead children?
>
> * 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.

Yes, we need to try out these ideas. We really appreciate your offer.

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

Best regards,
Hiroshi Imai
Chair of SystemC WG, JEITA (http://www.jeita-edatc.com)

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