RCW@DEI - Design Flow 4 SoPc


Published on

Published in: Technology
1 Comment
  • it's a releaving slide that helped me alot about basics
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

RCW@DEI - Design Flow 4 SoPc

  1. 1. Design Flow for SoPC P artial D ynamic R econfiguration W orkshop DRESD Team [email_address]
  2. 2. Motivations <ul><li>Especially interesting is the scenario of dynamically reconfigurable system, in which hardware reconfiguration is carried out without necessarily having to cease execution of those parts of the system that are not involved. </li></ul><ul><li>The successful deployment of such complex and reconfigurable embedded systems to the market requires the identification, formalization, and implementation of concepts, methods, and tools that are able to ease the development of the software components and the implementation of the system architecture. </li></ul><ul><li>This scenario is the one in which the Dynamic Reconfigurability in Embedded Systems Design (DRESD) research project takes place. </li></ul><ul><li>Aim of these presentations is to propose, after the overview of related work, the DRESD methodology. Up to now the proposed solution, extending and improving the Xilinx design flow, accomplishes the design and development of a particular kind of embedded systems that exploit the advantages of dynamic reconfiguration. </li></ul>
  3. 3. Outline <ul><li>FPGA </li></ul><ul><li>Xilinx design flows </li></ul><ul><li>Design Flow: challenges and rationale </li></ul><ul><li>DRESD contribution </li></ul>
  4. 4. What’s next <ul><li>FPGA </li></ul><ul><ul><li>Technology </li></ul></ul><ul><ul><li>CLB, Slice, LUT </li></ul></ul><ul><ul><li>Frame </li></ul></ul><ul><ul><li>Configuration bitstream </li></ul></ul><ul><li>Xilinx design flows </li></ul><ul><li>Design Flow: challenges and rationale </li></ul><ul><li>DRESD contribution </li></ul>
  5. 5. Xilinx FPGA technology
  6. 6. CLB Switch Box SLICE TBUF Y X 67 66 75 74 SLICE_X66Y74
  7. 7. The configuration bitstream <ul><li>Occupation must be determined only on the basis of </li></ul><ul><ul><li>Number of configuration words </li></ul></ul><ul><ul><li>Initial Frame Address Register (FAR) value </li></ul></ul>
  8. 8. Frame and Configuration Memory <ul><li>Virtex-II Pro </li></ul><ul><ul><li>Configuration memory is arranged in vertical frames that are one bit wide and stretch from the top edge of the device to the bottom </li></ul></ul><ul><ul><li>Frames are the smallest addressable segments of the VIIP configuration memory space </li></ul></ul><ul><ul><ul><li>all operations must act on whole configuration frames. </li></ul></ul></ul><ul><li>Virtex-4 </li></ul><ul><ul><li>Configuration memory is arranged in frames that are tiled about the device </li></ul></ul><ul><ul><li>Frames are the smallest addressable segments of the V4 configuration memory space </li></ul></ul><ul><ul><ul><li>all operations must therefore act upon whole configuration frames </li></ul></ul></ul>
  9. 9. Xilinx FPGA and configuration memory
  10. 10. What’s next <ul><li>FPGA </li></ul><ul><li>Xilinx design flows </li></ul><ul><ul><li>Difference based (smallbit) </li></ul></ul><ul><ul><li>Module based </li></ul></ul><ul><ul><li>EAPR </li></ul></ul><ul><li>Design Flow: challenges and rationale </li></ul><ul><li>DRESD contribution </li></ul>
  11. 11. Introduction <ul><li>Design flow for partially reconfigurable architectures </li></ul><ul><ul><li>Set of subsequent phases to implement the architecture </li></ul></ul><ul><ul><li>“ Partially reconfigurable” requirements </li></ul></ul><ul><ul><li>Need to partition the development phases into several steps </li></ul></ul><ul><li>Xilinx official design flows: </li></ul><ul><ul><li>Difference based (Smallbit) </li></ul></ul><ul><ul><li>Module based </li></ul></ul><ul><ul><li>EAPR </li></ul></ul>
  12. 12. Difference based (Smallbit) <ul><li>The basic brick to Xilinx partial reconfiguration </li></ul><ul><li>This method of partial reconfiguration is accomplished by making a small change to a design, and then by generating a bitstream based on only the differences in the two designs. </li></ul><ul><li>Switching the configuration of a module from one implementation to another is very quick, as the bitstream differences can be extremely smaller than the entire device bitstream. </li></ul>
  13. 13. Pre – Partial Reconfiguration <ul><li>Xilinx Virtex II Pro FPGA </li></ul>
  14. 14. Post – Partial Reconfiguration <ul><li>Xilinx Virtex II Pro FPGA </li></ul>
  15. 15. Module based 1/3 <ul><li>“ Traditional” design flow for partially reconfigurable architectures </li></ul><ul><ul><li>Based on a modular design approach (iterative) </li></ul></ul><ul><ul><ul><li>Design entry and synthesis </li></ul></ul></ul><ul><ul><ul><li>Design implementation </li></ul></ul></ul><ul><ul><ul><li>Design verification </li></ul></ul></ul><ul><li>Several design constraints </li></ul><ul><ul><li>Module definition </li></ul></ul><ul><ul><li>Module height and width </li></ul></ul><ul><ul><li>Inter-module communication </li></ul></ul>
  16. 16. Module based 2/3 <ul><li>The design flow has a relevant limitation </li></ul><ul><ul><li>Reconfigurable modules (regions) have strict shape requirements </li></ul></ul><ul><ul><li>Bus-macro replication </li></ul></ul>
  17. 17. Module based 3/3 <ul><li>The Module-based design flow at a glance </li></ul>1 2 HDL description and synthesis Initial Budgeting Phase (define design constraint) 3 Active Module Phase (implementation of each component) 4 Final Assembly Phase (asseble individual modules togheter)
  18. 18. Pre – Partial Reconfiguration Xilinx S3 FPGA
  19. 19. Post – Partial Reconfiguration Xilinx S3 FPGA
  20. 20. EAPR 1/3 <ul><li>Early Access Patial Reconfiguration (EAPR) flow </li></ul><ul><ul><li>Overcome the limitations imposed by module-based flow </li></ul></ul><ul><ul><li>The requirements of column-wise reconfiguration are removed </li></ul></ul><ul><ul><li>2-dimensional shaped modules can be defined </li></ul></ul><ul><ul><li>Support for Virtex-4 is now available </li></ul></ul>
  21. 21. EAPR 2/3 <ul><li>The EAPR design flow at a glance </li></ul>1 2 HDL description and synthesis Define design constraint (text editor, Floorplanner...) 3 Implement base design (static) 4 Implement PRM design 5 Merge phase: PRM + base
  22. 22. EAPR 3/3 <ul><li>The top component must be used to instantiate </li></ul><ul><ul><li>Base design </li></ul></ul><ul><ul><li>PR modules </li></ul></ul><ul><ul><li>B us-macros </li></ul></ul><ul><ul><li>Clock primitives (BUFG and DCM) </li></ul></ul><ul><li>The base design should not contain </li></ul><ul><ul><li>Any clocking or reset logic </li></ul></ul><ul><li>All PRMs should guarantee </li></ul><ul><ul><li>No clocking logic </li></ul></ul><ul><ul><li>Pin and port name consistency </li></ul></ul>
  23. 23. Pre – Partial Reconfiguration <ul><li>Xilinx Virtex 4 FPGA </li></ul>
  24. 24. Post – Partial Reconfiguration Xilinx Virtex 4 FPGA
  25. 25. What’s next <ul><li>FPGA </li></ul><ul><li>Xilinx design flows </li></ul><ul><li>Design Flow: challenges and rationale </li></ul><ul><li>DRESD contribution </li></ul>
  26. 26. Design Flow: Challenges and Rationale <ul><li>Dynamic reconfigurable embedded systems are gathering, an increasing interest from both the scientific and the industrial world </li></ul><ul><ul><li>The need of a comprehensive framework which can guide designers through the whole implementation process is becoming stronger </li></ul></ul><ul><li>No EDA support: </li></ul><ul><ul><li>to define which IP-Core has to become a reconfigurable core </li></ul></ul><ul><ul><li>to perform the actual swap of reconfigurable cores and the FPGA reconfiguration </li></ul></ul><ul><ul><li>to define interconnections among reconfigurable cores </li></ul></ul><ul><ul><li>to identify from an high-level or RT-Level specification how to define reconfigurable cores </li></ul></ul>
  27. 27. What’s next <ul><li>FPGA </li></ul><ul><li>Xilinx design flows </li></ul><ul><li>Design Flow: challenges and rationale </li></ul><ul><li>DRESD contribution </li></ul><ul><ul><li>INCA </li></ul></ul><ul><ul><li>Caronte </li></ul></ul><ul><ul><ul><li>Hardware side management </li></ul></ul></ul><ul><ul><ul><li>Software side management </li></ul></ul></ul>
  28. 28. INCA <ul><li>INCA </li></ul><ul><ul><li>Based on EAPR design flow </li></ul></ul><ul><ul><li>An automated tool for bitstream generation </li></ul></ul><ul><ul><li>To generate complete bitstreams for the entire architecture </li></ul></ul><ul><ul><li>To generate partial bitstreams for the partially reconfigurable regions </li></ul></ul>
  29. 29. Low-Level design flow: Caronte <ul><li>HW : H ard w are </li></ul><ul><li>RHW : R econfigurable HW </li></ul><ul><li>SW : S oft w are </li></ul>
  30. 30. Hardware Side – design flow
  31. 31. Low-Level Design: Contributions <ul><li>The design of a complete framework, able to support different devices , reconfiguration techniques and kinds of reconfiguration </li></ul><ul><li>IP-Core generation </li></ul><ul><li>System architecture generation </li></ul><ul><ul><li>Generation (context creation) of combinations of static and dynamic parts </li></ul></ul><ul><ul><li>Communication infrastructure creation </li></ul></ul><ul><ul><li>Automatic IP-Core generation starting from a given Core </li></ul></ul><ul><ul><ul><li>Generation time almost constant </li></ul></ul></ul><ul><ul><ul><li>Interface impact tends to 0 for the biggest Cores </li></ul></ul></ul>
  32. 32. System Description
  33. 33. Area Constraints Xilinx VIIP Xilinx S3 Xilinx V4
  34. 34. Reconfigurable Region Definition <ul><li>The flows require constraints to be satisfied when defining RRs in the UCF ( User Constraints File ) file </li></ul>AREA_GROUP &quot;RR1&quot; RANGE = SLICE_X28Y64:SLICE_X41Y127; AREA_GROUP &quot;RR1&quot; RANGE = RAMB16_X2Y9:RAMB16_X2Y15;
  35. 35. Design Synthesis and Placement Constraints Assignment
  36. 36. System Generation Context Creation: EAPR-based
  37. 37. <ul><li>YaRA : Y et a nother R econfigurable A rchitecture </li></ul><ul><li>The basic reconfigurable architecture defined </li></ul><ul><ul><li>a Static area : a basic Harvard architecture </li></ul></ul><ul><ul><li>a Reconfigurable area : a device area composed of several reconfigurable regions </li></ul></ul>YaRA v1: 1D, Whishbone BUS-based YaRA v2: 2D,CoreConnect-based The DRESD reconfigurable architecture
  38. 38. Software Side – Standalone Solution
  39. 39. Software side of the Caronte flow <ul><li>Standalone solution </li></ul><ul><ul><li>Specific reconfiguration libraries </li></ul></ul><ul><ul><li>Integration in the final bitstream </li></ul></ul><ul><ul><li>No multitasking </li></ul></ul><ul><li>Linux support </li></ul><ul><ul><li>High-level reconfiguration libraries </li></ul></ul><ul><ul><li>Support for multitasking and other OS services </li></ul></ul><ul><ul><li>Only a bootloader is integrated in the bitstream </li></ul></ul><ul><ul><li>Device driver development for specific hardware </li></ul></ul>
  40. 40. Reconfiguration Support <ul><li>Linux kernels do not natively support dynamic reconfiguration </li></ul><ul><ul><li>No interaction with the reconfiguration controller </li></ul></ul><ul><ul><li>Dynamic addition of hardware modules is supported… </li></ul></ul><ul><ul><li>… But area management or module caching are not! </li></ul></ul><ul><li>The kernel must be extended in order to perform a set of basic operations </li></ul><ul><ul><li>Module configuration upon request </li></ul></ul><ul><ul><li>Module release/removal </li></ul></ul><ul><li>General assumption: the partial bitstream is provided as part of the module request </li></ul>
  41. 41. IP-Core devices access <ul><li>Interaction with configured IP-Cores implemented by means of the standard Linux device access </li></ul><ul><ul><li>Open, Close, Read, write, ioctl operations </li></ul></ul>
  42. 42. Reconfigurable Process Control Block <ul><li>Reconfigurable process : an RFU object code in execution </li></ul><ul><li>Each reconfigurable process is represented in the system by a Reconfigurable Process Control Block (RPCB). </li></ul><ul><li>A RPCB contains all the information associated with a specific reconfigurable process </li></ul><ul><ul><li>State : the state in which the reconfigurable process control is at the current time </li></ul></ul><ul><ul><li>Position : the placement position on the device </li></ul></ul><ul><ul><li>Object Code Accounting Information : </li></ul></ul><ul><ul><ul><li>Object Code </li></ul></ul></ul><ul><ul><ul><li>Configuration Priority </li></ul></ul></ul><ul><ul><ul><li>Resources </li></ul></ul></ul><ul><ul><ul><li>Position </li></ul></ul></ul>
  43. 43. The Centralized Manager <ul><li>Userspace applications are not allowed to explicitly request a bitstream </li></ul><ul><ul><li>They request high-level functionalities </li></ul></ul><ul><li>Userspace requests are collected and served by a centralized manager ( Linux Reconfiguration Manager ) </li></ul><ul><ul><li>The OS chooses the configuration code </li></ul></ul><ul><ul><li>A new reconfigurable process is created </li></ul></ul><ul><li>Only the LRM can ask for a bitstream to be configured on the FPGA </li></ul><ul><ul><li>Centralized knowledge of the device status </li></ul></ul><ul><ul><li>Area management and module caching </li></ul></ul>
  44. 44. Software Side – Linux Solution
  45. 45. Concluding Remarks: Top Ten Reasons to work in Caronte and OSyRiS <ul><li>Definition of a complete methodology to implement self reconfigurable embedded systems </li></ul><ul><li>Description of adaptable solutions able to meet the user needs </li></ul><ul><li>Definition of an integrated HW/SW solution to support the reconfiguration </li></ul><ul><li>A design flow able to support different devices and basic design flows </li></ul><ul><li>Design support and available interaction at each level for expert users </li></ul><ul><li>Reconfiguration hiding for new users </li></ul><ul><li>OS solution Vs Standalone solution </li></ul><ul><li>Runtime decision on the RPCB gender </li></ul><ul><li>From now on, Transformers are the past! </li></ul><ul><li>Do we really need a ten? :) </li></ul>
  46. 46. Treasure Hunt <ul><li>Thursday 30, October </li></ul><ul><li>Search the Research: an adventure in the world of Reconfigurable </li></ul><ul><li>Will you be brave enough to live a 100% pure DRESD night to discover the reconfigurable systems secrets? If so, do not miss the next adventure in the world of Reconfigurable Systems: </li></ul><ul><ul><li>http://www.dresd.org/treasurehunt </li></ul></ul><ul><ul><li>http://www.dresd.org/th08_it </li></ul></ul>
  47. 47. Questions