Top Up Prev Next Bottom Contents Index Search

13.2 Targets

A code generation Domain is specific to the language generated, such as C (CGC) and DSP56000 assembly code (CG56). In previous versions of Ptolemy, we released code generation domains for the Sproc assembly language [Mur93], the DSP96000 assembly language, and the Silage language. Each code generation domain has a default target which defines routines generic to the target language. These targets are derived from targets defined in the CG domain.

A Target object has methods for generating a schedule, compiling the code, and running the code (which may involve downloading code to the target hardware and beginning its execution). There also may be child targets (for representing multiprocessor targets) together with methods for scheduling the communication between them. Targets also have parameters that are user specified. There are four targets in the CG domain; these are described below.

13.2.1 default-CG

This target is the default target for the CG domain. It allows the user to experiment with the various uniprocessor schedulers. Currently, there is a suite of schedulers that generate schedules of various forms of optimality. For instance, the default SDF scheduler generates schedules that try to minimize the amount of buffering required on arcs, while the loop schedulers try to minimize the amount of code that is generated. Refer to the schedulers section in this chapter for a discussion on these schedulers. There are only two parameters for this target:

directory (STRING) Default = $HOME/PTOLEMY_SYSTEMS
This is the directory to which all generated files will be written to.
looping Level (STRING) Default = ACYLOOP
The choices are DEF, CLUST, SJS, or ACYLOOP. Case does not matter; ACYLOOP is the same as AcyLoOP. If the value is DEF, no attempt will be made to construct a looped schedule. This can result in very large programs for multirate systems, since inline code generation is used, where a codeblock is inserted for each appearance of an actor in the schedule. Setting the level to CLUST invokes a quick and simple loop scheduler that may not always give single appearance schedules. Setting it to SJS invokes the more sophisticated SJS loop scheduler [Bha93c], which can take more time to execute, but is guaranteed to find single appearance schedules whenever they exist. Setting it to ACYLOOP invokes a scheduler that generates single appearance schedules optimized for buffer memory usage [Mur96][Bha96], as long as the graph is acyclic. If the graph is not acyclic, and ACYLOOP has been chosen, then the target automatically reverts to the SJS scheduler. For backward compatibility, "0" or "NO", "1", and "2" or "YES" are also recognized, with "0" or "NO" being DEF, "1" being CLUST, and "2" or "YES" being SJS. NOTE: Loop scheduling only applies to uniprocessor targets; hence, this parameter does not appear in the FullyConnected target.
In addition to these parameters, there are a number of parameters that are in this target that are not visible to the user. These parameters may be made visible to the user by derived targets. The complete list of these parameters follows:

host (STRING) Default =
The default is the empty string. This is the host machine to compile or assemble code on. All code is written to and compiled and run on the computer specified by this parameter. If a remote computer is specified here then rsh commands are used to place files on that computer and to invoke the compiler. You should verify that your .rhosts file is properly configured so that rsh will work.
file (STRING) Default =
The default is the empty string. This represents the prefix for file names for all generated files.
display? (INT) Default = YES
If this flag is set to YES, then the generated code will be displayed on the screen.
compile? (INT) Default = YES
If this flag is set to YES, then the generated code will be compiled (or assembled).
load? (INT) Default = YES
If this flag is set to YES, then the compiled code will be loaded onto a chip.
run? (INT) Default = YES
If this flag is set to YES, then the generated code is run.

13.2.2 bdf-CG

This target demonstrates the use of BDF semantics in code generation. It uses the BDF scheduler to generate code. See the BDF domain documentation for more information on BDF scheduling. There is only one target parameter available to the user; the directory parameter above. This parameter has the same functionality as above.

13.2.3 FullyConnected

This target models a fully connected multiprocessor architecture. It forms the baseclass for all multiprocessor targets with the fully connected topology. Its parameters are mostly to do with multiprocessor scheduling.

The parameters for FullyConnected are:

nprocs (INT) Default = 2
Number of processors in the target architecture.
sendTime (INT) Default = 1
This is the time required, in processor cycles, to send or receive one datum in the multiprocessor architecture. Sending and receiving are assumed to take the same amount of time.
oneStarOneProc (INT) Default = NO
If this is YES, then all invocations of a star are scheduled onto the same processor.
manualAssignment (INT) Default = NO
If this is YES, then the processor assignment is done manually by the user by setting the procId state in each star.
adjustSchedule (INT) Default = NO
If this is YES, then the automatically generated schedule is overridden by manual assignment. This feature requires improvements in the user interface before it can be implemented; hence, the default is NO.
childType (STRINGARRAY) Default = default-CG
This parameter specifies the names of the child targets, separated by spaces. If the number of strings is fewer than the number of processors specified by the nprocs parameter, the remaining processors are of type given by the last string. For example, if there are four processors, and childType is set to default-CG56[2] default-CGC, then the first two child targets will be of type default-CG56, and the next two of type default-CGC.
resources (STRINGARRAY) Default =
The default is the empty string. This parameter defines the specific resources that child targets have, separated by ";". For example, if the first processor has I/O capabilities, this would be specified as STDIO. Then, stars that request STDIO would be scheduled onto the first processor.
relTimeScales (INTARRAY) Default = 1
This defines the relative time scales of the processors corresponding to child targets. This information is needed by the scheduler in order to compute scheduling costs. The number of entries here should be the same as the number of processors; if not, then the last entry is used for the remaining processors. The entries reflect the relative computing speeds of different processors, and are expressed as relative cycle times. For example, if there is a DSP96000 (32Mhz) and a DSP56000 (20Mhz), the relative cycle times are 1 and 1.6. The default is 1 (meaning that all processors have the same computing speed).
ganttChart (INT) Default = YES
If this is YES, then the Gantt chart containing the generated schedule is displayed.
logFile (STRING) Default =
This is the name of the file to which a log will be written of the scheduling process. This is useful for debugging schedulers. If no file name is specified, no log is generated.
amortizedComm (INT) Default = NO
If this is YES, the scheduler will try to reduce the communication overhead by sending multiple samples per send. This has not really been implemented yet.
(STRING) Default = DL
Using the schedName parameter, a user can select which parallel scheduling algorithm to use. There are three basic SDF parallel scheduling algorithms. The first two can be used for heterogeneous processors, while the last can only be used for homogeneous processors.

HU selects a scheduling algorithm based on the classical work by T. C. Hu [Hu61]. This scheduler ignores the interprocessor communication cost (IPC) during scheduling and thus may result in unrealistic schedules. The next two scheduling algorithms take into IPC.

DL selects Gil Sih's dynamic level scheduler [Sih93a] (default).

DC selects Gil Sih's declustering algorithm [Sih93b]. This scheduler only supports homogeneous multiprocessor targets. It is more expensive than the DL and HU schedulers, so should be used only if the DL and HU schedulers produce poor schedules.

HIER selects a preliminary version of José Luis Pino's hierarchical scheduler [Pin95]. With this scheduler, the user can specify a top-level parallel scheduler from the three listed above and also specify uniprocessor schedulers for individual galaxies. The default top-level scheduler is DL; to specify another use the following syntax: HIER(HU) or HIER(DC). To specify a uniprocessor scheduler for a galaxy, add a new galaxy string parameter named Scheduler and set it to either Cluster (looping level 1), Loop (looping level 2) or SDFScheduler (looping level 0). See section
13.3.1 for more information on the uniprocessor schedulers.

CGDDF1 selects Soonhoi Ha's dynamic construct scheduler [Ha92]. A dynamic construct, clustered as a star instance, can be assigned to multiple processors. In the future, we may want to schedule a star exploiting data-parallelism. A star instance that can be assigned to multiple processors is called a "macro" actor. MACRO scheduler is expected to allow the macro actors. For now, however, MACRO scheduler is not implemented.

13.2.4 SharedBus

This third target, also a multiprocessor target, models a shared-bus architecture. In this case, the scheduler computes the cost of the schedule by imposing the constraint that more than one send or receive cannot occur at the same time (since the communication bus is shared).

Top Up Prev Next Bottom Contents Index Search

1 Note that in Ptolemy0.6, the CGDDF scheduler is not compiled into the default binaries. See "Bugs in pigi" on page A-34 for details.

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