Exercise 4: putting it all together, using the SDF3 design-flow
In the previous exercises you have seen how to model resource allocation decisions (e.g., buffer sizes) and architecture components (e.g., interconnect) into an FSM-SADF graph. Using sdf3analyze-fsmsadf, the throughput of the FSM-SADF graph under this resource allocation can be analyzed. A design-flow that maps a throughput-constrained application, modeled with an FSM-SADF graph, onto a multi-processor platform should perform exactly these two steps. Model the resource allocation decisions in the FSM-SADF graph and next check whether the throughput constraint is met. If so, the design-flow can continue with a next step. Otherwise, the design-flow needs to look for an alternative solution (i.e., mapping or scheduling).
The SDF3 tool-kit contains a tool called sdf3flow-fsmsadf that takes as input an FSM-SADF graph modeling an application and an (abstract) description of a multi-processor platform. In a series of steps, the tool maps the application onto the multi-processor platform. As a first step, the tool determines the buffer size requirements of the channels in the FSM-SADF graph. Next, the tool refines the throughput constraint in a number of additional constraints that are used to guide the binding of actors to processors. The actual binding of actors to processors is performed in the third step. Each scenario in the SADF graph could in principle use a different mapping. To implement this, a run-time reconfiguration mechanism is needed that can transfer data items (tokens) and code (actors) between different memories whenever a scenario switch occurs. To provide timing guarantees, a design flow should take the overhead of the run-time reconfiguration into account. In the worst-case, a reconfiguration is performed after executing a single iteration of the graph. Hence, scenario switches can occur very frequently (the MPEG-4 decoder may switch scenarios 20 times per second). Providing timing guarantees while allowing such frequent reconfigurations may lead to large resource reservations. Therefore sdf3flow-fsmsadf assumes that the actors of an SADF graph are mapped to the same resources in all scenarios. This unified mapping avoids that data items or code need to be moved between different memories when switching between scenarios. Next, the tool constructs static-order schedules for all processors to which actors have been bound. Finally, the tool computes the minimal TDMA time slices needed on these processors to guarantee that the throughput constraint of the application is met. By minimizing the TDMA time slices, processor resources are saved for other applications. The output of the tool is a set of Pareto optimal mappings that provide a trade-off in their resource usage. In some of these mappings, the application could for example use a lot of computational resources, but limited storage resources, whereas an opposite situation may be obtained in other mappings. At run-time the most suitable mapping can then be selected based on the resource usage of the applications which are already running on the platform.
In this exercise, you will be using the sdf3flow-fsmsadf tool to map a very simple FSM-SADF graph onto a homogeneous two processor platform. The figure below shows the graph as well as the platform used in this exercise. The platform consists of two tiles connected through (abstract) connections. In reality, these connections may be implemented using for example dedicated FIFOs or a network-on-chip. From the perspective of sdf3flow these connections provide timing guarantees on the amount of time needed to sent a token from one tile to another (i.e., it should be possible to model the timing behavior of the interconnect with a dataflow graph similar to the models we have used in the previous exercise). The tiles contain a processor, a local memory, and a network interface that connects a tile to its connections.



As mentioned before, the tool sdf3flow-fsmsadf can be used to map an application onto a multi-processor platform. You are now going to run this tool to generate such a mapping.
The tool will print information on its decisions in the various steps of the flow to the terminal. At the end, it will report to you whether it has found one or more feasible mappings of the application onto the platform. These mappings have been stored in the file 'mapping.xml'.

