Digital Signal Processing Reference
In-Depth Information
EIDF is based on a formalism in which actors execute through dynamic
transitions among modes, where each mode has “synchronous” (constant produc-
tion/consumption rate behavior), but different modes can have differing dataflow
rates. Unlike other forms of mode-oriented dataflow specification, such as stream-
fireability checking (checking whether or not the next mode has sufficient data to
execute), and mode execution (carrying out the execution of a given mode). This
allows for lightweight fireability checking, since the checking is completely separate
from mode execution. Furthermore, the approach improves the predictability of
mode executions since there is no waiting for data (blocking reads)—the time
required to access input data is not affected by scheduling decisions or global
dataflow graph state.
For a given EIDF actor, the specification for each mode of the actor includes
the number of tokens that is consumed on each input port throughout the mode,
the number of tokens that is produced on each output port, and the computation
(the
invoke function
) that is to be performed when the actor is invoked in the given
mode. The specified computation must produce the designated number of tokens on
each output port, and it must also produce a value for the
next mode
of the actor,
which determines the number of input tokens required for and the computation to
be performed during the next actor invocation. The next mode can in general depend
on the current mode as well as the input data that is consumed as the mode executes.
At any given time between mode executions (actor invocations), an enclosing
scheduler can query the actor using the
enable function
of the actor. The enable
function can only examine the number of tokens on each input port (without
consuming any data), and based on these “token populations”, the function returns
a Boolean value indicating whether or not the next mode has enough data to execute
to completion without waiting for data on any port.
The set of possible next modes for a given actor at a given point in time can
in general be empty or contain one or multiple elements. If the next mode set is
empty (the next mode is
null
), then the actor cannot be invoked again before
it is somehow reset or re-initialized from environment that controls the enclosing
dataflow graph. A
null
next mode is therefore equivalent to a transition to a mode
that requires an infinite number of tokens on an input port. The provision for multi-
element sets of next modes allows for natural representation of non-determinism in
EIDF specifications.
When the set of next modes for a given actor mode is restricted to have at most
one element, the resulting model of computation, called
core functional dataflow
the
functional DIF
simulation environment for behavioral simulation of signal
processing applications. Functional DIF integrates CFDF-based dataflow graph
specification using the
dataflow interchange format
(
DIF
), a textual language for
representing DSP-oriented dataflow graphs, and Java-based specification of intra-
actor functionality, including specification of enable functions, invoke functions,
