Appendix B - STIM_SCHEDULER

Appendix B - STIM_SCHEDULER


The STIM_SCHEDULER variant of the basic scheduler is intended for systems requiring multiple application flow graphs. Each top-level DFG is characterized as an independent graph having one START node and one END node. The static STIM_SCHEDULER compiles the multiple independent graphs into a common program file, and it orchestrates the initiation of specific graphs at specific times. The dynamic STIM_SCHEDULER also orchestrates the execution of multiple graphs at specific times, but without intervening program files.

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

The format of the STIM.file consists of two parts:
  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 first section names the DFG file names containing the DFGs you have defined.

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
This example would cause the TRACK_a DFG to be started 7,000-uS after the CLRSRCH DFG was initiated.


Section B-2: Scheduler Usage

First you should prepare a STIM.file and the DFG files that it refers to. You can name the STIM.file, DFGs, and their files anything you want, but the conventions shown here are common. If you process your hardware architecture file through CSIM to produce a netinfo file, this gives the scheduler additional information about the architecture for making better mapping decisions. Then invoke the scheduler with:
        sched  -stim  STIM.file  netinfo
The scheduler will then build the requested program files. If there are flow- graph errors, such as dead-locks or unused data left on arcs at graph completion, it will attempt to give you a detailed analysis of the state of all nodes and arcs in the graph. Figure B2 depicts the software generation process.

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

To use the DYNAMIC SCHEDULER in STIM mode, simply include the Dynamic Scheduler model before any PE models. This changes:
#define STIM 0
Change the setting to 1:
#define STIM 1
Then rebuild your hardware model.

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.

.
Table 1 - Summary of Scheduler Variants.
Single Graph Mulitple Graph (STIM)
Static
(Pre-Sim)
*Default Scheduler --

"Static normal" - use generic_pe.sim

Typical usage:
        sched sw.dfg netinfo
        sim.exe

(variant)

"Static w/STIM" - use multi_task_pe.sim

Typical usage:
        sched -stim STIM.file netinfo
        sim.exe

Dynamic
(During Sim)
(variant)

"Dynamic normal" - use generic_pe.sim

Typical usage:
        sim.exe sw.dfg netinfo

(variant)

"Dynamic w/STIM" - use generic_pe.sim

Typical usage:
        sim.exe -stim STIM.file netinfo



Usage Issues:

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)