Sub-Directories:
demo0 - A simplest example. Two boxes of the same type send messages to each other. (Does not use ATL's PM-Lib, just basic CSIM capabilities.) This model is merely illustrative of basic concepts and does not model any real thing. demo1 - Actual performance model of 72-processor system. This model uses an old (simple) version of ATL's PM-lib models. The application is the RASSP Benchmark-4, SAR Highclass processing system. demo2 - Purely algorithmic model example. This example shows how the fledgling vector-lib models can be used under CSIM to do purely algorithmic simulation. (It does not use ATL's PM-Lib.) It shows how to use some of the graphing and image-display gadgets. demo3 - An example performance model of a fictitious 72 processor mesh-connected system, with a fictitious hierarchical application flow-graph. This model uses an old (simple) version of ATL's PM-lib models. demo4 - Another example performance model. This models a system containing >200 processors through a Raceway backplane. Uses same application flow-graph as demo3.
1. Source the setup file in this directory.
This sets the needed environment variable that tells where
the CSIM tools are.
source ~chein/csim/demo_examples/setup
2. Copy the respective demo directory to your own area.
This contains the ".sim" and perhaps ".dfg" files for the
respective demo model.
(For example, you could make a copy of all the demo's by:
mkdir /tmp/test
cp -r ~chein/csim/demo_examples/demo* /tmp/test
Then move to each demo directory:
cd /tmp/test/demo0
)
3. Invoke the GUI and open the model.
Either: gui model.sim
Or: gui
(then use file/open/open-new-file to open model.sim)
Where "model.sim" is whatever the model is called. See specifics below.
4. Peruse or edit the model. (First time, best to do nohing.)
5a. Build the simulation, by hitting Tools/Build-hw under the Tools menu.
For demo's 1, 3, and 4, which use the ATL PM-Lib and have software applications:
Build the routing table:
5b. Select Tools / Build-Routing-Table.
Schedule the DFG by:
5c. Open the DFG under the File/Open menu.
5d. Build the software under the Tools/Build-sw menu.
6. Run the simulation, by hitting Tools/Run under the Tools menu.
A simulation control panel will appear, and you can run the
simulation, change viewing options, etc.
For demo's 1, 3, and 4, which use the ATL PM-Lib, time-line histories
will be produced, and you can view them by selecting:
Tools/Proc-Timeline and Tools/Proc+Comm-Timeline.
Demo0 - The model is called: "test.sim".
Build it and run it. Text printouts from the models will appear
in your text window.
This model does not have its own explicit calls to animate
activities in the boxes or on the links, so you may want to
set box and link animation modes to use one of the built-in modes.
Select: Animation / Animation-Types / 1.Nodes-Individual-Events
and: Animation / Animation-Types / 1.Links-Individual-Events
Then you can see the boxes and links flash as the simulation runs.
Demo1 - The main hardware model is called: "arch4.sim".
(It includes the pm-lib.)
The application DFG is called: "hiclass4.dfg".
(This DFG is very simple and contains no hierarchy.)
This model does not have its own explicit calls to animate
activities on the links, so you will want to set the link
animation mode to use one of the built-in modes, select:
Animation / Animation-Types / 2.Links-Concurrent-Activities
To speed-up the animation, you can reduce the update of the
time-display by selecting:
Animation / Time-Display / Update-Once-Every-1,000-Time-Advances
You can navigate the box hierarchy to see activities down inside
individual boxes. However, you may want to flatten the hierarchy
of some or all of the boxes by selecting by clicking or dragging
a rubber-band around them so they are selected with tick-marks, and
then hitting menu: View / Flatten-Selected-Subgraphs .
Demo2 - The main model is called: "demo2.sim".
(It includes library files for the math and vector library
elements.) Build the simulation and run it. You can navigate
the hierarchy as it runs.
Demo3 - The hardware model is called: "demo3.sim".
(It contains topology and behavior descriptions all in one file.)
The application DFG is called: "demo3.dfg".
(This DFG contains hierarchy.)
Alternate variations of the basic DFG are included in files:
"demo3b.dfg" and "demo3c.dfg". These basically have more
iterations of data and produce more interesting visualizations
because the simulations driven by them run longer. But the basic
"demo3.dfg" is good for producing a simple time-line graph.
As in demo1, this model does not have its own explicit calls to animate
activities on the links, so you will want to set the link
animation mode to use one of the built-in modes, select:
Animation / Animation-Types / 2.Links-Concurrent-Activities
Demo4 - The main hardware model is called: "arch.sim".
(It includes various PM-Lib models, such as bus.sim and pe.sim
that are kept in separate files, which is actually the more
traditional way it is done on real projects).
The application DFG is called: "app1.dfg".
This model contains special calls to animate special events on
the links and in the boxes. So you do not have to change the
animation modes. The architecture was pre-flattened for
demonstration purposes, so you do not have to flatten this one.
Because of the crowded-ness of the architecture, you will want to
turn-off the port-names. Select: View / Show-Port-Names.
When the simulation first starts, the "monitor.sim" model asks a
question to the screen about what verbosity level to use.
The question appears in the text window from which you launched
the simulation or GUI. I suggest answering with zero. Higher
verbosity levels will yield copious information revealing the
details being simulated. (Sometimes very interesting.)
Explanation of link animation:
In this model of a Mercury Raceway network, the modeler
chose to show new attempts for connections through the network
by lighting links along a requested path in yellow. (They are
normally violet when unused.) If the requested path is successfully
granted, the links are turned green to indicate the presence of
data flowing through them. If the requested path cannot be
granted because of contention with another ongoing communication
on a link, the contented link will be high-lighted red to indicate
contention, the requested path will be returned to violet until
the next re-try.
As the simulation model runs, you will see the links blinking,
changing colors, data flowing, and occasional red flashes as
contentions occur. If you stop the simulation, or step through it
by a small amount, perhaps 10 or 20 time-units at a step, you can
catch individual communications being made, contented, and broken
as they complete.