Uploaded on

MPHS (a.a. 06/07) - Reconfigurable Computing: Available Projects

MPHS (a.a. 06/07) - Reconfigurable Computing: Available Projects

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
511
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
10
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. M etodologie di P rogettazine H ardware e S oftware Reconfigurable Computing - Projects -
  • 2. EARENDIL
    • Hail, Earendil, of mariners most renowned, the looked for that cometh at unawares, the longed for that cometh beyond hope! Hail Earendil, bearer of light before the Sun and Moon! Splendour of the Children of Earth, star in the darkness, jewel in the sunset, radiant in the morning!
    • But Earendil came, shining with white flame, and about Vingilot were gathered all the great birds of heaven.
    • [...]and a guard is set for ever on those walls, and Earendil keeps watch upon the ramparts of the sky.
    • J.R.R. Tolkien, Silmarillion
  • 3. Earendil Design Flow: Basic Principles
    • Modularity
      • It is possible to use/design/manage a specific tool or the entire flow
    • Scalability
      • Easy to add or remove modules/projects
    • Portability
      • Earendil runs on different platforms: Linux, Mac OS X, Windows
    • Ubiquity
      • Decentralized collaboration to design and develop the Earendil project
  • 4. Earendil Design Flow: an Overview DRESD - HLR DRESD - BE
  • 5. DRESD - HLR
  • 6. DRESD - BE
  • 7. DRESD Project examples
  • 8. DRESD Project examples
    • HLR
      • Some theoretical aspects
    • YaRA
      • The reconfigurable architecture
    • Acheronte
      • The back-end design flow
    • YaRA and Acheronte extension
    • LINUX
      • Reconfiguration operating System support
      • Microlinux
    • SyCERS
      • The simulation framework
    • LimboWARE
      • Reconfigurable computing, some new idea
    • VIRGIL
      • A new possible flow
  • 9. DRESD Project examples
    • HLR
      • Some theoretical aspects
    • YaRA
      • The reconfigurable architecture
    • Acheronte
      • The back-end design flow
    • YaRA and Acheronte extension
    • LINUX
      • Reconfiguration operating System support
      • Microlinux
    • SyCERS
      • The simulation framework
    • LimboWARE
      • Reconfigurable computing, some new idea
    • VIRGIL
      • A new possible flow
  • 10. Reconfigurable Hardware: why?
  • 11. Reconfigurable Hardware: why?
  • 12. Motivations
    • Increasing need for behavioral flexibility in embedded systems design
      • Support of new standards, e.g. in media processing
      • Addition of new features
    • Applications too large to fit on the device all at once
    • Current configurable devices allow us to obtain this
      • FPGAs
    • However, we need a way to process a specification to make it suitable for reconfigurable implementation
  • 13. Aims
    • Define and implement a partitioning approach to produce descriptions of module-based reconfigurable systems from a specification
    • In particular:
      • Propose an algorithm to produce partitioning candidates
      • Propose criteria to evaluate the candidates
      • Use a proven scheduling and allocation approach for reconfigurable systems to complete the flow
  • 14. Core Generation
    • Process the specification graph, producing a set of clusters possibly to be used as configurable modules
    • Self-similarity: rationale
      • Configuring modules onto an FPGA takes time
      • Identifying recurrent structures allows us to reuse them
      • Gain in reconfiguration time, thus better performance
    • Extracting regularity means detecting isomorphism
  • 15. Core Generation
    • Result of the core generation phase:
    • Choice of which of the identified cores to use
      • Policies: LFF, MFF…
    • Greedy approach: choose the winning core, then eliminate the overlapping ones
  • 16. Cover Generation
  • 17. Cover Generation
  • 18. Cover Generation: Result
  • 19. DRESD Project examples
    • HLR
      • Some theoretical aspects
    • YaRA
      • The reconfigurable architecture
    • Acheronte
      • The back-end design flow
    • YaRA and Acheronte extension
    • LINUX
      • Reconfiguration operating System support
      • Microlinux
    • SyCERS
      • The simulation framework
    • LimboWARE
      • Reconfigurable computing, some new idea
    • VIRGIL
      • A new possible flow
  • 20. YaRA: the embedded 1D approach
  • 21. YaRA: fixed side
  • 22. YaRA: FPGA Layers Clock Modulo Riconf. Macro HW PPC-405 BRAM e Moltiplicatori 18x18 Parte Fissa CLB x CLB y Layer
  • 23. DRESD Project examples
    • HLR
      • Some theoretical aspects
    • YaRA
      • The reconfigurable architecture
    • Acheronte
      • The back-end design flow
    • YaRA and Acheronte extension
    • LINUX
      • Reconfiguration operating System support
      • Microlinux
    • SyCERS
      • The simulation framework
    • LimboWARE
      • Reconfigurable computing, some new idea
    • VIRGIL
      • A new possible flow
  • 24. The Acheronte flow
  • 25. DRESD Project examples
    • HLR
      • Some theoretical aspects
    • YaRA
      • The reconfigurable architecture
    • Acheronte
      • The back-end design flow
    • YaRA and Acheronte extension
    • LINUX
      • Reconfiguration operating System support
      • Microlinux
    • SyCERS
      • The simulation framework
    • LimboWARE
      • Reconfigurable computing, some new idea
    • VIRGIL
      • A new possible flow
  • 26. How to extend YaRA and Acheronte
    • The “YaRA” side:
      • HW-IPCM
      • D-ICAP
      • BiRF
      • IP-Core Generator Tool
      • EDK System Creator
    • The “Acheronte” side:
      • BUBA
      • ComIC
      • ADG
      • BAnMaT
  • 27. D-ICAP: DRESD - ICAP
    • Objectives
      • Define the DRESD – ICAP core, characterized by the following parameters:
        • Support for different bus infrastructure
        • Custom buffer memory dimension
        • Support DMA communication
    • Rationale
      • Create a tool able to design a specific D-ICAP IP-Core according to the listed parameters
  • 28. BiRF: Bitstream Relocation Filter
    • Objectives
      • Automatic replacement of a reconfiguration bitstream
      • HW implementation of such a filter to speed-up its execution
    • Rationale
      • Target: reduce the amount of memory used to store partial bitstreams in dynamically self reconfiguring systems based on column-wise approach
      • Methodology: bitstream relocation
      • Solution: an hardware filter created to perform internal bitstream relocation
  • 29.
    • Objectives
      • Realize a framework able to automatically generate an IP-Core starting from an already existing core, provided by the user.
      • Support the PLB, OPB and the Wishbone BUS infrastructure
      • Fully support the YARA architecture
      • EDK compatible
    • Rationale
      • Reduce the overall IP-Core design time;
      • Speedup the reconfigurable cores generation phase in the Acheronte workflow;
      • Increment cores reuse with different communication infrastructures.
    IP-Core Generator Tool
  • 30. EDK System Creator
    • Objectives
      • Given a known EDK system architecture and a generic IP-Core description
        • Automatic binding of the two inputs into a downloadable and executable bitstream
      • Fully support the YARA architecture
    • Rationale
      • Speedup the creation of the YaRA fixed side according to the specific IP-core belonging to the input specification
      • Full-automatic support to the YaRA fixed side generation phase, combining it with the IPGen tool
  • 31. BUBA
    • Objectives
      • Assign the placement constraints for a reconfigurable core to be used with the YARA architecture
      • Find the best floorplanning constraints according with different optimization function, e.g. #AssignedCLBs/#UsedCLBs
    • Rationale
      • Automatic generation of the correct placement constraints into the UCF file for a self reconfigurable architecture
  • 32. ComIC
    • Objectives
      • Create the communication infrastructure for a given instance of the YARA architecture
      • Automatic XDL description manipulation to define the correct MacroHW for the bus infrastructure
    • Rationale
      • Provide a full-automatic support to the generation phase of the communication infrastructure
  • 33. ADG: Automatic Driver Generator
    • Objectives
      • Complete the IP-Core Generator tool work with the creation of the correct driver for a given IP-Core
      • Create the basic infrastructure for both the standalone and the OS version of the driver
  • 34. BAnMaT: Bitstream Analizer Manipulator Tool
    • Objectives
      • Bitstream analyzer
      • Easy API to manage the bitstream file
      • Difference bitstream file checker
      • Reconfiguration bitstream debugger
  • 35. DRESD Project examples
    • HLR
      • Some theoretical aspects
    • YaRA
      • The reconfigurable architecture
    • Acheronte
      • The back-end design flow
    • YaRA and Acheronte extension
    • LINUX
      • Reconfiguration operating System support
      • Microlinux
    • SyCERS
      • The simulation framework
    • LimboWARE
      • Reconfigurable computing, some new idea
    • VIRGIL
      • A new possible flow
  • 36. Linux and reconfiguration software architecture
  • 37. Socket communication
  • 38. Devices communication
  • 39. Architectural Layers
  • 40. R econfiguration O f T he F PGA with L inux
    • Reconfiguration Manager
      • Module Manager
      • Allocation Manager
      • Positioning Manager
  • 41. L oad O n L inux
    • Device Driver Manager
      • Kernel module loading
      • Kernel module unloading
    • Device Manager
      • Add device (/dev/…)
      • Remove device
  • 42. DRESD Project examples
    • HLR
      • Some theoretical aspects
    • YaRA
      • The reconfigurable architecture
    • Acheronte
      • The back-end design flow
    • YaRA and Acheronte extension
    • LINUX
      • Reconfiguration operating System support
      • Microlinux
    • SyCERS
      • The simulation framework
    • LimboWARE
      • Reconfigurable computing, some new idea
    • VIRGIL
      • A new possible flow
  • 43. Microlinux
  • 44. Microlinux structure Kernel Source RamDisk image zImage.elf zImage.initrd.elf U-Boot & Bitstream Deployment on the board
  • 45. Microlinux on Xilinx Virtex II Pro Virtex II Pro S D R A M F L A S H Driver Kernel APs MicroLinux boot image copy load boot contiene Absolute physical addresses
  • 46. Development framework and compilation chain Xilinx Platform Studio Xparameters.h ./genMicroLinux Kernel Image
    • Modular
    • Scalable
    • Small
    eMdev :
  • 47. DRESD Project examples
    • HLR
      • Some theoretical aspects
    • YaRA
      • The reconfigurable architecture
    • Acheronte
      • The back-end design flow
    • YaRA and Acheronte extension
    • LINUX
      • Reconfiguration operating System support
      • Microlinux
    • SyCERS
      • The simulation framework
    • LimboWARE
      • Reconfigurable computing, some new idea
    • VIRGIL
      • A new possible flow
  • 48. SyCERS - Objectives
    • Define a novel model to describe reconfigurable systems
      • Based on know HDL (no new languages)
      • To be used in the early first stage of the project; to consider the reconfiguration at the system level
    • Propose a complete framework for the simulation and the design of reconfigurable systems
      • Providing system specification that can be simulated
      • Allowing fast parameters setting, e.g. number of reconfigurable blocks, reconfigurable time
      • Taking into account the software side of the final system
  • 49. TLM e SystemC
    • In TLM the system is first described at an high level of abstraction where communication details are hidden
    • The key concept of TLM is the separation of functionality definitions from communication details
      • to achieve this TLM uses through the concept of channel
        • DEF.: SystemC channel is a class that implements one or more SystemC interface classes. A channel implements all the methods of the inherited interface classes.
        • DEF.: A SystemC port is a class template with and inheriting from a SystemC interface. Ports allow access of channels across module boundaries.
        • DEF.: A SystemC interface is an abstract class that provides only pure virtual declarations of methods referenced by SystemC channels and ports.
    • SystemC, starting from the 2.0 version, support TLM using the following structures:
    write() read() module A pA->write(v) module B v=pB->read() channel pA pB sc_interface sc_port
  • 50. The SyCERS methodology Specification Model Component Assembly Model Bus Functional Model
    • Define the system functionality
      • No information regarding the final implementation
    • Solution space exploration
      • Provides the functionalities implementation details
      • No information regarding the communication
    • Computed solution validation via the simulation
  • 51. A reconfigurable component using SystemC
    • It’s not possible to instantiate an sc_module during the simulation phase
    • It’s possible to modify the SC_THREAD and the SC_METHOD via:
      • function pointer
      • sc_mutex
    • Configuration
        • Combined with the reconfiguration time
    • Elaboration
        • Provided with the elaboration time
    *g() Reconfigurable Component (sc_module) Configuration (function pointer) mutex
  • 52. Reconfigurable component behavior
  • 53. DRESD online
    • http://www.dresd.org/
    • http://www.dresd.org/forum/
    • tel.elet.polimi.it/dwl
  • 54. Questions
  • 55. END?
    • Are you ready to see how deep the rabbit-hole goes?…