1 / 13

A2B: a Framework for Fast Prototyping of Reconfigurable Systems

Workshop on Reconfigurable Computing (WRC). A2B: a Framework for Fast Prototyping of Reconfigurable Systems. Christian Pilato , R. Cattaneo, G. Durelli, A.A. Nacci, M.D. Santambrogio, D. Sciuto Politecnico di Milano Dipartimento di Elettronica. Informazione e Bioingegneria, Italy.

tokala
Download Presentation

A2B: a Framework for Fast Prototyping of Reconfigurable Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Workshop on Reconfigurable Computing (WRC) A2B: a Framework for Fast Prototyping of Reconfigurable Systems Christian Pilato , R. Cattaneo, G. Durelli, A.A. Nacci, M.D. Santambrogio, D. Sciuto Politecnico di MilanoDipartimento di Elettronica. Informazione e Bioingegneria, Italy

  2. Motivations • The design of reconfigurable systems is a difficult task • Interactions between the different phases have to be taken into account • Decision in the frontend phase may highly affect the backend implementation • E.g.: Mapping onto reconfigurable regions and floorplacing of the tasks may generate low-quality solutions due to a wrong partitioning or assignment of implementations • The optimal design methodology (and the number of its iterations) cannot be known in advance A2B is an ongoing project at Politecnico di Milano to assist the design of such complex systems

  3. Agenda • Framework Overview • How do we explore the design space? • How do we generate a design solution? • Conclusions and Future Work

  4. Framework Overview • Inputs: • Information about the target device (.XML) • Application source files (.C) • Decision Making (Exploration): • Task graph generation • Library generation • Mapping, Scheduling, Floorplacing • Architectural modification • Refinement (Evaluation): • Specification of the platform • Generation of the SW code • Output: • Project files ready for the synthesiswith back-end tools Exploration Evaluation

  5. XML Exchange Format • The entire project can be represented through an XML file • Architecture: components’ characteristics (e.g., reconfigurable regions), … • Applications: source code files and profiling information • Library: task implementations with the characterization (time, resources, ...) • Partitions: task graph, mapping and scheduling, … • It allows a modular organization of the framework, but also the sharing of information among the different phases • The phases can be applied in any order to progressively optimize the design • The designer can perform as many iterations as he/she wants to refine the solution • Specific details of the target architecture are taken into account only in the refinement phase (interactions with backend tools)

  6. Task Graph and Library Generation • Application source code files can be analyzed to extract the task graphs • Profiling information can drive the generation of such solutions • Task graph will be then specified in the XML file as processing nodes connected by data transfers • Currently they can be designed by hand, but automated methodologies for automatic parallelization will be investigated in the future • Transformations to improve the description by splitting/merging the tasks • LLVM-based compiler to extract the DFG of each task • Estimation of required resources (including bit-width analysis) • Interaction with HLS synthesis tools to obtain more accurate results • Generated implementations are then store in the XML file to offer opportunities to the mapping phase and information to the floorplacer

  7. Mapping, Scheduling and Floorplacing • We generate one or more configurations where each task of the applications is analyzed and assigned to • An available and admissible implementation • A component of the architecture (e.g., processor or reconfigurable region) • This supports to • “share” implementations across different tasks (hardware sharing) • move a task implementation to another processing element at run-time (task relocation) • Tasks assigned to the same reconfigurable region are analyzed to determine its constraints and requirement of resources • Floorplacing of the regions to determine their positions and the feasibility of the mapping

  8. Architecture Exploration • An additional step can be included to explore the target architecture • Adding/removing processing elements • Modifying their parameters • Determining the proper interconnection topology • It can affect: • task graph transformations and library generation • mapping and floorplacing: modification to the computational resources (especially the number of reconfigurable regions) • It allows a progressive refinement of the solution and a concurrent customization of both architecture and application • E.g.: mapping and floorplacing can suggest which resources should be added

  9. Supported Platforms • Virtex-5 XC5VLX110T • Two XCF32P Platform Flash PROMs (32Mbyte each) SystemACE™ Compact Flash configuration controller • 64-bit wide 256Mbyte DDR2 small outline DIMM (SODIMM) • MPC Research Platform MaxWorkstation • Intel i7 2600s@2.8GHz, 16GB RAM, 500GB HDD • Max3 dataflow engine (DFE) • Virtex 6 SX475T FPGA, 24GB memory • DFE connected to CPU via PCI Express gen2 x8 XUPV5 MAX3 DFE DRAM (24GB) DDR2 (256MB) CPU0 Compute FPGA Interface FPGA CPU1 Reconf. Area CPU CPU DRAM (16GB) CPU CPU

  10. Solution Refinement for the Target Platforms • DFGs for HW tasks • Mapping configurations .xml .c • Source code for CPU MaxWorkstation FPGA-based embedded system CPU Compiler DFG-MaxJ DFG-C Manual VHDL Implementations Manual MaxJ Implementations HLS (C-VHDL) HLS (MaxJ-VHDL) MaxIDE Bitstream Generation Bitstream Generation exec bin The code can be always further optimized by hand; e.g., glue code for data transfers bit bit

  11. Graphical User Interface (GUI) • Practical GUI to support the designer, to limit the errors in the interactions with the XML and to allow custom design methodologies

  12. Conclusions and Future Work • A2B is a modular framework to design reconfigurable systems • Easy to plug alternative methods for each of the phase • Possibility to perform progressive refinement of both application and architecture • A2B is becoming part of a larger project (ASAP – Advanced Synthesis of Applications and Platforms) • Refinement will also include the generation of SystemC TLM models of the target system for (co-)simulation and early validation • Closer interaction with actual synthesis (e.g., high-level synthesis) • Automated methodologies to accelerate the design Our goal is to make them available to the community (open-source) as soon as possible (a.k.a. ASAP)!

  13. Thank you!Christian Pilatopilato@elet.polimi.it Research partially funded by the European Community’s Seventh Framework Programme, FASTER project.

More Related