Problema dual

To achieve more efficient scheduling, and especially more efficient scheduling analysis, the intended behavior of a program needs to be more strongly defined. There are in principle three alternatives for how this can be done: 1) by adding descriptive constructs to the language, 2) by restricting the MoC and using a subset of the available features, 3) by using the available constructs of the language to highlight the intention, or 4) by decorating the program with information that is not part of the actual programming language and only adds information but not functionality.

Updating a language is in general out of the question; perhaps some constructs that have been proven useful may be included in future versions of a language, but before reaching that point, the other alternatives are more useful. Restricting the MoC is an alternative that cannot be ignored, just look at all the different MoCs presented in Chapter 2, but then again, the goal with this work is to allow maximal expressive power of the language but still keep some of the benefits from inherently statical models. This leaves us with using CAL itself to produce more analyzable models, or to allow separate specifications to be added to the model.

As mentioned above, the programmer should describe control depen- dencies as clearly as possible in the code in order to allow efficient analysis. However, what we are interested in here is adding information without mod- ifying the original implementation; anything added should be possible to be removed without changing the behavior of the program.

seq BTYPE A B C dcpred A B C BTYPE QP IN OUT PTR QUANT SIGNED START dcsplit IN DC AC Spec BT BTYPE data QP

Figure 8.1: Adding an actor to strengthen the guards of the actors scheduled based on the input BTYPE.

seq BTYPE A B C dcpred A B C BTYPE QP IN OUT PTR QUANT SIGNED START dcsplit IN DC AC Spec BT QP DT BT QP DT BTYPE data QP

Figure 8.2: Adding an actor to define the scheduling of the rest of the partition.

Adding Scheduler Actors Let us play with the idea that we add ac-

tors that does nothing else than introduce stronger guards into a partition. An appropriate example where stronger guards could be useful is the acdc network in Case Study V, where there are two actors which guards are func- tionally dependent but this cannot be proved as it is possible to come up with input tokes that never will occur in practice (e.g. a frame is never both I and P), but that will cause the unwanted behavior. In this example, the network has one control input which is connected to two actors, namely

DCPred and Sequence. These actors receives identical copies of the same

control value and it is known that the four firing rules of DCPred can be used to decide which firing rule will be enabled in Sequence, however, with the given guards this cannot be proved.

An additional actor, which gives stronger guards regarding these control tokens, can be added either in parallel or in sequence with the other actors that use this control value, as shown in Figures 8.1 and 8.2 respectively. Neither of these structures add any new behavior to the dataflow program; instead they introduce a sequence of firing rules that should be strong enough to define the scheduling of the other actors. To do this the actors might include an FSM and a set of actions defining strong guards. The idea is then that, when a the scheduling model is generated, these actors can be chosen as the actors that the scheduling is based on as the firing rules have been constructed such that a functional dependency can be proved.

tion actors as a listener, that is, it is tapped to the channel carrying control information and consumes these values. Now the question is, if this actor should be treated as any actor or if the tools should assume that this is a specific actor that specifies how the other actors work. This potentially becomes a problem if it is desired that the actor adds more information regarding, for example, the sequence in which inputs may arrive. While this type of specification actor adds a minimal modification to the dataflow network, the sequential alternative will have control over how information flows in to the partition.

The second alternative, shown in Figure 8.2, the actor connected in sequence actually resends every token that is received at the inputs of the partition. Except from defining stronger firing rules in form of guards, this version also makes it possible to add more specific firing sequences as it fully can control how the tokens are streamed in to the partition. With this construct, it is easy to specify the exact scenarios that the partition is supposed to perform. Furthermore, in this example the control token described the type of one 64-coefficient block in an MPEG-4 decoder, and it might be desired to describe that if a block is either an I-block or a P-block, the next five blocks will be of the same type. This is easy to describe using the FSM of the specification actor as this actor controls what is allowed to enter the partition.

While these actors are rather simple, it might be easier to describe the behavior of these in some other representation than CAL. A more high-level representation, from which these simple actors can be generated, could be more appropriate. Such representations could also easily be used to decorate the model with information that cannot be expressed in CAL.

Adding Information Software systems are often tested for correctness

by adding additional statements which are only used for testing or verifying that the program works according to the specifications. Typically asser- tions or invariants, pre- and post- conditions, are defined which describe which properties should hold and when. The format of these specification are often a more mathematical format than the language the application is implemented in provides, e.g. the Spin model checker accepts linear-time

temporal logic statements to describe the correct behavior of the Promela

program being verified.

If we return to the example discussed above, where the problem was that the tools cannot know that a I-block cannot be a P-block, it would

be practical to add a few statements like btype ∈ I ∪ P ∪ Nvop and I ∩

P = _{∅, where I and P represent the sets of possible values that belong}

to these types of blocks. This actually would add a new dimension to the possibilities of specifying the program, first of all, scheduling becomes easier, but second, it is also possible to verify that the program acts according to

the specifications.