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.
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.
An example STIM.file appears below:
/* Part 1 - */
/* Master STIM file for XYZ system. */
/* DFG file Program file */
/* Part 2 - */
/* DFG invocations. */
/* macro x=y or monotonic dt or dfg-name or delay dt */
The first section names the DFG file names containing the DFGs you
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.
This example would cause the TRACK_a DFG to be started 7,000-uS after the
CLRSRCH DFG was initiated.
sched -stim STIM.file netinfoThe 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.)
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
setenv PMOD_STIM <full_path_name>/file_name
To use the DYNAMIC SCHEDULER in STIM mode, simply include the Dynamic Scheduler
model before any PE models. This changes:
#define STIM 0Change the setting to 1:
#define STIM 1Then 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..
|Single Graph||Mulitple Graph (STIM)|
"Static normal" - use generic_pe.sim
"Static w/STIM" - use multi_task_pe.sim
"Dynamic normal" - use generic_pe.sim
"Dynamic w/STIM" - use generic_pe.sim
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: firstname.lastname@example.org)