Re: Process Control Extensions

Tor, all,

sorry, my explanation was lacking real-world numbers which I will fix
right away.
So, I will take again the example of a SystemC TLM platform interacting
with an IP mapped on
a hardware emulator. We have many such platforms at ST. Let us consider
the following scenario:
the system produces images in loop. To do this it depends on results
computed by the IP mapped on
the emulator, as well as computations performed by the embedded software
itself. In other words,
the embedded software "delegates" part of the computation to the IP in
the emulator, then perform
its own duties.
It takes some time for the hardware IP to perform its computation and
send back the result. In our
typical case, we are at around 1 fps (depends on the frame resolution).
And on the embedded software front, we are now running into situations
where the embedded software
execution itself takes more and more time. All in one, this results in
increased workstation time taken
to complete an evaluation phase of the scheduler (as the main process
executing the embedded software
is taking more and more time). In some situations, the evaluation phase
takes more than one second (1.6
to be precise).
The result of the benchmark really depends on the process order
execution chosen by the scheduler, and may change
if you add other processes in the loop. But it is obvious that we have
to prioritize the processes that will result
in the IP on emulator starting its computations, as the sooner it will
start the better. The worst case is if the emulator
starts at the end of the evaluation phase, as we then add 1 second of
penalty waiting for the result. With the numbers
I given that is one second in addition to 1.6 already taken by the
SystemC simulation. So in this example we can gain
  (or lose depending on which side you look at it) up to 62 % percent
per evaluation phase. Process priorities ensures
that you will never lose anything, whatever the process execution order
is, and provided you have got a "priority-aware"
simulator.

I have focused here on the hardware emulator example, but there is room
to exploit this feature in many other
situations.

Regards,

Jerome

On 5/8/2010 5:43 AM, Jeremiassen, Tor wrote:
>
> I'm not going to oppose this, but has ST done any benchmarking with
> respect to the utility of such a proposal? It would be good to have
> some quantitative idea of the possible performance benefit before
> making it part of the standard.
>
> Best regards,
>
> Tor Jerermiassen
>
> ---
> Tor Jeremiassen, Ph.D.
> Simulation and Modeling CTO
> SDO Foundational Tools
> Texas Instruments Ph: 281 274 3483
> P.O. Box 1443, MS 730 Fax: 281 274 2703
> Houston, TX 77251-1443 Email: tor@ti.com <mailto:tor@ti.com>
>
> ------------------------------------------------------------------------
>
> *From:* owner-systemc-p1666-technical@eda.org
> [mailto:owner-systemc-p1666-technical@eda.org] *On Behalf Of *Stuart Swan
> *Sent:* Friday, May 07, 2010 11:58 PM
> *To:* john.aynsley@doulos.com; systemc-p1666-technical@eda.org
> *Subject:* RE: Process Control Extensions
>
> John, All-
>
> I think I'm in favor of the process priority "hints", as long as it is
> absolutely clear in the standard that they are just
>
> hints and that a compliant implementation is always free to ignore them.
>
> Thanks
>
> Stuart
>
> *From:* owner-systemc-p1666-technical@eda.org
> [mailto:owner-systemc-p1666-technical@eda.org] *On Behalf Of
> *john.aynsley@doulos.com
> *Sent:* Friday, May 07, 2010 4:00 AM
> *To:* systemc-p1666-technical@eda.org
> *Subject:* RE: Process Control Extensions
>
> 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.)
>
> 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?
>
> 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* <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.