EECS 221 Assignment 4: Monte Carlo example
------------------------------------------

As discussed in Friday's class, we will use the Monte Carlo
example for further experiments towards software synthesis.
Please find Friday's example on the 'epsilon.eecs.uci.edu'
server: /home/doemer/EECS221_F06/mc.sc

To prepare this example for synthesis and execution on the
ARM ISS, a couple of improvements are still necessary:

1 insert messages such as "Behavior XXX starting..." and
  "Behavior XXX waiting for data..." into the source code
  such that the actual execution and scheduling order becomes
  observable in the output

2 for SCE to work, you also need to introduce a new level
  of hierarchy, i.e. a behavior "design" or "SWroot" that
  can be set as the top-level of the design. At least one more
  level of hierarchy is necessary, more levels are possible
  as well

3 another useful improvement would be a defined program
  ending, e.g. when 3.14 is reached; this could easily
  be inserted as a conditional 'exit(0)' call in the
  behavior ApproxPi; that way, no manual abortion through
  CTRL-C is not necessary any more.
  Please note, however, that such an 'exit()' call may lead
  to trouble when running the code on the ARM ISS because
  in the embedded world, there is no exit! ;-)
  I'm actually not sure what will happen, but you may want
  to find out...
  One safe way of exiting the simulation is implemented in
  the task example that we have used earlier; here, when the
  SW wants to end, it sends a handshake signal to the hardware
  component in the system; that hardware component will not
  be synthesized so will still run as a SpecC behavior
  and therefore has no problem calling 'exit()' on behalf of
  the software in the simulation

After these preparations (the last step is optional), the
example should be ready for synthesis. Please try to follow
the steps outlined earlier for the tasks example;
for the scheduling portions, you may want to experiment with
different settings (static/dynamic scheduling) and parameters
(i.e. priorities).

One goal to optimize could be minimal number of context
switches; try to assign priorities such that the scheduler
performs the least number of task switches; you may want to
change the depth of the queues (currently 10) as well, or even
use different styles of communication between the blocks
in order to achieve that.

To see how far this experiment is successful (and where the
problems lie), I ask for the following deliverable:
Describe the steps you took and the problems you encountered
in a brief (about 10 sentences max!) text and send it to
me by email before Friday morning (so that I have a chance
to read it before the next class).

We will discuss any problems then in class and decide how to
proceed with this experiment. Good luck!

--
Rainer Doemer (ET 444C, x4-9007, doemer@uci.edu)