Re: Process Control Extensions

Thank you for the clarification. I now understand why, and I think your
points are valid. I will be fully in favor of your proposition given the
explanation.

On Fri, May 7, 2010 at 10:38 AM, Jerome CORNET <jerome.cornet@st.com> wrote:

> 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> <stuart@cadence.com> wrote: -----
>
> To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>
> <john.aynsley@doulos.com> <john.aynsley@doulos.com>,
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> <systemc-p1666-technical@eda.org> <systemc-p1666-technical@eda.org>
> From: Stuart Swan <stuart@cadence.com> <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<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* <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.