Integrated Modeling Using Finite State Machines and Dataflow Graphs - Signal Processing Systems - page 966

Having such consistent SDF graphs, two approaches can be taken: (i) The
heterochronous dataflow approach only switches modes if the graph has finished an
iteration. This has the advantage that all channel fill sizes are known at compile-
time, as the consistent SDF graph starts from a known initial marking of the
channels. This information allows the synthesis step for the consistent SDF graph
to calculate a static schedule .The static schedule can eliminate the checking for the
presence of tokens. Furthermore, other transformations which depend on knowledge
of the channel fill sizes for each actor execution in the static schedule can also be
performed, e.g., lowering of FIFOs to registers if applicable, etc. The disadvantage
is the constraint that the FSM can only change its state at the end of an iteration.
This makes the model non-compositional as the points in time for which transitions
in an FSM of a refined dataflow actor A are allowed depend on the consumption
and production rates of other dataflow actors in the same HDF domain. (ii) The
approach presented in [ 33 ] takes the opposite view. The mode transitions can be
taken at any time. This implies that no knowledge of the channel fill sizes is
present when a schedule for a consistent SDF graph is executed. Therefore, each
actor in the schedule has to test for presence of tokens, i.e., the scheduler has to
execute the enable function to decide if the actor can be fired via its invoke function .
Furthermore, optimizations depending on knowledge of the channel fill sizes for
each actor execution in the static schedule cannot be performed. However, a speedup
compared to the round robin scheduler can still be obtained for multirate dataflow
graphs . The speedup stems from the fact that the generated schedules queries the
enable function of the contained actors in the correct proportion to each other. The
simple round robin scheduler would check the actors A to E for executability in
sequence. However, this constant checking is wasteful as B needs only be checked
once per two executions of E and C only once per three executions of E .

2.4 CAL Actor Language

The CAL Actor Language ( CAL ) is a programming language which was first
invented [ 11 ] to describe actors and their behavior only. Later on, the language was
extended to allow specification of dataflow graphs containing these actors.
We will first briefly review the syntax of CAL actors and the accompanying
formal model. For the mathematical model, we assume that all data values processed
by CAL actors are from the universal set of values V .The CAL language itself
is primarily concerned with the definition of the actors themselves and assumes
an environment which provides the concrete dataflow graph and channel types in
which the actors are instantiated. Data types which are underspecified in the CAL
actor description are assumed to be inferred from the types used in the concrete
channels to which the actor will be connected in the environment. For an in-depth
review of the type system used in CAL , we refer the interested reader to the language
manual [ 11 ] .