• 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
808
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
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. D ynamic R econfigurability in E mbedded S ystem D esign Project Presentation DRESD @ PdM – September 2006
  • 2. Outline
    • Introduction
      • MicroLAB
      • DRESD
        • Philosophy
        • Team and meeting
        • Web
        • Results
        • In the world
    • Reconfiguration
      • Basic principles
      • Where we are working
    • Reconfiguration @ PdM: DRESD
      • Earendil flow
        • DRESD-HLR
        • DRESD-BE
      • DRESD Project examples
    • Questions?
  • 3. What’s next
    • Introduction
      • MicroLAB
      • DRESD
        • Philosophy
        • Team and meeting
        • Web
        • Results
        • In the world
    • Reconfiguration
      • Basic principles
      • Where we are working
    • Reconfiguration @ PdM: DRESD
      • Earendil flow
        • DRESD-HLR
        • DRESD-BE
      • DRESD Project examples
    • Questions?
  • 4.
    • MicroLAB organization:
      • Thesis works: 50-60 /year
      • Class Projects: 80-100 /year
      • PhD students: 8
      • Researchers: 4
      • Professors: 8
    • MicroLAB Workstations:
      • Linux: 26
      • Windows: 3
      • Laptop (Linux/Win): 20
      • SUN: 15
    MicroLAB
  • 5. MicroLAB
  • 6. MicroLAB
  • 7. What’s next
    • Introduction
      • MicroLAB
      • DRESD
        • Philosophy
        • Team and meeting
        • Web
        • Results
        • In the world
    • Reconfiguration
      • Basic principles
      • Where we are working
    • Reconfiguration @ PdM: DRESD
      • Earendil flow
        • DRESD-HLR
        • DRESD-BE
      • DRESD Project examples
    • Questions?
  • 8. DRESD Philosophy
    • Do or do not! There’s no try!
    • Master Yoda
    • I need to believe that something
    • extraordinary is possible!
    • Alicia Nash
  • 9. DRESD Team @ September 2006
    • People
      • 32 Undergraduate students
      • 12 Graduate students
      • 3 PhD
      • 1 Researchers
      • 4 Professors
    • Meeting
      • Regular meeting every two weeks
      • DRESD Beer
      • 3G-DRESD: the DRESD official meeting, August
  • 10. DRESD @ PdM
    • and many more…
  • 11. DRESD online
    • http://www.dresd.org/
    • http://www.dresd.org/forum/
    • tel.elet.polimi.it/dwl
  • 12. DRESD in regular curricula @ PdM a.a. 06/07
    • Undergraduate classes
      • Logic Synthesis (projects)
    • Graduate classes
      • SW Laboratory (projects)
      • Computer Architecture (projects)
      • High Performance Processors and Systems (projects and regular class)
      • Soft Computing (projects)
      • IA and Robotics Lab (projects)
      • Hardware Design Methodologies (projects)
      • Hardware and Software Design Methodologies (projects)
      • Embedded Systems (projects)
  • 13. An example: RLA Project – How to
    • Team
      • Max team members: 3
      • Team leader
        • Create/maintain the project web-page
        • Upload the project documentation on the web-site
        • Prepare the project flayer
    • Project organization
      • A first meeting to assign the project
      • A project proposal presentation (after 2-3 weeks max from the first meeting)
      • Project documentation and results
        • A tex document presenting the project
        • A “ppt” final project presentation
        • The ZIP containing all the file of the project
        • A project demo: files and docs describing how to use the demo
    • MicroLAB logistic
      • Access to the MicroLAB using the Politecnico ID Card
        • Download the access module from the DRESD web site
        • Download the detail instruction document from the DRESD web site
      • MicroLAB laptop connection
        • Download the module form the DRESD web site
        • Fill the module with the required information
  • 14. DRESD Results - Projects and Thesis
    • The next 2 slides (11 - 12) present the number of students involved in MicroLAB activities for their undergraduate thesis work
      • Slide 12 - a.a. 03/04
      • Slide 14 – a.a. 04/05
      • No distinction between DRESD and other MicroLAB activities has been done
    • Slide 16 reports the number of student involved only in the DRESD project for their undergraduate thesis work
      • From the a.a. 05/06 the number of students involved in DRESD allows to study and to monitor only this project
    • Slide 18 lists the number of graduate degree originated by the DRESD project
  • 15. “ Logic Synthesis” Class Project 03/04 Students working in the MicroLAB: 30
  • 16. “ Logic Synthesis” Class Project 03/04 Students working in the MicroLAB: 30
  • 17. “ Logic Synthesis” Class Project 04/05 Students working in the MicroLAB: 75
  • 18. “ Logic Synthesis” Class Project 04/05 Students working in the MicroLAB: 75
  • 19. “ Logic Synthesis” Class Project 05/06 Students working in the DRESD prj: 35
  • 20. “ Logic Synthesis” Class Project 05/06 Students working in the DRESD prj: 35
  • 21. Graduate Degree a.a 05/06
    • April ‘06: 1
      • SyCERS: a SystemC design exploration framework for the simulation of reconfigurable SoC architecture.
    • July ‘06: 2
      • Task partitioning for the scheduling on partially dynamically reconfigurable FPGAs.
      • An hardware resources estimation framework for reconfigurable architecture.
    • October ‘06: 1
      • A novel methodology for dynamically reconfigurable embedded systems design.
    • December ‘06: 1
      • Task partitioning for the scheduling on reconfigurable systems driven by specification self-similarity.
  • 22. DRESD Results Conferences and Publications ’06 –’07
    • Published work:
      • Papers: 15
        • Works presented (‘06): 10
        • Works accepted (‘07): 5
      • Journal: 1
    • Guest editing:
      • EURASIP Journal of Embedded Systems
      • Title: Reconfigurable computing and hardware/software codesign.
    • Conferences Organization:
      • Chair: 3 – ERSA06, ISCAS07, ERSA07
      • PC: 5 – ERSA 06, 07; ReConfig 06, 07; RAW 07
      • EC: 1 – ERSA 07
      • Review
        • International conferences
        • TVLSI
        • JSA
  • 23. DRESD Results Partnerships/Collaborations @ August ‘06
    • Companies:
      • Italian-European:
        • Siemens Mobile, contact: Ferrara Giovanna
        • ATMEL, contacts: Ben Altieri, Piergiovanni Bazzana, Pier Stanislao, Chiara Nencioni
      • American:
        • Xilinx Inc., contacts: Jeff Weintraub, Monica Maccan
        • ImpulseC, contacts: David Buechner, David Pellerin
    • Italian Universities:
      • Collegio Sant’Anna, Contact: prof. Marco Di Natale
      • Università degli studi di Milano, Contacts: prof. Vincenzo Piuri, prof. Roberto Cordone
    • European Universities:
      • ALaRI, contacts: prof.ssa Mariagiovanna Sami, prof. Umberto Bondi
      • Paderborn e Heinz Nixdoerf Institute, contact: prof. Mario Porman
      • Universitaet Karlsruhe, contact: prof. Juergen Becker
      • KTH - Royal Institute of Technology , contact: prof. Axel Jantsch
    • Noth American Universities:
      • UIC, contacts: prof. John Lillis, prof. Florin Balasa, prof. Shantanu Dutt, Lynn Thomas
      • Northwestern, contact: prof. Seda Ogrenci Memik
      • ITTC, contact: prof. David Andrews
    • Asia:
      • National Chung Cheng University - Taiwan, contact: prof. Pao-Ann Hsiung
      • University of Peradeniya – Sri Lanka, contact: prof. Sanath Alahakoon
      • King Mongkut's Institute of Technology - Thailand, contact: prof. Surin Kittitornkun
      • Computer Science and Engineering HCMC University of Technology – Vietnam, contact: prof. Dinh Duc Anh Vu
      • Walchand College of Engineering – India, contact: prof. Shaila Subbaraman
  • 24. DRESD in the WORLD @ August ‘06
    • Europe
      • Paderborn University and HNI
    • USA:
      • UIC
      • Northwestern
  • 25. DRESD and HNI
    • Partitioning and Scheduling
    • Static Scheduling for Reconfigurable Architecture
    • Placement and Scheduling
    • Linux on Raptor2000
    • Dynamic Driver Generation for Custom IPs
    • Distributed reconfigurable scenarios
      • Cluster Based and Network Based
  • 26. DRESD and UIC
    • Memory management
      • Deriving a multilevel memory architecture for distributed embedded systems optimized for area and/or reconfiguration, subject to performance constraints.
      • Definition of a novel set of metrics for self partial reconfigurable architecture, based memory information
    • JHDL
      • Extension JHDL to describe reconfigurable architecture
      • HW debugging using the JHDL framework
    • UML
      • Novel self reconfigurable
      • architecture description and
      • definition, based on UML
  • 27.
    • It is common to consider HW components as fast but not flexible while SW solutions as flexible but slow.
    • With FPGA (in general, reconfigurable computing ): the HW domain has moved into the SW domain.
    • We aim to show also the SW domain might be moved closer into the HW.
      • AC2SWA - Adaptive Computing to SW acceleration
      • AC4C - Adaptive Computing for Codesign
    DRESD and Northwestern
  • 28. What’s next
    • Introduction
      • MicroLAB
      • DRESD
        • Philosophy
        • Team and meeting
        • Web
        • Results
        • In the world
    • Reconfiguration
      • Basic principles
      • Where we are working
    • Reconfiguration @ PdM: DRESD
      • Earendil flow
        • DRESD-HLR
        • DRESD-BE
      • DRESD Project examples
    • Questions?
  • 29. Reconfiguration
    • The process of physically altering the location or functionality of network or system elements. Automatic configuration describes the way sophisticated networks can readjust themselves in the event of a link or device failing, enabling the network to continue operation.
    • Gerald Estrin, 1960
  • 30. Reconfiguration in everyday life
    • Soccer
    Hockey Football (Partial – Static) (Complete – Static) (Partial – Dynamic)
  • 31. What’s next
    • Introduction
      • MicroLAB
      • DRESD
        • Philosophy
        • Team and meeting
        • Web
        • Results
        • In the world
    • Reconfiguration
      • Basic principles
      • Where we are working
    • Reconfiguration @ PdM: DRESD
      • Earendil flow
        • DRESD-HLR
        • DRESD-BE
      • DRESD Project examples
    • Questions?
  • 32. Where we are working Partial Total
  • 33. Where we are working Partial Embedded f i x
  • 34. Where we are working Single Device Distributed System
  • 35. What’s next
    • Introduction
      • MicroLAB
      • DRESD
        • Philosophy
        • Team and meeting
        • Web
        • Results
        • In the world
    • Reconfiguration
      • Basic principles
      • Where we are working
    • Reconfiguration @ PdM: DRESD
      • Earendil flow
        • DRESD-HLR
        • DRESD-BE
      • DRESD Project examples
    • Questions?
  • 36. 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
  • 37. Earendil Design Flow: an Overview DRESD - HLR DRESD - BE
  • 38. DRESD - HLR
  • 39. DRESD - BE
  • 40. What’s next
    • Introduction
      • MicroLAB
      • DRESD
        • Philosophy
        • Team and meeting
        • Web
        • Results
        • In the world
    • Reconfiguration
      • Basic principles
      • Where we are working
    • Reconfiguration @ PdM: DRESD
      • Earendil flow
        • DRESD-HLR
        • DRESD-BE
      • DRESD Project examples
    • Questions?
  • 41. 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
  • 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. Reconfigurable Hardware: why?
  • 44. Reconfigurable Hardware: why?
  • 45. 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
  • 46. 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
  • 47. 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
  • 48. 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
  • 49. Cover Generation
  • 50. Cover Generation
  • 51. Cover Generation: Result
  • 52. 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
  • 53. YaRA: the embedded 1D approach
  • 54. YaRA: fixed side
  • 55. YaRA: FPGA Layers Clock Modulo Riconf. Macro HW PPC-405 BRAM e Moltiplicatori 18x18 Parte Fissa CLB x CLB y Layer
  • 56. 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
  • 57. The Acheronte flow
  • 58. 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
  • 59. 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
  • 60. 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
  • 61. 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
  • 62.
    • 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
  • 63. 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
  • 64. 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
  • 65. 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
  • 66. 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
  • 67. BAnMaT: Bitstream Analizer Manipulator Tool
    • Objectives
      • Bitstream analyzer
      • Easy API to manage the bitstream file
      • Difference bitstream file checker
      • Reconfiguration bitstream debugger
  • 68. 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
  • 69. Linux and reconfiguration software architecture
  • 70. Socket communication
  • 71. Devices communication
  • 72. Architectural Layers
  • 73. R econfiguration O f T he F PGA with L inux
    • Reconfiguration Manager
      • Module Manager
      • Allocation Manager
      • Positioning Manager
  • 74. L oad O n L inux
    • Device Driver Manager
      • Kernel module loading
      • Kernel module unloading
    • Device Manager
      • Add device (/dev/…)
      • Remove device
  • 75. 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
  • 76. Microlinux
  • 77. Microlinux structure Kernel Source RamDisk image zImage.elf zImage.initrd.elf U-Boot & Bitstream Deployment on the board
  • 78. 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
  • 79. Development framework and compilation chain Xilinx Platform Studio Xparameters.h ./genMicroLinux Kernel Image
    • Modular
    • Scalable
    • Small
    eMdev :
  • 80. 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
  • 81. 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
  • 82. 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
  • 83. 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
  • 84. 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
  • 85. Reconfigurable component behavior
  • 86. 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
  • 87. LimboWARE: The idea
    • The basic idea is to postpone the decision of whether executing a task in HW or in SW moving it at run-time
    • This will be done not for every task, because of code memory overhead, but only where is not possible to take a wise choice at design or compile-time
  • 88. LimboWARE: When - Where
    • Compile-time Unbounded number of execution
      • If n is a number known only at run-time. The limbo choice is wiser than the corresponding one done at compile time (without this information)
      • for(i=0; i<n; i++){
      • function();
      • }
    • Execution trace dependent choice between HW and µ-code
      • Functionality already in HW (past)
      • Functionality that in this branch will be used many times (constrained future)
  • 89. LimboWARE: Execution path dependent choice
    • The execution of node 6 depends on the path
      • If the path is 1-3-5-6 the predicate P is TRUE, is executed in HW and the relative µ-code for the SW execution is skipped, by branching after
      • If the path is 2-4-5-6, the predicate P is FALSE, HW_CALL and JMP are not executed and the µ-code for is executed
  • 90. 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
  • 91. VIRGIL: Workflow HLR
  • 92. VIRGIL: The Compiler
  • 93. What’s next
    • Introduction
      • MicroLAB
      • DRESD
        • Philosophy
        • Team and meeting
        • Web
        • Results
        • In the world
    • Reconfiguration
      • Basic principles
      • Where we are working
    • Reconfiguration @ PdM: DRESD
      • Earendil flow
        • DRESD-HLR
        • DRESD-BE
      • DRESD Project examples
    • Questions?
  • 94. Questions