Abstract

Many high-performance, embedded applications work in rapidly changing environments. Both power and size constraints limit hardware, while performance requirements demand algorithm-specific architectures. Adaptive systems combine flexibility of software with the possibility of adapting hardware to varying requirements. These adaptive systems contain reconfigurable computing devices integrated in a fixed infrastructure and unchangeable components. Reconfigurable computing devices enable hardware architecture changes in response to the changing environment. Various static and dynamic adaptation methods already exist. However, existing dynamic methods are restricted to do hardware changes prior application execution. In this work we develop a new dynamic method, which allows applicationspecific hardware changes during application runtime. In order to achieve this goal a new method of hardware-based monitoring and controlling is utilized. Because the system hardware layer has a very restricted view in matters of application goals, it is necessary to involve all system layers into the adaptation process. Therefore we develop the Metamorphosys concept. To proof the quality of the concept, the adaptive processor-as an example system component-was developed. This processor incorporates one single off-the-shelf processor-core with additional reconfigurable resources and pattern-based monitoring and controlling functions. Different benchmark programs have shown that the developed adaptive processor equals other approaches in terms of computing performance but show a reduced utilization of hardware-resources by at least 20%. The results of this work are also applicable in the domain of the design of high-performance computers, which are based on fast general-purpose processor-cores and additional configurable accelerator devices.

Kurzfassung

Viele Anwendungen im Bereich der eingebetteten Systeme erfordern hohe Rechenleistung und eine zeitnahe Anpassung an sich ¨ andernde Umgebungsbedingungen. Hierf¨ ur eignen sich adaptive Systeme, die neben der Flexibilit¨ at durch Software zus¨ atzlich eine Anpassung der System-Hardware erlauben. Adaptive Systeme verf¨ ugen ¨ uber eine vorgegebene,

unver¨ anderbare Struktur mit zus¨ atzlichen rekonfigurierbaren Ressourcen. Letztere erlauben eine Hardware-Anpassung an konkrete Anwendungen oder Anwendungsbereiche mittels anwendungsspezifischer logischer Schaltungen. Diesbez¨ uglich existieren statische und grobk¨ ornige dynamische Anpassungsmechanismen. Im Zuge dieser Arbeit wurde ein feingranularer Ansatz untersucht, der es erm¨ oglicht eine zeitnahe dynamische Anpassung auf Grund des Anwendungsverhaltens durchzuf¨ uhren. Die Grundlage der Adaption ist eine hardwarebasierte ¨ Uberwachung und Regelung der, mit rekonfigurierbaren Kapazit¨ aten ausgestatteten, Systemkomponenten. Die gesammelten Messdaten werden in Form von Mustern abgelegt und ausgewertet. Auf Grund der beschr¨ ankten Sichtweise der Hardware im Bezug auf die Zielsetzung einer Anwendung und des Gesamtsystems, bedarf es diverser Erweiterungen aller Systemschichten. In diesem Zusammenhang ist das Metamorphosys -Konzept entstanden, das s¨ amtliche Systemschichten mit in den Adaptionsprozess einbindet. Exemplarisch werden die ¨ Uberwachungs- und Regelungsmechanismen am adaptiven Prozessor gezeigt. Die Untersuchungen mithilfe verschiedener, in ihren Adaptionsm¨ oglichkeiten beschr¨ ankten, Bewertungsprogramme ergeben zu vergleichbaren adaptiven Ans¨ atzen ¨ aquivalente Leistungsdaten f¨ ur den adaptiven Prozessor und dar¨ uber hinaus einen ca. 20% geringeren Ressourcenbedarf. Des Weiteren schaffen diese Untersuchungen die Grundlagen f¨ ur den Entwurf von Hochge-schwindigkeitsprozessoren, die aus einem leistungsf¨ ahigen Kern und zus¨ atzlichen dynamisch umdefinierbaren Acceleratoren bestehen.

Danksagung

Im Laufe der Arbeit an dieser Dissertation unterst¨ utzten mich viele Menschen mit Worten und Taten, bei denen allen ich mich sehr herzlich bedanken m¨ ochte. Obgleich allen ein Platz auf dieser Seite zust¨ unde, kann im Folgenden nicht jeder namentlich erw¨ ahnt werden:

Allen voran geb¨ uhrt Prof. Dr. Arndt Bode mein gr¨ oßter Dank. Insbesondere daf¨ ur, dass er mir ¨ uberhaupt erst die Arbeit an meiner Dissertation erm¨ oglichte und in meinen Jahren am Lehrstuhl f¨ ur Rechnertechnik und Rechnerorganisation der Technischen Universit¨ at M¨ unchen ein hervorragendes Arbeitsumfeld zur Verf¨ ugung gestellt hat.

Zudem bin ich Prof. Eike Jessen zu Dank verpflichtet, da er kurzfristig als Gutachter zu gewinnen war und in sehr kurzer Zeit noch viele wertvolle Anmerkungen und ¨ Anderungsvorschl¨ age einbrachte.

Außerdem hatte ich w¨ ahrend der gesamten Zeit das Gl¨ uck und die Gelegenheit mit herausragenden Wissenschaftlern und Pers¨ onlichkeiten zusammenzuarbeiten. Besonders zu erw¨ ahnen sind in diesem Zusammenhang Wolfgang Karl, Martin Schulz und Carsten Trinitis, die mir als Betreuer zur Seite standen.

Die Liste derjeniger, die mich am Lehrstuhl mit zahlreichen fachlichen und manchmal auch nicht so fachlichen Diskussionen, aber stets mit wertvollen Ideen bereicherten und in meiner Arbeit unterst¨ utzten, ist lang. Unter anderem z¨ ahlen Georg Acher, Rainer Buchty, Jan-Thomas Czornack, Michael Eberl, Amitava Gupta, Elfriede Kelp, Edmond Kereku, Markus Lindermeier, Robert Lindhof, Thomas Ludwig, Peter Luksch, Martin Mairandres, Harald Meier, J¨ urgen Obermeier, Bruno Piochacz, G¨ unther Rackl, Sabine Rathmayer, Karl-Heinz Seubert, Andreas Schmidt, Alexandros Stamatakis, Daniel Stodden, Jie Tao, Klaus Tilk, Max Walter, Josef Weidendorfer, Christian Weiß und Roland Wism¨ uller zu ihnen.

Dar¨ uber hinaus m¨ ochte ich mich bei Beate Hinterwimmer, der guten Fee des Lehrstuhls, bedanken, dass sie mir stets bei organisatorischen Problemen mit Rat und Tat behilflich war.

Einen weiteren entscheidenden Beitrag zur Durchf¨ uhrung dieser Arbeit hat mein privates Umfeld geleistet. Obwohl alle wert w¨ aren erw¨ ahnt zu werden, beschr¨ anke ich mich auf die Nennung Dreier, deren Unterst¨ utzung in unmittelbarem Zusammenhang mit meiner Arbeit stand, ohne den Beitrag anderer schm¨ alern zu wollen: Alexander Wißpeintner, der mich wissenschaftlich beraten und stets als Freund hinter mir gestanden hat. Und Peter Obermayer und Lambert Weeber, die auf Grund ihrer langj¨ ahrigen Arbeitserfahrung bei technischen Problemen immer einen Ausweg wussten.

Am Ende angekommen, bleiben nur noch wenige aber nicht minder wertvolle: Meinen Eltern ist f¨ ur ihre unerm¨ udliche jahrelange Unterst¨ utzung, in jeglicher Hinsicht, zu danken. Ebenso

meiner kleinen Schwester, die es versteht mich immer aufzuheitern. Und meiner Partnerin Elke Braumiller, die, wenn auch verst¨ andlicher Weise, mit manchmal gemischten Gef¨ uhlen das Fortschreiten meiner Arbeit be¨ augte, einen wichtigen unverzichtbaren Beitrag geleistet hat.

Inhaltsverzeichnis

1  Einleitung und Motivation  1

1.1  Struktur der Arbeit  3

2  Grundlagen  5

2.1  Prozessorarchitektur  5

2.1.1  Befehlssatzarchitektur  5

2.1.2  Leistungsmessung, Bewertung und Effizienz  7

2.1.3  Der Maschinenbefehlszyklus  9

2.1.4  Fließbandverarbeitung  10

2.2  Field Programmable Gate Arrays  13

2.2.1  Aufbau und Struktur von FPGAs  13

2.2.2  Rekonfigurierbarkeit von FPGAs  14

2.2.3  FPGA Derivate  15

2.3  Eingebettete Systeme  16

2.3.1  Leistungsaufnahme  16

2.3.2  Beschr ankungen der Speicherarchitektur  17

2.3.3  Mikroprozessoren f ur eingebettete Systeme  17

2.3.4  Betriebssysteme f ur eingebettete Systeme  21

2.4  Entwurf von Niedrigenergie- und Energiespar-Systemen  23

2.4.1  Drei Ebenen des Systementwurfs  24

3  Regelung von Systemen  31

3.1  Regelkreis und Wirkungsplan  31

3.2  Regler  32

3.3  Digitale Regler  33

3.3.1  Fuzzy-Regler  33

3.3.2  Neuronale Netze  33

3.3.3  Erweiterungen Fuzzy-basierter Regler  34

3.4  Regelungsverfahren auf Basis statistischer Zeitreihenanalyse  34

3.4.1  Statistische Zeitreihenanalyse  35

3.4.2  Zeitreihenprognosen mit statistischen Modellen  38

3.5  Tracking  39

4  Adaptive Rechensysteme  41

4.1  Klassifikation adaptiver Rechensysteme  41

4.2  Einteilung adaptiver Rechensysteme mit rekonfigurierbarer Logik  43

4.2.1  Klassifikation anhand der Rekonfigurationseigenschaften  43

ii

4.2.2 Klassifikation adaptiver Prozessoren . . . . . . . . . . . . . . . . . . . 43 4.3 Dynamische Anpassung von Systemen . . . . . . . . . . . . . . . . . . . . . 44 4.3.1 Adaptivit¨ at von Systemen ohne rekonfigurierbare Logik . . . . . . . . 44 4.3.2 Adaptivit¨ at von FPGA-basierten Systemen . . . . . . . . . . . . . . . 45 4.4 Bestehende FPGA-basierte adaptive Systeme . . . . . . . . . . . . . . . . . . 46 4.4.1 OneChip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.4.2 Garp und seine Nachfolgeprojekte . . . . . . . . . . . . . . . . . . . . 47 4.4.3 ¨

Uberblick ¨ 4.4.4 ¨ Uberblick ¨ 5 Metamorphosys: Konzept eines autonomen adaptiven Systems 51

5.1 Konzept des Gesamtsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.1.1 Aufbau der Systembibliothek und des Komponentenpools . . . . . . . 56 5.2 Nutzung und Auswirkung der Adaptivit¨ at . . . . . . . . . . . . . . . . . . . 60 5.2.1 Einsatz adaptiver Recheneinheiten . . . . . . . . . . . . . . . . . . . 60 5.2.2 Erweiterung des Betriebssystems . . . . . . . . . . . . . . . . . . . . 67 5.2.3 Implementierungsaspekte adaptiver Komponenten . . . . . . . . . . . 72 5.2.4 Infrastruktur f¨ ur die Konfiguration . . . . . . . . . . . . . . . . . . . 76 5.3 ¨ Uberwachung und Regelung im System . . . . . . . . . . . . . . . . . . . . . 80 5.3.1 Passive und aktive adaptive Systemkomponenten . . . . . . . . . . . 81 5.3.2 Wirkungskreisl¨ aufe adaptiver Komponenten . . . . . . . . . . . . . . 83 5.3.3 Regelungsziel aktiver adaptiver Komponenten . . . . . . . . . . . . . 84 5.3.4 Anwendungsverhalten und Regelungsans¨ atze . . . . . . . . . . . . . . 84 5.3.5 Resultierender Regelungsablauf . . . . . . . . . . . . . . . . . . . . . 95 5.3.6 Grundlagen der ¨ Uberwachungsumsetzung . . . . . . . . . . . . . . . . 97

5.4 Implementierungsaspekte der ¨ 5.4.1 Spezielle Anforderung an eine Hardware-Umsetzung . . . . . . . . . . 118 5.4.2 Grundlegende ¨ Uberwachungsbausteine . . . . . . . . . . . . . . . . . 118

6 Der adaptive Prozessor 127

6.1 Entwurf des adaptiven Prozessors . . . . . . . . . . . . . . . . . . . . . . . . 127 6.1.1 Aufbau und Befehlsfluß . . . . . . . . . . . . . . . . . . . . . . . . . . 130 6.1.2 Dekodierung und Wandlung . . . . . . . . . . . . . . . . . . . . . . . 133 6.1.3 Leistungsbewertung und Vergleich mit der Basisarchitektur . . . . . . 141 6.2 Implementierungsaspekte des adaptiven Prozessors . . . . . . . . . . . . . . 143 6.2.1 Integration der Wandlung . . . . . . . . . . . . . . . . . . . . . . . . 143 6.2.2 Hardware-Implementierung der Wandlung . . . . . . . . . . . . . . . 152 6.2.3 Aufbau des adaptiven Kerns . . . . . . . . . . . . . . . . . . . . . . . 153 6.2.4 Aufbau der Anpassungskomponenten . . . . . . . . . . . . . . . . . . 162 6.2.5 Integration der ¨ Uberwachung und Regelung . . . . . . . . . . . . . . 165

6.2.6 Hardware-Implementierung der ¨

6.3 Simulationsergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 6.3.1 Allgemeine Ergebnisse zur ¨ Uberwachung und Regelung . . . . . . . . 170

6.3.2 Regelungsbasierter Moduleinsatz . . . . . . . . . . . . . . . . . . . . 174 6.3.3 Ergebnisbewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

7 Zusammenfassung und Ausblick 181

7.1 Ausblick und Weiterf¨ uhrendes . . . . . . . . . . . . . . . . . . . . . . . . . . 183 7.1.1 N¨ achste Arbeitsschritte . . . . . . . . . . . . . . . . . . . . . . . . . . 183 7.1.2 Zuk¨ unftige Arbeitsschritte . . . . . . . . . . . . . . . . . . . . . . . . 184

A Simulation des adaptiven Prozessors 187

A.1 Aufbau des Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 A.2 Anwendungs¨ ubersetzung und Ausf¨ uhrung . . . . . . . . . . . . . . . . . . . . 189 A.2.1 Einschr¨ ankungen und bekannte Fehler . . . . . . . . . . . . . . . . . 189 A.2.2 Modulnutzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 A.3 Verifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 A.4 Anmerkungen zur Implementierung des Simulators . . . . . . . . . . . . . . 191 A.5 Ausgabe der ¨ Uberwachungsdaten . . . . . . . . . . . . . . . . . . . . . . . . 191

Glossar 193

Literaturverzeichnis 197

Index 207

Abbildungsverzeichnis

2.1 Prinzipieller Aufbau von FPGAs . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2 Befehlsgruppen des 32 Bit ARM Befehlssatzes . . . . . . . . . . . . . . . . . 19

3.1 Vereinfachte Wirkungspl¨ ane . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Einteilung von Rechensystemen . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.2 Schema der OneChip-Prozessorpipeline . . . . . . . . . . . . . . . . . . . . . 46 4.3 Aufbau der rekonfigurierbaren Funktionseinheit . . . . . . . . . . . . . . . . 47

5.1 Die vier Schichten des adaptiven Systems . . . . . . . . . . . . . . . . . . . 52 5.2 Die logischen Bestandteile des adaptiven Systems . . . . . . . . . . . . . . . 53 5.3 Komponenten der Systembibliothek und des Komponentenpools . . . . . . . 57 5.4 Struktur der Software- und Hardware-Bibliothek . . . . . . . . . . . . . . . 58 5.5 Verwaltung der Systemkomponenten . . . . . . . . . . . . . . . . . . . . . . 59 5.6 Codegenerierung aus einer Hochsprache . . . . . . . . . . . . . . . . . . . . 61 5.7 Erweiterung der Systembibliothek und des Komponentenpools . . . . . . . . 62 5.8 Aufbau eines generierten VM-Programms . . . . . . . . . . . . . . . . . . . 63 5.9 Konfigurationserweiterungen f¨ ur den VM-Code . . . . . . . . . . . . . . . . 64 5.10 Idealisierte Betrachtung eines Kontextwechsels . . . . . . . . . . . . . . . . 69 5.11 Probleme im Zusammenhang mit Anwendungswechsel . . . . . . . . . . . . 70 5.12 Unzureichende Rechenzeit einer Anwendung . . . . . . . . . . . . . . . . . . 71 5.13 Logische Bestandteile adaptiver Komponenten . . . . . . . . . . . . . . . . 72 5.14 Realisierung des Zugriffs auf einzelne adaptive Komponenten . . . . . . . . 73 5.15 Prinzipieller Aufbau der Zustandsinformation . . . . . . . . . . . . . . . . . 74 5.16 Der Zugriff auf adaptive Recheneinheiten . . . . . . . . . . . . . . . . . . . 75 5.17 Speicherhierarchie f¨ ur Konfigurationsvorg¨ ange . . . . . . . . . . . . . . . . . 77 5.18 Konfliktvermeidung bei Konfigurationsvorg¨ angen . . . . . . . . . . . . . . . 79 5.19 Systemschichten und zugeh¨ orige Regelungsabl¨ aufe . . . . . . . . . . . . . . 80 5.20 Wirkungskreisl¨ aufe im Gesamtsystem . . . . . . . . . . . . . . . . . . . . . 83 5.21 Urspr¨ ungliche und vollst¨ andig optimierte Anwendungslaufzeit . . . . . . . . 85 5.22 Anpassung im Bedarfsfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.23 H¨ aufigkeit als Grundlage der Anpassung . . . . . . . . . . . . . . . . . . . . 90 5.24 Exemplarische H¨ aufigkeitsverteilung zweier Gleitkommaoperationen . . . . . 92 5.25 Prinzipielle Probleme der Zyklenerkennung . . . . . . . . . . . . . . . . . . 93 5.26 Verhalten konkurrierender Module . . . . . . . . . . . . . . . . . . . . . . . 95 5.27 ¨ Ubersicht ¨ uber den Regelungsablauf des Gesamtsystems . . . . . . . . . . . 96 5.28 Erzeugung eines Nutzungsprofils . . . . . . . . . . . . . . . . . . . . . . . . 99

vi

5.29 Problematik der Zyklen- und ¨ Uberwachungsintervalle . . . . . . . . . . . . . 99

5.30 Auswirkung einer Unsch¨ arfe bei Messwerten . . . . . . . . . . . . . . . . . . 101 5.31 Zyklenverschiebung nach w-facher Wiederholung . . . . . . . . . . . . . . . 104 5.32 Rechtsverschiebung bei Zyklen mit Rest . . . . . . . . . . . . . . . . . . . . 104 5.33 Linksverschiebung f¨ ur dominanten Zyklusrest . . . . . . . . . . . . . . . . . 105 5.34 Auswirkung von Rechts- und Linksverschiebung beim Einsatz von Mustern . 108 5.35 Fr¨ uhzeitige Verschiebungserkennung auf Grund von Startpunktsonderf¨ allen . 109 5.36 Einsatz von H¨ aufigkeiten als Musterwerte . . . . . . . . . . . . . . . . . . . 114 5.37 Phasen und zugeh¨ orige Schichten der ¨ 5.38 Aufbau einer ¨ Uberwachungszelle . . . . . . . . . . . . . . . . . . . . . . . . 121 5.39 Aufbau einer Nutzungshistorie . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.40 Aufbau eines Musterspeichers . . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.41 Exemplarischer Aufbau eines Indikators zur Zyklenerkennung

. . . . . . . . 125 6.1 Schematisches Grundmodell des adaptiven Prozessors . . . . . . . . . . . . 128 6.2 Komponentenschema des adaptiven Prozessors . . . . . . . . . . . . . . . . 131 6.3 Komponentschema der Monitoringschicht . . . . . . . . . . . . . . . . . . . 134 6.4 Einfaches Schema m¨ oglicher Operationskombinationen . . . . . . . . . . . . 135 6.5 Dekodierung und Wandlung anhand ausgesuchter Beispiele . . . . . . . . . 136 6.6 Schematische Darstellung des erweiterten internen Befehlswortes . . . . . . 137 6.7 Rahmenbedingungen f¨ ur Operationskombinationen . . . . . . . . . . . . . . 140 6.8 Anforderungen an interne Abl¨ aufe von Funktionseinheiten . . . . . . . . . . 141 6.9 Vergleich adaptiver Prozessor und ARM10 . . . . . . . . . . . . . . . . . . . 142 6.10 Dekodierung mit anschließender Wandlung in Komponentendarstellung . . . 143 6.11 Der Zerteilungsmechanismus in der Praxis . . . . . . . . . . . . . . . . . . . 145 6.12 Die logischen Komponenten der Zerteilung . . . . . . . . . . . . . . . . . . . 146 6.13 Aufbau des Gesamtvergleichers . . . . . . . . . . . . . . . . . . . . . . . . . 148 6.14 Aufbau der Operationsfeldvergleicher . . . . . . . . . . . . . . . . . . . . . . 149 6.15 Aufbau der Einzeloperationsvergleicher . . . . . . . . . . . . . . . . . . . . . 149 6.16 Aufbau der Operationskombinationsvergleicher . . . . . . . . . . . . . . . . 150 6.17 Schematische Darstellung der Zerteilung . . . . . . . . . . . . . . . . . . . . 151 6.18 Aufbau einer Kombinationseinheit . . . . . . . . . . . . . . . . . . . . . . . 152 6.19 Integration der rekonfigurierbaren Bereiche in den adaptiven Kern . . . . . 154 6.20 Struktur eines exemplarischen konfigurierbaren Bereichs mit zwei Kontexten 156 6.21 Phasenspezifische Anpassung des internen Befehlswortes . . . . . . . . . . . 159 6.22 Vorgaben f¨ ur die Integration konfigurierbarer Bereiche . . . . . . . . . . . . 161 6.23 Aufbau der Anpassungskomponenten im adaptiven Prozessor . . . . . . . . 162 6.24 Schematischer Aufbau des Bibliotheksteils . . . . . . . . . . . . . . . . . . . 164 6.25 Integration der ¨ Uberwachung und Regelung . . . . . . . . . . . . . . . . . . 165 6.26 Aufbau der Auswertungseinheit . . . . . . . . . . . . . . . . . . . . . . . . . 166 6.27 Aufbau der Steuereinheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 6.28 Auswirkung der Messintervalle auf die ¨ Uberwachungsdaten . . . . . . . . . 171

6.29 Beschr¨ ankung der Nutzungsh¨ aufigkeit bei geeigneter Granularit¨ at . . . . . . 172 6.30 Zyklenverk¨ urzung auf Grund des Einsatzes eines FMUL-Moduls . . . . . . . 173 6.31 Modulnutzungen der RSpeed01-Beispielanwendung . . . . . . . . . . . . . . 175 6.32 Modulnutzungen der Bezier01-Beispielanwendung . . . . . . . . . . . . . . . 175 6.33 Zus¨ atzliche Modulnutzungsm¨ oglichkeit . . . . . . . . . . . . . . . . . . . . . 176

vii

6.34  Beschleunigungsfaktoren der V-Mbasierten Modulnutzung  178

6.35  Beschleunigungsfaktoren der hardware-basierten Modulnutzung (Operations-  

kombinationen  )  178

7.1  Geteilter gemeinsamer Rekonfigurationsbereich  185

A  1 Screenshot des Simulator-GUI  188

Tabellenverzeichnis

5.1 Erforderliche Steuersignale der ¨ Uberwachungs- und Regelungselemente . . . 119

6.1 Ausz¨ uge aus Syntheseberichten von Operationskombinationen . . . . . . . . 138 6.2 Hardware-Implementierung der Wandlung . . . . . . . . . . . . . . . . . . . 153 6.3 Auszug aus den Herstellerangaben zu ausgesuchten MegaCores . . . . . . . . 157 6.4 Auszug aus eigenen Synthesel¨ aufen mittels Quartus II Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 6.5 Hardware-Implementierung der ¨ Uberwachungskomponenten . . . . . . . . . . 168

Abk¨ urzungen und Symbole

Abk¨ urzungen:

ALU Arithmetic Logic Unit

ALU T Adaptive Look-up Table ARM Advanced RISC Machines Ltd ASIC Application Specific Integrated Circuit CISC Complex Instruction Set Computer CLB Complex Logic Block CP U Central Processing Unit CP LD Complex Programmable Logic Device DCG Deterministisches Clock-gating DP GA Dynamically Programmable Gate Array DP M Dynamic Power Management DSP Digital Signal Processor DV S Dynamic Voltage Scaling EP I Energie pro Instruktion EP IC Explicit Parallel Instruction Computer F E Funktionseinheit F F T Fast Fourier Transformation F P GA Field Programmable Gate Array GAL Generic Array Logic ILP Instruction Level Parallelism LAB Logic Array Block M AC Multiply Accumulate M U L Multiply N oC Network on Chip P AL Programmable Array Logic P LB Pipeline Balancing P LD Programmable Logic Device P P M Power and Performance Management RAW Read After Write RISC Reduced Instruction Set Computer RF E Rekonfigurierbare Funktionseinheit

xii

RF U Reconfigurable Function Unit SHL Shift Left SHR Shift Right SoC System on Chip V LIW Very Long Instruction Word V LSI Very Large Scale Integration V M Virtuelle Maschine W AR Write After Read W AW Write After Write

Symbole:

A i

c ⁱ G G M

H M

k KW i

m

M \M Ohne Modul M. M (P x) n

^{M ax} n M ax.P rof il Maximale Anzahl Eintr¨ age in einer Nutzungshistorie (Nutzungsprofil).

T Anwendung Rechenzeit einer Anwendung (bei Zeitscheibenverfahren, jeweils maximal mit der L¨ ange einer Zeitscheibe).

T Ef f ekt (M ) Der (positive oder negative) Effekt auf die Ausf¨ uhrungszeit einer Anwen-

T G

T ^M T ^\M T M A

T M R U berwachung Gegebenes ¨ T ¨

u W i

xiv

Definitionen

Echtzeitbetrieb (DIN 44300) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Energieeffizienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Regelung (DIN 19226) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Adaptive Rechensysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Autonome adaptive Rechensysteme . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Die Modulrekonfigurationszeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Modulanwahlzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Die Messwertzugeh¨ origkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Sichere Nullstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

xvi Definitionen

1.

Einleitung und Motivation

Viele Anwendungen im Bereich der eingebetteten Systeme erfordern hohe Rechenleistung und m¨ ussen zudem zeitnah an sich ¨ andernde Umgebungsbedingungen angepasst werden. Vor allem Energie- und Formfaktor-Vorgaben beschr¨ anken ¨ ublicherweise die verwendete

Hardware, wobei andererseits die geforderte Rechenleistung h¨ aufig den Einsatz von anwendungsspezifischen Architekturen notwendig macht.

Moderne Fertigungsmethoden erlauben zwar die Herstellung immer umfangreicherer und komplexerer Chips, jedoch stellt sich der Fertigungslauf solcher Prozesse als mehr und mehr zeitaufwendig und kostenintensiv dar. Ein gangbarer Ausweg ist in diesem Zusammenhang der Einsatz rekonfigurierbarer Schaltungen. Systeme mit rekonfigurierbarer Logik verf¨ ugen in der Regel ¨ uber eine feste Chip-Plattform, die zudem durch nachtr¨ agliche Anpassung der rekonfigurierbaren Anteile auf ein Einsatzgebiet oder eine konkrete Anwendung adaptiert werden k¨ onnen. Neben dem Aspekt der allgemeinen Kostensenkung durch den Einsatz von Massenbausteinen ist durch rekonfigurierbare Schaltungen ein hohes Maß an Anpassungsf¨ ahigkeit w¨ ahrend und nach dem Entwurfsprozess gegeben.

Die hohe Flexibilit¨ at bei der Verwendung von Standardprozessoren ist ausschließlich auf die ublicherweise durch die ¨ Software zur¨ uckzuf¨ uhren und ¨ Uberdimensionierung des Prozessors

gew¨ ahrleistet: Einzelne Funktionen, Algorithmen oder Teilalgorithmen lassen sich h¨ aufig effizient in Hardware realisieren. Weniger performant zeigen sich diesbez¨ ugliche Software-L¨ osungen, die zum Ausgleich auf einen insgesamt leistungsf¨ ahigeren Prozessor angewiesen sind. Eine universelle L¨ osung sollte deshalb zus¨ atzlich zur Flexibilit¨ at auf Seiten der Software auch in Hardware-Aspekten anpassbar sein.

Derartige adaptive Rechensysteme basieren h¨ aufig auf FPGAs, die mittlerweile zum einen ausreichend rekonfigurierbare Ressourcen f¨ ur Rechenanwendungen bereitstellen und zum anderen brauchbare Resultate in Bezug auf Energie und maximale Taktfrequenzen liefern. Dennoch muss, um entscheidende Leistungssteigerungen zu erzielen, die Adaptivit¨ at in allen Entwicklungsphasen und dar¨ uber hinaus in den einzelnen Schichten des Zielsystems ber¨ ucksichtigt werden. Grundvoraussetzung sind zum Beispiel Werkzeuge zur Anwendungs¨ ubersetzung, welche die M¨ oglichkeiten der Hardware-Anpassung weitgehend ohne Eingriffe des Anwendungsprogrammierers aussch¨ opfen. Zus¨ atzlich sollten diesem Mechanismen verf¨ ugbar gemacht werden, die eine manuelle Beeinflussung der adaptiven F¨ ahigkeiten zulassen. F¨ ur eine dynamische Hardware-Anpassung, die nicht nur auf einer einmaligen Konfiguration zur Ausrichtung auf eine Anwendung oder ein Anwendungsgebiet beruht, repr¨ asentiert das Betriebssystem die Systemschicht, die im laufenden Betrieb durch ge- eignete Maßnahmen das Rechensystem auf ausgef¨ uhrte und auszuf¨ uhrende Anwendungen

2 1. Einleitung und Motivation

unter Ber¨ ucksichtigung aktueller Rahmenbedingungen einstellt. Darunter befindet sich die Hardware-Schicht.

In bisherigen adaptiven Rechensystemen existieren Hardware-Komponenten, die eine bestimmte Menge an Ressourcen bereithalten. Die Nutzung der Ressourcen obliegt ausschließlich dem Betriebssystem. Anwendungsspezifische Schaltungen werden zum Beispiel w¨ ahrend der Prozesswechsel vorbereitet und Konfigurationslatenzen durch entsprechendes Scheduling vermindert. Auf feink¨ ornigere Anwendungsanforderungen, die sich der Sichtweise eines Betriebssystems entziehen, kann nicht dynamisch geantwortet werden. Die Beobachtung, Verfolgung und Ausnutzung solcher Abl¨ aufe bilden den Schwerpunkt dieser Arbeit. Ziel ist es durch eine zuverl¨ assige Prognose des feingranularen Anwendungsverhaltens eine zu den g¨ angigen statischen Methoden vergleichbare Leistungssteigerung mit der Forderung einer weitgehend optimalen Nutzung und Minimierung der eingesetzten rekonfigurierbaren Ressourcen zu erreichen.

Obwohl der zentrale Punkt die Bereitstellung und Integration geeigneter ¨ Uberwachungs- und

Regelungsmaßnahmen innerhalb der Hardware-Schicht eines Systems ist, m¨ ussen hierf¨ ur zus¨ atzliche Vorkehrungen in oberen Systemschichten getroffen werden und Mechanismen eingebettet sein, die eine feink¨ ornige Hardware-Anpassung ¨ uberhaupt erst erm¨ oglichen. Die

Resultate der Untersuchungen sind in das so genannte Metamorphosys Konzept f¨ ur den Entwurf eines autonomen adaptiven Gesamtsystems eingeflossen.

Das autonome adaptive Gesamtsystem stellt sich in f¨ unf Schichten dar. Die vier horizontalen Schichten, Anwendungs- und ¨ Ubersetzer-, Betriebssystem-, Virtuelle-Maschinen- und

Hardware-Schicht, werden durch die vertikale PPM-Ebene (Performance and Power Management), die s¨ amtliche ¨ Uberwachungs- und Regelungsmechanismen der einzelnen Schichten

umfasst, geschnitten. In Bezug auf die ¨

bliothek und der Komponentenpool als zus¨ atzliche Systemkomponenten, die f¨ ur den Einsatz adaptiver Komponenten notwendig sind, eingef¨ uhrt. Der Komponentenpool beinhaltet alle im System verf¨ ugbaren Hardware-Module, die in adaptive Komponenten geladen werden k¨ onnen. Die Systembibliothek ¨ ubernimmt die systemweite Ver¨ offentlichung der Module und Moduleigenschaften.

Die Nutzung der Anpassungsf¨ ahigkeit, wie sie f¨ ur das autonome adaptive System vorgestellt wird, erfordert verschiedene Erweiterungen in den einzelnen Systemschichten. Besonders f¨ ur die Anwendungs¨ ubersetzung stellt die Gruppe adaptiver Recheneinheiten, die eine Teilmenge adaptiver Komponenten repr¨ asentieren, eigene Anforderungen, die zum einen notwendig sind und zum anderen unterst¨ utzend zur dynamischen Anpassung beitragen. Das Einf¨ ugen von Bibliotheksinstruktionen, die die Verwendung von Hardware-Modulen anzeigen, in den VM-Code einer Anwendung stellt in diesem Zusammenhang die Grundvoraussetzung der dynamischen Adaptivit¨ at dar. Dar¨ uber hinaus ist eine automatisierte Modul-Generierung vorgesehen, die sowohl eine hardware-beschleunigte als auch reine software-basierte Ausf¨ uhrung in Abh¨ angigkeit vom Konfigurationszustand des Systems erlaubt. Des Weiteren k¨ onnen Konfigurationsinstruktionen zur Einhaltung von Laufzeitkriterien bzw. Echtzeitanforderungen genutzt werden.

Auf Grund des Einsatzes von rekonfigurierbarer Logik existieren diverse Probleme, die ein Resultat der zeitaufwendigen Konfigurationsvorg¨ ange sind. Diesbez¨ uglich bietet das Konzept Betriebssystemerweiterungen, z.B. in Form spezieller Scheduling-Techniken, und Vorschl¨ age zur Gestaltung einer eigenen Konfigurationsinfrastruktur, die zu einer vollst¨ andigen Aufl¨ osung bzw. Minimierung der Latenzproblematik f¨ uhren.

1.1. Struktur der Arbeit 3

ubernehmen Aufgaben in Bezug auf die ¨ Alle Systemschichten ¨ Uberwachung und Regelung

des adaptiven Gesamtsystems. Zu den vorrangigen Aufgaben des Betriebssystems z¨ ahlen z.B. die Regulierung der Spannung und Frequenz einzelner Systemteile und Komponenten. Des Weiteren zeigen sich Vorg¨ ange, in Verbindung mit dem Einsatz rekonfigurierbarer Hardware, innerhalb von adaptiven Komponenten, die sich der ¨ Uberwachung und Rege-

lung durch das Betriebssystem entziehen. Die Rolle des Betriebssystems beschr¨ ankt sich auf die Einstellung von Rahmenbedingungen, wie z.B. die rechtzeitige Pufferung ben¨ otigter Hardware-Module. Dies bildet die Grundlage der ¨ Uberwachung und Regelung innerhalb akti-

ver adaptiver Komponenten, die eigenst¨ andig zur optimierten Ausf¨ uhrung einer Anwendung beitragen. In diesem Zusammenhang ist das oberste Ziel, die vorhandenen rekonfigurierbaren Ressourcen weitestgehend optimal zu nutzen. Hierzu wird eine Regelung auf Basis von Nutzungsh¨ aufigkeiten und eine bedarfsorientierte L¨ osung bei zyklischem Anwendungsverhalten eingesetzt.

Eine zweite, im Bereich der Hochleistungsprozessoren wesentliche Bedeutung liegt im Einsatz von Acceleratoren, die zusammen mit dem Prozessor auf einem Chip untergebracht sind. Die Anzahl der auf einem Chip integrierbaren Transistorfunktionen ist in den letzten 25 Jahren exponentiell angestiegen. Mit den derzeit bekannten Prozessorarchitekturen ist eine Nutzung dieses technologischen Potentials nicht mehr m¨ oglich. Als Alternative weichen die Hersteller zurzeit auf Multi-Core-Chips aus. Diese erlauben im Allgemeinen weniger als einen n-fachen Durchsatzzuwachs mit n-facher Transistorenzahl, da der Durchsatz stark von der Effektivit¨ at der Anwendungsparallelisierung abh¨ angt. Wenn der Einsatz der rekonfigurierbaren Acceleratoren mehr als den Faktor n erzielt, ist die adaptive Architektur ¨ uberlegen.

J¨ ungste Forschungsarbeiten, die auf der Supercomputing 2006 pr¨ asentiert wurden, zeigen, dass bereits statisch eingesetzte FPGA-Acceleratoren eine Leistungsverbesserung von 60% bis 125% im Gegensatz zu Standard-Mikroprozessoren wie z.B. Intels Pentium 4 aufweisen.

1.1 Struktur der Arbeit

Der gesamte Text l¨ asst sich in zwei Teile gliedern. Der erste Teil der Arbeit behandelt die Grundlagen sowie eine ¨ Ubersicht ¨ uber den aktuellen Stand der Forschungen. Der zweite Teil

umfasst den Aufbau des entstandenen Rechensystems, die theoretischen Aspekte des Konzepts und diesbez¨ uglich essentielle Erweiterungen innerhalb der einzelnen Systemschichten und untermauert die Ergebnisse anhand der Experimente im Zusammenhang mit dem so genannten adaptiven Prozessor.

Im Einzelnen ist die vorliegende Arbeit wie folgt aufgebaut:

• Die Grundlagen bieten eine kurze Darstellung der f¨ ur diese Arbeit relevanten Methoden und Techniken der Prozessorarchitektur. Anschließend findet sich eine prinzipielle Beschreibung aktueller FPGAs, deren Logikelemente und Infrastruktur sich f¨ ur den Einsatz in Systemkomponenten des erarbeiteten Konzepts eignen. Des Weiteren wird der Bereich der eingebetteten Systeme als vorgesehener Einsatzschwerpunkt vorgestellt. Der abschließende Abschnitt gibt einen ¨ Uberblick ¨ uber die heutzutage g¨ angigen

Grundlagen des Systementwurfs unter Ber¨ ucksichtigung der Faktoren Energie und Rechenleistung.

4 1. Einleitung und Motivation

• Im Kapitel Regelung von Systemen werden grundlegende Begriffe der Rege-lungstheorie eingef¨ uhrt. Dar¨ uber hinaus liefert das Kapitel eine ¨ Ubersicht ¨ uber gebr¨ auchliche Regler. Abschließend werden Regelungsverfahren mit dem Schwerpunkt statistischer Prozesse angesprochen und die als Tracking bezeichnete Vorgehensweise eingef¨ uhrt.

• Das Kapitel Adaptive Rechensysteme stellt eine Klassifikation von Rechensystemen anhand ihrer Eigenschaften vor. Im Weiteren werden die M¨ oglichkeiten der dynamischen Anpassung bestehender Systeme aufgezeigt. Den Abschluss bildet eine detaillierte Beschreibung zweier existierender Projekte, die einen unmittelbaren Einfluss auf diese Arbeit haben und zus¨ atzliche Kurzbeschreibungen weiterer Projekte, die insgesamt den Stand der Forschung aufzeigen.

• Das aus den eigenen Untersuchungen resultierende Konzept ist in Kapitel Metamorphosys beschrieben. Vorgestellt wird der Entwurf eines gesamten Rechensystems. Zudem beschreibt das Kapitel die Auswirkungen und die Nutzungsm¨ oglichkeiten, die sich aus der F¨ ahigkeit der Adaption ergeben. Darauf folgt eine ausf¨ uhrliche Behandlung der ¨ Uberwachungs- und Regelungsmechanismen des Systems. Diesbez¨ ugliche Implementierungsaspekte stehen im Anschluss daran.

• Der praktische Einsatz des Konzepts wird exemplarisch im Kapitel der adaptive Prozessor durchexerziert. Einf¨ uhrend wird das Prozessordesign erl¨ autert. Entsprechende Implementierungsaspekte schließen sich an. Beendet wird das Kapitel mit einer Zusammenfassung der, anhand des adaptiven Prozessors gewonnen, Ergebnisse im Zusammenhang mit dem autonomen adaptiven Rechensystem.

• Das n¨ achste Kapitel gibt eine gesamte Zusammenfassung der Arbeit und einen Ausblick auf die n¨ achsten Schritte. Zudem werden weiterf¨ uhrende Arbeiten ange- sprochen.

2.

Grundlagen

Im Vordergrund dieses Kapitels steht die Einf¨ uhrung der in der vorliegenden Arbeit verwendeten Begriffe und eine ¨ Ubersicht ¨ uber die in diesem Zusammenhang tangierten Themenbereiche.

Zu Beginn steht die auszugsweise Behandlung der Prozessorarchitektur. Im Anschluss folgt ein ¨ Uberblick ¨ uber programmierbare Logikbausteine. Beide Abschnitte bilden die Grundlage f¨ ur den in Kapitel 6 vorgestellten adaptiven Prozessor. Des Weiteren gibt Abschnitt 2.3 eine Einf¨ uhrung zum Thema eingebettete Systeme, die das Haupteinsatzgebiet des autonomen adaptiven Gesamtsystems darstellen. Der letzte Abschnitt widmet sich den g¨ angigen Methoden und Techniken des Systementwurfs unter den Gesichtspunkten des Energiebedarfs. Diesen kommt insbesondere im Bereich der eingebetteten Systeme eine tragende Rolle zu und sie sind seit einigen Jahren ¨ uber diesen Einsatzbereich hinaus von zunehmender Bedeutung.

2.1 Prozessorarchitektur

Der folgende Abschnitt bietet einen ¨ Uberblick ¨ uber die f¨ ur diese Arbeit relevanten Grund-

lagen und Techniken der Prozessorarchitektur. Behandelt werden die g¨ angigen Befehlssatzarchitekturen, Leistungsmessung und Leistungsbewertung sowie der logische Maschinenbefehlszyklus und Fließbandverarbeitung.

2.1.1 Befehlssatzarchitektur

In der Literatur der letzten Jahre wird meist darauf hingewiesen, dass die historische Einteilung in CISC (Complex Instruction Set Computing) und RISC (Reduced Instruction Set Computing) Architekturen nicht mehr ad¨ aquat und aus dieser Sicht das Post-RISC-Zeitalter angebrochen ist [65, 95].

Der Vollst¨ andigkeit halber muss erw¨ ahnt werden, dass es mehrere M¨ oglichkeiten gibt eine Befehlssatzarchitektur (ISA, Instruction Set Architecture) umzusetzen. Nach Hennessey und Patterson [72] wurde jedoch seit 1980 prinzipiell nur noch die Umsetzung von so genannten load-store Architekturen auf der Grundlage von Allzweckregistern verfolgt. Diese Art der Implementierung wird auch in der vorliegenden Arbeit favorisiert.

6 2. Grundlagen

2.1.1.1 CISC (Complex Instruction Set Computing)

Der urspr¨ ungliche Gedanke der CISC-Architektur beruhte auf der Feststellung, dass bei der Ausf¨ uhrung einer Anwendung, die meiste Zeit f¨ ur das Holen der Daten in Anspruch genommen wird. Die logische Konsequenz daraus ist, Maschinenbefehle bereit zu stellen, die m¨ oglichst aufwendige Operationen auf den einmal geholten Daten durchf¨ uhren k¨ onnen [92]. Zudem sollte eine verh¨ altnism¨ aßig geringe Programmgr¨ oße erzielt werden, um wertvolle Speicherressourcen zu sparen und kompakten, effizienten Code zu erhalten. Diese und eine Reihe weiterer ¨ Uberlegungen, sowie die Forderung von Aufw¨ artskompatibilit¨ at von Befehlss¨ atzen, f¨ uhrten zu den heute als klassische Merkmale einer CISC-Architektur geltenden Eigenschaften [42, 121]:

• Umfangreiche Befehlsarten

• Viele Adressierungsmodi

• Variable L¨ ange der Instruktionen (vertikale Codierung)

• Eher wenige Register

2.1.1.2 RISC (Reduced Instruction Set Computing)

Der verst¨ arkte Einsatz von Compilern und eine Abkehr von der Programmierung auf Maschinenbefehlsebene zeigten, dass Compiler nur einen Teil (typischerweise 70-80%) eines CISC-Befehlssatzes nutzen. Demzufolge sollte bei einem neuen Architekturansatz die Einfachheit einer Architektur im Mittelpunkt stehen. Dies f¨ uhrte zu den so genannten RISC-Architekturen, die folgende Eigenschaften aufweisen [92, 72, 95]:

• Einfacher/reduzierter Befehlssatz

• Wenige Adressierungsarten (meist load-store)

• Viele Register

• Feste Befehlsl¨ angen

• Befehle mit gleicher, meist einfacher, Ablaufstruktur f¨ ur den Einsatz von Pipelines

2.1.1.3 Post-RISC

Mit dem Fortschreiten der technischen M¨ oglichkeiten bei der Fertigung von Prozessoren (z.B. VLSI, Very Large Scale Integration) wurden die vormals bestehenden Restriktionen aufgehoben. Dies f¨ uhrte dazu, dass die einzelnen Eigenschaften von klassischen RISC- bzw. CISC-Architekturen nicht mehr als Unterscheidungskriterien greifen. Eine Einteilung aktueller Prozessoren in RISC- oder CISC-Architektur beruht im Allgemeinen auf der Einteilung ihrer Vorg¨ anger [95]. Beim Entwurf heutiger Prozessoren bedient man sich aller Techniken und Hilfsmittel die eine Leistungssteigerung in Aussicht stellen ohne darauf zu achten, die Merkmale der historischen Einteilung in CISC und RISC aufrechtzuerhal- ten. Als wohl bekannteste Beispiele k¨ onnen diesbez¨ uglich die IA32-Architektur (80x86)

2.1. Prozessorarchitektur 7

von Intel [84] als CISC sowie die MPCxxxx-Prozessoren (PowerPC) von Motorola [113,

114] als RISC-Vertreter angef¨ uhrt werden. Die aktuellen Prozessoren beider Hersteller weisen weder eindeutige CISC- noch RISC-Merkmale auf und gelten ausschließlich auf Grund ihrer fr¨ uhen Vorg¨ anger als CISC- bzw. RISC-Prozessoren.

Ein weiterer Aspekt der Befehlssatzarchitekturen sind die als VLIW/ EPIC (Very Large Instruction Word/ Explicit Parallel Instruction Computing) bezeichneten Architekturen. Im Gegensatz zu CISC und RISC ist bei VLIW/EPIC-Architekturen ausschließlich der Compiler f¨ ur eine optimierte Ausf¨ uhrung des Anwendungscodes verantwortlich. Hierbei muss der Compiler anhand der statischen Codeinformation Befehlsabh¨ angigkeiten erkennen und wenn m¨ oglich so aufl¨ osen, dass mehrere Befehle zu einer einzelnen Gruppe parallel ausf¨ uhrbarer Befehle (Bundle) zusammengefasst werden. Der zugeh¨ orige Prozessor verf¨ ugt ¨ uber keinerlei

Hardware zur weiteren Optimierung der Programmausf¨ uhrung. Inwiefern die vom Prozessor bereitgestellten Rechenressourcen genutzt werden, h¨ angt somit nur vom Compiler und dem Parallelismus auf Instruktionsebene (Instruction Level Parallelism, ILP) des Anwendungscodes ab [23, 59, 92]. Aktuelle Vertreter der VLIW/EPIC-Architekuren sind z.B. die Intel IA64-Prozessoren Itanium [76] bzw. Itanium II [78].

2.1.2 Leistungsmessung, Bewertung und Effizienz

Allgemein wird die (Rechen-)Leistung von Rechenmaschinen durch die Geschwindigkeit und Qualit¨ at, mit der ein oder mehrere Auftr¨ age bearbeitet werden, definiert [42, 72]. Zur Leistungsbewertung werden dementsprechend Messgr¨ oßen herangezogen, die einen Vergleich von Rechenmaschinen erlauben. Diesbez¨ uglich sind die wichtigsten Gr¨ oßen:

• Durchsatz: Zahl der pro Zeiteinheiten bearbeiteten Auftr¨ age

• Ausf¨ uhrungszeit: Zeit die vom Stellen der Aufgabe bis zur kompletten Fertigstellung erforderlich ist.

• Verf¨ ugbarkeit: Wahrscheinlichkeit eine Anlage zu einem gegebenen Zeitpunkt in einem funktionsf¨ ahigen Zustand anzutreffen.

Zwei Maschinen k¨ onnen z.B. auf Basis der Ausf¨ uhrungszeit einer Anwendung bzw. der Leistung in Relation gesetzt werden [72]:

Dies f¨ uhrt zur Aussage, dass M aschine X n-mal mehr leistet als M aschine Y oder umgekehrt.

F¨ ur eine weitgehend objektive Betrachtung von Durchsatz und Antwortzeit k¨ onnen Bewertungsprogramme (Benchmarks) herangezogen werden, deren prim¨ ares Ziel es ist, einheitliche Bedingungen auf unterschiedlichen Rechenanlagen zu schaffen, um einen Leistungsvergleich anstellen zu k¨ onnen. Um einen m¨ oglichst hohen Grad an Objektivit¨ at zu erreichen, sind Bewertungsprogramme, die jeweils auf unterschiedliche Aspekte der Leistung einer Rechenanlage abzielen, zu so genannten Benchmark Suites zusammengefasst. Die wohl bekanntesten Sammlungen von Bewertungsprogrammen f¨ ur PCs und PC-¨ ahnliche Rechner sind SPEC, Dhrystone und Whetstone. Dar¨ uber hinaus stellt z.B. die EEMBC (gesprochen: Embassy) Benchmark Suite [36] Bewertungsprogramme f¨ ur eingebettete Systeme (siehe Abschnitt 2.3) bereit.

8 2. Grundlagen

2.1.2.1 Geschwindigkeitsvergleich

Der Leistungsgewinn bzw. der Faktor (Speedup), um den die optimierte Ausf¨ uhrungszeit einer Aufgabe im Verh¨ altnis zur urspr¨ unglichen Ausf¨ uhrungszeit verk¨ urzt wurde, beschreibt Amdahls Gesetz mit:

Speedup =

In diesem Zusammenhang gilt, dass eine durchgef¨ uhrte Optimierung dann zur Anwendung kommen muss, wenn diese eingesetzt werden kann. Meist k¨ onnen Optimierungen oder Erweiterungen nur f¨ ur bestimmte Teile einer Aufgabe verwendet werden. Diesbez¨ uglich weiterf¨ uhrende Gedanken finden sich in [72].

2.1.2.2 Leistung und Effizienz

Bisher wurden die grundlegenden M¨ oglichkeiten zur Leistungsbewertung von Rechenanlagen diskutiert. F¨ ur die Bewertung einer Prozessorarchitektur m¨ ussen auf obiger Basis Kriterien herangezogen werden, die Vergleiche verschiedener Paradigmen einer Architektur sowie unterschiedlicher Architekturen zulassen. Hierzu eignen sich in erster Linie Messungen unter Ber¨ ucksichtigung des Taktzyklus (in Zeiteinheiten) oder der Frequenz (1/ Taktzyklus) eines Prozessors und die angefallene Ausf¨ uhrungszeit (Vgl. [72]):

oder

Eine weitere Betrachtung der Leistungsmessung und deren Auswertung f¨ uhrt zum so genannten CPI-Faktor (Clock cycles per instruction) bzw. IPC (Instructions Per Clock cycle), der die L¨ ange des ausgef¨ uhrten Instruktionspfades (Anzahl der ausgef¨ uhrten Befehle eines Programms) in Relation zu den f¨ ur die Ausf¨ uhrung ben¨ otigten Taktzyklen stellt:

Weiterf¨ uhrend wird in [72] die Formel der CPU Zeit in messbare Faktoren zerlegt, was zu drei Kriterien f¨ uhrt, welche die Leistungsbewertung eines Prozessors bestimmen:

• L¨ ange der Taktzyklen

• CPI-Faktor respektive IPC-Faktor

• Anzahl der ausgef¨ uhrten Instruktionen

2.1. Prozessorarchitektur 9

Die Kriterien sind jeweils voneinander abh¨ angig. Die L¨ ange der Taktzyklen wird von der eingesetzten Hardware-Technologie und der Organisation des Prozessors bestimmt. Der CPI-Faktor h¨ angt sowohl von der Organisation, wie auch der Befehlssatzarchitektur ab und die Anzahl der ausgef¨ uhrten Instruktionen wiederum von der Befehlssatzarchitektur und dem verwendeten ¨ Ubersetzer.

Effizienz

M¨ ochte man eine Aussage ¨ uber die Effizienz einer Architektur bzw. ¨ uber deren Derivate

bez¨ uglich einer Anwendung treffen, erscheint die Zeit f¨ ur die Ausf¨ uhrung von Programmen denkbar ungeeignet, da diese keine oder nur bedingt R¨ uckschl¨ usse auf die Ausnutzung etwaiger eingesetzter Optimierungstechniken zul¨ asst. Der Versuch die Effizienz einer Pro-zessorarchitektur anzugeben h¨ angt maßgeblich von zwei Faktoren ab:

• Der theoretischen oberen Schranke f¨ ur den maximalen Durchsatz von Maschinenbefehlen.

• Dem tats¨ achlichen Durchsatz von Befehlen.

Eine obere Schranke f¨ ur den Durchsatz von Maschinenbefehlen wird haupts¨ achlich durch die Organisation des Prozessors bestimmt. Diesbez¨ uglich ist von Interesse, wie viele Befehle je Takt abgeschlossen werden k¨ onnen und somit wird dieser Wert als theoretische obere Schranke f¨ ur den Durchsatz des Prozessors angesehen. Der tats¨ achliche Befehlsdurchsatz (IPC) variiert meist stark, je nach ausgef¨ uhrter Anwendung, und ist im Normalfall eine gemessene Gr¨ oße. Die Effizienz einer Architektur in Bezug auf eine bestimmte Anwendung l¨ asst sich folgendermaßen definieren [72]:

Ef f izienz Anwendung =

Die Effizienz eines Prozessors f¨ ur eine ausgew¨ ahlte Menge von Anwendungen kann mit Hilfe des arithmetischen Mittels wie folgt beschrieben werden:

2.1.3 Der Maschinenbefehlszyklus

Unabh¨ angig vom Befehlssatz eines Prozessors besteht ein ausgef¨ uhrter Prozess aus einer Folge von Maschinenbefehlen bzw. Instruktionen i 0 , i 1 , . . . i n . Zur Verarbeitung jeder einzelnen Instruktion sind im Allgemeinen die folgenden logischen Phasen notwendig [72, 121]:

• Befehlsholphase (BH): Der Maschinenbefehl wird aus dem Speicher in ein Befehlsregister geholt. Die Steuerung erfolgt mittels Befehlsz¨ ahler.

• Dekodierphase (DK): Der Befehl wird aus dem Befehlsregister entnommen und entsprechend dem Operationscode werden die Steuersignale erzeugt sowie die Adressen aus dem Adressteil extrahiert und an die Operandenspeicher weitergeleitet.

10 2. Grundlagen

• Operandenholphase (OH): Die Operanden werden gelesen.

• Ausf¨ uhrungsphase (AF): Die mittels den Steuersignalen gew¨ ahlte Operation wird im Rechenwerk auf den Operanden ausgef¨ uhrt.

• R¨ uckschreibphase (ZS): Die Ergebnisse werden in den (Operanden-)Speicher zur¨ uck geschrieben.

2.1.4 Fließbandverarbeitung

Allgemein ist unter Fließbandverarbeitung (Pipelining) die Aufteilung des Befehlsablaufs in Einzelschritte (oder Stufen) zu verstehen. Die ben¨ otigte Zeit f¨ ur die gesamte Verarbeitung eines Befehls bleibt hierbei in erster N¨ aherung unver¨ andert. Ein erh¨ ohter Befehlsdurchsatz ist aber dann erkennbar, wenn das Fließband (Pipeline) gef¨ ullt ist und dementsprechend die Verarbeitung der Einzelschritte ¨ uberlappend ausgef¨ uhrt wird.

Der Einsatz von Fließbandverarbeitung bedeutet f¨ ur die Architektur eines Prozessors, dass die Einzelschritte des Maschinenbefehlszyklus durch physikalisch voneinander getrennte Teilwerke (Pipelinestufen), die jeweils durch Register (Latches) synchronisiert sind, realisiert werden. Die Abarbeitung jeder Instruktion erfolgt stufenweise. Im Idealfall ergibt sich bei vollst¨ andig gef¨ ullter Pipeline ein Durchsatz, der dem Kehrwert der Verarbeitungszeit der l¨ angsten Pipelinestufe entspricht.

Der Ablauf des Maschinenbefehlszyklus unter Ber¨ ucksichtigung einer Pipeline ist

grunds¨ atzlich mit der sequentiellen Befehlsverarbeitung identisch. Beim Design eines Pro-zessors spielen unterschiedliche Kriterien, wie z.B. die maximale resultierende Taktfrequenz, Energiebedarf (siehe Abschnitt 2.4) usw., bei der letztendlich gew¨ ahlten Abbildung des Maschinenbefehlszyklus auf physikalische Teilwerke eine erhebliche Rolle. Vereinfachend wird im Folgenden nicht mehr zwischen logischen Phasen und physikalischen Teilwerken unterschieden, d.h. dass Phase, Teilwerk und Pipelinestufe als ¨ aquivalent angesehen werden.

2.1.4.1 Fließbandprobleme

Selbst unter der Annahme einer idealen Speicheranbindung sind drei Probleme bei der Verwendung von Pipelines (Pipeline Hazards) anzutreffen:

• Ressourcenkonflikte (Structural Hazards): Ressourcen des Prozessors sind nicht im erforderlichen Umfang vorhanden.

• Datenabh¨ angigkeiten (Data Hazards): Daten werden ben¨ otigt, bevor diese verf¨ ugbar sind.

• Kontrollflussabh¨ angigkeiten (Control/ Branch Hazards): Wenn die Sprungbedingung noch nicht ausgewertet ist, f¨ uhren bedingte Spr¨ unge zu einer schlechten Nutzung der Pipeline.

Jeder dieser Konflikte bzw. Abh¨ angigkeiten f¨ uhrt zu einer Verschlechterung der Leistung eines Prozessors mit Fließbandverarbeitung, da das Auftreten eines Hazards zum Anhalten (Stall) der Verarbeitung bzw. zum Auff¨ ullen von abh¨ angigen Pipelinestufen mit Leeroperationen (NOOP- bzw. NOP-Operationen) f¨ uhren kann. Die volle Leistung einer Pipeline wird jedoch nur erreicht, wenn die Pipeline mit produktiven Operationen gef¨ ullt ist.

2.1. Prozessorarchitektur 11

Ressourcenkonflikte

Allgemein tritt ein Ressourcenkonflikt dann auf, wenn ein Betriebsmittel, dass n-mal verf¨ ugbar ist, mehr als n-mal zu einem bestimmten Zeitpunkt ben¨ otigt wird. Ressourcenkonflikte k¨ onnen - ohne die Verwendung von rekonfigurierbarer Hardware - nicht zur Laufzeit eines Programms gel¨ ost werden. Das heißt entweder es wurde bereits zum Entwurfszeitpunkt darauf geachtet, dass m¨ oglichst wenige oder keine Ressourcenkonflikte auftreten, oder es muss die Pipeline im Konfliktfall angehalten bzw. mit Leeroperationen, bis zur L¨ osung des Problems, gef¨ ullt werden. Obwohl Ressourcenkonflikte in der Regel bereits zur Entwurfszeit einfach zu identifizieren sind, kann, z.B. aus Gr¨ unden der Platzersparnis oder wegen zu hoher Anforderungen an die Speicherbandbreite, eine meist kosteng¨ unstigere Variante mit bekannten Konflikten einer konfliktfreien L¨ osung vorgezogen werden (Vgl. [72]).

Datenabh¨ angigkeiten

Datenabh¨ angigkeiten entstehen immer dann, wenn eine Instruktion Daten einer Vorg¨ angerinstruktion ben¨ otigt, die jedoch zum Zeitpunkt der Anfrage noch nicht lieferbar sind. Drei Arten von Datenabh¨ angigkeiten f¨ uhren zu einem Konflikt die mit zwei sequenziellen Instruktionen i und j wie folgt beschrieben werden k¨ onnen [72]:

• RAW (Read After Write): j versucht ein Ergebnis von i zu lesen, bevor dieses geschrieben wurde (echte Datenabh¨ angigkeit).

• WAW (Write After Write): j schreibt sein Ergebnis, bevor das Ergebnis von i in den gleichen Speicher geschrieben wurde, was zu Dateninkonsistenz f¨ uhrt. (Output-Datenabh¨ angigkeit)

• WAR (Write After Read): Befehl j hat sein Ergebnis bereits geschrieben, bevor i den urspr¨ unglichen Wert lesen konnte. (Anti-Datenabh¨ angigkeit)

Das Auftreten von RAW-Konflikte ist ausschließlich von der Reihenfolge der Maschinenbefehle bzw. den zugeh¨ origen Registerzugriffen abh¨ angig. Im Gegensatz dazu sind WAW- und WAR-Konflikte bedingt durch die Architektur des Prozessors. Diese treten nur dann auf, falls es mehrere Pipelinestufen gibt, die ein Schreiben in Register erlauben.

Kontrollflussprobleme

Die letzte Kategorie von Pipeline Hazards sind Kontrollflussprobleme. Jeder bedingte Sprung einer Anwendung kann ein Kontrollflussproblem hervorbringen, da bei einer g¨ ultigen Sprungbedingung alle nachfolgenden, bereits in der Pipeline befindlichen, Befehle ung¨ ultig werden bzw. nicht mehr zur Ausf¨ uhrung gebracht werden d¨ urfen. Das heißt, dass die Pipeline erst nach der Neuberechnung des Befehlsz¨ ahlers, falls eine Verzweigung erfolgt ist, an einer anderen Programmadresse mit der Ausf¨ uhrung von Befehlen und somit einer Neuf¨ ullung der Pipeline beginnen kann.

2.1.4.2 L¨ osungen f¨ ur Fließbandprobleme

Dieser Abschnitt gibt eine ¨ Ubersicht ¨ uber die Techniken zur Reduzierung und Behebung

von Fließbandproblemen, die unmittelbar im Zusammenhang mit dem adaptiven Prozessor

12 2. Grundlagen

stehen (siehe Kapitel 6). Eine detaillierte weiterf¨ uhrende Betrachtung findet sich z.B. in [72, 121, 92].

Bypassing

F¨ ur die Umgehung oder Minimierung von Wartezyklen in Bezug auf RAW-Datenabh¨ angigkeiten sorgt das so genannte Bypassing oder Forwarding. RAW-Konflikte ergeben sich aus einer Programmsequenz. Falls eine Instruktion j das Ergebnis der vorangegangenen Instruktion i lesen m¨ ochte, bevor diese die R¨ uckschreibphase passiert hat, muss das Ergebnis vorher schon bekannt gemacht werden. Die L¨ osung basiert darauf, dass das Ergebnis von i bereits nach der Ausf¨ uhrungsphase vorliegt. Dementsprechend werden Datenpfade eingef¨ uhrt, die eine Ergebnisanlieferung an etwaige wartende Instruktionen erm¨ oglichen ohne dass die Instruktion i vollst¨ andig abgearbeitet ist. Die Daten der Instruktion j werden nicht aus dem Registersatz geholt, sondern das Ergebnis wird direkt aus der Ausf¨ uhrungsphase von i geliefert. Diese Umgehung des regul¨ aren Pipelineablaufs bzw. des vorzeitigen Bereitstellens von Ergebnissen f¨ uhrte zu den Namen Bypassing oder Forwarding.

Register Renaming

Zu den bereits aufgef¨ uhrten Datenabh¨ angigkeiten existieren Abh¨ angigkeiten die rein aus der Position oder Adresse (auch engl. name) von Daten resultieren und auf einen Mangel an Ressourcen zur¨ uckzuf¨ uhren sind. Z.B. tritt dieser Fall ein, falls zwei Befehle i und j auf den gleichen Registern rechnen, ohne das i Daten von j ben¨ otigt und umgekehrt. Somit ergibt sich die Abh¨ angigkeit nur aus der Position, nicht jedoch aus einer Werteabh¨ angigkeit. Eine L¨ osung dieses Problems kann durch das Umbenennen von Registern erreicht werden. F¨ ur dieses Vorgehen ben¨ otigt ein Prozessor die F¨ ahigkeit, eine eindeutige Abbildung von logischen auf physikalische Register vorzunehmen. Das Register Renaming bleibt f¨ ur einen ¨ Ubersetzer transparent und wird intern vom Prozessor vorgenommen.

Verzweigungsvorhersage

Zur Minderung der Kontrollflussabh¨ angigkeiten wird ¨ ublicherweise eine Sprungvorhersage

(Branch Prediction) eingesetzt. Ziel der Sprungvorhersage ist die Aufrechterhaltung einer gef¨ ullten Pipeline. Wird das Sprungverhalten falsch vorhergesagt, muss dennoch die Pipeline geleert und neu gef¨ ullt werden. Je tiefer eine Prozessorpipeline um so h¨ oher ist der Zeitverlust durch falsche Vorhersagen. Damit eine m¨ oglichst zuverl¨ assige Vorhersage unter Ber¨ ucksichtigung des Programmverlaufs erzielt wird, kommen vermehrt dynamische Sprung- vorhersagen zum Einsatz.

2.2. Field Programmable Gate Arrays 13

2.2 Field Programmable Gate Arrays

Field Programmable Gate Arrays (FPGAs) z¨ ahlen zu den Programmable Logic Devices (PLDs). Hierbei handelt es sich allgemein um Logikbausteine, deren interne Verschaltung respektive Funktionalit¨ at frei programmierbar ist. Die einmalige Programmierung solcher Bausteine heißt Konfiguration. K¨ onnen Bausteine mehrfach oder beliebig oft konfiguriert werden, gelten diese als rekonfigurierbare Bausteine. In dieser Arbeit sind ausschließlich letztere von Bedeutung, weshalb die Begriffe Konfiguration und Rekonfiguration synonym Verwendung finden.

Neben der urspr¨ unglichen Programmable Array Logic (PAL) bzw. Generic Array Logic (GAL) bilden heutzutage Complex Programmable Logic Devices (CPLDs) und FPGAs die am h¨ aufigsten eingesetzte Gruppe der PLDs. FPGAs stellen diesbez¨ uglich die feink¨ ornigsten Bausteine dar und bieten umfangreiche Logik- und Speicherressourcen, die stets die M¨ oglichkeit der Rekonfiguration er¨ offnen (Vgl. auch [2]).

2.2.1 Aufbau und Struktur von FPGAs

FPGAs bestehen aus einzelnen Logikelementen (bzw. Logikzellen), die in Form einer Matrix angeordnet sind. F¨ ur die Kommunikation zwischen Logikelementen steht eine aufwendige Leitungsinfrastruktur mit unterschiedlichen Leitungsl¨ angen und Verbindungsm¨ oglichkeiten zur Verf¨ ugung. Die Verbindung zwischen vertikalen und horizontalen Signalleitungen wird in Abh¨ angigkeit von der programmierten Funktionalit¨ at mit Hilfe von Switch-Matrizen her-

14 2. Grundlagen

gestellt. Dar¨ uber hinaus stellen FPGAs so genannte IO-Pads, entsprechend den zugeh¨ origen Pins des FPGAs, bereit (Abbildung 2.1).

Der Aufbau und Funktionsumfang der einzelnen Bestandteile eines FPGAs variieren von Hersteller zu Hersteller und ¨ andern sich zudem massiv mit jeder neuen Bausteingeneration. Zudem ist die Nomenklatur herstellerspezifisch. Z.B. bezeichnet Xilinx die Logikelemente der Virtex-FPGA-Familie als Complex Logic Blocks (CLBs). F¨ ur die vergleichbare Stratix-Serie von Altera werden die Logikelemente als Adaptive Look-up Tables (ALUTs) bezeichnet. Der Funktionsumfang beider Logikelemente ist jedoch weitgehend identisch [11, 155].

Des Weiteren sind in aktuellen FPGAs zus¨ atzliche Ressourcen integriert. Hierzu z¨ ahlen z.B. Speicherbl¨ ocke unterschiedlicher Gr¨ oße, die ¨ uber diverse, konfigurierbare Adressierungsmodi verf¨ ugen. Zus¨ atzlich bieten Digital Signal Processing-Elemente (DSP-Elemente) die M¨ oglichkeit eine gewisse Funktionalit¨ at in optimierter Form, ohne die Nutzung von Logikelementen, umzusetzen. Z.B. erlaubt ein DSP-Element die Realisierung einer kompletten 18×18 Bit Multiplikation ohne den zus¨ atzlichen Einsatz von herk¨ ommlichen Logikelementen [11, 155].

2.2.2 Rekonfigurierbarkeit von FPGAs

Von besonderer Wichtigkeit f¨ ur das autonome adaptive Gesamtsystem ist die dynamische Rekonfigurationsf¨ ahigkeit von FPGAs. D.h. die F¨ ahigkeit w¨ ahrend des Betriebs Konfigurationsdaten an den FPGA zu ¨ ubergeben und somit bei Bedarf unterschiedliche Funktionalit¨ at bereitzustellen ¹ . Diesbez¨ uglich unterscheidet man zwei Arten von Rekonfiguration:

1. Partielle Rekonfiguration, die nur einen ausgew¨ ahlten Teil der FPGA-Ressourcen beeinflusst.

2. Totale (oder vollst¨ andige) Rekonfiguration, bei der stets alle Ressourcen neu konfiguriert werden.

F¨ ur die Verwendung im adaptiven Gesamtsystem ist die Art der Rekonfiguration von unter-geordneter Bedeutung. Welche Rekonfigurationsart eingesetzt werden muss, h¨ angt von der Integration der rekonfigurierbaren Elemente in einer Hardware-Komponente ab. Im Zusammenhang mit dem adaptiven Gesamtsystem bzw. dem exemplarisch vorgestellten adaptiven Prozessor eignet sich die totale Rekonfiguration (siehe Abschnitt 5.2.4 bzw. 6.2.3).

Die Rekonfigurationszeit, also der Zeitraum vom Beginn der Rekonfiguration bis zu deren Abschluss, ist maßgeblich f¨ ur die resultierende Rechenleistung des adaptiven Prozessors respektive betroffener Systemteile und dementsprechend des Gesamtsystems. W¨ ahrend einer Rekonfigurationsphase ist der betroffene Teil (partielle Rekonfiguration) bzw. der gesamte rekonfigurierbare Bereich nicht funktionsf¨ ahig.

Unterschiedliche Arbeiten befassen sich mit dem Thema Rekonfigurationszeit und weisen dies als Nachteil von ¨ alteren sowie aktuellen FPGAs aus (Vgl. [2, 157, 30]). Obwohl inzwischen ¨ Ubertragungsraten von bis zu 200 MBit/s [11, 155] unterst¨ utzt werden, dauern Rekonfigurationsvorg¨ ange - in Abh¨ angigkeit des Umfangs der zu ladenden Logikschaltung

¹ Sowohl Rekonfiguration als auch Konfiguration werden in der gesamten Arbeit synonym zu dynamischer Rekonfiguration verwendet.

2.2. Field Programmable Gate Arrays 15

- bis hin zu mehreren Millisekunden. F¨ ur die vorliegende Arbeit sind diese Zeitr¨ aume inakzeptabel. Dementsprechend enth¨ alt Abschnitt 6.2.3 einen L¨ osungsansatz, dessen Umsetzung im autonomen adaptiven Gesamtsystem vorstellbar ist und zu ad¨ aquaten Rekonfigurationszeiten f¨ uhrt.

2.2.3 FPGA Derivate

2.2.3.1 Multi-Kontext-FPGAs

Eine weitere Gruppe von FPGAs bilden die Multi-Kontext FPGAs oder Dynamically Programmable Gate Array (DPGAs). Solche FPGAs sind in der Lage mehrere unabh¨ angige Logikschaltungen gleichzeitig in Form von Konfigurationsinformationen aufzunehmen. Jede unabh¨ angige Schaltung wird hierbei als Kontext bezeichnet. W¨ ahrend des Betriebs kann zu einem bestimmten Zeitpunkt ausschließlich ein einziger Kontext aktiv sein. Die Einf¨ uhrung von Mutli-Kontext-FPGAs dient der Reduzierung von Latenzen durch Konfigurationsvorg¨ ange (siehe vorherigen Abschnitt 2.2.2), ben¨ otigt jedoch zus¨ atzliche Speicherressourcen innerhalb des FPGAs zur Ablage der Konfigurationsinformation [157, 30].

2.2.3.2 Mischform aus FPGA und unver¨ anderbarem Prozessorkern

Sowohl von Xilinx als auch Altera wird zu den aktuellen FPGA-Familien jeweils eine FPGA-Baureihe mit fest integriertem Prozessorkern (Hard-Core) angeboten. Ein oder mehrere unver¨ anderliche Prozessorkerne sind hierbei von rekonfigurierbaren Elementen umgeben. Der Platzbedarf des oder der Prozessorkerne verringert die Anzahl der rekonfigurierbaren Ressourcen im Vergleich zu den entsprechenden FPGA-Baureihen ohne integrierten Prozessor. Andererseits erlaubt dies z.B. eine schnelle Umsetzung von Systemen auf einem Chip (SoC). In diesem Zusammenhang setzt Xilinx auf einen PowerPC-Prozessorkern [156] und Altera auf die Prozessorkerne der Firma ARM (Advanced RISC Machines) unter der Bezeichnung Nios [12]. Diese Bausteine sind die Urspr¨ unge des Accelerator-Ansatzes f¨ ur Hochgeschwin- digkeitsprozessoren (Vgl. [139, 94]).

16 2. Grundlagen

2.3 Eingebettete Systeme

Unter eingebetteten Systemen versteht man im Allgemeinen Rechensysteme, die auf bestimmte Anwendungsbereiche spezialisiert und in einen technischen Kontext integriert sind. Dementsprechend erkennt man eingebettete Systeme h¨ aufig nicht als Computer. Im Gegensatz dazu stehen universal einsetzbare Systeme, wie z.B. Arbeitsplatzrechner usw., deren Entwurf keine Festlegung eines speziellen Verwendungszwecks vorsieht [2, 43, 148].

Eingebettete Systeme zeichnen sich vorrangig durch folgende Eigenschaften aus [137]:

• Echtzeitf¨ ahigkeit: Da eingebettete Systeme h¨ aufig in zeitkritischen Anwendungen zum Einsatz kommen (z.B. Prozess-Steuerungen), m¨ ussen bestimmte zeitliche Vorgaben bei der Verarbeitung eingehalten werden, um fehlerhafte Zust¨ ande zu vermeiden. In diesem Zusammenhang wird zwischen harter und weicher Echtzeitf¨ ahigkeit (siehe Abschnitt 2.3.4) unterschieden.

• Heterogenit¨ at: Eingebettete Systeme beinhalten oft unterschiedliche Hardware- und Software-Komponenten. Meist sind mehrere Mikroprozessoren, Mikrokontroller, DSPs sowie ASICs oder PLDs in ein Gesamtsystem integriert.

• Verteilte Implementierung: Die Kommunikation zwischen Komponenten eines eingebetteten Systems erfolgt h¨ aufig ¨ uber ein oder mehrere gemeinsame, protokollbasierte

Kommunikationssysteme. Hierbei sind zum Teil hohe Bandbreiten notwendig. Zudem liegen meist kritische zeitliche Anforderungen vor.

• Begrenzte Ressourcen: Auf Grund festgelegter Anwendungsbereiche sowie aus ¨ okonomischen Erw¨ agungen (z.B. Bauteilpreis) liegen in der Regel starke Ressourcenrestriktionen vor. Die Beschr¨ ankungen betreffen z.B. Stromverbrauch, Rechenleistung, Speichergr¨ oße, Formfaktor usw. Dar¨ uber hinaus sind eingebettete Systeme oftmals nur mit hohem Aufwand erweiterbar.

2.3.1 Leistungsaufnahme

Die elektrische Leistungsaufnahme ist in der Regel f¨ ur eingebettete Systeme durch ihr Einsatzgebiet limitiert. In diesem Zusammenhang m¨ ussen zum einen direkte Einfl¨ usse, wie z.B. Akku- bzw. Batteriebetrieb, Formfaktor, Kosten usw., ber¨ ucksichtigt werden und zum anderen indirekte, wie z.B. geringe oder keine K¨ uhlm¨ oglichkeit des Systems: Ein Großteil der aufgenommenen elektrischen Energie wird als Abw¨ arme abgegeben [2].

Die Leistungsaufnahme ist ein wichtiger Aspekt der beim Entwurf von eingebetteten Systemen und in zunehmendem Maße auch f¨ ur Arbeitsplatzrechner zu beachten ist (siehe Abschnitt 2.4). Bei den ¨ ublicherweise eingesetzten CMOS-Bausteinen ist die Verlustleistung maßgeblich von den statischen Leckstr¨ omen der MOSFET-Transistoren sowie den Verlusten durch die dynamische Umladung bestimmt. Die Leckstr¨ ome steigen mit der Anzahl der Transistoren und der Verkleinerung der Integrationsstrukturen. Im Gegensatz dazu steigt die dynamische Leistungsaufnahme nahezu linear mit der Taktfrequenz [70].