- 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
-
- It is possible to use/design/manage a specific tool or the
entire flow
-
- Easy to add or remove modules/projects
-
- Earendil runs on different platforms: Linux, Mac OS X,
Windows
-
- 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
-
- The reconfigurable architecture
- YaRA and Acheronte extension
-
- Reconfiguration operating System support
-
- Reconfigurable computing, some new idea
9. DRESD Project examples
-
- The reconfigurable architecture
- YaRA and Acheronte extension
-
- Reconfiguration operating System support
-
- Reconfigurable computing, some new idea
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
- Applications too large to fit on the device all at once
- Current configurable devices allow us to obtain this
- 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
-
- 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
- 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
-
- The reconfigurable architecture
- YaRA and Acheronte extension
-
- Reconfiguration operating System support
-
- Reconfigurable computing, some new idea
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
-
- The reconfigurable architecture
- YaRA and Acheronte extension
-
- Reconfiguration operating System support
-
- Reconfigurable computing, some new idea
24. The Acheronte flow 25. DRESD Project examples
-
- The reconfigurable architecture
- YaRA and Acheronte extension
-
- Reconfiguration operating System support
-
- Reconfigurable computing, some new idea
26. How to extend YaRA and Acheronte
27. D-ICAP: DRESD - ICAP
-
- Define the DRESD ICAP core, characterized by the following
parameters:
-
-
- Support for different bus infrastructure
-
-
- Custom buffer memory dimension
-
-
- Support DMA communication
-
- Create a tool able to design a specific D-ICAP IP-Core
according to the listed parameters
28. BiRF: Bitstream Relocation Filter
-
- Automatic replacement of a reconfiguration bitstream
-
- HW implementation of such a filter to speed-up its
execution
-
- 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.
-
- 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
-
- 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
-
- 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
-
- 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
-
- 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
-
- Automatic generation of the correct placement constraints into
the UCF file for a self reconfigurable architecture
32. ComIC
-
- 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
-
- Provide a full-automatic support to the generation phase of the
communication infrastructure
33. ADG: Automatic Driver Generator
-
- 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
-
- Easy API to manage the bitstream file
-
- Difference bitstream file checker
-
- Reconfiguration bitstream debugger
35. DRESD Project examples
-
- The reconfigurable architecture
- YaRA and Acheronte extension
-
- Reconfiguration operating System support
-
- Reconfigurable computing, some new idea
36. Linux and reconfigurationsoftware architecture 37. Socket
communication 38. Devices communication 39. Architectural Layers
40. R econfigurationO fT heF PGA withL inux
41. L oadO nL inux
42. DRESD Project examples
-
- The reconfigurable architecture
- YaRA and Acheronte extension
-
- Reconfiguration operating System support
-
- Reconfigurable computing, some new idea
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
eMdev : 47. DRESD Project examples
-
- The reconfigurable architecture
- YaRA and Acheronte extension
-
- Reconfiguration operating System support
-
- Reconfigurable computing, some new idea
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:
-
-
- Combined with the reconfiguration time
-
-
- 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/forum/
54. Questions 55. END?
- Are you ready to see how deep the rabbit-hole goes?