A slightly more complex application, an Infinite Impulse Response (IIR) filter, makes the scheduling more complex by requiring the dataflow net- work to handle delay tokens. An IIR filter, compared to an FIR filter, uses previous output samples, in additions to input samples, to produce the out-
Figure 7.3: The IIR filter implementation in Orcc.
put. Using output values to produce new output means that is is possible to design a filter where an input impulse affects all future outputs. The CAL program to be used in this case study is shown in Figure 7.3; what is interesting with this program, from a scheduling point of view, is that it is expected to have static token rates but it also has a feedback loop implying that delay tokens are needed.
To schedule this program as SDF means that the requirement to have empty buffers between running the schedules is too strict as there will always be delay tokens present in the dataflow network during the normal operation of the filter. The delay tokens, in this specific program are implemented in the delay actor, which after running its initializer runs an action outputting a number of delay tokens before it moves on to its normal operation to simply send tokens forward. This behavior is implemented in the action scheduler of the delay actor:
schedule fsm s i n i t : s i n i t ( i n i t ) −−> s d e l a y ; s d e l a y ( t o k e n ) −−> s d e l a y ; s d e l a y ( run ) −−> s r u n ; s r u n ( run ) −−> s r u n ; end
The scheduling of this program is quite similar to that of the FIR filter in the previous case study. The main difference is the delay actor which has a sequence of action firings before it starts acting in an SDF fashion, and produces the delay tokens as a result of this. The program is, therefore, expected to require two schedules, one that initializes the actors and runs the actions producing the delay tokens, and another SDF like schedule that represents the normal operation of the filter. To make the schedules make sense, the schedules are produced with the requirement that the program has been initialized, that progress has been made, and that all internal FIFOs except the output of the delay actor are empty. The output of the delay actor is a natural choice since the other actors have static token rates while this actor for every N tokens it has consumed has produced N + D outputs, where D is the number of delay tokens.
<superactor name=” c l u s t e r a d d 1 ”> <fsm i n i t i a l =”s 0”> <t r a n s i t i o n s r c=”s 0 ” dst=”s 1 ” action=” s 0 o n e s t a t e u n t a g g e d 0 ”/> <t r a n s i t i o n s r c=”s 1 ” dst=”s 2 ” action=” s 1 o n e s t a t e u n t a g g e d 0 ”/> <t r a n s i t i o n s r c=”s 2 ” dst=”s 2 ” action=” s 2 o n e s t a t e u n t a g g e d 0 ”/> </fsm> <superaction name=” s 0 o n e s t a t e u n t a g g e d 0 ”> <guard/>
<iterand action=” i n i t ” r e p e t i t i o n s =”1” actor=” d e l a y 1 ”/> </superaction>
<superaction name=” s 1 o n e s t a t e u n t a g g e d 0 ”> <guard/>
<iterand action=”t o k e n ” r e p e t i t i o n s =”1” actor=” d e l a y 1 ”/> </superaction>
<superaction name=” s 2 o n e s t a t e u n t a g g e d 0 ”> <guard/>
<iterand action=”u n t a g g e d 0 ” actor=”mul 1”/> <iterand action=”u n t a g g e d 0 ” actor=”a d d 1 ”/> <iterand action=”u n t a g g e d 0 ” actor=” r s h i f t ”/> <iterand action=”u n t a g g e d 0 ” actor=”mul 2”/>
<iterand action=”run ” actor=” d e l a y 1 ”/>
</superaction> </superactor>
Figure 7.4: The scheduler for the IIR filter.
The scheduling, however, produces three schedules. The reason for this is that the first schedule, where the requirement is progress and initialized actors, is satisfied when the delay actor has been initialized, the action producing the delay token is not required to satisfy this condition. The second schedule is produced in a similar fashion, and the condition is satisfied when the delay token has been produced. The third schedule, however, requires inputs in order to have progress which makes the program run one iteration of an SDF like schedule. The generated schedule is shown in Figure 7.4.
It is, to some extent, unclear how delay tokens can be identified in the general case, as it requires analysis of the token rates between the actors, which becomes more complex when the application to schedule is more com- plex than the simple filters that have been analyzed in these two case studies. It is, however, not required that these are exactly identified but instead it is enough to have an approximation that tells that some FIFOs most probably
may need to contain delay tokens and therefore should not be required to be empty.