Re: Process Control Extensions

John, all

reply in the text below:

Jerome

On 5/7/2010 12:59 PM, john.aynsley@doulos.com wrote:
> All,
>
> Does anyone have any specific objections or counter-proposals
> concerning the Process Control Extensions, or is everyone positive
> about them as they stand? (Of course, I am not trying to rule out any
> improvements or clarifications as we refine the spec.)

No objections on ST side for the Process Control Extensions. We do
believe this is an important contribution to the standard.

> How about ST's proposal for process priorities as hints? Adding actual
> process priorities to SystemC would seem to be a radical change that
> would impact the scheduler, process control, and might introduce the
> possibility of new use models. On the other hand, ST's proposal is
> only for "hints", in which case, do we want to change the IEEE
> standard "merely" to incorporate scheduler optimization hints?

Indeed, this calls for clarifications.

Our proposal of process priorities is not a proposal of a new scheme for
programming with processes. In our opinion,
this would be rather dangerous, as the programmer would have to keep in
mind tte various process priorities to understand
how its simulation would behave (and this would be the opposite of what
is proposed in the Process Control Extensions, where
the added features integrate nicely on top of the existing).

So, actually we propose process priorities as "hints" that the user
model can give to the simulator on whether executing a given
process is a priority. The simulator is free to ignore these hints so
the semantics of execution of processes is unchanged, and the programmer
is not messed up. However, if the simulator is "hint" aware, the
simulation performance can be significantly optimized.

Let me give an example: imagine the SystemC simulation has to
communicate with "the external world".
One may take "an external hardware emulator" as a good example of
"external world".

Assume the interaction with the external world require to send data to
it, then receives feedback from it (imagine an IP
mapped on a hardware emulator to compute something in response to
incoming data, and that return the result of the
computation). If we perform the interaction in a naive way, we will,
inside a SystemC process, send the data to the external
world, then wait for the result. In this case the SystemC simulation is
blocked until the interaction is finished, and as you guess this is
rather inefficient. A more efficient way of doing the interaction would
be to decouple the interaction into "sending data to the external
world" and "getting back the result", which would allow to do something
else in SystemC in between.

Now, imagine that, at a given simulation time, we have got many things
to do in SystemC (i.e. many SystemC processes runnable), in addition
to perform interactions with the external world. If we are lucky,
SystemC will execute the process that is sending the data to the
external world, then we will execute the other processes, then we will
execute the process that receives the result. But if
we are not so lucky, SystemC will execute first all the processes that
are not related to the interaction, and at the end of the simulation
time it will execute the processes responsible for the interaction with
the external world. The simulation will then be blocked until the
interaction
is completed, which is not efficient.

With priority, it would be possible for processes responsible for the
interaction with the external world to signal themselves as
process with more priority than others. A priority-aware simulator would
execute these processes first, resulting in increased performance.
The good point is that an non-aware simulator would execute correctly as
well, although less efficiently.

So we are not talking about optimization of the scheduler implementation
here, which could rather be implemented without
modifying the norm. We are talking about optimizing *the simulation*
itself, by putting a missing bridge between the simulation
and the user code.

Hopes this will have clarified ST proposal on this topic.

Meanwhile, we have scaled back our proposal on 'simulator' callbacks,
because this is quite tedious to implement in an efficient manner .
I will do the proposition next week, I can say that this is
complimentary to Mentor's proposal, and has also to do with communication
with the external world.

Regards,

Jerome

>
> Thanks,
>
> John A
>
>
> -----Stuart Swan <stuart@cadence.com> wrote: -----
>
> To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>,
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> From: Stuart Swan <stuart@cadence.com>
> Date: 05/06/2010 10:05PM
> Subject: RE: Process Control Extensions
>
> John-
>
> Some quick answers embedded below to your questions..
>
> Thanks
>
> Stuart
>
> *From:* owner-systemc-p1666-technical@eda.org
> [mailto:owner-systemc-p1666-technical@eda.org] *On Behalf Of
> *john.aynsley@doulos.com
> *Sent:* Wednesday, May 05, 2010 7:18 AM
> *To:* systemc-p1666-technical@eda.org
> *Subject:* Process Control Extensions
>
> *Issues/Questions*
>
> * Should we now deprecate SC_CTHREAD or keep SC_CTHREAD as a
> first-class feature of SystemC, or something else?
>
> SC_CTHREAD has been around for so long that it won’t go away
> anytime soon. One option is to say something in the LRM such as
> “SC_CTHREAD
>
> is now redundant since all of its features are now available with
> SC_THREAD, so SC_CTHREAD may be deprecated and removed from the
> standard
>
> at some point in the future.”
>
>
> * Should we invite input from the members of the OSCI Synthesis WG
> on the subject of clocked threads and synchronous and asynchronous
> resets?
>
> * 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?
>
> If I understood Jerome’s proposal, the priorities are just “hints”
> and can always be ignored. So it seems to me one option is to say
> that from the perspective
>
> of the process control extensions, the priorities have no
> implications on the standard.
>
>
> * Is include_descendants intended to find descendents of
> intermediate processes that have already terminated, i.e. children
> of dead children?
>
> I think it is supposed to get them all, Bishnupriya needs to confirm.
>
>
> * 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.
>
> We accept your offer! Having such openly available tests will be
> very helpful in getting the features implemented properly in all
> simulators.
>
> We have donated some tests for process control constructs to OSCI.
> More tests are clearly needed. We have also implemented all of the
> constructs
>
> in our simulator and will run any tests that people offer against
> our implementation and provide the log results.
>
>
>
> John A
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>,
> and is
> believed to be clean.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

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