Re: Process Control Extensions

Well, I agree with your analysis. I'm guessing that everybody in this WG
wants to retain the current SystemC semantics of having nondeterministic
process execution order during the evaluation phase. Neither your idea of
optimization hints nor the suggestion of randomization breaks this;
randomization actually emphasizes it!

I suppose one could argue that randomization should be a tool feature and
should not be present in the SystemC API. The ability to randomize process
execution order would be a nice feature in any SystemC simulator.
Similarly, a command to actually use the process priority hints should be
a tool feature, not in the API.

I guess I am arguing for your first option: set the process priorities
through the SystemC API, and that's all.

The current LRM says "The order in which process instances are selected
from the set of runnable processes is implementation-defined. However, if
a specific version of a specific implementation runs a specific
application using a specific input data set, the order of process
execution shall not vary from run to run.". Perhaps we should review this
to explicitly allow for priority hints and for randomization; you might
WANT the execution order to vary from run-to-run, either by setting a
randomization seed or by switching priorities on/off.

John A

From:
Jerome CORNET <jerome.cornet@st.com>
To:
john.aynsley@doulos.com
Cc:
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
14/05/2010 14:41
Subject:
Re: Process Control Extensions

John,

ok, I guess that now we arrives in dangerous territory, and this is the
limitation of using priority hints for testing process order.

For testing process order, you need to "rely" on the scheduler actually
implementing the priorities, because no one would want to do such testing
on a non-priority aware scheduler (as that would be useless).

And so comes this need for a priority_implemented() function.
But in which situations should this function return true?

We can have a loose definition which would say:

priority_implemented() will return true if the simulator "tries" to to
execute before
process with higher priority (but there is not formal guarantee),

or a more formal "hard" definition:

priority_implemented() will return true if the simulator executes in each
delta
cycle the processes in the order of decreasing priorities.

The risk of the latter option is that people may write programs that could
refuse to execute
if the scheduler is not priority aware, and that may then completely rely
on the priority
for correct execution of their program.
And then we have transformed the priorities "hints" into elements to can
be used
by the programmer.

So to me, either:

- we don't highlight the possible use of priorities for testing bugs
linked to process
ordering, and we don't have to provide any stuff related to randomization,

or

- we tell people that it is possible to do some variations on the process
order by using
random process priorities, we add randomization related stuff, and the
priority_implemented()
function (or maybe is_priority_aware() or something) but we voluntarily
tell the user that no
strong formal ordering is guaranteed by the implementation even if the
function returns true.

What do you think?

Jerome

On 5/14/2010 3:09 PM, john.aynsley@doulos.com wrote:
Jerome,

Right. So regardless of whether we add any features for randomization or
repeatable randomization, it sounds like we might benefit from adding:

bool priority_implemented() const;

???

John A

From:
Jerome CORNET <jerome.cornet@st.com>
To:
john.aynsley@doulos.com
Cc:
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
14/05/2010 13:23
Subject:
Re: Process Control Extensions

Hi John,

good point!
Indeed, exploring the various possible process execution orders allows to
discover bugs both in the platform synchronization
and in the embedded software (in the TLM case). I did not push for this
usage as we have other means of testing this (with full
coverage, which randomization does not guarantee), but clearly it could
anyway be a benefit (rather than always getting the same process order).
However, we have to be careful with allowing a reproducible randomization
from one run to the other. I would default to "same process
order" by default, and add an option (command line, for instance) to
change the random seed.
The other problem in using this feature for testing is to know whether the
simulator is priority-aware or not, else testing
with different random priorities is obviously useless.

Jerome

On 5/14/2010 1:23 PM, john.aynsley@doulos.com wrote:
Jerome,

Does ST foresee the process priority hint being used as a way to produce
pseudo-random process execution order within an evaluation phase as a way
of improving test case coverage? If this were the case then a simulator
that supports the "priority hint" would have superior capability going
beyond mere simulation speed.

I don't see a problem with this. We could even add a set_priority_random()
!

John A

From:
Jerome CORNET <jerome.cornet@st.com>
To:
"Jeremiassen, Tor" <tor@ti.com>
Cc:
Stuart Swan <stuart@cadence.com>, "john.aynsley@doulos.com"
<john.aynsley@doulos.com>, "systemc-p1666-technical@eda.org"
<systemc-p1666-technical@eda.org>
Date:
11/05/2010 09:19
Subject:
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 
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, and is 
believed to be clean. 
-- 
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. 
-- 
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.