The execution of multiple application graphs is coordinated and initiated through a hierarchical control process. To the application programmer, this is specified through a STIM.file and various DFG graph files. The STIM.file lists the sequence of DFGs to be run, while the DFG files list the application tasks, their data dependencies, and the mapping of tasks to processor elements. In the static mode, prior to running the simulation, the user invokes the scheduling tool to process the STIM.file which produces a set of program files that are interpreted by the model during simulation execution.

The STIM.file serves as the master control file for the modeled system. With it, you can specify the control actions of several parallel controllers. The STIM.file represents the highest level of the control hierarchy, as depicted in figure B1.

Figure B1 - Control Hierarchy.

The DFG syntax and the scheduler tool were extended from the basic scheduler that was intended for single flow graph environments. The STIM_SCHEDULER variant described here is intended for multiple flow graph scenarios. The STIM.file, DFG file formats, and scheduler tool usage are described in the following sections B-1 and B2 respectively.

Section B-1: The STIM File Format

1. DFG file binding,
   (List of DFG files to use.)
2. DFG execution sequence list.
   (Sets order and time of flow-graph execution.)

An example STIM.file appears below:

	/************************************/
	/* Part 1 -			    */
	/* Master STIM file for XYZ system. */
	/* DFG file        Program file	    */
	/************************************/

	clrsrch.dfg
	trkmode.dfg


	/************************************/
	/* Part 2 -			    */
	/* DFG invocations.		    */
	/************************************/

        START
 	 /* macro x=y  or  monotonic dt  or  dfg-name  or  delay dt */
	 CLRSRCH
	 TRACK_a
	 delay 100.3
	 CLRSRCH
	 delay 10
	 TRACK_a
	 delay 10
	 TRACK_a
	 delay 20
	 TRACK_a
	 CLRSRCH
        DONE

The second section of the STIM.file must begin with the keyword START. The remaining section lists the order in which the flow-graphs should be initiated.

To control the time of initiating new graph executions, delay and monotonic delay commands may be interspaced between the DFG names in the second section.
Example:

	 CLRSRCH
         monotonic     7000
         TRACK_a

Section B-2: Scheduler Usage

        sched  -stim  STIM.file  netinfo

By default, the static-STIM-Scheduler now distributes the program commands into separate files, one for each PE. To instead combine the program instructions into a common file (to support older models), use the -nd command line option. (Stands for no distribute.)

Figure B2 - Software generation process.

Note-1: You cannot use the generic_pe.sim model with .prog-files from the STIM-Scheduler. Instead, the static STIM-Scheduler must be used with the PE model core_models/multi_task_pe.sim; not the simple generic PE models.

Note-2: The static STIM-scheduler does not look at anything past START in your STIM-file. Instead, it generates programs for the DFG files listed above START, -- and then the special PE models look at the second section of your STIM-FILE to actually start the respective dfg/programs.

The special PE models look at the second section of your STIM file to actually start the respective dfg/programs. The models assume the default STIM file to be named stim_file and located in the current directory. To use another file name or directory, a special environment variable named PMOD_STIM is to be used, as in:
        setenv PMOD_STIM <full_path_name>/file_name

DYNAMIC STIM_SCHEDULER

#define STIM 0

#define STIM 1

The dynamic STIM-scheduler uses a newer STIM-file format from that of the Static STIM Scheduler described above. It does not use a two-part STIM-file. Rather, it expects DFG file-names only, with optional delays between them (delay xx). It is based on the assumption that you have one top-level DFG graph per file, (now the modern norm).

Example STIM.file for DYNAMIC STIM-SCHEDULER:

	xyz1.dfg
	qrst.dfg
	delay 45.9
	wxy.dfg
	xyz1.dat
	DONE
etc..


When using the Dynamic STIM Scheduler, you must use generic_pe.sim,
NOT multi-task-pe.sim !!!

This is because the multi-task-pe.sim does not support the Dynamic
case, and with the Dynamic case, the generic_pe supports both
non-STIM and STIM cases.  Please see Table-1 below for the allowable
combinations of models and typical usage of the Scheduler variants.

First, you should realize that the Dynamic Scheduler does not store *any* program files. Dynamic means that it is active at simulation run-time; not static as in the case where the Scheduler is run a priori or off-line.

The Dynamic Scheduler sends program instructions directly to the PE's through the ether using command-queues on each processor model.

Second, you should not run the (normal) Static Scheduler (Sched) when you are using the Dynamic Scheduler. The Dynamic Scheduler is an alternative to the Static Scheduler.

In the Dynamic Scheduler case, you do not schedule as separate step, like you normally might with the static scheduler. This is because the Dynamic Scheduler runs inside the simulation, and during the simulation, not before.

Therefore, you must give the Dynamic Sched it's arguments on the sim.exe command line.

Example:
        sim.exe -stim STIM.file netinfo

(Note, you cannot use the default commands issued by GUI/Tools menu.
 Instead, give them explicitly from the command line, or use the
 GUI/Tools/Modify-Command method, or modify the scheduler command
 in your gui_setups file.  Dynamic-Scheduler is not the default.)

(Questions, Comments, & Suggestions: admin@csim.com)