3rd 3DDRESD: OSyRIS

698 views

Published on

Published in: Economy & Finance, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
698
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

3rd 3DDRESD: OSyRIS

  1. 1. Operating System Support for Core Management in a Dynamic Reconfigurable Environment D ynamic R econfigurability in E mbedded S ystems D esign Ivan Beretta: ivan.beretta@dresd.org
  2. 2. Outline <ul><li>Context definition </li></ul><ul><li>Aims </li></ul><ul><li>Related works </li></ul><ul><li>Proposed Methodology </li></ul><ul><li>Validation results </li></ul><ul><li>Concluding remarks </li></ul>
  3. 3. Outline <ul><li>Context definition </li></ul><ul><li>Aims </li></ul><ul><li>Related works </li></ul><ul><li>Proposed Methodology </li></ul><ul><li>Validation results </li></ul><ul><li>Concluding remarks </li></ul>
  4. 4. Reconfigurable devices <ul><li>Reconfigurable devices can be re-programmed multiple times during their lifetime </li></ul><ul><ul><li>High reusability </li></ul></ul><ul><ul><li>Dynamic reconfiguration </li></ul></ul><ul><li>Field Programmable Gate Arrays (FPGAs) </li></ul><ul><ul><li>Large amount of computational resources </li></ul></ul><ul><ul><li>System-on-Chip </li></ul></ul><ul><ul><li>Software multitasking </li></ul></ul>
  5. 5. Some Definitions <ul><li>Configuration Code : the executable active physical (either hardware or software) implementation of a given functionality </li></ul><ul><ul><li>E.g. Bitstream and partial bitstreams for hardware implementations on FPGAs </li></ul></ul><ul><li>Relocation : the ability of moving a configuration code from a location to a new one </li></ul><ul><li>Reconfiguration Controller : the element that is responsible for the physical implementation of the reconfiguration process </li></ul><ul><ul><li>E.g. The Internal Configuration Access Port (ICAP) on Xilinx FPGAs </li></ul></ul><ul><li>Core : a representation of a functionality </li></ul><ul><ul><li>E.g. It is possible to have a core described in VHDL, in C or in an intermediate representation (e.g. a DFG) </li></ul></ul><ul><li>IP-Core : a core described using a HDL combined with its communication infrastructure (i.e. the bus interface) </li></ul><ul><ul><li>It can be configured on the FPGA as a part of the whole system </li></ul></ul>
  6. 6. Classification of reconfigurable architectures (1 of 2) <ul><li>Static vs Dynamic </li></ul><ul><ul><li>Can an FPGA be reconfigured during its execution? </li></ul></ul><ul><li>Internal vs External </li></ul><ul><ul><li>Is a reconfiguration controller accessible within the FPGA? </li></ul></ul><ul><li>Partial vs Total </li></ul><ul><ul><li>Is the whole FPGA area being reconfigured? </li></ul></ul><ul><li>Module based vs Difference based </li></ul><ul><ul><li>Does the reconfiguration process involve a small number of logic gates or an entire IP-Core? </li></ul></ul>
  7. 7. Classification of reconfigurable architectures (2 of 2) <ul><li>Mono-dimensional vs Bi-dimensional </li></ul><ul><ul><li>Is there any limitation on the IP-Core shape? </li></ul></ul><ul><li>Reference architecture </li></ul><ul><ul><li>Dynamic, internal, partial, module based and mono-dimensional </li></ul></ul>
  8. 8. Reconfiguration challenges <ul><li>Reconfiguration times heavily impact on the final solution’s latency </li></ul><ul><li>Possible solution: </li></ul><ul><ul><li>Maximize the reuse of configured modules </li></ul></ul><ul><ul><li>Reconfiguration hiding </li></ul></ul><ul><ul><li>Alternative implementation (Software execution) </li></ul></ul><ul><li>Software has a huge role in the reconfiguration process </li></ul><ul><ul><li>User applications request functionalities and IP-Cores </li></ul></ul><ul><ul><li>A software code manages requests and optimizes the overall latency </li></ul></ul>
  9. 9. Why do applications ask for IP-Cores? <ul><li>Software applications are executed on a General Purpose Processor (GPP) on the FPGA </li></ul><ul><ul><li>They may require hardware acceleration </li></ul></ul><ul><li>90-10 rule </li></ul><ul><ul><li>90% of the execution is spent in 10% of the code </li></ul></ul><ul><ul><ul><li>Inner loops in algorithms </li></ul></ul></ul><ul><ul><ul><li>Computational intense code </li></ul></ul></ul><ul><ul><li>10% of the execution is spent in 90% of the code </li></ul></ul><ul><ul><ul><li>Exceptions </li></ul></ul></ul><ul><ul><ul><li>User interaction </li></ul></ul></ul><ul><ul><li>The 10% computational intense code has to be executed as hardware on reconfigurable devices </li></ul></ul><ul><ul><li>The 90% exception code is run as executable files on GPPs </li></ul></ul>
  10. 10. Software applications and reconfiguration management <ul><li>Who manages the reconfiguration process? </li></ul><ul><ul><li>Standalone vs Operating System solutions </li></ul></ul><ul><li>Standalone solutions directly interact with the reconfigurable device </li></ul><ul><ul><li>Deal with the specific hardware and the specific task </li></ul></ul><ul><ul><li>Lack of portability and reusability </li></ul></ul><ul><li>Operating systems take care of the reconfiguration issues </li></ul><ul><ul><li>Increased portability of user applications </li></ul></ul><ul><ul><li>Inherited multitasking capabilities </li></ul></ul>
  11. 11. Outline <ul><li>Context definition </li></ul><ul><li>Aims </li></ul><ul><li>Related works </li></ul><ul><li>Proposed Methodology </li></ul><ul><li>Validation results </li></ul><ul><li>Concluding remarks </li></ul>
  12. 12. Aims <ul><li>Problem statement </li></ul><ul><ul><li>Operating system definition aimed at an efficient exploitation of the potentiality provided by dynamic reconfigurable architectures. </li></ul></ul><ul><li>Aims </li></ul><ul><ul><li>[A1] Definition of a portable solution for the partial reconfiguration management, based on a widely used kernel such as Linux </li></ul></ul><ul><ul><li>[A2] Implementation of a hardware-independent interface for software applications </li></ul></ul><ul><ul><li>[A3] Efficient management of FPGA resources within the operating system </li></ul></ul>
  13. 13. Outline <ul><li>Context definition </li></ul><ul><li>Aims </li></ul><ul><li>Related works </li></ul><ul><li>Proposed Methodology </li></ul><ul><li>Validation results </li></ul><ul><li>Concluding remarks </li></ul>
  14. 14. Related works <ul><li>Two main classes of OSs for FPGAs </li></ul><ul><ul><li>Specific operating systems to handle dynamic reconfiguration </li></ul></ul><ul><ul><li>Extensions of GNU/Linux kernels </li></ul></ul><ul><li>Implementations for multiple architectures and applications </li></ul><ul><ul><li>Single and multi FPGA systems </li></ul></ul><ul><ul><li>Real-time systems </li></ul></ul><ul><li>Area management and hardware preemption explored outside the scope of an OS </li></ul>
  15. 15. Specific OSs for dynamic reconfiguration <ul><li>Tightly coupled with the specific hardware [1][3] </li></ul><ul><ul><li>Advanced runtime functionalities </li></ul></ul><ul><ul><li>Lack of portability on different architectures </li></ul></ul><ul><ul><li>Lack of a user interface </li></ul></ul><ul><li>ReConfigME [2] explicitly deals with user interfaces </li></ul><ul><ul><li>Still a custom interface </li></ul></ul><ul><ul><li>Not suitable for software development </li></ul></ul>[1] Wigley and Kearney: The management of applications for reconfigurable computing using an operating system . In Seventh Asia-Pacific Computer Systems Architectures Conference (ACSAC2002), eds. F. Lai and J. Morris, Melbourne, Australia, 2002. ACS. [2] Wigley et al.: ReConfigME: a detailed implementation of an operating system for reconfigurable computing . Parallel and Distributed Processing Symposium, 2006. IPDPS 2006. 20th International, April 2006. [3] Steiger et al.: Operating systems for reconfigurable embedded platforms: online scheduling of real-time tasks . Transactions on Computers, 53(11):1393–1407, November 2004.
  16. 16. Operating systems based on Linux <ul><li>Dynamic reconfiguration support within the Linux kernel </li></ul><ul><ul><li>Standard and well-known programming interface </li></ul></ul><ul><li>Access to the reconfiguration controller [4][5][7] </li></ul><ul><ul><li>Software application can configure their own bitstreams </li></ul></ul><ul><ul><li>Interaction with configured IP-Cores </li></ul></ul><ul><ul><li>Only a “bridge” between user applications and the FPGA </li></ul></ul><ul><li>Transparency between hardware and software implementations in BORPH [6] </li></ul><ul><ul><li>No efficient FPGA exploitation </li></ul></ul>[4] Donato et al.: Operating system support for dynamically reconfigurable SoC architectures . SOC Conference, 2005. Proceedings. IEEE International, pages 233–238, September 2005. [5] Williams and Bergmann: Embedded linux as a platform for dynamically self-reconfiguring systems-on-chip . In Proceedings of the International Conference on Engineering of Reconfigurable Systems and Algorithms, ed. T. P. Plaks, pages 163–169. CSREA Press, June 2004. [6] So and Brodersen: Improving usability of FPGA-based reconfigurable computers through operating system support . Field Programmable Logic and Applications, 2006. FPL ’06. International Conference on, pages 1–6, 2006. [7] Donato, A., Ferrandi, F., Redaelli, M., Santambrogio, M. D., and Sciuto, D.: Exploiting partial dynamic reconfiguration for SOC design of complex application on FPGA platform . Ricardo Augusto da Luz Reis, Adam Osseiran, Hans-Jorg Pfleiderer (Eds.): VLSI-SoC: From System To Sylicon, Springer 2007, pp.:87-109
  17. 17. Outline <ul><li>Context definition </li></ul><ul><li>Aims </li></ul><ul><li>Related works </li></ul><ul><li>Proposed Methodology </li></ul><ul><ul><li>The Caronte flow </li></ul></ul><ul><ul><li>Reconfiguration support </li></ul></ul><ul><ul><li>Linux Reconfiguration Manager </li></ul></ul><ul><ul><li>Implementation of the LRM </li></ul></ul><ul><li>Validation results </li></ul><ul><li>Concluding remarks </li></ul>
  18. 18. The Caronte flow HW: Hardware RHW: Reconfigurable HW SW: Software
  19. 19. The 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>
  20. 20. The 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>
  21. 21. Outline <ul><li>Context definition </li></ul><ul><li>Aims </li></ul><ul><li>Related works </li></ul><ul><li>Proposed Methodology </li></ul><ul><ul><li>The Caronte flow </li></ul></ul><ul><ul><li>Reconfiguration support </li></ul></ul><ul><ul><li>Linux Reconfiguration Manager </li></ul></ul><ul><ul><li>Implementation of the LRM </li></ul></ul><ul><li>Validation results </li></ul><ul><li>Concluding remarks </li></ul>
  22. 22. 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>
  23. 23. 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>
  24. 24. Implementation of reconfiguration support <ul><li>Implementation by means of two kernel modules and a high-level library </li></ul><ul><li>Pros: the OS can handle the entire reconfiguration process </li></ul><ul><li>Cons: inefficient exploitation of FPGA resources </li></ul><ul><ul><li>Each application has a limited knowledge of the FPGA status </li></ul></ul><ul><ul><li>User applications are aware of the underlying reconfiguration </li></ul></ul>
  25. 25. Outline <ul><li>Context definition </li></ul><ul><li>Aims </li></ul><ul><li>Related works </li></ul><ul><li>Proposed Methodology </li></ul><ul><ul><li>The Caronte flow </li></ul></ul><ul><ul><li>Reconfiguration support </li></ul></ul><ul><ul><li>Linux Reconfiguration Manager </li></ul></ul><ul><ul><li>Implementation of the LRM </li></ul></ul><ul><li>Validation results </li></ul><ul><li>Concluding remarks </li></ul>
  26. 26. Reconfigurable Process <ul><li>Reconfigurable process : a configuration 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>Configuration Code Accounting </li></ul></ul><ul><ul><li>Information : </li></ul></ul><ul><ul><ul><li>Configuration Code pointer </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>
  27. 27. 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>
  28. 28. A further level of abstraction
  29. 29. Outline <ul><li>Context definition </li></ul><ul><li>Aims </li></ul><ul><li>Related works </li></ul><ul><li>Proposed Methodology </li></ul><ul><ul><li>The Caronte flow </li></ul></ul><ul><ul><li>Reconfiguration support </li></ul></ul><ul><ul><li>Linux Reconfiguration Manager </li></ul></ul><ul><ul><li>Implementation of the LRM </li></ul></ul><ul><li>Validation results </li></ul><ul><li>Concluding remarks </li></ul>
  30. 30. Implementation of the LRM
  31. 31. Selection of hardware/software implementations <ul><li>Multiple implementations of the same functionality </li></ul><ul><ul><li>Hardware implementations with different timing performances or area constraints </li></ul></ul><ul><ul><li>Software implementations </li></ul></ul><ul><li>Selection among the implementations </li></ul><ul><ul><li>Expected number of iterations </li></ul></ul><ul><ul><li>Reconfiguration overhead </li></ul></ul><ul><ul><li>Processor and FPGA usage </li></ul></ul><ul><li>The Reconfigurable process abstraction does not allow user applications to be aware of the chosen implementation </li></ul>
  32. 32. Module caching <ul><li>What happens when a hardware module is released? </li></ul><ul><ul><li>Hard removal </li></ul></ul><ul><ul><li>Soft removal </li></ul></ul><ul><ul><li>Caching </li></ul></ul><ul><li>A cached module can be reused without the reconfiguration overhead </li></ul><ul><li>Modules are cached according to the Reconfigurable Process Caching Value (RPC) </li></ul><ul><ul><li>Stored in the RPCB </li></ul></ul><ul><ul><li>Updated when a module is reused or removed </li></ul></ul>
  33. 33. Preemptive module allocation <ul><li>Allocation policy decides where a module needs to be placed on the FPGA </li></ul><ul><li>Reconfigurable area may be fragmented </li></ul><ul><ul><li>An IP-Core cannot be placed even if enough area is available </li></ul></ul><ul><ul><li>A module cannot be split into different slots </li></ul></ul><ul><li>Preemption of active </li></ul><ul><li>IP-Cores and defragmentation </li></ul>Static Part IP-Core 1 IP-Core 2 IP-Core 3 IP-Core 4 Static Part IP-Core 2 IP-Core 3 IP-Core 1 Static Part IP-Core 2 IP-Core 3 IP-Core 1 IP-Core 4
  34. 34. Preemptive allocation rules <ul><li>Fragmentation can be prevented by keeping the free area clustered </li></ul><ul><ul><li>If more than one location is available, we need policies to choose among them (e.g. the smallest one is chosen) </li></ul></ul><ul><li>If the area is fragmented, defragmentation is performed </li></ul><ul><ul><li>E.g. in a mono-dimensional environment, all the IP-Cores are pushed on the left side </li></ul></ul><ul><li>If a module has to be relocated, it is preempted </li></ul><ul><ul><li>The context must be read and restored </li></ul></ul>Static Part IP-Core 1 IP-Core 2 IP-Core 3 IP-Core 4 Static Part IP-Core 1 IP-Core 2 IP-Core 3
  35. 35. Outline <ul><li>Context definition </li></ul><ul><li>Aims </li></ul><ul><li>Related works </li></ul><ul><li>Proposed Methodology </li></ul><ul><li>Validation results </li></ul><ul><li>Concluding remarks </li></ul>
  36. 36. Validation Results <ul><li>Experimental results for the proposed OS </li></ul><ul><ul><li>Testing of the reconfiguration support </li></ul></ul><ul><ul><li>Two case studies to validate the centralized approach </li></ul></ul><ul><li>Simulation results for the preemptive allocation policy </li></ul><ul><li>Testing framework </li></ul><ul><ul><li>Linux kernel: μCLinux </li></ul></ul><ul><ul><ul><li>ELDK and PetaLinux distributions </li></ul></ul></ul><ul><ul><li>Two FPGAs: Xilinx Virtex-II Pro xc2vp7 and xc2vp30 </li></ul></ul><ul><ul><ul><li>Internal Configuration Access Port (ICAP) </li></ul></ul></ul><ul><ul><li>Two processors: PowerPC and MicroBlaze </li></ul></ul><ul><ul><ul><li>Different approaches to memory management </li></ul></ul></ul>
  37. 37. Dynamic reconfiguration support (1 of 2) <ul><li>PowerPC architecture on Virtex-II Pro vp7 </li></ul><ul><li>Introduction of a device driver for the ICAP device </li></ul><ul><li>Dynamic reconfiguration accessed from the shell </li></ul><ul><li># cat bistream_name.bit > /dev/icap </li></ul><ul><li># ioctl /dev/icap c 2 </li></ul>
  38. 38. Dynamic reconfiguration support (2 of 2) Throughput enhancement of ~ 2x compared to [7] [7] Donato, A., Ferrandi, F., Redaelli, M., Santambrogio, M. D., and Sciuto, D.: Exploiting partial dynamic reconfiguration for SOC design of complex application on FPGA platform . Ricardo Augusto da Luz Reis, Adam Osseiran, Hans-Jorg Pfleiderer (Eds.): VLSI-SoC: From System To Sylicon, Springer 2007, pp.:87-109
  39. 39. First case study: simple logic application (1 of 2) <ul><li>Test of the Linux Reconfiguration Manager </li></ul><ul><ul><li>Selection between multiple implementations </li></ul></ul><ul><li>PowerPC-based hardware architecture </li></ul><ul><li>Inversion of 1 to 8 bits in a 8-bit register </li></ul><ul><ul><li>Software version writes 1 bit at a time </li></ul></ul><ul><ul><li>Hardware version reconfigures the entire register </li></ul></ul><ul><li>Communication between clients and LRM based on UNIX sockets </li></ul><ul><ul><li>Clients connect to the LRM and request the functionality </li></ul></ul><ul><ul><li>LRM generates a new process to serve the request </li></ul></ul><ul><ul><li>The new process computes and returns the result </li></ul></ul>
  40. 40. First case study: simple logic application (2 of 2)
  41. 41. Second case study: cryptography application (1 of 2) <ul><li>Two cryptographic algorithms available on the LRM </li></ul><ul><ul><li>Data Encryption Standard (DES) </li></ul></ul><ul><ul><li>Advanced Encryption Standard (AES) </li></ul></ul><ul><li>MicroBlaze architecture on Virtex-II Pro vp30 </li></ul>
  42. 42. Second case study: cryptography application (2 of 2) <ul><li>Area occupation </li></ul><ul><li>Performances </li></ul>AES IP-Core  DES IP-Core  Static part  Throughput w/ caching = 246 kB/s Throughput w/ caching = 436 kB/s
  43. 43. Evaluation of IP-Core preemption (1 of 2) <ul><li>Simulation results </li></ul><ul><ul><li>Lack of a runtime relocation technique </li></ul></ul><ul><li>When an IP-Core is preempted: </li></ul><ul><ul><li>Its context must be stored </li></ul></ul><ul><ul><li>It must wait until the new location is available </li></ul></ul><ul><ul><li>It must be reconfigured on the device </li></ul></ul><ul><li>Total delay: </li></ul><ul><li>IP-Cores are associated a timing constraint </li></ul><ul><ul><li>If they cannot meet the constraint, they are discarded </li></ul></ul><ul><ul><li>Otherwise, they are accepted </li></ul></ul>
  44. 44. Evaluation of IP-Core preemption (2 of 2) [3] Steiger et al.: Operating systems for reconfigurable embedded platforms: online scheduling of real-time tasks . Transactions on Computers, 53(11):1393–1407, November 2004.
  45. 45. Outline <ul><li>Context definition </li></ul><ul><li>Aims </li></ul><ul><li>Related works </li></ul><ul><li>Proposed Methodology </li></ul><ul><li>Validation results </li></ul><ul><li>Concluding remarks </li></ul>
  46. 46. Concluding Remarks (1 of 2) <ul><li>[A1] Definition of a portable solution for the partial reconfiguration management, based on a widely used kernel such as Linux </li></ul><ul><ul><li>Portable on different processors </li></ul></ul><ul><ul><li>Portable on different distributions </li></ul></ul><ul><li>[A2] Implementation of a hardware-independent interface for software applications </li></ul><ul><ul><li>Hardware-specific issues handled by the LRM </li></ul></ul><ul><ul><li>Hardware/software transparency </li></ul></ul>
  47. 47. Concluding Remarks (2 of 2) <ul><li>[A3] Efficient management of FPGA resources within the operating system </li></ul><ul><ul><li>Centralized control of device resources </li></ul></ul><ul><ul><li>Module caching </li></ul></ul><ul><ul><li>Area management and IP-Core preemption </li></ul></ul><ul><li>Collaborations with National Chung Cheng University (Taiwan) and Heinz Nixdorf Institut (Germany) </li></ul>
  48. 48. Future works <ul><li>Extension to bi-dimensional environments </li></ul><ul><ul><li>More complex allocation policies </li></ul></ul><ul><ul><li>More complex defragmentation techniques </li></ul></ul><ul><li>Integration with a runtime relocation tool </li></ul><ul><ul><li>Bitstreams can be relocated anywhere on the FPGA </li></ul></ul><ul><li>Implementation of task migration </li></ul><ul><ul><li>From hardware to software executions and viceversa </li></ul></ul><ul><ul><li>Implementation-independent context saving </li></ul></ul>
  49. 49. References <ul><li>[1] Wigley, G. and Kearney, D.: The management of applications for reconfigurable computing using an operating system . In Seventh Asia-Pacific Computer Systems Architectures Conference (ACSAC2002), eds. F. Lai and J. Morris, Melbourne, Australia, 2002. ACS. </li></ul><ul><li>[2] Wigley, G., Kearney, D., and Jasiunas, M.: ReConfigME: a detailed implementation of an operating system for reconfigurable computing . Parallel and Distributed Processing Symposium, 2006. IPDPS 2006. 20th International, pages 8 pp.–, April 2006. </li></ul><ul><li>[3] Steiger, C., Walder, H., and Platzner, M.: Operating systems for reconfigurable embedded platforms: online scheduling of real-time tasks . Transactions on Computers, 53(11):1393–1407, November 2004. </li></ul><ul><li>[4] Donato, A., Ferrandi, F., Redaelli, M., Santambrogio, M. D., and Sciuto, D.: Exploiting partial dynamic reconfiguration for SOC design of complex application on FPGA platform . Ricardo Augusto da Luz Reis, Adam Osseiran, Hans-Jorg Pfleiderer (Eds.): VLSI-SoC: From System To Sylicon, Springer 2007, pp.:87-109 </li></ul><ul><li>[5] Williams, J. and Bergmann, N.: Embedded linux as a platform for dynamically self-reconfiguring systems-on-chip . In Proceedings of the International Conference on Engineering of Reconfigurable Systems and Algorithms, ed. T. P. Plaks, pages 163–169. CSREA Press, June 2004. </li></ul><ul><li>[6] So, H. K.-H. and Brodersen, R. W.: Improving usability of FPGA-based reconfigurable computers through operating system support . Field Programmable Logic and Applications, 2006. FPL ’06. International Conference on, pages 1–6, August 2006. </li></ul>
  50. 50. General Information <ul><li>Webpage </li></ul><ul><ul><li>www.dresd.org/osyris </li></ul></ul><ul><li>Mailing List </li></ul><ul><ul><li>[email_address] </li></ul></ul><ul><li>Contact </li></ul><ul><ul><li>To have more information regarding the OSyRiS project: </li></ul></ul><ul><ul><ul><li>osyris@dresd.org </li></ul></ul></ul><ul><ul><li>For a complete list of information on how to contact us: </li></ul></ul><ul><ul><ul><li>www.dresd.org/contact_osyris </li></ul></ul></ul>
  51. 51. ¿ Questions ? <ul><li>Thanks for your attention </li></ul>

×