1. Task Graph Scheduling for RTR Paper Review By Gregor Scott

2. Paper Objective This paper provides an ILP formulation to minimize schedule length on partial dynamic reconfigurable architectures. A heuristic scheduler designed to exploit hardware module reuse Analysis of theses scheduling methods to address problem in current HW/SW Co-design.

3. Introduction An FPGA solution loaded with the a single configuration at the end of the design phase, can be termed as Compile Time Reconfiguration (CTR). Technology now allows FPGA’s to be reconfigured between different stage of computation. If a hardware application is bigger then the FPGA fabric allows, it must be partitioned into pieces that fit. Classical HW/SW co-design must be improved to take advantage of FPGA’s that support dynamic and partial reconfiguration.

4. Target Device and Context (a) 1D reconfiguration modules are confined to columns. (b) 2D, modules can consume lass space on the FPGA allowing for more efficient use of space. Xilinx Virtex4 & 5 FPGA’s allow for dynamic 2D partial reconfiguration like this.

5. Target Device and Context Module reuse means multiple tasks can be completed with a single configuration. Deconfiguration policy is a set of rules used to decide how to remove a configuration module from the FPGA. Antifragmentation techniques avoid fragmentation of the FPGA space. Configuration Prefetching means a module is loaded on to the FPGA as soon as possible.

6. Target Device and Context A 2D reconfigurable platform is modeled as a grid of reconfigurable units (RU). Each cell can be represented as its row, column pair (r,c). An application is provided as a set of tasks in the form of a Directed Acyclic Graph (DAG). Tasks in the application can be executed using a set of execution units (EU) which correspond to different RU configurations on the device, and a configuration bitstream.

7. Target Device and Context For any task with its set of EU implementations, using the latency, size and reconfiguration time for each implementation, a function can be defined that specific for the task: The EU that is needed to execute it The position on the FPGA to place the EU The time the EU can be configured if reuse is not possible. And the time the execution can start.

8. The ILP formulation for 2D reconfiguration and software execution A processor must exist in a static area to take of reconfiguration and be a processing element. The possibility of having a task execute only in software exists. Processor and the RU’s have separate memory. Communication model and latency between the processors and RU’s must be considered. Lots of algebra defining the parameters and constrains of the Integer linear Formulation can be found in this section of the paper.

9. Napoleon: a Heuristic Approach This algorithm will sort the task set based on dependencies and potential module reuse by later tasks. Then creating a placement list for EU’s that do not leave and RU’s empty. Replacing EU’s before a task is run if space is available.

10. Napoleon: a Heuristic Approach An example of a scheduled tasks

11. Napoleon: Task Graph and RU layout

12. Results ILP vs. Napoleon Heuristic Napoleon approach times very close to ILP.

13. Results ILP vs. Napoleon ILP takes much longer to compute than Napoleon.

14. Conclusion The first goal of this paper was to propose a model to assist in hardware/software co design of runtime reconfigurable systems. The second goal of the paper was to introduce a heuristic approach that can obtain good results in a reasonable amount of time. Next steps are in extending napoleon to work on line and schedule tasks at runtime.

15. Review opinions Long Results not very grounded Explains problems and premise well Presents new concepts well Interesting and easy to read Thank You, Questions?