Dynamic Dataflow Modeling in Ptolemy II - Ptolemy Project ...

In this method, we classify all actors into three categories: actors that are not enabled,
actors that are enabled but deferrable, and actors that are enabled and not deferrable. We
also search those actors for a parameter named requiredFiringsPerIteration, which
specifies the number of times the actor must be fired in one iteration. Since some actors
may not get fired in one basic iteration, one iteration consists of several basic iterations
(possible infinite if the model is ill-designed). The reason we introduce this mechanism to
define an iteration is to match the user’s expectation. For example, intuitively a user
would expect to see one token consumed and plotted by a sink actor in each iteration,
which can be achieved by adding the parameter to the sink plotter with value 1.
prefire()
If the DDF domain is embedded in another domain, we first check the input ports of the
container composite actor to see whether they have enough tokens. It is tricky to do that
because unlike SDF, it is undecidable for DDF to determine the exact number of tokens
required to finish one iteration. This point will be further elaborated in section 3.5 when
we mix DDF domain with other Ptolemy II domains. We also reset to zero the counting
variables for those actors which are required to fire specified number of times in each
iteration.
fire()
This is the place where the bulk of computation is performed. Each invocation of this
method corresponds to one iteration of the model, which by default is one basic iteration.
However, if some actor has a parameter named requiredFiringsPerIteration, continue to
execute basic iterations until the actor has been fired at least the number of times given
32