Director for the synchronous dataflow (SDF) model of computation.
SDF overview
The Synchronous Dataflow(SDF) domain supports the efficient execution of Dataflow graphs that lack control structures. Dataflow graphs that contain control structures should be executed using the Process Networks(PN) domain instead. SDF allows efficient execution, with very little overhead at runtime. It requires that the rates on the ports of all actors be known before hand. SDF also requires that the rates on the ports not change during execution. In addition, in some cases (namely systems with feedback) delays, which are represented by initial tokens on relations must be explicitly noted. SDF uses this rate and delay information to determine the execution sequence of the actors before execution begins.
Schedule Properties
- The number of tokens accumulated on every relation is bounded, given an infinite number of executions of the schedule.
- Deadlock will never occur, given an infinite number of executions of the schedule.
Class comments
An SDFDirector is the class that controls execution of actors under the SDF domain. By default, actor scheduling is handled by the SDFScheduler class. Furthermore, the newReceiver method creates Receivers of type SDFReceiver, which extends QueueReceiver to support optimized gets and puts of arrays of tokens.
Actors are assumed to consume and produce exactly one token per channel on each firing. Actors that do not follow this convention should set the appropriate parameters on input and output ports to declare the number of tokens they produce or consume. See the {@link ptolemy.domains.sdf.kernel.SDFScheduler} for more information.The {@link ptolemy.domains.sdf.lib.SampleDelay} actor is usually usedin a model to specify the delay across a relation.
The allowDisconnectedGraphs parameter of this director determines whether disconnected graphs are permitted. A model may have two or more graphs of actors that are not connected. The schedule can jump from one graph to another among the disconnected graphs. There is nothing to force the scheduler to finish executing all actors on one graph before firing actors on another graph. However, the order of execution within an graph should be correct. Usually, disconnected graphs in an SDF model indicates an error. The default value of the allowDisconnectedGraphs parameter is a BooleanToken with the value false.
The iterations parameter of this director corresponds to a limit on the number of times the director will fire its hierarchy before it returns false in postfire. If this number is not greater than zero, then no limit is set and postfire will always return true. The default value of the iterations parameter is an IntToken with value zero.
The vectorizationFactor parameter of this director sets the number of times that the basic schedule is executed during each firing of this director. This might allow the director to execute the model more efficiently, by combining multiple firings of each actor. The default value of the vectorizationFactor parameter is an IntToken with value one.
The SDF director has a period parameter which specifies the amount of model time that elapses per iteration. If the value of period is 0.0 (the default), then it has no effect, and this director never increments time nor calls fireAt() on the enclosing director. If the period is greater than 0.0, then if this director is at the top level, it increments time by this amount in each invocation of postfire(). If it is not at the top level, then it calls fireAt(currentTime + period) in postfire().
This behavior gives an interesting use of SDF within DE: You can "kick start" an SDF submodel with a single event, and then if the director of that SDF submodel has a period greater than 0.0, then it will continue to fire periodically with the specified period.
If period is greater than 0.0 and the parameter synchronizeToRealTime is set to true
, then the prefire() method stalls until the real time elapsed since the model started matches the period multiplied by the iteration count. This ensures that the director does not get ahead of real time. However, of course, this does not ensure that the director keeps up with real time.
@see ptolemy.domains.sdf.kernel.SDFScheduler
@see ptolemy.domains.sdf.kernel.SDFReceiver
@author Steve Neuendorffer
@version $Id: SDFDirector.java,v 1.148 2007/04/05 01:02:11 cxh Exp $
@since Ptolemy II 0.2
@Pt.ProposedRating Green (neuendor)
@Pt.AcceptedRating Green (neuendor)