Top Up Prev Next Bottom Contents Index Search

3.4 Targets

As is typical of simulation domains, the SDF domain does not have many targets. To choose one of these targets, with your mouse cursor in a schematic window, execute the Edit:edit-target command (or just type "T"). You will get a list of the available Targets in the SDF domain. The "default-SDF" target is normally selected by default. When you click "OK", dialog box appears with the parameters of the target. You can edit these, or accept the defaults. The next time you run the schematic, the selected target will be used.

3.4.1 Default SDF target

The default SDF target has a simple set of options:

logFile
(STRING) Default =
The name of a file into which the scheduler will write the final schedule. The initial default is the empty string.
loopScheduler
(INT) Default = YES
A Boolean specifying whether to attempt to compact the schedule for forming looping structure (see below).
schedulePeriod
(FLOAT) Default = 0.0
A floating-point number defining the time taken by one iteration through the schedule. This is not needed for pure SDF systems, but if SDF systems are mixed with timed domains, such as DE, then this will determine the amount of simulated time taken by one iteration. The SDF scheduler determines the order of execution of stars in a system at start time. It performs most of its computation during its setup() phase. If the loopScheduler target parameter is NO, then we get a scheduler that exactly implements the method described in [Lee87a] for sequential schedules. If there are sample rate changes in a program graph, some parts of the graph are executed multiple times. This scheduler does not attempt to generate loops; it simply generates a linear list of blocks to be executed. For example, if star A is executed 100 times, the generated schedule includes 100 instances of A. A loop scheduler will include in its "looped" schedule (where possible) only one instance of A and indicate the repetition count of A, as in (100 A). For simulation, a long unstructured list might be tolerable, but not in code generation. (The SDF schedulers are also used in the code generation for a single processor target).

Neglecting the overhead due to each loop, an optimally compact looped schedule is one that contains only one instance of each actor, and we refer to such schedules as single appearance schedules. For example, the looped schedule (3 A)(2 B), corresponding to the firing sequence AAABB, is a single appearance schedule, whereas the schedule AB(2 A)B is not.

By setting the loopScheduler target parameter to YES, we can select a scheduler developed by Joe Buck. Before applying the non-looping scheduling algorithm, this algorithm collects actors into a hierarchy of clusters. This clustering algorithm consists of alternating a "merging" step and a "looping" step until no further changes can be made. In the merging step, blocks connected together are merged into a cluster if there is no sample rate change between them and the merge will not introduce deadlock. In the looping step, a cluster is looped until it is possible to merge it with the neighbor blocks or clusters. Since this looping algorithm is conservative, some complicated looping possibilities are not always discovered.

3.4.2 The loop-SDF target

A more sophisticated looping algorithm, available in an alternative target called the loop-SDF target, was developed by adding postprocessing steps to the above loop scheduling algorithm to handle more cases. For lack of a better name, we call this technique "SJS scheduling", for the first initials of the designers (Shuvra Bhattacharyya, Joe Buck, and Soonhoi Ha). In the postprocessing, we attempt to decompose the graph into a hierarchy of acyclic graphs [Bha93b], for which a compact looped schedule can easily be constructed. Cyclic subgraphs that cannot be decomposed by this method, called tightly interdependent subgraphs, are expanded to acyclic precedence graphs in which looping structures are extracted by the techniques developed in [Bha94a] and extensions to these techniques developed by Soonhoi Ha. This scheduling option is selected when the loopTarget is chosen instead of the default SDF target. The target options are:

logFile
schedulePeriod
They have the same interpretation as for the default target, but in the loop-SDF target, schedulePeriod has an initial default of 10000.0.

When there are sample rate changes in the program graph, the default SDF scheduler may be much slower than the loop schedulers, and in code generation, the resulting schedules may lead to unacceptably large code size. Buck's scheduler provides a fast way to get compact looped schedules for many program graphs, although there are no guarantees of optimality. The somewhat slower SJS scheduler is guaranteed to find a single appearance schedule whenever one exists [Bha93c]. Furthermore, a schedule generated by the SJS scheduler contains only one instance of each actor that is not contained in a tightly interdependent subgraph.

The looped result can be seen by setting the logFile target parameter. That file will contain all the intermediate procedures of looping and the final scheduling result. The loop scheduling algorithms are usually used in code generation domains, not in the simulation SDF domain. See The Almagest.

3.4.3 Compile-SDF target

A third target in the SDF domain, called compile-SDF. Instead of executing a simulation by invoking the go() methods of stars from within the Ptolemy process, it generates a C++ program that implements the universe, links it with appropriate parts of the Ptolemy kernel, and then invokes that system. The schedule is constructed statically, so the generated program has no scheduler linked in. Instead, the generated code directly invokes the go() methods of the stars. The target parameters are:

directory
(STRING) Default= $HOME/PTOLEMY_SYSTEMS
The directory into which to place the generated code.
LoopingLevel
(INT) Default = 1
If the value is "0", no attempt will be made to construct a looped schedule. This can result in very large programs for multirate systems, since the invocation of the go() methods will be in line. Setting the level to "1" invokes a quick a simple loop scheduler. Setting it to "2" invokes the more sophisticated SJS loop scheduler, which can take considerably more time to execute.
writeSchedule?
(INT) Default = NO
If the value is YES, then the schedule is written out to a file named .sched in the directory named by the directory target parameter. If you wish to try this SDF target, open any of the basic SDF demos in figure 3-20, edit the target to change it to the compile-SDF target (in vem, hit `T'), and run the system. You can then examine the source code and makefile the are placed in the specified directory. An executable with the same name as the name of the demo will also be placed in that directory. This is a standalone executable that does not require any part of the Ptolemy system to run (except for the Ptolemy Tcl/Tk startup scripts in $PTOLEMY/lib/tcl). For example, if you choose the butterfly demo in figure 3-20, your destination directory will contain the following files:

butterfly butterfly.cc code.cc make.template makefile The first of these is executable. Try executing it. You can modify the number of sample points generated using a command-line argument. For example, to generate 1,000 points instead of 10,000, type


butterfly 1000
 The compile-SDF target is an example of a code-generation Target within the SDF domain. So, in a very fundamental way, a Target defines the way a system is executed. The default target is essentially an interpreter. The compile-SDF target synthesizes a standalone program and then executes it on the native workstation. It should be viewed merely as an example of the kinds of extensions users can build. More elaborate targets parallelize the code and execute the resulting programs on remote hardware. Targets can be defined by users and can make use of existing Ptolemy schedulers. Knowledgeable users can also define their own schedulers.

The compile-SDF target first creates the C++ source code for the current universe in a file of the same name of the universe followed by .cc. Then, it copies the C++ code into code.cc and builds the makefile to compile code.cc using the make template file CompileMake.template in the $PTOLEMY/lib directory. Next, the compile-SDF target runs the makefile to compile code.cc into an executable called code. The compile-SDF target then renames code to the name of the Ptolemy universe. If there is an error reported by make, then it is likely that one of make configuration variables is incorrect. The makefile includes the configuration makefile for the workstation you are using. The configuration makefiles are in the $PTOLEMY/mk directory.

The compile-SDF target has a number of known problems:

3.4.4 SDF to PTCL target

The SDF-to-PTCL target was introduced in Ptolemy 0.6. This target is substantially incomplete, we give a rough outline below. We hope to complete work on the SDF-to-PTCL target in a later release. The SDF-to-PTCL target uses CGMultiInOut stars to generate abstract ptcl graphs which capture the SDF semantics of a simulation SDF universe. These abstract graphs can then be used to test SDF schedulers.

The ptcl output filename will use the universe name as a prefix, and append .pt to the name (e.g., the ptcl output for the butterfly demo would be in butterfly.pt). Currently the directory that will contain the ptcl output is hardwired to ~/PTOLEMY_SYSTEMS/ptcl/. You may need to create this directory by hand.

The most interesting aspect about the target is that it collects statistics on the execution time of each star. This is valuable for seeing the relative runtimes of the various stars which can be used in code generation. It collects statistics by running the scheduled universe, accumulating elapsed CPU time totals for each star. This new target does not call the wrapup methods of the stars, so you will not see XGraph outputs.


Top Up Prev Next Bottom Contents Index Search

Copyright © 1990-1997, University of California. All rights reserved.