RCIM 2008 - Allocation Relocation


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

RCIM 2008 - Allocation Relocation

  1. 1. HLR Core allocation and relocation management for self dynamically reconfigurable architectures Reconfigurable Computing Italian Meeting 19 December 2008 Room S01, Politecnico di Milano - Milan (Italy) Massimo Morandi: massimo.morandi@dresd.org Marco Novati: marco.novati@dresd.org
  2. 2. Outline Aims Introduction Basic Concepts Rationale Relocation solutions Core Allocation manager Concluding Remarks 2
  3. 3. Aims Provide support for self partially and dynamically reconfigurable systems: Relocation support: 1D and 2D solutions SW and HW solutions Runtime Core Placement support with: Low overhead High versatility Efficient use of resources 3
  4. 4. Reconfigurable architecture A basic reconfigurable architecture consists of: a Static area: a basic Harward architecture a Reconfigurable area: an device area composed by several reconfigurable regions 4
  5. 5. Basic Definitions Core: a specific representation of a functionality. It is Core possible, for example, to have a core described in VHDL, in C or in an intermediate representation (e.g. a DFG) IP-Core: a core described using a HD Language Core combined with its communication infrastructure (i.e. the bus interface) Reconfigurable Functional Unit: an IP-Core that can be Unit plugged and/or unplugged at runtime in an already working architecture Reconfigurable Region: a portion of the device area Region used to implement a reconfigurable core 5
  6. 6. Relocation: The Problem Set of Available RFU Functionalities Implementations B B 1/2 A F 2/2 RR1 RR2 RR3 RR1 RR2 RR3 C 2/2 2/1 A E 1/1 D 1/1 D C Legenda: Fi Area/Time RR1 RR2 RR3 RR1 RR2 RR3 E F RR1 RR2 RR3 RR1 RR2 RR3 6
  7. 7. Relocation: Motivation Area Area Demanded Tasks A A 2/1 A B 1/2 B B Rec. C Rec. C 2/2 C D 1/1 R2 D C C D Legenda: E 1/1 Ti Area/Time Request Rec. D R2 F Sequnce F 2/2 D Rec. E F E Rec. F F Time 7
  8. 8. Relocation: Rationale Bitstreams relocation technique to: speedup the overall system execution reduce the amount of memory used to store partial bitstreams achieve a core preemptive execution assign at runtime the bitstreams placement 8
  9. 9. Proposed Relocation Solutions Architectural support for relocation: Create an integrated HW/SW system to manage online relocation (1D and 2D) in reconfigurable architecture Create efficient bitstream relocation solutions suitable for the target system: 1D (BiRF) – 2D (BiRF Square) HW (BiRF, BiRF Square) – SW (BAnMaT Lite) 9
  10. 10. Xilinx FPGAs and Configuration Memory 10
  11. 11. CRC Calculation Particular CRC value, used by Xilinx tools Two version of BiRF and BiRF Square: By using the “predefined” values With actual CRC calculation X16 + X15 + X2 + 1 [1D] X32 + X28 + X27 + X26 + X25 + X23 + X22 + X20 + X19 + X18 + X14 + X13 + X11 + X10 + X9 + X8 + X6 + 1 [2D] 11
  12. 12. Synthesis Results: Area BiRF BiRF Square FPGA Generic Optimized Generic Optimized Version Version Version Version − − xc2vp7 11.6 % 3.6 % − − Xc2vp20 5.8 % 1.8 % − − xc2vp30 4.2 % 1.3 % − − xc4vlx40 2.2 % 0.9 % − − xc4vlx60 1.5 % 0.6 % − − xc4vlx100 0.8 % 0.3 % − − xc5vlx50 1.1 % 0.8 % − − xc5vlx85 0.6 % 0.4 % − − xc5vlx110 0.5 % 0.3 % 12
  13. 13. Relocation Solutions Results (1/2) BiRF, BiRF Square, BAnMaT Lite Permit to support relocation in a self partially and dynamically 1D or 2D reconfigurable system The occupation ratio is relatively small Frequency more than acceptable Reduction of internal memory requirements Throughput: BiRF: 6 MB/s BiRF Square: 7.3 MB/s BAnMaT Lite: 2.6 MB/s 13
  14. 14. Relocation Solutions Results (2/2) A total configuration file size is about 1 MB Considering an architecture: 1/3 of the area as fixed part 2/3 as reconfigurable part with 6 slots With such hypothesis Size of a partial bitstream will be about 110 KB Relocation time of about: 18 ms with BiRF 15 ms with BiRF Square 42 ms with BAnMaT Lite 14
  15. 15. Outline Aims Introduction Basic Concepts Rationale Relocation solutions Core Allocation manager Concluding Remarks 15
  16. 16. Runtime Core Allocation Management Choose where to place Cores to achieve: Low Core Rejection Rate (CRR) Fast application completion time Small management overhead Other policy driven goal Choose how to maintain information on empty space Keep all information (Expensive but more accurate) Heuristically prune information (Cheaper) 16
  17. 17. Evaluation and Proposed Approach Choice driven by: Need for low complexity solution to reduce overhead at runtime Desire to keep high flexibility, to best suit user needs We propose heuristic (KNER-like) empty space manager: Support both general and focused policy (in particular FF, BF, RA) Suitable for dynamic schedule and blind schedule Exploiting multiple RFUs per Core, to improve quality 17
  18. 18. The Online Placement Algorithm The whole processing of a Core is completed in linear time 18
  19. 19. Experiment 1: Routing Aware Comparison against literature solutions dynamic schedule scenario, RA placement policy Measuring CRR, routing costs and overhead Benchmark of 100 randomly generated Cores: Size (5% to 20% of FPGA), randomly interconnected 19
  20. 20. Experiment 2: Application Completion Time Benchmark applications composed of cores taken from opencores.org like JPEG, AES, 3DES … Blind Schedule, measure the time instants needed to complete the applications with different amounts of resources Infinite resources is shown, to compare against lower bound 20
  21. 21. Experiment 3: Multiple Shapes Similar benchmark, but Cores have deadlines (for CRR) Shapes defined with the heuristics described previously Difference in runtime on average 30% more for 3 shapes and 40% more for 5 shapes w.r.t. 1 shape CRR more than halved, often reduced to one third 21
  22. 22. Concluding Remarks Original goals met: Create efficient bitstream relocation solution suitable for target systems: 1D - 2D HW – SW Create a Core allocation manager with: Low overhead High efficiency (CRR, application completion time, routing costs …) High versatility 22
  23. 23. Questions 23