Off-line hardware tasks classification in dynamically and partially reconfigurable platforms

1. FOSFOR FOSFOR meeting 15th October 2008 Off-line hardware tasks classification in dynamically and partially reconfigurable platforms BELAID Ikbel, MULLER Fabrice E-mail: {Ikbel.Belaid,Fabrice.Muller}@unice.fr

2. Outline • Motivations. • Off-line Hw tasks classification. • Work in progress: Off-line Reconfigurable Zones (RZs) classification. • Future works: On-line Hw tasks placing.

3. Motivations • Increasing in the amount of resources on reconfigurable platforms. • Heterogeneity of the recent reconfigurable devices and hardness of resources managing. • Resources wastage and fragmentation. • Tasks rejection. • High performance and low power requirements. Novel approach managing efficiently Hw resources and guaranteeing QoS of the application.

4. Outline • Motivations. • Off-line Hw tasks classification. • Work in progress: Off-line Reconfigurable Zones (RZs) classification. • Future works: On-line Hw tasks placing.

5. Off-line Hw tasks classification • Hw execution unit description. • Off-line Hw tasks classification flow.

6. The essential elements • Hardware tasks. • OS services • External/internal communication management. • Scheduling/placing. • Memory management. • I/O devices controllers (Microblaze system). • Inter-tasks and tasks-OS services communication network.

7. Hw execution unit abstraction • Partitioning into Static Region (SR) and Reconfigurable Regions (RRs): • SR: Consider OS services, I/O controlling (microblaze and IPs controllers) and communication network. • RR • Dynamic tasks. • Run-time modification (temporal multiplexing). • One RR is a set of Reconfigurable Zones (RZs): RR ={RZs}. • RZ • RZs are physical blocks composed by heterogeneous resources. • Every Hw task is performed by allocation of the suitable RZ. • RZs are useful for switching between functioning modes or between applications in complex design. • Two RZs types: frequently-modified RZs and non-frequently-modified RZs. RZ RZ RZ Hw Execution Unit SR RR

8. Physical modeling of Hw tasks (1/6) • Principle features of Hw tasks • Behavioral model: state machine, memory, data, registers, etc • Functional features: • Priority • Timing features • First configuration overhead • Execution time (WCET) • Period • Deadline • Resources: CLBs, BRAMs, DSP, etc • Non-functional features • Power consumption, bitstream size • Physical modeling • Set of reconfiguration-granularity-based Reconfigurable Blocks (RB).

9. Physical modeling of Hw tasks (2/6) • It is essentially based on the Hw tasks resources. • It consists of two steps: • Step 1: Definition of physical blocks (RBs) in the specified device (execution unit). • Step 2: Extraction of RBs in the Hw tasks. Physical Modeling Physical model Task resources A A A B B C Hw task = {y1 A, y2 B, y3 C,…} Hw task = {x1 CLBs, x2 BRAMs, x3 DSP,…}

10. Physical modeling of Hw tasks (3/6) • Step 1: Definition of RBs in the specified device • Reconfiguration-granularity-based RBs: RB shape depends on the configuration frame. • RB is a vertical stack of Hw resources: CLB, BRAM, DSP slices, IOB, etc. • RBs are homogeneous blocks. • Step Result • RBs repository according to chosen technology.

11. Physical modeling of Hw tasks (4/6) • Step1: Example in Virtex 5 technology RB A= 20 CLBLs RB B= 20 CLBMs RB C= 4 BRAMs RB D= 8 DSP slices RBs_repository = {RB A, RB B, RB C, RB D} RBs_div = {20,20,4,8}

12. Physical modeling of Hw tasks (5/6) • Step2: Extraction of RBs in Hw tasks • Hw tasks abstraction. • Presentation of Hw tasks by RBs depends on the technology. • Two steps for RBs extraction in Hw tasks • Step 2.1: Synthesizing of Hw task: many possible implementations: • Impl 1 = {CLBs, BRAMs, DSPs} • Impl 2 = {CLBs, BRAMs} • Impl 3 = {CLBs, DSPs} • Impl 4 = {CLBs} • … • Step 2.2: Executing abstraction algorithm • Step Result • Physical model of Hw tasks

13. Physical modeling of Hw tasks (6/6) • Step 2: Example in Virtex 5 technology RBs repository (step 1) Hw task implementations (step 2.1) RB 1: A (20 CLBLs) RB 2: B (20 CLBMs) RB 3: C (4 BRAMs) . . . Impl 1 : 0 Impl 2 : 25 CLBLs 4 BRAMs Impl 3 : 0 Impl 4 : 25 CLBLs 9 CLBMs Step 2.2 Physical model of task T in Impl 2 HW task_impl 1 = {0} HW task_impl 2 = {2A,0B,1C,0D} HW task_impl 3 = {0} HW task_impl 4 = {2A,1B,0C,0D} A A C

14. Off-line Hw tasks classification • Hw execution unit description • Off-line Hw tasks classification flow

15. Goals of the flow • The flow for off-line Hw tasks classification is performed manually by the designer in the aim of searching the possible RZs for a set of tasks. • This flow is guided essentially by task resources and some other rules. • After executing this flow we can perform the off-line RZs classification on the reconfigurable execution unit.

16. Flow Inputs • Static constraints • Static components in the device: DCMs, ICAP, Ethernet blocks, PCI blocks should be predefined to be avoided by the reconfigurable part. • Static part (communication network, I/O controlling, OS services) must be subtracted initially from the available reconfigurable resources in the device. Practically, the static part will be partitioned automatically by the specified tools. • The remainder part will be dedicated for the reconfigurable part which contains CLBs, BRAMs, DSP slices, etc.

17. Flow Inputs • Example FPGA SR: DCMs ICAP JTAG … SR: Ethernet PCI RR1 RR0 • RRx = {x1 CLBs, x2 IOBs, x3 BRAMs, x4 DSP slices} • SR = {y1 CLBs, y2 IOBs, y3 BRAMs, y4 DSP slices, y5 Ethernet blocks, y6 PCI blocks, y7 DCMs, y8 ICAP, y9 JTAG,…}

18. Rules • The number of RZs and their contents are strongly linked to application tasks and offered resources in the chosen technology. • The RZs have rectangular form. • the RZs are constrained by the reconfiguration granularity. • The Hw task could be implemented in several RZs. • At a time, and during the execution, the Hw task will be implemented in one RZ.

19. Flow (1/3) M: number of RRs. Resources types (RTx): {CLB, IOB, BRAM, DSP} SR: Static Region RR: the whole Reconfigurable Region including all the RRx. RRx: the x Reconfigurable Region Mx: matrix of several RZs types in RRx. MEx,i: matrix of required RZs types for task i in RRx. xЄ [0,M-1] iЄ [0,nb_tasks – 1] Static constraints SR SR RRx RRx SR RRx RTx Definition of the possible RZs types in RRx Mx for RRx BRAM Tasks resources: CLB,BRAM,… CLB BRAM CLB IOB BRAM DSP Task i Resources = {27 CLB, 0 IOB, 1 BRAM, 0 DSP} … Extraction of required RZs types for each task RZ_type_1 RZ_type_(2RTx-1) MEx,i for task i in RRx CLB CLB BRAM CLB BRAM CLB IOB DSP … … … RZ_type_1 RZ_type_(2RTx-1)

20. Flow (2/3) MEx,i MEAx,i: matrix of abstracted required RZs types for task i in RRx. Optimal_RZ_abs: matrix of optimal RZs types for tasks in RRx. N: number of tasks. RZs types abstraction for each task MEAx,i for Task i in RRx MEAx,i A A C A A B C D … Mx RZ_type_1 RZ_type_(2RTx-1) Searching optimal RZs types Optimal RZ type for task i in RRx A A C Optimal_RZ_abs for all tasks, RRx RZ_type_1

21. Flow (3/3) RRAx {Optimal_RZ_abs for RRx} RRAx: matrix of abstraction of RRx. Final_RB: matrix of the selected RZs types with the required number of RBs. Optimal filtering of required RZs types Choosing another device YES NO Filtering required RZs types Placing RZs types into dynamically reconfigurable platform Hw tasks classification

22. Advantages (1/2) • The obtained RZs are tightly packed to application tasks. Consequently, we enhance resources efficiency and power use and decrease fragmentation. • This off-line flow will facilitate the later on-line placing. Comparing with related works in the on-line placing, it minimizes also tasks rejection, especially in the complex applications, as it guarantees Hw tasks partitioning. • The resulted RZs are fixed during execution and will be occupied by the tasks relying on scheduler and placer decisions and by using certain concepts as preemption (context switch), DPR,…

23. Advantages (2/2) • This flow is considered standard and can be applied for whatever application and whatever technology. It can be also updated easily with the number of tasks within the application. • This off-line flow is interactive with Hw tasks. The related research works using pre-partitioned blocks, fix the physical blocks (1D, 2D) independently from tasks requirements.

24. Outline • Motivations. • Off-line Hw tasks classification. • Work in progress: Off-line Reconfigurable Zones (RZs) classification. • Future works: On-line Hw tasks placing.

25. Work in progress: Off-line RZs classification • Rules • Possible solutions.

26. Rules • In this step, the RZs and the Hw tasks are combined. • In this step, the obtained RZs from the off-line Hw tasks classification flow will be placed on the RRs included within dynamically reconfigurable platform. • This step relies on the tasks graph dependencies. • The order of RBs within RZ will be known at the end of this off-line RZs classification. • Constraining RZs placing not only by the RZs contents and the available resources in the device but also by communication network (CAIRN).

27. Work in progress: Off-line RZs classification • Rules. • Possible solutions.

28. Possible solutions Column A A C A A A C A A B A A D C A A D C A B C A Line RZs repository … A C C A A A A A A B A D C C B D A D B CLB IOB BRAM DSP How to place ? A A A B A D A B B D C A A C C A A A A Column-based technology (Virtex4, Virtex5) Future technologies: Mont blanc ? Our first proposed approach : horizontal-vertical full scanning approach dedicated to Xilinx column-based technology which gives a complexity estimated by O(m*n) where n is the number of required resources in the RZ and m is the number of lines in the specified technology.

29. Outline • Motivations. • Off-line Hw tasks classification. • Work in progress: Off-line Reconfigurable Zones (RZs) classification. • Future works: On-line Hw tasks placing.

30. Future works: On-line Hw tasks placing • The on-line placer exploits the results of the two previous steps: Hw tasks classification and RZs classification. • The placing quality: tasks rejection rate and resources waste rate and the overhead will be enhanced. • The off-line Hw tasks classification and off-line RZs classification might create a guarantee-based schedulers/placers.