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.
STRING) Default =
INT) Default = YES
FLOAT) Default = 0.0
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.
loop-SDFtarget, 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:
loop-SDFtarget, 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.
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:
$HOME/PTOLEMY_SYSTEMSThe directory into which to place the generated code.
INT) Default = 1
INT) Default = NO
.schedin the directory named by the directory target parameter.
compile-SDFtarget (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
butterflydemo in figure 3-20, your destination directory will contain the following files:
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.
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
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
LoopingLevelparameter set to "0". Unfortunately, there is no convenient way to interrupt the code generation process.
makeprogram on your path must be the GNU
CompileMake.templateover an existing
make.template. If you get errors after you have switched versions of Ptolemy, then delete the
makefilein the destination directory of the
SDF-to-PTCLtarget 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-PTCLtarget in a later release. The
CGMultiInOutstars 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
.ptto the name (e.g., the ptcl output for the
butterflydemo 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