55
POLITECNICO DI MILANO Marco D. Santambrogio [email protected] Metodologie di Progettazine Hardware e Software Reconfigurable Computing Reconfigurable Computing - Projects - Projects - -

MPHS RC Prj

Embed Size (px)

DESCRIPTION

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

Citation preview

  • 1.M etodologie diP rogettazineH ardware eS 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 FPGAtakes time
    • Identifying recurrent structures allows us toreusethem
    • Gain in reconfiguration time, thus better performance
  • Extracting regularity means detectingisomorphism

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 ModuloRiconf. MacroHW PPC-405 BRAM e Moltiplicatori 18x18 ParteFissa 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;
    • Speedupthe 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 reconfigurationsoftware architecture 37. Socket communication 38. Devices communication 39. Architectural Layers 40. R econfigurationO fT heF PGA withL inux

  • Reconfiguration Manager
    • Module Manager
    • Allocation Manager
    • Positioning Manager

41. L oadO nL 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 usingSystemC

  • Its not possible to instantiate an sc_module during the simulation phase
  • Its 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?