Entwurf und Synthese von Eingebetteten Systemen: Ein Lehrbuch 9783486721096

Citation preview

Entwurf und Synthese von Eingebetteten Systhemen Ein Lehrbuch von

Dr. Walter Lange Prof. Dr. Martin Bogdan

Oldenbourg Verlag München

Dr. Walter Lange war über 20 Jahre lang Entwicklungsingenieur bei IBM Büromaschinen GmbH in Böblingen und ist seit 2004 als Lehrbeauftragter am WilhelmSchickard-Institut (WSI) für Informatik an der Universität Tübingen tätig. Prof. Dr. Martin Bogdan ist seit 2008 Professor für Technische Informatik an der Universität Leipzig. Seine Forschungsinteressen liegen in den Bereichen Informationsund Signalverarbeitung, Eingebettete Systeme, Datenanalyse, neuronale Netze und maschinelles Lernen.

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © 2013 Oldenbourg Wissenschaftsverlag GmbH Rosenheimer Straße 143, D-81671 München Telefon: (089) 45051-0 www.oldenbourg-verlag.de Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen. Lektorat: Dr. Gerhard Pappert Herstellung: Tina Bonertz Titelbild: shutterstock.com Einbandgestaltung: hauser lacour Gesamtherstellung: Grafik + Druck GmbH, München Dieses Papier ist alterungsbeständig nach DIN/ISO 9706. ISBN 978-3-486-71840-9 eISBN 978-3-486-72109-6

Vorwort Der Siegeszug des Personal Computers in den achtziger Jahren des vergangenen Jahrhunderts wird abgel¨ ost durch die wachsende Verbreitung der Eingebetteten Systeme. Eingebettete Systeme werden immer kleiner, heute bestehen sie aus mikroelektronischen Einheiten, deren Strukturen zu weniger als einem Tausendstel des Durchmessers eines Menschenhaares zusammengeschrumpft sind. Man spricht vom unsichtbaren Compu” ter“. Die elektronischen Winzlinge dr¨ angen nicht nur in alle Bereiche der Technik, der Wirtschaft, des Bauwesens, sondern auch in alle privaten Lebensbereiche wie den Haushalt, die Freizeit usw. Beinahe jeder Teenager tr¨agt ein hoch kompliziertes Mini-System in Form eines Handys in der Tasche, aber auch in Kraftfahrzeugen, Photoapparaten, medizinischen Ger¨ aten, Flugzeugen, Haushaltsger¨aten, Fernsehapparaten usw. findet man Eingebettete Systeme, die dort Steuerungs- Regelungs- und DatenverarbeitungsAufgaben wahrnehmen (Ubiquitous Computer, Ambient Intelligence [deMan03]). Nach heutigen Sch¨ atzungen werden bereits weit mehr Prozessoren in Eingebetteten Systemen eingebaut als in PCs. Damit w¨ achst auch st¨andig der Bedarf an Programmcode f¨ ur Eingebettete Systeme. Das vorliegende Buch will der wachsenden Bedeutung der Eingebetteten Systeme Rechnung tragen. Es richtet sich haupts¨ achlich an Studenten der Informatik und der Naturwissenschaften in den Bachelor- und Masterstudieng¨angen, die sich f¨ ur die praxisbezogene Facette der Informatik interessieren sowie an Ingenieure, die sich in das Themengebiet einarbeiten wollen und die Grundkenntnisse auf dem Gebiet der Elektrotechnik, Elektronik, der Rechnerarchitektur, der Technischen und der Theoretischen Informatik mitbringen. ¨ Ziel des Buches ist es, einen Uberblick u ¨ber die Grundlagen, Anwendungen sowie die Entwicklungsmethodik von Eingebetteten Systemen zu vermitteln, wobei versucht wird, den Stoff mit vielen Beispielen aus der Praxis anschaulich und verst¨andlich darzustellen. F¨ ur jeden einzelnen Themenbereich ist jedoch eine tiefer gehende Behandlung im Rahmen dieses Buches nicht m¨ oglich und der Spezialliteratur vorbehalten. Studenten, aber auch Ingenieure aus anderen Fachbereichen, die sich in das Gebiet Eingebettete Systeme einarbeiten wollen, werden eventuell einige der folgenden F¨acher vertiefen m¨ ussen: Digitale Signalverarbeitung, Regelungs- und Steuerungstechnik, Rechenarchitektur, Betriebssysteme, Formale Verifikation, Spezifikationssprachen, Hardwarebeschreibungssprachen, Techniken des Niedrig-Leistungsverbrauchs (Low Power), Datensicherheit, Zuverl¨ assigkeit, Telekommunikation, drahtlose Kommunikation, Sensoren, Aktoren usw. Hinweise auf einschl¨ agige Literatur werden gegeben. Ein Lehrbuch st¨ utzt sich immer auch auf vorhandene Literatur. Wir haben zum Beispiel folgende Quellen verwendet: Vorlesungsmaterialien von J. Teich und L. Thiele [TeiThi03], D. D. Gajski et al.: Embedded Systems Design, [Ga09], W. Wolf, Computers

VI

Vorwort

as Components, [Wolf02], Principles of Embedded Computing System Design [Wolf07], P. Marwedel, Eingebettete Systeme [Mar07], G. Martin und H. Chang, Winning the SoC Revolution [Mart03] und viele andere. Weitere B¨ ucher, wissenschaftliche Aufs¨atze, Normen usw. sind im Text und in den Bildunterschriften zitiert und in der Literaturliste zusammengefasst. Eine Anmerkung zur Rechtschreibung: Zusammengesetzte W¨orter werden aus Gr¨ unden der besseren Lesbarkeit meist in der Bindestrich-Form geschrieben. Zum Beispiel wird anstatt Hardwarebeschreibungssprachen die Bindestrich-Form Hardware-BeschreibungsSprachen verwendet. Beide Schreibformen existieren nebeneinander. Die im Buch aufgef¨ uhrten Firmennamen sind gesetzlich gesch¨ utzte Bezeichnungen. Die meiste Fachliteratur ist in englischer Sprache und daher sind fast alle Fachausdr¨ ucke englisch. Oft gibt es deutsche Begriffe f¨ ur diese Fachausdr¨ ucke, die in diesem Buch bevorzugt verwendet werden, jedoch wird in einem solchen Fall der englische Ausdruck das erste Mal – und oft auch die Abk¨ urzung – in Klammern dahinter gesetzt. Zum Beispiel: System-Verhaltensmodell“ (System Behaviour Model SBM). Viele Fach” ¨ ausdr¨ ucke haben sich allerdings bei uns so eingeb¨ urgert, dass eine Ubersetzung nicht verstanden oder zur Verwirrung f¨ uhren w¨ urde. Ein Beispiel daf¨ ur ist der Begriff Chip“ ” als Siliziumpl¨ attchen, das eine gedruckte elektronische Schaltung enth¨alt. Dieses Buch ist aus Vorlesungen an den Universit¨aten T¨ ubingen und Leipzig entstanden. Wir danken Herrn Professor Dr. Wolfgang Rosenstiel f¨ ur die Unterst¨ utzung und Beratung bei den T¨ ubinger Vorlesungen und den Kollegen des Arbeitsbereichs Technische Informatik der Universit¨ at T¨ ubingen f¨ ur viele Diskussionen, Anregungen und Hilfen. Ein herzlicher Dank geht an Herrn Professor Dr. Oliver Bringmann f¨ ur die fachliche Durchsicht und f¨ ur viele konstruktive Vorschl¨age zur Aktualisierung des Inhalts. Desweiteren danken wir Herrn Prof. Dr. Udo Kebschull (ehemals Universit¨at Leipzig) f¨ ur ur die Einf¨ uhrung der Vorlesung VHDL an der Universit¨at Leipzig, die den N¨ahrboden f¨ die Vorlesung Eingebettete Systeme bereitet hat. Weiterhin danken wir Herrn J¨orn Hoffmann von der Universit¨ at Leipzig f¨ ur die Erstellung des Titelbildes und der Durchsicht eines Kapitels sowie den Herren Wolfgang Fuhl und Benjamin Matthes aus T¨ ubingen f¨ ur die Durchsicht einzelner Kapitel des Buches und f¨ ur viele Korrekturvorschl¨age. Die Struktur des Buches ist wie folgt: Im ersten Kapitel wird der Begriff Eingebet” tete Systeme“ erkl¨ art und abgegrenzt, Beispiele werden aufgef¨ uhrt und erl¨autert sowie der typische Aufbau von Eingebetteten Systemen beschrieben und anhand eines Beispiels n¨ aher erkl¨ art. Kapitel 2 stellt Grundstrukturen und Implementierungsarten ¨ von Eingebetteten Systemen vor. Kapitel 3 gibt einen Uberblick u ¨ber die Verwendung von Mikroprozessoren in Eingebetteten Systemen. Kapitel 4 behandelt Grundlagen der Kommunikation und geht auf Verbindungsnetze, verteilte Systeme und Verbindungselemente bei Eingebetteten Systemen ein, beispielsweise auf parallele und serielle Busse. In Kapitel 5 wird das weite Gebiet der Entwicklungsmethodik von den Anforderungen u ¨ber die Spezifikation zur Modellierung und der Realisierung von Eingebetteten Systemen vorgestellt. Kapitel 6 behandelt Beschreibungssprachen f¨ ur den Systementwurf mit Schwerpunkt auf VHDL und SystemC. Kapitel 7 ist den Sensornetzwerken gewidmet. Kapitel 8 stellt den theoretischen Hintergrund der High-Level-Synthese vor. High-LevelSynthesesysteme sind wichtige Werkzeuge f¨ ur den Entwickler von Eingebetteten Systemen. Die Kapitel 1, 2, 3, 4 und 6 sind Grundlagenkapitel und f¨ ur Bachelorstudenten

Vorwort

VII

gedacht, w¨ ahrend die Kapitel 5, 7, 8 weiterf¨ uhrende Themen behandeln und eher f¨ ur Masterstudenten und Fortgeschrittene bestimmt sind. F¨ ur positive Kritik und vor allem Verbesserungsvorschl¨ age sind wir aufgeschlossen und dankbar. Unsere Email-Adressen k¨ onnen Sie vom Verlag erfragen oder auch im Internet auf den Seiten der Universit¨aten T¨ ubingen und Leipzig finden. Wir w¨ unschen unseren Lesern einen guten Lernerfolg beim Lesen des Buches! Die Autoren. T¨ ubingen und Leipzig im Dezember 2012.

Inhaltsverzeichnis 1

Einf¨ uhrung

1

1.1

Begriffsbestimmung und Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Systemkategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.3

Typischer Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.4

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2

Bauformen und Implementierungsarten

9

2.1

Bauformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2

Implementierungsarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 2.3.1 2.3.2

¨ Ubersicht u ur Eingebettete Systeme . . . . . . . . . . . . . . . . 12 ¨ber Technologien f¨ Anwendungsspezifische Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Feldprogrammierbare Bausteine (FPGAs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4

Evolution der Siliziumtechnologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3

Mikroprozessor-Grundlagen

3.1

Evolution der Mikroprozessoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2

Mikroprozessoren in Eingebetteten Systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 3.3.7 3.3.8

Mikroprozessor-Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mikroprozessor-Architekturen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eingabe und Ausgabe durch Befehle, Register und Interrupts . . . . . . . . . . Speicher-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hauptspeicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Festwertspeicher (ROM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Befehls-Verarbeitungsmethoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performanz und Energieverbrauch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ein-Ausgabe-Ger¨ ate und Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26 26 29 31 37 40 40 46 50

3.4 3.4.1 3.4.2 3.4.3

Mikrokontroller und Mikroprozessoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Niedrigpreis-Mikrokontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mikroprozessoren h¨ oherer Leistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mikroprozessor-Familien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51 52 53 53

23

X

Inhaltsverzeichnis

3.5 3.5.1

Mehrprozessorsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Beispiel f¨ ur ein Mehrprozessor-System: Der Cell-Prozessor . . . . . . . . . . . . . . 63

3.6 3.6.1 3.6.2 3.6.3 3.6.4 3.6.5 3.6.6

Prozesse und Betriebssysteme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wozu Betriebssysteme? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aufgaben und Schichtenmodell eines Betriebssystems . . . . . . . . . . . . . . . . . . Echtzeitbetriebssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zeitablaufplanung in Echtzeitbetriebssystemen . . . . . . . . . . . . . . . . . . . . . . . . . Priorit¨ atsumkehr und Priorit¨ atsvererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.7

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4

Kommunikation, Busse, Netzwerke und verteilte Systeme

4.1

Das ISO-OSI-Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.2 4.2.1 4.2.2

Modellierung der Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Kommunikationsprimitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Der parallele Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.3

Verteilte Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

4.4 4.4.1 4.4.2

Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Kommunikationsmodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Netzwerk-Topologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

4.5 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5

Bus¨ ahnliche Netzwerke oder serielle Busse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Der I 2 C-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Der CAN-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FlexRay, LIN und MOST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Profibus (Process Field Bus) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Weitere Verbindungsnetzwerke f¨ ur verteilte Systeme. . . . . . . . . . . . . . . . . . . .

4.6

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

5

Entwicklungsmethodik

5.1

Die Produktivit¨ atsl¨ ucke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

5.2 5.2.1 5.2.2

Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Lastenheft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

5.3 5.3.1 5.3.2 5.3.3

Der Beginn einer Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Der Architekturbegriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pflichtenheft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.4 5.4.1 5.4.2

Entwurfsmethoden von Software-Systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Das Wasserfallmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Das Spiralmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

64 64 66 68 70 70 77

81

103 105 106 109 110 112

115

123 124 125 126

Inhaltsverzeichnis

XI

5.5

Hardware-Entwicklungsmethodik: Die Abstraktionsebenen . . . . . . . . . . . . . 131

5.6 5.6.1 5.6.2 5.6.3 5.6.4 5.6.5 5.6.6

Entwicklungsmethoden von Eingebetteten Systemen . . . . . . . . . . . . . . . . . . . Erfassen und Simulieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beschreiben und Synthetisieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Spezifizieren, Explorieren und Verfeinern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evolution der Chip-Entwicklung: Vom ASIC zum SoC . . . . . . . . . . . . . . . . . Plattformbasierter Entwurf f¨ ur Ein-Chip-Systeme . . . . . . . . . . . . . . . . . . . . . . Beispiele von Mehrprozessor-Entwicklungsplattformen . . . . . . . . . . . . . . . . . .

135 136 137 138 140 143 145

5.7 5.7.1 5.7.2 5.7.3 5.7.4 5.7.5 5.7.6

Modellieren von Systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Was sind Modelle? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modelle auf System- und algorithmischer Ebene: Berechnungsmodelle . . Unified Modeling Language (UML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transaction Level-Modellierung (TLM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modellieren auf RT-Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modelle auf Logik-Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

150 150 153 166 168 174 179

5.8 5.8.1 5.8.2 5.8.3 5.8.4

Modellbasierte Entwicklungsmethode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System-Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software-Synthese von Eingebetteten Systemen . . . . . . . . . . . . . . . . . . . . . . . . Das ESE-Werkzeug von Gajski et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

179 181 182 192 209

5.9 5.9.1 5.9.2 5.9.3 5.9.4 5.9.5 5.9.6

Software-Entwicklung f¨ ur Eingebettete Systeme . . . . . . . . . . . . . . . . . . . . . . . . Programmentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Entwickeln von Klassendiagrammen mit CRC-Karten . . . . . . . . . . . . . . . . . . Entwurfsmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Programm-Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compiler f¨ ur Eingebettete Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Programm-Optimierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

210 211 211 214 214 217 217

5.10 5.10.1 5.10.2 5.10.3

Verifikation, Simulation und Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Formale Verifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Werkzeuge f¨ ur Modellierung und Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . .

223 224 231 234

5.11 5.11.1 5.11.2 5.11.3 5.11.4

Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Begriffsbestimmungen, Black-Box- und White-Box-Test . . . . . . . . . . . . . . . . Ein klassisches Fehlermodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . JTAG Boundary-Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

236 237 238 238 240

5.12

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

6

Beschreibungssprachen f¨ ur den Systementwurf

243

6.1 6.1.1 6.1.2 6.1.3

VHDL – Eine Hardware-Beschreibungssprache . . . . . . . . . . . . . . . . . . . . . . . . . Grundlegender Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Sprachkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Schaltungsbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

244 245 249 250

XII

Inhaltsverzeichnis

6.1.4 6.1.5 6.1.6 6.1.7

Signale und Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parallele und sequenzielle Anweisungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

255 260 263 276

6.2 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6

Die System-Beschreibungssprache SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grundlagen von SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel eines SystemC-Moduls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulationssemantik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transaction-Modellierung mit SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RTL-Modellierung mit SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

277 279 282 291 293 294 295

7

Sensornetzwerke

297

7.1 7.1.1

Drahtlose Sensornetzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Einsatz von Sensornetzwerken, Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

7.2 7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.2.6 7.2.7

Kommunikation im Sensornetzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Der Protokoll-Stapel (Protocol Stack) von drahtlosen Sensornetzwerken Anwendungsschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transportschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Netzwerkschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Datensicherungsschicht (Data Link) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Medium Access Control (MAC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physikalische Schicht von drahtlosen Sensornetzwerken . . . . . . . . . . . . . . . . .

7.3 7.3.1

Der Sensorknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Beispiele von Sensorknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

7.4

Kommunikationsstandards f¨ ur MANETs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

7.5

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

8

High-Level-Synthese

321

8.1 8.1.1 8.1.2 8.1.3

Einf¨ uhrung: Begriffsbestimmungen und Bewertung . . . . . . . . . . . . . . . . . . . . . Begrisffsbestimmungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eingabe und Ausgabe eines High-Level-Synthese-Werkzeugs . . . . . . . . . . . . Bewertung von elektronischen Schaltkreisen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

322 322 323 326

8.2 8.2.1 8.2.2

Die wesentlichen Schritte der High-Level-Synthese . . . . . . . . . . . . . . . . . . . . . . 328 Allokierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Die Komponentenbibliothek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

8.3 8.3.1 8.3.2 8.3.3 8.3.4 8.3.5

Zeitablaufplanung (Scheduling) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Einf¨ uhrung in die Zeitablaufplanung: Der Sequenzgraf . . . . . . . . . . . . . . . . . . Zeitablaufplanung ohne Ressource-Schranken. . . . . . . . . . . . . . . . . . . . . . . . . . . Zeitablaufplanung unter Ressource- und Zeitschranken . . . . . . . . . . . . . . . . . Einige besondere Verfahren der Zeitablaufplanung . . . . . . . . . . . . . . . . . . . . . . Zusammenfassung des Abschnitts Zeitablaufplanung . . . . . . . . . . . . . . . . . . .

300 302 303 304 304 305 306 312

331 331 334 338 351 355

Inhaltsverzeichnis

XIII

8.4 8.4.1 8.4.2 8.4.3 8.4.4

Ressourcen-Bindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kompatibilit¨ ats- und Konfliktgraf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bindung von Speicher-Ressourcen (Registern) . . . . . . . . . . . . . . . . . . . . . . . . . . Die Grafen-Partitionierungs-Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zuweisung von Verbindungselementen und Erstellung der Netzliste . . . .

355 356 358 361 363

8.5 8.5.1 8.5.2

Steuerwerksynthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 Das mikrocodebasierte Steuerwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 Das hartverdrahtete Steuerwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

8.6

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

Literaturverzeichnis

375

Index

383

1

Einfu¨hrung

Computer und Eingebettete Systeme nehmen dem Menschen Routinearbeiten ab. Wir betrachten als Beispiel das Eingebettete System Temperaturregelung“ (siehe Abbil” dung 1.3). Zu Beginn des vorigen Jahrhunderts wurde die Temperatur in einem Raum durch die Intensit¨ at des Heizens und der L¨ uftung bestimmt, die eine Person im Raum vornahm. Dadurch waren relativ große Temperaturschwankungen unvermeidlich. Erst mit dem Aufkommen und der Verbreitung der Messger¨ate, der Elektronik und der mathematischen Grundlagen wurden Ger¨ ate ersonnen, die Regel- und Steueraufgaben u ¨bernehmen konnten. Mit dem Eingebetteten System Temperaturregelung“ ist ” es m¨ oglich, sehr effizient und wirtschaftlich, ohne menschlichen Arbeitsaufwand die Temperatur in einem Raum in engen Grenzen konstant zu halten. Diese Kapitel beginnt mit einer Auslegung des Begriffs Eingebettete Systeme und mit einigen Beispielen f¨ ur Eingebettete Systeme aus unserer Umgebung und der Industrie. Der Typische Aufbau von Eingebetteten Systemen wird vorgestellt und anhand des Beispiels Temperaturregelung veranschaulicht. Auf Grundstrukturen und Implementierungsarten wird eingegangen.

1.1

Begriffsbestimmung und Beispiele

Eingebettete Systeme sind datenverarbeitende Systeme, die in u ¨ bergeordnete Systeme integriert sind. Sie f¨ uhren spezielle Aufgaben und Funktionen im u ¨bergeordneten System aus und werden ausschließlich f¨ ur diese Funktionen entwickelt. In dem vorliegenden Buch werden ausnahmslos elektronische Systeme behandelt. Eingebettete Systeme sind, wenn nicht gerade das Herzst¨ uck, so doch meist unverzichtbarer integraler Bestandteil in beispielsweise folgenden u ¨bergeordneten Systemen (siehe Abbildung 1.1) • In Transport-Vehikeln als Antriebssteuerung, Klimaregelung, Bremssysteme, Navigationssysteme. – In Kraftfahrzeugen z. B. als Motorsteuerung, ABS. – In Flugzeugen z. B. als Autopilot, Klimaanlage und Druckregelung in der Kabine. – In Eisenbahnen. – In Schiffen. • In medizinischen Ger¨ aten als Gehirn- und Retina-Tomographen, Mikromessger¨aten, z. B. f¨ ur die Darmspiegelung, in Herzschrittmachern, k¨ unstlichen Prothesen usw.

2

1 Einf¨ uhrung • In der mobilen und Festnetz-Kommunikation. • In milit¨ arischen Ger¨ aten, Anlagen und Transport-Vehikeln. • Im intelligenten Haus“ bzw. im intelligenten B¨ uro“ als Klimaregelung, Sicher” ” heits¨ uberwachung, Anzeige von belegten R¨aumen usw. • In optischen Ger¨ aten. • In Produktionsanlagen als Fließbandsteuerung, zur Steuerung von Hochregallagern, als Klimaregelung, in Alarmsystemen usw. • In Kraftwerken, die Energie umwandeln als Steuerung und Regelung der Energieumwandlung in W¨ arme oder Strom und deren Verteilung. • In der Chemie- und Verfahrenstechnik als Prozess-Steuerungen. • In Multimedia-Anwendungen, z. B. in der Unterhaltungselektronik und in Spielen. • In Handel- und Bankenendger¨ aten als Kassensysteme, in speziellen Druckern, zum Beispiel in Kontoauszugsdruckern, Sparbuchdruckern, in Geldausgabe-Automaten usw.

Kraftfahrzeuge

Schiffe

Flugzeuge

Handel- und BankenTerminals

Medizinische Geräte Eingebettetes System

Optische Geräte

HaushaltsGeräte Büro- und Geschäftshäuser

MobilTelefone

Abbildung 1.1: Beispiele von u ¨bergeordneten Systemen, die Eingebettete Systeme enthalten k¨ onnen.

1.2 Systemkategorien

3

Wie bereits erw¨ ahnt, geh¨ ort zu einem Eingebetteten System immer ein u ¨bergeordnetes System, in dem es eine dedizierte Aufgabe ausf¨ uhrt. Damit ist der Begriff Einge” bettetes“ System hinl¨ anglich eingegrenzt. Ist beispielsweise das Platzbuchungssystem einer Fluggesellschaft ein Eingebettetes System? Antwort: Nein, es ist selbst ein eigenst¨ andiges Software-System, das zwar in einem oder mehreren Computern l¨auft, die aber nicht als u ¨bergeordnete Systeme betrachtet werden. Der Trend zur Miniaturisierung Eingebetteter Systeme und zur Durchdringung aller Arbeits- und Lebensbereiche schl¨ agt sich nieder in den folgenden drei Begriffen, die teilweise synonym sind: allge” genw¨ artiges Computing“ (Ubiquituos Computing) [Mar07], u ¨beralleindringendes Com” puting“ (Pervasive Computing) [Hnsm01] und Intelligente Umgebung“ (Ambient Intel” ligence, AmI) [deMan03]. W¨ ahrend allgegenw¨artiges Computing“ die Tendenz Infor” ” mation u ¨berall und zu jeder Zeit“ zum Ausdruck bringt, zielt das u ¨beralleindringende ” Computing“ mehr in die Richtung praktischer Ger¨ate wie Haushaltsmaschinen, die nach und nach von Eingebetteten Systemen gesteuert bzw. geregelt werden und mit den Benutzern kommunizieren. Ambient Intelligence“ schließlich bedeutet, dass hochinteg” rierte Chips in unsere n¨ achste Umgebung einziehen werden, also in Geb¨aude oder, noch n¨ aher, in unsere Kleider, Jacken, Handschuhe, beispielsweise als medizinische Helfer, zur Unterhaltung, im Sport oder als Helfer im Beruf, z. B. als Erinnerungs-Ansage f¨ ur einen Termin bzw. als Navigationshilfe in einem un¨ ubersichtlichen Geb¨aude.

1.2

Systemkategorien

Im vorhergehenden Abschnitt werden Beispiele Eingebetteter Systeme in verschiedenen Industriezweigen und Anwendungen aufgef¨ uhrt. Eine Einteilung in verschiedene Kategorien kann aus verschiedenen Gesichtspunkten vorgenommen werden. A. Jantsch [Jan04] zeigt eine Klassifikation entsprechend der Systemeigenschaften. Eine Klassifizierung der Eingebetteten Systeme im Hinblick auf die Schnittstellen nach außen und in Bezug auf die Bedienung des jeweils u ¨bergeordneten Systems kann – ohne Anspruch auf Vollst¨ andigkeit – wie folgt vorgenommen werden: • Eingebettete Systeme, die Steuerungs- und Regelungsaufgaben wahrnehmen und die keine offenen Bedienungs-Schnittstellen zum Benutzer haben. Dies sind die u ¨berwiegende Menge der sogenannten Versteckten Systeme“ wie z. B. die Hei” zungsregelung, ABS im KFZ, Autopilot im Flugzeug, Herzschrittmacher, Fokussiersteuerung in der Kamera, Ger¨ ate der Unterhaltungs- und Kommunikationselektronik wie z. B. Fernseh-, Video- und Stereo-Ger¨ate usw. • Ger¨ ate, die von der Fachfrau bzw. vom Fachmann bedient werden. In diesem Zusammenhang bedeutet Fachfrau bzw. Fachmann eine Person, die Grundlagenkenntisse u ¨ber das Einsatzgebiet des Ger¨ats besitzt und/oder einer Anlernung bedarf, entweder durch eine Fachperson oder entsprechende Literatur. Beispiele daf¨ ur sind: Steuerungen von chemischen Prozessen oder Kraftwerken, Medizinische Ger¨ ate, Physikalische Messger¨ ate usw. • Datenendger¨ ate, die von der Fachfrau bzw. vom Fachmann bedient werden. Datenendger¨ ate sind Ger¨ ate, die mit einem zentralen Computer verbunden sind. Oft

4

1 Einf¨ uhrung stehen diese Ger¨ ate mit einer Datenbank in Verbindung. Beispiele sind: Supermarkt-Kasse, elektronische Waagen im Supermarkt, Drucker in LAN-Umgebungen usw. • Selbstbedienungsger¨ ate, die von Laien benutzt werden: z. B. alle sogenannten Automaten wie Fahrkartenautomat, Geldausgabeautomat, Haushaltsmaschinen usw. F¨ ur diese Ger¨ ate ist besondere Beachtung auf eine gute Benutzerf¨ uhrung zu legen. Die Bedienung muss einfach sein und die Bedienerf¨ uhrung gut verst¨andlich. Besonders wichtig ist, dass Fehlbedienungen keine katastrophalen Folgen haben, sondern wieder geduldig zum Ausgangspunkt der Bedienung f¨ uhren und eventuell dem Benutzer den Fehler anzeigen. F¨ ur den Entwicklungsingenieur bzw. -Informatiker ist ¨ es wichtig zu wissen, dass Selbstbedienungsger¨ate, die in der Offentlichkeit stehen, oft Vandalismus zu erleiden haben, d. h. sie m¨ ussen entsprechend mechanisch robust aufgebaut werden. • Mobile, tragbare Ger¨ ate f¨ ur die private und gesch¨aftliche Nutzung mit und ohne drahtlose Verbindung zu einer Basisstation bzw. einem Server wie z. B. Mobiltelefone, PDAs, Laptops usw.

Je nach Systemkategorie werden an die u ¨bergeordneten Systeme und an die Eingebetteten Systeme verschiedene Anforderungen gestellt (siehe Kapitel 5).

Eingabe

Prozessor 1

Speicher

Prozessor 2

Ausgabe

Schnittstelle

Verbindungselement

Schnittstelle

ASIC

Sensor(en)

Schnittstelle

Aktor(en) Eingebettetes System System-Umgebung

Abbildung 1.2: Typischer Aufbau eines Eingebetteten Systems (nach [TeiThi03]).

1.3 Typischer Aufbau

1.3

5

Typischer Aufbau

Der typische Aufbau von Eingebetteten Systemen ist in Abbildung 1.2 dargestellt. Ein Eingebettetes System enth¨ alt in der Regel einen Prozessor, der ein Vielzweck-Prozessor (General Purpose Processor) oder ein anwendungsorientierter Prozessor sein kann. Auf die Art und die Anwendungsbereiche der verschiedenen Prozessoren wird intensiver in Kapitel 3 eingegangen. In vielen F¨ allen ist ein zweiter, dritter usw. Prozessor bzw. ein ASIC (Application Specific Integrated Circuit), also ein anwendungsspezifischer Schaltkreis n¨ otig, um die erforderliche Rechenleistung zu bew¨altigen, die bei Eingebetteten Systemen oft in Echtzeit“ ausgef¨ uhrt werden muss (siehe Kapitel 3). Diese zus¨atzlichen ” Prozessoren wurden fr¨ uher Rechenbeschleuniger“ genannt. Heute werden meist Mehr” ” prozessorsysteme“ (siehe Abschnitt 3.5) eingesetzt. Der Speicher enth¨alt sowohl Datenals auch das Ausf¨ uhrungs-Programm des Prozessors bzw. der Prozessoren und kann sowohl als RAM (Random Access Memory) als auch als ROM (Read Only Memory) ausgef¨ uhrt sein. Als zus¨ atzliche Prozessoren k¨onnen auch FPGAs (siehe Abschnitt 2.3.2) zum Einsatz kommen. Ein Beispiel f¨ ur die Verwendung eines Mehrprozessorsystems ist ein Videoger¨ at, bei dem Videobilder in schneller Abfolge dekomprimiert oder komprimiert werden m¨ ussen. Schnittstellen nach außen sind: Eingabe und Ausgabe-Schnittstellen. Beispiele f¨ ur Eingaben sind bei einer Temperaturregelung: der Sollwert der Temperatur und Parameter der Heizanlage. Ausgaben sind beispielsweise Fehler-Anzeigen. Schnittstellen sind aber auch n¨ otig bei Sensor-Eingaben und Aktor-Ausgaben (auch Aktuator“” Ausgaben genannt). Beispiele bei einer Temperaturregelung: Eingabe des TemperaturSensors und Ausgabe des Stellwerts als Aktor-Ausgabe f¨ ur das Mischer-Ventil, das die Verteilung des Heizungswassers in den Heizk¨ orpern bestimmt. Das Verbindungselement kann ein Bus“ sein (siehe sp¨ ater). ” Ein ASIC (siehe Tabelle 2.1) ist ein anwendungsspezifischer Integrierter Schaltkreis. Es ist ein Hardware-System, das speziell f¨ ur eine dedizierte Anwendung entwickelt und gefertigt wird. Die Vorteile von ASICs sind folgende: Bei sehr hohen St¨ uckzahlen sind sie sehr kosteng¨ unstig. Die Ausf¨ uhrungszeit eines ASICs kann relativ kurz sein, ebenso ist der Leistungsverbrauch relativ gering. Die Nachteile von ASICs sind: Da sie nur f¨ ur ¨ die eine Anwendung bestimmt sind, sind sie recht unflexibel, auch kleine Anderungen sind nicht m¨ oglich. Der Aufwand f¨ ur die Entwicklung und Einf¨ uhrung in die Produktion von ASICs ist relativ hoch. Abbildung 1.3 zeigt schematisch ein einfaches Beispiel f¨ ur eine Temperaturregelung als Eingebettetes System. Das u ¨bergeordnete System ist die zentrale WarmwasserHeizungsanlage f¨ ur ein Haus. Gezeigt wird ein beheizter Raum, in dem sich ein Heizk¨ orper und als Sensor ein Temperaturf¨ uhler befindet. Ein weiterer Temperaturf¨ uhler ermittelt die Außentemperatur. Das Eingebettete System hat an den Sensoreing¨angen Analog/Digital-Wandler (A/D-Wandler), in dem die analogen Temperaturf¨ uhler-Signale in digitale Signal umgewandelt werden. Der Prozessor, der als Eingabe den TemperaturSollwert und die Parameter der Heizanlage erh¨ alt, berechnet aus dem Sollwert und dem Istwert der Temperatur im Raum den Stellwert f¨ ur den Mischer, der den HeißwasserZufluss f¨ ur den Heizk¨ orper im Raum steuert. Der Stellwert liegt zun¨achst als digitaler Wert vor und wird in einem Digital/Analog-Wandler (D/A-Wandler) in einen analogen Wert umgewandelt.

6

1 Einf¨ uhrung TemperaturFühler, außen

Beheizter Raum TemperaturFühler, innen

Heizkörper

Temperatur-Regler als Eingebettetes System

A/DWandler

A/DWandler

SollwertEingabe

Prozessor

D/A Wandler

Aktor

D/A Wandler

Aktor

Heizkessel + Brenner

Mischer Anzeigen: Istwert, Fehler

Heizanlage

Abbildung 1.3: Schematische Darstellung einer Temperaturregelung als Beispiel f¨ ur ein Eingebettetes System. Das u ¨bergeordnete System ist die Warmwasser-Heizanlage.

Der Außenf¨ uhler dient dazu, die Heizleistung zus¨atzlich zu steuern und bei hohen Aussentemperaturen den Brenner ganz ab zu schalten. Je nach Anforderungen an die Regelgenauigkeit muss in diesem Beispiel der Prozessor in der Lage sein, entweder Differenzen zwischen Ist- und Sollwert zu bilden (Proportional P-Regler) oder auch bei h¨oheren Anforderungen zu integrieren bzw. zu differenzieren (PI- bzw. PID-Regler). Als Parameter werden z. B. das Raumvolumen, die Leistung der Heizanlage, der Zusammenhang zwischen Stellwert und Heizenergiezufuhr eingegeben. Tabelle 1.1 (nach [TeiTie03]) zeigt Beispiele verschiedener Eingebetteter Systeme, deren Sensoren und Aktoren mit den jeweiligen dazugeh¨origen Schnittstellen. Aufgef¨ uhrt ist eine Temperaturregelung, ein Antiblockiersystem (ABS), ein Laserdrucker und eine Motoreinspritzung im Auto.

1.4 Zusammenfassung

Beispiele

Sensoren

Temperaturregelung ABS (AntiblockierSystem)

Temperaturf¨ uhler

Laserdrucker MotorBrennstoffeinspritzung

SchlupfAnzeige, Drehzahl Temperaturf¨ uhler Tasten/ Schalter Motordrehzahl, Position d. Gaspedals u. d. Kurbelwelle

7 SensorSchnittstelle A/D-Wandler

A/D-Wandler

A/D-Wandler, ParallelSchnittStelle A/D Wandler, Komparatoren

AktorSchnittstelle D/A-Wandler, Komparatoren, Pulsformer

Mischer-Motor, Heizungs-Schalter

D/A-Wandler, Pulsformer

HydraulikVentile

D/A-Wandler, Pulsformer

Lasersteuerung, Leistungselektronik f¨ ur Motoren

D/A-Wandler, Pulsformer

Z¨ undung Einspritzung

Aktoren

Tabelle 1.1: Beispiele f¨ ur Sensoren/Aktoren und deren Schnittstellen bei verschiedenen Eingebetteten Systemen (nach [TeiThi03]).

1.4

Zusammenfassung

Eingebettete Systeme sind bereits integraler Bestandteil unserer Umgebung, sei es in unserem B¨ uro, im Wohnhaus, im Kraftfahrzeug, in medizinischen Ger¨aten, in Industrieanlagen usw. Ein typisches Eingebettetes System enth¨ alt ein oder mehrere Prozessorelemente, Verbindungselemente, Schnittstellen zu Sensoren und Aktoren sowie zu Eingabe- und Ausgabevorrichtungen. Sensoren nehmen bestimmte physikalische Gr¨oßen der Umgebung auf (zum Beispiel Temperatur, Wege, Schaltereinstellungen) und berechnen mit Hilfe eines Prozessorelements den Zeitverlauf des Aktorsignals. Das Aktorsignal muss oft in Echtzeit“ erfolgen, d. h. es muss als Reaktion zum Sensorsignal bestimmte Zeitgrenzen ” einhalten (siehe sp¨ ater).

2

Bauformen und Implementierungsarten

Eingebettete Systeme werden oft als unsichtbare Computer“ bezeichnet. In der Tat ” baut die Hardware von Eingebetteten Systemen zu einem großen Teil auf ComputerHardware auf. Technologien, die im Computerbau Anwendung finden, werden meist mit Zeitverz¨ ogerung u ¨bernommen und den Anforderungen von Eigebetteten Systemen angepasst.

2.1

Bauformen

Bauformen von Eingebetteten Systemen sind [TeiThi03]: • Ein-Chip-Systeme • Multi-Chip-Module und • Board-Systeme Bei Ein-Chip-Systemen (System on a Chip, SoC) ist das gesamte System auf einem Chip integriert. Der Entwicklungsaufwand ist sehr hoch (siehe Tabelle 2.1), daf¨ ur ist die Zuverl¨ assigkeit bei diesem System ebenfalls sehr hoch; denn ein Chip ist relativ klein, leicht und in einem Geh¨ ause eingebaut. Es ist nahezu unzerbrechlich und ziemlich unempfindlich gegen Ersch¨ utterungen und St¨ oße. Der Leistungsverbrauch ist niedrig; denn Leitungstreiber und Ausgabe-Puffer entfallen bzw. sind nur an der Peripherie des Chips n¨ otig. Die Entwicklung von Ein-Chip-Systemen lohnt sich nur, wenn die St¨ uckzahlen sehr hoch sind, d. h. abh¨ angig von System und Anwendung etwa in der Gr¨ oßenordnung von einigen zehn- bis hunderttausend St¨ uck und dar¨ uber. Board-Systeme sind aus einer oder mehreren Platinen, d. h. gedruckten Schaltun” gen“ aufgebaut. Der Entwickler kauft die einzelnen Teile des Systems ein bzw. entwirft fehlende Teile selbst, testet das gesamte System und l¨asst es auf ein Board“ oder eine ” Platine aufbringen und verdrahten. Der Entwicklungsaufwand ist relativ gering, daf¨ ur sind die Produktions- und St¨ uckkosten sehr hoch und die Zuverl¨assigkeit wegen des relativ großen Verdrahtungsnetzes und der Verbindungsstecker gering. Erfahrungsgem¨ aß versagen Board-Systeme bei Beanspruchung, z. B. bei Ersch¨ utterungen, weil L¨ otstellen zwischen Modulanschl¨ ussen und gedruckten Leiterbahnen den Kontakt verlieren k¨ onnen oder weil Leiterbahnen oder Steckverbindungen brechen.

10

2 Bauformen und Implementierungsarten

Gr¨ oße Leistungsverbrauch Zuverl¨ assigkeit Entwicklungskosten, Entwicklungszeit St¨ uckkosten bei sehr hoher St¨ uckzahl (≥106 )

ASIC oder SoC

Multi-Chip-Module (MCM oder SIP)

Board-Systeme (Platinen)

sehr klein (1) sehr niedrig (1) sehr hoch (10) sehr hoch (10)

klein (3) sehr niedrig (1–2) sehr hoch (9) hoch (8)

sehr groß (10) sehr hoch(10) relativ gering (1) gering (4)

sehr gering (1)

gering (3)

hoch (10)

Tabelle 2.1: Vergleich der Bauformen von Eingebetteten Systemen. Bewertungsziffern von 1: (sehr klein) bis 10 (sehr groß) (nach [TeiThi03]).

Ein Multi-Chip-Modul (MCM Multi Chip Package MCP) besteht aus mehreren separaten Chips (englisch: Dies), die meist auf einem Keramik- oder Kunststoffpl¨attchen (dem Verdrahtungstr¨ ager) mit aufgedampfter oder aufgedruckter Verdrahtung planar aufgebracht sind und dort verdrahtet werden. Die Verdrahtung geschieht durch bon” den“, d. h. hauchd¨ unne Dr¨ ahte (25 bis 500 μm) aus einer Gold- oder AluminiumLegierung werden mit den Anschl¨ ussen des Chips und dem Verdrahtungstr¨ager mit speziellen Verfahren verschweißt. Der Verdrahtungstr¨ager mit den Chips wird wie ein Einzelchip in ein Geh¨ ause eingeschweißt und ist von außen nicht als MCM erkennbar. Die Bezeichnung MCM wird auch auf Module angewendet, die neben Halbleiter-Chips auch diskrete passive Bauelemente wie z. B. Kondensatoren oder Widerst¨ande in SMDBauformen (Surface Mounted Device) beinhalten. Die Einzelchips k¨onnen speziell f¨ ur die Integration in einem MCM und auf der Basis unterschiedlicher Technologien entworfen werden, deren Integration auf einem Einzelchip schwierig w¨are. Beispiele sind hier Mikrokontroller und ihre analogen Peripheriebausteine und/oder Flash-, oder SRAMSpeicher, Mikroprozessorkerne und Cache-Bausteine oder in Handys die Kombination von Prozessor mit SRAM- und Flash-Speichern und anderen Funktionseinheiten. Werden mehrere Chips u ¨bereinander gestapelt, spricht man von einem System-inPackage (SIP), auch Die-Stacking“ genannt. Damit das komplette Bauteil bei ge” stapelten Chips nicht zu hoch wird, werden die Chips vorher oft mit einigem Aufwand d¨ unn geschliffen. Die Verdrahtung wird entweder mittels Durchkontaktierung durch die Chips oder durch D¨ unnschichten an den Seitenkanten mit aufgedruckten Leiterbahnen ausgef¨ uhrt. Anschließend wird das Chip-Paket mit einer Kunstoffmasse vergossen, die Anschl¨ usse zu den externen Pins gebondet (verschweißt) und in ein Geh¨ause verpackt. Die Anzahl der gestapelten Chips ist durch die n¨otige W¨armeabfuhr begrenzt. Ein MCM oder ein SIP l¨ asst sich meist schneller produzieren als ein SoC. In der Bewertung der Eigenschaften liegen MCMs und SIPs zwischen den Ein-Chip-Systemen und den Board-Systemen (siehe Tabelle 2.1).

2.2 Implementierungsarten

2.2

11

Implementierungsarten

Die Wahl der Implementierungsart eines Eingebetteten Systems h¨angt ab von den Anwendungsanforderungen, von der St¨ uckzahl, von der Vorgeschichte der Entwicklung, vom geforderten Leistungsverbrauch, vom Zeitplan der Fertigstellung usw. Abbildung 2.1 zeigt schematisch verschiedene Implementierungsarten [TeiThi03]. Auf der linken Seite sind Vielzweck-, Spezial- und anwendungsspezifische Befehlssatz-Prozessoren dargestellt. F¨ ur diese Prozessoren muss Software entwickelt werden. Auf der rechten Seite von Abbildung 2.1 ist Hardware als Implementierungsart von Eingebetteten Systemen dargestellt. Rechts oben programmierbare Hardware, zum Beispiel FPGAs, (siehe Abschnitt 2.3.2) und anwendungsspezifische Hardware. Vielzweck-Prozessoren (General Purpose Processors) sind f¨ ur Systeme mit hohen Leistungsanforderungen mit hoher Programmierbarkeit und Flexibilit¨ at geeignet, sie sind aber relativ teuer und verbrauchen viel Energie. Man wird sie bei Eingebetteten Systemen eventuell f¨ ur Prototypen einsetzen, bei denen der Preis und die Verlustleistung eine untergeordnete Rolle spielen.

Prozessoren + Software

Flexibilität, Energieverbrauch Programmierbar

(Vielzweck- Mikro-) Prozessor

Hardware

Spezial-Prozessoren DSP, Mikrokontroller

Field Programmable Gate Array

FPGA, PLD

ASIP Application Specific

ASIC

Instruction Set Processor

Application Specific Integrated Circuit

Ein-Chip-System (SoC)

Abbildung 2.1: Implementierungsarten von Eingebetteten Systemen (nach [TeiThi03]).

Spezialprozessoren sind Prozessoren f¨ ur besondere Aufgaben, Beispiele sind digitale Signal-Prozessoren (DSP), Mikrokontroller und Prozessoren mit anwendungsspezifischem Befehlssatz (Application Specific Instruction Set Processors: ASIP). Die Spezialisierung kann den Befehlssatz, die Funktionseinheiten und/oder die Speicherarchitektur betreffen. Die Operatorverkettung Multiply-Accumulate (MAC) ist ein Beispiel f¨ ur die Spezialisierung des Befehlssatzes, die bei Matrizen-Rechnungen eingesetzt wird. Bei-

12

2 Bauformen und Implementierungsarten

spiele f¨ ur die Spezialisierung der Funktionseinheiten und der Speicherarchitektur findet man bei Grafik-Prozessoren, die oft Funktionseinheiten f¨ ur Pixel-Operationen enthalten und mehrere Speicherb¨ anke mit parallelem Zugriff f¨ ur die Komprimierung und Dekomprimierung von Video-Daten einschließen. Digitale Signal-Prozessoren werden beispielsweise f¨ ur die Verarbeitung von Audio- und Bild-Signalen eingesetzt. Mikrokontroller sind Prozessoren, denen haupts¨achlich Steuerungsaufgaben zugewiesen werden (siehe Abschnitt 3.4). Sie sind optimiert z. B. f¨ ur Bitund Logik-Operationen. F¨ ur die Ausf¨ uhrung umfangreicher arithmetischer Operationen sind sie nicht geeignet. Spezialprozessoren im Vergleich zu Vielzweck-Prozessoren sind f¨ ur eine spezielle Anwendung ausgelegt und f¨ uhren diese Anwendung effizient aus bei relativ geringem Energieverbrauch und relativ geringen Kosten. Field Programmable Gate Arrays (FPGA) sind Hardware-Module, die vom Benutzer konfigurierbar sind. FPGAs sind praktisch programmierbare Hardware“, auf sie ” wird im Abschnitt 2.3.2 n¨ aher eingegangen. Unten rechts im Diagramm der Abbildung 2.1 ist das vollkundenspezifische ASIC aufgef¨ uhrt. Es ist spezielle Hardware f¨ ur eine spezifische Anwendung, es ist nicht flexibel, weist aber die beste Leistung (Performanz) bei geringstem Leistungsverbrauch auf (siehe Abschnitt 2.3). Das Ein-Chip-System (SoC) kann Mikroprozessoren plus Speicherbausteine f¨ ur die erforderliche Software und Daten, Spezialprozessoren, ASIPs, sowie FPGAs und ASICs enthalten. F¨ ur das SoC gilt das gleiche wie f¨ ur das ASIC bez¨ uglich Kosten, Entwicklungszeit und Energieverbrauch.

2.3

¨ Ubersicht u¨ber Technologien fu¨r Eingebettete Systeme

Wie Abbildung 2.2 zeigt, kann die Technologie-Ausf¨ uhrung von Integrierten Schaltkreisen f¨ ur Eingebettete Systeme in voll kundenspezifisch“ (Custom) und teilweise ” ” kundenspezifisch“ (Semi-custom) eingeteilt werden. Die teilweise kundenspezifischen Technologien k¨ onnen weiter untergliedert werden in Zellen-basiert und Array-basiert usw.

2.3.1

Anwendungsspezifische Hardware

Zur voll kundenspezifischen Technologie (Abbildung 2.2) geh¨ort der anwendungsspezifische Integrierte Schaltkreis (ASIC). Wie in den vorhergehen Abschnitten bereits erw¨ ahnt, ist die Entwicklung eines ASIC teuer und aufw¨andig, hat aber auch große Vorteile in Bezug auf Zuverl¨ assigkeit, Gr¨ oße und St¨ uckkosten bei großen St¨ uckzahlen. Bei der Fertigung eines ASIC werden etwa dreißig fotolithograhische Masken verwendet. Ein ganzer Maskensatz ist sehr teuer. Die teilweise kundenspezifische SchaltkreisTechnologie, z. B. die Standard-Zellen“- und die Makro-Zellen“-Technologie ist ” ” kosteng¨ unstiger, weil f¨ ur die Chip-Fertigung bereits teilweise vorgefertigte fotolithograpische Masken bereit stehen. Die Standard-Zellen-Schaltkreise (siehe Abbildung 2.3 links) haben eine feste Zellenh¨ ohe und eine variable Zellenbreite. Die Chipgr¨oße und

¨ 2.3 Ubersicht u ur Eingebettete Systeme ¨ber Technologien f¨

13

ES-Technologien

Teilweise kundenspez. Semi-Custom

Kundenspez. (Custom) (ASIC) Zellen-basiert

Array-basiert

vorverdrahtet: FPGA

Standard-Zellen

Makro-Zellen

Gate-Array

einmalprogrammierbar

wiederprogrammierbar

Abbildung 2.2: Technologien von Eingebetteten Systemen (nach [RechPom02]).

die Anzahl der Ein/Ausgabeanschl¨ usse ist variabel. Es existieren verschiedene vorgegebene Zellbibliotheken (z. B. NAND, NOR, Inverter usw.) f¨ ur die jeweiligen aktuellen Strukturbreiten. Komplexe Funktionen lassen sich nur u ¨ber langgestreckte Zellen oder mehrere Reihen realisieren. Der Nachteil ist eine große Chipfl¨ache, daher ist ihr Integrationsgrad begrenzt [RechPom02]. Beim Makro-Zellen-Schaltkreis (siehe Abbildung 2.3 Mitte) werden komplexe Strukturen wie Prozessorkerne, Speicher, Standardzellen-Bl¨ocke usw. kundenspezifisch fl¨achenoptimiert zusammengestellt. Auch hier ist die Chipgr¨oße und die Anzahl der Ein/Ausgabeanschl¨ usse variabel. Die Tendenz der Entwicklung geht in Richtung MakrozellenSchaltkreis. Beim Gate-Array“ (siehe Abbildung 2.3 rechts) liegt die Grundstruktur und da” mit die Chipgr¨ oße sowie die Anzahl der Ein/Ausgabeanschl¨ usse fest, nur die Verdrahtung wird kundenspezifisch ausgef¨ uhrt. Zur Kategorie der Gate-Arrays geh¨oren auch die Read-Only-Memories (ROM). Gate-Arrays werden eingesetzt f¨ ur spezielle Anwendungen wo z. B. strahlungsharte“ Schaltkreise ben¨otigt werden oder f¨ ur Prototypen. ” Die vorverdrahteten Array-basierten Integrierten Schaltkreise, die sogenannten feldprogrammierbaren Gate-Arrays (FPGAs, siehe Abschnitt 2.3.2) werden unterteilt in einmalprogrammierbare Schaltkreise, das sind z. B. PROMs (Programmable Read Only Memories), PLDs (Programmable Logic Devices), einmalprogrammierbare FPGAs und wiederprogrammierbare (auch rekonfigurierbare) Schaltkreise, das sind z. B. EPROMs (eraseable PROMs), EPLDs (eraseable PLDs) und reprogrammierbare FPGAs.

14

2 Bauformen und Implementierungsarten

Zelle

Verdrahtungskanäle

Makro-Zellen-IC Verdrahtungskanäle

Anschlussstellen (pads)

ALU

PLD

STDZellen

Anschlussstellen

Gate-Array aktives Gebiet gleicher Zellen

ROM

RAM

Standard-Zellen-IC

Verdrahtungskanäle

Ein/Ausgabezellen

Abbildung 2.3: Zellen-basierte, teilweise kundenspezifische Technologie. Links ist schematisch ein Standard-Zellen-Schaltkreis, in der Mitte ein Macro-Zellen-Schaltkreis gezeigt. Rechts: Array-basierte kundenspezifische Technolgie: Gate Array (nach [RechPom02]).

Tabelle 2.2 zeigt einen ungef¨ ahren Vergleich der Technologien f¨ ur Eingebettete Systeme. Bei einem ASIC-Baustein ist die Transistordichte sehr hoch, ebenso die Taktrate und damit die Ausf¨ uhrungsgeschwindigkeit, die Entwicklungs- und die Produktionszeit wird relativ lang sein, es fallen dadurch hohe Entwicklungskosten und damit PrototyenKosten an. Das bedeutet, die Kosten f¨ ur eine geringe Anzahl von Versuchsmustern fallen damit ebenfalls sehr hoch aus, daf¨ ur sind aber die St¨ uckkosten bei hoher St¨ uckzahl optimal niedrig. Das heißt: Ein ASIC eignet sich am besten f¨ ur ein ausgereiftes Produkt, das mit sehr hohen St¨ uckzahlen in Serie geht. Die Fertigung von Zellen-basierten Integrierten Schaltungen nimmt normalerweise weniger Zeit in Anspruch als bei einem ASIC, die Kosten f¨ ur wenige Prototypen werden auch hier sehr hoch sein, jedoch werden die St¨ uckkosten bei sehr hoher St¨ uckzahl etwas h¨ oher sein als bei ASICs, da die Chip-Fl¨ ache bei Zellen-basierten Schaltungen gr¨oßer ausfallen wird. Bei einem Gate-Array gilt: Die Gr¨ oße des Chips ist vorgegeben, d. h. hier wird in vielen F¨ allen der Baustein nicht optimal genutzt werden k¨onnen. Die Produktionskosten sind geringer als bei den Zellen-basierten Bausteinen, aber die St¨ uckkosten bei sehr hohen St¨ uckzahlen sind h¨ oher als beim ASIC. Wiederprogrammierbare FPGAs k¨onnen handels¨ ublich bezogen werden. Die Funktion wird erst nach der Fabrikation festgelegt. Die Taktrate ist je nach Gate-Array-Typ wesentlich niedriger als bei den ASICs, kann aber bei leistungsf¨ ahigen Xilinx-FPGAs (siehe Abschnitt 2.3.2) nahe an die Taktraten von g¨ angigen Vielzweckprozessoren gleicher Technologie kommen. Die Entwicklungszeit f¨ ur

¨ 2.3 Ubersicht u ur Eingebettete Systeme ¨ber Technologien f¨

15

ein Produkt, dessen Zieltechnologie ein FPGA ist, ist relativ gering und die Produktion des ersten Prototyps ohne Risiko, da das FPGA mit der entwickelten Schaltung programmiert bzw. konfiguriert“ wird. Bei einem Fehler in der Schaltung kann nach ” der Korrektur des Fehlers der Baustein relativ einfach neu konfiguriert werden. Damit eignen sich FPGAs sehr gut f¨ ur Prototypen oder f¨ ur erste Produktionsserien mit sehr geringen St¨ uckzahlen.

Anzahl Transistoren Chip-Fl¨ ache Taktrate Entwicklungszeit Produktionszeit PrototypenKosten St¨ uckkosten bei sehr hoher St¨ uckzahl (> 106 )

Vollkundenspezifisches ASIC sehr hoch bis 109 sehr klein (1) sehr hoch (10) sehr lang (10) sehr lang (10) sehr hoch (10) sehr niedrig (1)

MakroZellen

StandardZellen

GateArray

sehr hoch bis 109 klein (3)

hoch bis 107 mittel (5)

hoch bis 107 mittel (5)

sehr hoch (9) lang (8)

hoch (8)

hoch (8)

FPGA reprogrammierbar sehr hoch 107 –109 sehr groß (10) mittel (5–9)

mittel (5)

mittel (5)

kurz (1)

lang (8)

lang (8)

sehr hoch (9)

hoch (8)

niedrig (2–3) mittel (6)

sofort verf¨ ugbar (1) sehr niedrig (1)

sehr niedrig (2)

niedrig (3)

mittel (5)

sehr hoch(10)

Tabelle 2.2: Vergleich der Technologien f¨ ur Eingebettete Systeme. Die Bewertungsziffern sind sehr grob und reichen von (1): sehr klein bis (10): sehr groß.

2.3.2

Feldprogrammierbare Bausteine (FPGAs)

Der Markt der feldprogrammierebaren Bausteine ¨andert sich st¨andig. Was heute noch aktuell ist, kann morgen bereits vom Markt verschwunden sein. Dasselbe gilt f¨ ur die Hersteller und die Bausteinbezeichnungen. Daher kann die folgende Abhandlung nur ¨ einen kleinen Uberblick u ¨ber die derzeitige Marktsituation geben. Die klassischen programmierbaren Logik-Bausteine sind die einmalprogrammierbaren PLDs (Programmable Logic Device) genannt, die etwa seit dem Jahre 1976 auf dem Markt verf¨ ugbar sind. Unter dem Oberbegriff PLD und SPLD (Simple PLD) existieren verschiedene Arten von Bausteinen, mit leider nicht immer eindeutigen Bezeichnungen. Sie sind inzwischen auch teilweise wiederprogrammierbar erh¨altlich z. B. • PAL (Programmable Array Logic) • PLA (Programmable Logic Array)

16

2 Bauformen und Implementierungsarten • EPLD (Electrically Programmable Logic Device) • CPLD (Complex Programmable Logic Device)

a b

b c

abcd

x x

x x

a

c11

t

c d

x x

b

FUSE-Schalter

c12

y c21

c22



Beispiel: y = ab + bc + cd

Konfigurierungsschema mit „Fuses“ Vereinfachte Struktur eines PLD

Abbildung 2.4: Links: Vereinfachte Struktur eines PLD (PAL-Struktur). Rechts: Konfigurierungsschema mit Fuses“ (nach [RechPom02]). ”

Das Schema eines PAL zeigt Abbildung 2.4, linke Seite. Die zu implementierende Logik muss in der konjunktiven Normalform bzw. als Sum of Products“, beispielsweise ” in der Form y = ab + bc + cd vorliegen, wobei der Produktterm ab das logische UND und a + b das logische ODER bedeutet. Dies ist realisierbar durch eine Reihe von UND-Gattern, deren Ausg¨ ange in einem ODER-Gatter zusammengefasst werden. Die Eingangsvariablen, im Beispiel: a, b, c, d, meist auch die invertierten Variablen a, b, c, d, werden als Reihe paralleler Leitungen senkrecht zu den Eing¨angen der UND-Gatter, durch eine Isolierschicht davon getrennt, gef¨ uhrt. Soll eine bestimmte Verbindung einer Eingangsvariablen, (z. B. im Bild: a) mit einem Eingang hergestellt werden, so wird dies durch das Anti-Fuse-Verfahren erreicht. Bei diesem Verfahren werden zwei Leitungen durch einen Stromstoß verschmolzen. Beim Fuse-Verfahren (Fuse bedeutet Schmelzsicherung) sind zun¨ achst alle Verbindungen in der Eingangs-Matrix fest vorhanden. Die nicht erw¨ unschten Verbindungen werden durch einen Stromstoß aufgeschmolzen und dadurch getrennt. Sowohl das Fuse- als auch das Anti-Fuse-Verfahren erzeugen sogenannte strahlungsharte“ (Radiation Hard) Verbindungen, im Gegensatz zu Verbindungen auf ” CMOS-Transistor-Basis. Die strahlungsharten Bausteine werden in strahlungsbelasteter Umgebung, z. B. in der Raumfahrt verwendet. Beim PLA sind im Gegensatz zum PAL mehrere programmierbare ODER-Gatter am Ausgang verf¨ ugbar. Neuere PLDs enthalten auch programmierbare Speicherelemente,

¨ 2.3 Ubersicht u ur Eingebettete Systeme ¨ber Technologien f¨

17

zum Beispiel D-FFs und Tri-State-Ausg¨ ange (siehe Abschnitt 4.2.2), sodass nicht nur Grundschaltungen mit kombinatorischer Logik, sondern auch Schaltwerke einfach konfiguriert werden k¨ onnen. Bei den CPLDs werden mehrere PLA-Bl¨ocke u ¨ber ein Kop” pelfeld“ miteinander verbunden. PLDs werden z. B. als Glue Logic“, d. h. als Verbindungslogik zwischen Modulen f¨ ur ” Board-Systeme in kleineren St¨ uckzahlen eingesetzt. Die Bedeutung der wiederprogrammierbaren (auch rekonfigurierbaren) Gate-Arrays und PLDs, allgemein FPGAs genannt, hat in den letzten Jahren sehr stark zugenommen. Auch hier gibt es eine Vielzahl von Bausteinbezeichnungen, neben den oben genannten PALs, PLAs, CPLDs und GALs (Generic Array Logic) noch eine Menge weitere. GAL-Bausteine wurden etwa Mitte der 80er Jahre von der Firma Lattice in der elekt” risch-l¨ oschbaren“ (Electrical Eraseable) EECMOS-Technik entwickelt. Die Bezeichnung GAL wurde von Lattice gesch¨ utzt. Der Vorteil gegen¨ uber den ersten PAL-Bausteinen war die Rekonfigurierbarkeit, die niedrige Verlustleistung, die f¨ ur die damaligen Verh¨altnisse relativ hohe Taktfrequenz (bis zu ca. 50 MHZ) sowie der sehr g¨ unstige Preis. Außer kombinatorischer Logik (UND-ODER-Gatter), enthalten die GAL-Bausteine zum Beispiel Speicherelemente (D-FF), Inverter und konfigurierbare Tri-State-Ausg¨ange, sodass eine Vielzahl von digitalen Grund- und Rechenschaltungen sehr einfach programmierbar sind. GALs werden f¨ ur kleinere Schaltungen zum Beispiel in Versuchs- und Testlabors eingesetzt. FPGAs werden auch als programmierbare bzw. rekonfigurierbare Hardware bezeichnet. FPGAs, anfangs auch LCAs (Logic Cell Arrays) genannt, wurden 1984 von der Firma Xilinx eingef¨ uhrt. Xilinx ist bis heute Marktf¨ uhrer bei FPGAs geblieben. Anwendungen f¨ ur FPGAs sind: • Prototypen, d. h. f¨ ur die Emulation beliebiger Hardware. ¨ • F¨ ur Eingebettete Systeme, bei denen Flexibilit¨at gefordert ist und Anderungen im Betrieb m¨ oglich sind. • F¨ ur Rechenbeschleuniger (siehe Abschnitt 1.3). • F¨ ur kleine St¨ uckzahlen, ein vollkundenspezifisches ASIC lohnt sich nicht. Dasselbe FPGA kann innerhalb einer Anwendung mehrfach verwendet werden. Daf¨ ur ahrend der Laufzeit dynamisch rekonfiguriert werden, d. h. die Konfiguramuss es w¨ tion muss bei Bedarf neu in das FPGA geladen werden. Dies kann, je nach Ausf¨ uhrung des FPGA, zwischen Sekunden und Bruchteilen von Millisekunden geschehen. Obwohl die Taktfrequenzen in der Regel kleiner sind als bei vollkundenspezifischen ASICs, werden FPGAs oft als Hardware-Beschleuniger eingesetzt, da hier die Parallelit¨at der Ausf¨ uhrung, – eine wesentliche Grundeigenschaft der Hardware – die geringere Taktfrequenz ausgleichen kann. Der Unterschied der Taktfrequenzen zwischen ASICs und FPGAs schrumpft allerdings im Laufe der Zeit. Vor einem Jahrzehnt betrug dieser Unterschied etwa den Faktor zehn, d. h. die Taktfrequenz bei den meisten FPGAs waren

18

2 Bauformen und Implementierungsarten

etwa zehn mal niedriger als bei ASICs. Heute besteht kaum ein Unterschied zwischen den Taktfrequenzen der Hochleistungs-FPGAs der Firma Xilinx (siehe unten) und Prozessoren die im gleichen Jahr gefertigt werden, da Xilinx bereits ¨ahnliche Strukturbreiten verwendet, wie sie bei modernen Prozessoren zu finden sind.

c11

a

c12

I/O-Block

Logik-Block

b CMOS-Schalter

c21 c22



Konfigurierungsschema eines wiederprogrammierbaren PLDs

Struktur rekonfigurierbarer FPGAs

Abbildung 2.5: Links: Konfigurierung wiederprogrammierbarer PLDs. Die VerbindungsElemente sind CMOS-Schalter. Rechts: Struktur rekonfigurierbarer FPGAs (nach [RechPom02]).

Abbildung 2.5 links zeigt das Konfigurierungsschema wiederprogrammierbarer PLDs. An den Kreuzungspunkten der Eingangsleitungen mit den Variablen-Leitungen (a und b) liegen CMOS-Schalter, die u usse c11 bis c22 akti¨ber die Konfigurierungs-Anschl¨ viert werden k¨ onnen. Die Konfigurierung kann bei einigen FPGAs u ¨ber die JTAG” Schnittstelle“ (siehe Abschnitt 5.11.4) durchgef¨ uhrt werden. Die Struktur eines FPGAs zeigt Abbildung 2.5, rechts. Sie ist ein Feld aus Logik-Bl¨ocken (auch Logik-Zellen genannt), zwischen denen Verbindungsleitungen liegen. An der Peripherie des Bausteins liegen die Eingabe/Ausgabe- (I/O) Bl¨ocke. Ein wichtiger Begriff ist die Granularit¨ at“ der Logik-Bl¨ ocke. Sie kann folgende Blockgr¨oßen annehmen: ” • Gatter. • Tabellen und Speicher (LUTs und FlipFlops). • Funktionsbl¨ ocke (ALUs, Arithmetische Komponenten, Kommunikationseinheiten). W¨ ahrend Gatter f¨ ur ein FPGA eine geringe Granularit¨at darstellen, sind Tabellen, sogenannte Look up Tables“ (LUTs) und Funktionsbl¨ocke grob-granular“. Funktions” ” bl¨ ocke werden bei der Firma Xilinx konfigurierbare Logik-Bl¨ocke“ (CLBs) bzw. Slices“ ” ”

¨ 2.3 Ubersicht u ¨ber Technologien fu ¨r Eingebettete Systeme

19

genannt. Die etwas ¨ alteren CLBs bestehen aus Look-Up-Tables LUTs mit jeweils vier bis sechs Eing¨ angen und Speicherbausteinen (Flipflops), die durch konfigurierbare Selektoren (Multiplexer) miteinander verbunden sind. Slice ist die neuere Bezeichnung der Funktionsbl¨ ocke. Ein Slice ist kleiner als ein CLBs. Die Look-Up-Tables sind im Wesentlichen Wahrheitstabellen, die je nach Konfigurierung verschiedene logische Funktionen in der disjunktiven Normalform (DNF) oder der konjunktiven Normalform (KNF) realisieren k¨ onnen. Leistungsf¨ ahige FPGAs werden z. B. f¨ ur die Emulation von großen, komplexen Schaltungen und Digitalen Signalprozessoren (DSP) eingesetzt. Die Firma Xilinx fertigt eine große Vielzahl von programmierbaren FPGAs und CPLDs. Dazu sind Entwicklungs-Werkzeuge wie zum Beispiel FPGA-Boards, Werkzeuge f¨ ur die Konfigurierung usw. verf¨ ugbar. Xilinx bietet haupts¨achlich zwei FPGA-Produktfamilien an: Die Spartan- und die Virtex-Familie mit vielen verschiedenen Typen. Diese Typenvielfalt ist wichtig, damit der Entwickler f¨ ur sein System das FPGA in passender Gr¨ oße und mit passenden Eigenschaften ausw¨ahlen kann. Die Spartan-Linie als die Niedrigpreis-Familie“ mit relativ niedrigem Energieverbrauch ist gedacht f¨ ur den Mas” senmarkt, zum Beispiel f¨ ur die Anwendung im Automobilbau, f¨ ur drahtlose Kommunikations-Ger¨ ate (Mobiltelefone), f¨ ur Flachbildschirme usw. Die Virtex-Linie ist die Hochleistungs-Familie f¨ ur hohe Anforderungen an Performanz und Daten¨ ubertragungsgeschwindigkeit. Die Virtex-7-Linie ist noch in zwei Unterfamilien aufgeteilt, die Kintex und die Artix-Familien. Sie finden Anwendungen beispielsweise in Eingebetteten Systemen der Raumfahrt, der Industrie, der Medizin und der Wissenschaft (IMS) sowie in milit¨ arischen Ger¨ aten. Die Xilinx-FPGAs beinhalten unter anderem FIFOs, DSP (Digitale Signal Prozessoren)Bl¨ ocke, Steuereinheiten f¨ ur den PCI-Express, Takt-Steuereinheiten (Clock Mangaement), Speicher-Steuereinheiten (Memory Controller Blocks) und HochgeschwindikeitsTransceiver. Der PCI-Express (Peripheral Component Interconnect) ist ein serieller Bus (siehe Kapitel 4), um Peripherieger¨ ate mit einem Prozessor zu verbinden. Transceiver dienen der Daten¨ ubertragung (Transmit) und dem Datenempfang (Receive). Die DSPBl¨ ocke der Xilinx-FPGAs enthalten jeweils einen Multiplizierer, einen Addierer und einen Akkumulator, das heißt einen Speicherbaustein mit einem oder mehreren Registern. Tabelle 2.3 zeigt einige handels¨ ubliche Xilinx-FPGAs und deren Eigenschaften. Die Zahlen in der Tabelle geben jeweils die Charakteristika des Typs mit den H¨ochstwerten der genannten Familie wieder. Die Logik-Zellen, Logik-Bl¨ocke bzw. CLBs sind die kleinsten Einheiten der FPGA-Module, die durch die Konfigurierung ihre spezifische Funktion erhalten und miteinander verbunden werden. Jede Logik-Zelle enth¨alt einige Tausend Transistoren. Dadurch wird eine massive Parallelverarbeitung m¨oglich. Jedes Spartan-6 Slice (siehe Tabelle) enth¨ alt 4 LUTs und 8 FlipFlops. Die LUTs der Slices k¨onnen als verteilter Speicher“ (Distributed RAM) konfiguriert werden. Der Typ Virtex-5QV ist ” so ausgelegt, dass auch in strahlungsbelasteter Umgebung, zum Beispiel in der Raumfahrt, eine einwandfreie Funktion gew¨ ahrleistet ist. Die Virtex-7-Familie eignet sich unter anderem f¨ ur die Modellierung von Digitalen Signalprozessoren (DSP), die Datenstr¨ ome mit sehr schneller Eingabe-Ausgabe (E/A) verarbeiten k¨ onnen. Die gesamte Daten¨ ubertragungsrate betr¨agt maximal 2,8 TeraBit/s.

20

2 Bauformen und Implementierungsarten

Daf¨ ur stehen 1200 E/A-Anschl¨ usse zur Verf¨ ugung. Die Slices der Virtex-7-Familie enthalten 6 LUTs am Eingang, die ebenfalls als verteilter Speicher konfigurierbar sind. Logik-Zellen (CLBs) DSP-Slices Block-RAM Prozessoren Anzahl Transceiver Technologie Eingabe/AusgabePins

Spartan-6 150 000 180 4,8 MB 1 MicroBlaze 8 St¨ uck

Virtex-5 332 000 192 10,3 MB 2 Power PC 440 24

Virtex-6 760 000 2128 38 MB – 72

Virtex-7 1,9 Millionen 3 600 68 MB – 96

45 nm 576

65 nm 1200

40 nm 1200

28 nm 1200

Tabelle 2.3: Vergleich einiger handels¨ ublicher Xilinx-FPGAs aus der Spartan- und der VirtexSerie. Die Zahlen geben jeweils die Eigenschaften des Typs mit den H¨ ochstwerten der genannten Familie wieder (aus Xilinx-Datenbl¨ attern, Stand 2012).

Im Folgenden werden einige weitere bekannte Firmen aufgef¨ uhrt, die FPGAs produzieren, sowie deren Technologie und Struktur-Eigenschaften. • Die Firma ALTERA fertigt CPLDs und andere FPGA-Bausteine in SRAM-Technologie. Die Struktur ist feink¨ ornig. Die FPGAs enthalten eine hohe Anzahl von Registern. Die Verz¨ ogerungszeiten sind relativ gering und die Ausf¨ uhrungsgeschwindigkeiten sind vorhersagbar. • Die Firma LATTICE liefert eine weite Palette von GALs, FPGAs und CPLDs, letztere werden Crossover PLDs“ genannt. ” • Die Firma ACTEL liefert FPGAs mit feink¨orniger Struktur.

2.4

Evolution der Siliziumtechnologie

Tabelle 2.4 zeigt die Evolution der Silizium-Prozess-Technologie“ f¨ ur Ein-Chip-Systeme ” ab 1997 (erweitert aus [Chang99]). Die Strukturbreite, das heißt die kleinste Distanz zum Beispiel zwischen Leiterbahnen auf den Chips, ist in den Jahren von 1997 bis 2011 von 350 nm (10−9 m) auf 22 nm geschrumpft. Die Strukturbreite 11 nm ist im Jahr 2012 in Bearbeitung. Als Strukturbreite ist hier der aktuelle Wert des entsprechenden Jahres aufgef¨ uhrt, der in der Regel nur f¨ ur Vielzweck-Prozessoren neuester Bauart eingesetzt wird. Die Kosten einer Chip-Fabrik sind im gleichen Zeitraum von ca. 1,5 Mrd. (1,5 ∗ 109 ) Euro auf u ¨ber 6 Mrd. Euro angestiegen (gesch¨atzt). Das entspricht in etwa dem Wert von 6000 Einfamilienh¨ ausern einschließlich Grundst¨ uck mit einem durchschnittlichen Preis von je einer Million Euro (2012). Die Komplexit¨ at der Chips ist von etwa 200 000 (1997) bis ca. 800 Millionen Gatter (2012) pro Chip gestiegen. Rechnet man mit bis zu sechs Transistoren pro Gatter, so sind

2.5 Zusammenfassung

Strukturbreite Kosten der ChipFabrik (ca. Euro) Entwurfs-Zyklus (Monate) Entwurfs-Zyklus f¨ ur Folge-Version Anzahl der log. Gatter Anwendungen

21 1997 350 nm 1,5–2 Mrd 18–12

2002 130 nm > 4 Mrd

2005 90 nm > 5 Mrd

2007 65 nm > 5 Mrd

2012 22 nm > 6 Mrd

10–8

ca. 7–8

ca. 6–7

ca. 5–6

8–6 Monate 200–500 k

4–3

ca. 2

ca. 2

ca. 2

10–25 M

> 200 M

> 400 M

> 800 M

Handy PDA

MP3 Plyr. PDA

Foto-Hdy. DVD-Plyr.

UMTSFoto-Hdy.

I-Core i7 Ivy Bridge

Tabelle 2.4: Evolution der Silizium-Prozess-Technologie. Abgesehen von der Strukturbreite [ITRS] sind die Werte der letzten drei Spalten von den Autoren gesch¨ atzt (erste und zweite Spalte nach [Chang99]).

das einige Milliarden Transistoren. Zum Beispiel hat der Intel Ivy Bridge Quad-CoreProzessor (im Jahre 2012) ca. 1,4 Milliarden Transistoren (www.intel.com). Dagegen ist der Entwurfszyklus f¨ ur einen vergleichbaren Entwurf von 18 Monaten auf gesch¨atzte 5-6 Monate gesunken. Der Entwurfszyklus h¨ angt allerdings stark von der Art und der Komplexit¨ at des Eingebetteten Systems ab. Die Reduzierung des Entwurfszyklus wird erreicht durch moderne, hocheffiziente Entwurfs- und Testmethoden z. B. durch den Plattfom-basierten Entwurf (siehe Kapitel 5). Die in der letzten Zeile von Tabelle 2.4 aufgef¨ uhrten Anwendungen in Eingebetteten Systemen beinhalten aus Kostengr¨ unden in der Regel nicht Chips mit der aktuellen Strukturbreite, sondern meist Chips mit der Strukturbreite der vorhergehenden Generation(en). So werden beispielsweise Chips eines im Jahre 2007 produzierten Handy meist Strukturbreiten von 90 nm oder gar 130 nm aufweisen. Die neueste Chip-Technologie wird in der Regel f¨ ur die neuesten VielzweckProzessoren eingesetzt. Die in der letzten Spalte aufgef¨ uhrte 22 nm-Technologie wird, wie bereits erw¨ ahnt, im Jahre 2012 noch nicht in Eingebetteten Systemen verwendet, sondern kommt in Intel-Prozessoren zur Anwendung, wie zum Beispiel im Intel Core i7 bzw. in den Prozessorkernen der Intel- Ivy Bridge“-Familie. ”

2.5

Zusammenfassung

Die Bauformen von Eingebetteten Systemen sind Ein-Chip-Systeme, (System-on-aChip, SoC), Multi-Chip-Module und Board-Systeme. Die Wahl der Bauform h¨angt stark von der St¨ uckzahl der zu fertigenden Systeme ab. Die Wahl der Implementierungsart, d. h. der Bauform eines Eingebetteten Systems, ist eine wichtige Entscheidung des Entwicklers zusammen mit der Markt- bzw. PlanungsAbteilung. Sie h¨ angt von vielen Faktoren ab, z. B. von den Anforderungen, der erwarteten St¨ uckzahl, des geforderten Termins der Markteinf¨ uhrung, von den Funktionen usw. Die Implementierung kann demnach mit Hilfe von Vielzweck-Prozessoren,

22

2 Bauformen und Implementierungsarten

Spezial-Prozessoren, FPGAs, voll kundenspezifischen (ASICs), teilweise kundenspezifischen Schaltkreisen oder Ein-Chip-Systemen erfolgen. Der Trend der Technologieentwicklung von Eingebetteten Systemen geht bei großen St¨ uckzahlen in Richtung voll kundenspezifischer Integrierter Schaltkreise bzw. EinChip-Systeme mit mehreren Prozessoren und geringem Energieverbrauch. Bei kleineren St¨ uckzahlen werden h¨ aufig rekonfigurierbare FPGAs eingesetzt. Zudem werden h¨aufiger programmierbare Mikroprozessoren verwendet. Damit steigt der Bedarf an Software.

3

Mikroprozessor-Grundlagen

Ein Mikroprozessor (MP) ist per Definition eine zentrale Recheneinheit (CPU) auf ” einem Chip“. Als der Begriff Mikroprozessor“ gepr¨agt wurde, war das noch etwas ” Besonderes, heute ist es die Regel. Eingebettete Systeme haben heute meist mehrere Mikroprozessoren, oft sind es verschiedene Typen, RISC-Prozessoren, DSPs, VLIWProzessoren usw. Aus Hardware-Sicht betrachtet, ist die Entwicklung eines Eingebetteten Systems auf Mikroprozessor-Basis eine Bottom-up-Methode (siehe unten); denn man geht von einer vorhandenen Hardware aus, auf der der Entwurf aufgebaut wird. Jedoch kommt in unserem Fall die Software als wesentlicher Teil der Systementwicklung hinzu und die wird top-down entwickelt oder sogar automatisch generiert. Der Schwerpunkt der Entwicklung verschiebt sich somit auf die SW-Ebene. Wesentlich zum Gelingen des Entwurfs tr¨ agt die Wahl der Prozessoren bei. Aus der großen Vielzahl der Mikroprozessoren, die es heute auf dem Markt gibt, gilt es an Hand der gestellten Aufgabe, die geeignetsten Mikroprozessoren in Bezug auf Performanz, Energieverbrauch, Preis, Schnittstellen, SW-Entwicklungsplattformen, Testm¨oglichkeiten usw. herauszufinden. Das Ziel dieses Kapitels ist es, Hilfestellung f¨ ur das Aussuchen des passenden Prozessors f¨ ur die Entwicklungsaufgabe zu geben. Es kann hier wieder ¨ nur eine Ubersicht u ¨ber die einzelnen Themengebiete wie Mikroprozessor-Architekturen, Eingabe/Ausgabe, Speicher und Speicherverwaltung, Energieverbrauch, ein kurzer Blick auf Programmentwicklung und Betriebssysteme gegeben werden. Wer weiter in die Tiefe gehen m¨ ochte, der sei auf die B¨ ucher von Hennessy & Patterson [HenPat07], Brinkschulte & Ungerer [BriUng10], Wayne Wolf [Wolf02] usw. verwiesen, die hier haupts¨achlich als Vorlage verwendet werden. Hennesey & Patterson ist das Standardwerk f¨ ur das Gebiet Rechnerarchitektur, Wayne Wolf in seinem etwas ¨alteren Buch hat dieses Thema aus Sicht der Eingebetteten Systeme behandelt.

3.1

Evolution der Mikroprozessoren

Mikroprozessoren und Mikrokontroller haben in den letzten vier Jahrzehnten eine enorme Entwicklung durchgemacht. Angefangen mit dem ersten Intel 4004-Prozessor im Jahr 1971 mit einer Strukturbreite von 10 μm bis zum Intel Core i7 (siehe 2.4) mit einer Strukturbreite von 22 nm im Jahr 2012, hat die Prozessorentwicklung zwei grundlegende Hindernisse zu u ¨berwinden: Das erste Hindernis wird das Speicher-Hindernis Memory Wall“ und das zweite Hindernis wird die Leistungsgrenze Power Wall“ ge” ” nannt [BriUng10]. Die Memory Wall entstand durch die unterschiedlichen Taktraten von Speicher und Prozessor. Die Befehls-Ausf¨ uhrungszeiten des Prozessors verringerten sich st¨ andig durch die steigenden Taktraten, zudem gelang es, durch ausgekl¨ ugelte

24

3 Mikroprozessor-Grundlagen

Pipeline-Techniken (siehe Abschnitt3.3.6) die Anzahl der Taktzyklen pro Befehlsverarbeitung nahezu bis auf einen Zyklus zu verringern, bei superskalarer Technik (siehe Abschnitt3.3.6) sogar noch darunter. Die Versorgung des Prozessors mit gen¨ ugend Befehlen, das heißt die Geschwindigkeit des Speicherzugriffs stieß jedoch fr¨ uh an Grenzen. Der Ausweg aus diesem Dilemma war der Einsatz von Caches und die Entwicklung von Speicherhierarchien (siehe Abschnitt 3.3.3), die den Zugriff auf Programmspeicher und Daten wesentlich beschleunigten. Das zweite Hindernis, die Power Wall“, entstand durch die kontinuierliche Erh¨ohung ” der Taktraten, die in gleichem Maße eine Erh¨ohung der Prozessor-Temperatur bedeutete. Die K¨ uhlung der Prozessoren wurde immer aufw¨andiger und kam an technische und wirtschaftliche Grenzen. Eine Prognose der Semiconductor Industry Association (SIA) aus dem Jahre 1998 sagte f¨ ur die Jahre 2008 und 2010 Taktraten von 6 und 10 GHz voraus (zitiert in [BriUng10]). Beide Prognosen waren falsch, die Power Wall stand im ¨ Weg. Eine Uberwindung der Power Wall ist durch den Einsatz von Mehrkernprozessoren m¨ oglich geworden. Mehrkernprozessoren haben mehrere Prozessorkerne auf dem gleichen Chip, die unabh¨ angig voneinander Programme ausf¨ uhren k¨onnen. Sie weisen ein besseres Verh¨ altnis der Performanz zur Leistungsaufnahme auf (Performance/Watt Ratio) [BriUng10], das heißt die Leistungsaufnahme steigt lediglich linear mit der Performanz und die Temperaturverteilung auf dem Chip l¨asst sich beherrschen und bleibt in Grenzen. Einerseits stagnieren die Taktfrequenzen f¨ ur Mikroprozessoren bei etwa 5 MHz (2012), andererseits erlauben die Mehrkernprozessoren durch Parallelverarbeitung weiterhin Performanzsteigerungen. Die Anzahl der Prozessorkerne w¨ achst st¨ andig an und f¨ uhrte zur Erweiterung“ bzw. ” zur Fortsetzung des Mooreschen Gesetzes (siehe Abschnitt 5.1), das besagt, dass sich die Anzahl der Prozessoren pro Chip in jeweils 18 bis 24 Monaten verdoppeln wird. Gordon Moore hat sein Gesetz“ in Bezug auf die Anzahl der Transistoren pro Chip formuliert ” und diese steigt tats¨ achlich weiterhin im vorhergesagten Maße an. Zum Beispiel besitzt der Fermi-Grafikprozessor der Firma NVIDIA (www.nvidia.com) im Jahre 2010 bereits 512 Kerne (zitiert in [BriUng10]). Um die steigende Prozessorzahl pro Chip tats¨achlich zu nutzen, sind nicht nur parallelisierende Compiler gefragt, sondern auch Anwenderprogramme, die entsprechend parallelisiert werden k¨ onnen. Das heißt, damit alle Prozessorkerne auf dem Chip ausgelastet sind, m¨ ussen gen¨ ugend Threads zur Verf¨ ugung stehen. Hier st¨oßt allerdings die Compiler- und SW-Entwicklung an ihre Grenzen, die als Parallelit¨ats-Mauer bzw. die Parallelism Wall“ bezeichnet wird [BriUng10]. ”

3.2

Mikroprozessoren in Eingebetteten Systemen

Es gibt viele M¨ oglichkeiten, Eingebettete Systeme in verschiedenen Technologien zu entwickeln. Einige davon wurden im Kapitel 2 Bauformen und Implementierungsarten erw¨ ahnt. Wir betrachten die M¨ oglichkeit, einen oder mehrere Mikroprozessoren f¨ ur die Entwicklung eines Eingebetteten Systems zu verwenden, im Gegensatz zu anwendungsspezifischen integrierten Schaltkreisen (ASICs) oder feldprogrammierbaren Schalkreisen (FPGAs).

3.2 Mikroprozessoren in Eingebetteten Systemen

25

Welche Vor- und Nachteile bieten (programmierbare) Mikroprozessoren? Zun¨achst seien einige Vorteile von Mikroprozessoren genannt: • Mikroprozessoren sind kosteng¨ unstig und in vielen verschiedenen Bauweisen verf¨ ugbar. Einfache“ Mikroprozessoren, zum Beispiel Intels 8051-Derivate (siehe ” uck) sehr Abschnitt 3.4.1) sind bei hohen St¨ uckzahlen (ab etwa 104 bis 105 St¨ preisg¨ unstig. Es gibt eine Vielzahl von Bauweisen des Intel 8051 und die Kunst ist es, hier das Richtige auszusuchen. • Mikroprozessoren sind sehr vielseitig und flexibel, sie sind erweiterungsf¨ahig (Upgradeability, Scaleability). • Mit Mikroprozessoren ist es einfacher, Produktfamilien zu entwickeln. Ist in einem Eingebetteten System ein Mikroprozessor eingebaut, so bedarf es oft nur einer Programm¨ anderung, um Zusatzfunktionen herauszubringen. Damit kann schnell auf neue M¨ arkte oder auf Konkurrenzprodukte reagiert werden. • Mikroprozessoren sind stark optimiert auf Geschwindigkeit. Die neueste Technologie wird in der Produktion verwendet. Mikroprozessoren verarbeiten Programme sehr effizient. Zum Beispiel kann ein RISC-Prozessor etwa einen Befehl pro Taktzyklus verarbeiten, ein superskalarer Prozessor sogar mehrere Befehle pro Taktzyklus (siehe Abschnitt 3.3.6). Damit kann man in manchen F¨allen Ausf¨ uhrungszeiten erreichen, die vergleichbar sind mit der Ausf¨ uhrungszeit eines ASIC der gleichen Funktionalit¨ at. • Hardware und Software k¨ onnen nebenl¨ aufig entwickelt werden. Besser ist allerdings die modellbasierte Entwicklungsmethode“ von Gajski et al. [Ga09] (siehe ” Kapitel 5), bei der zu Beginn einer Entwicklung zwischen Hardware und Software nicht unterschieden wird. Es gibt allerdings auch Nachteile bei der Verwendung von Mikroprozessoren: • Ein non-volatile (nicht fl¨ uchtiger) Programmspeicher und ein Arbeitsspeicher wird ben¨ otigt. • Das Testen und Debuggen mit Mikroprozessoren ist komplex, da die Beobachtbarkeit und Pr¨ ufbarkeit von Funktionen des Eingebetteten Systems mit Mikroprozessoren eingeschr¨ ankt sind. Computergest¨ utzte Entwicklungsumgebungen f¨ ur Eingebettete Systeme mit Mikroprozessoren sind oft nicht vorhanden und m¨ ussen erst erstellt werden. Es gibt bei der Auswahl von Mikroprozessoren f¨ ur Eingebettete Systeme unter Einbeziehung von Produktionskosten und Performanz folgende Punkte zu beachten: • Welcher Mikroprozessoren-Typ kommt in Frage? • Welche Speichergr¨ oße wird ben¨ otigt?

26

3 Mikroprozessor-Grundlagen • Welche Peripherie? • Gibt es f¨ ur den gew¨ ahlten Mikroprozessoren-Typ Entwicklungsumgebungen und -Werkzeuge auf dem Markt?

3.3

Mikroprozessor-Grundlagen

Dieser Abschnitt ist gedacht f¨ ur Leser, die wenig oder keine Kenntnisse auf den Gebieten Rechnerachitektur, Ein/Ausgabe-Verwaltung, Speicherverwaltung, Energieverbrauch usw. von Mikroprozessoren haben.

3.3.1

Mikroprozessor-Architekturen

Zur Architektur eines Prozessors z¨ ahlt beispielsweise der Befehlssatz (RISC oder CISC), der Aufbau und der Zugriff zum Speichersystem, die Unterteilung nach Anzahl der Prozessorkerne, Pipelining-Eigenschaften usw. (siehe auch Abschnitt 5.3.1 Seite 124).

Speicher

Programm und Daten

Adresse

Daten

CPU

DatenSpeicher

Adresse Daten

Register r0 r1 rx

v. Neumann-Architektur

CPU

Register

ProgrammSpeicher

Adresse Befehle

r0 r1 rx

Harvard-Architektur

Abbildung 3.1: Schematische Darstellung der Von-Neumann- und der Harvard-Architektur von Mikroprozessoren.

Abbildung 3.1 zeigt schematisch zwei grundlegende Mikroprozessor-Architekturen, die nach der Speicherverwaltung unterschieden werden: die Von-Neumann- und die HarvardArchitektur. John von Neumann (1903-1957) war ein ¨osterreich-ungarischer Mathematiker, der sp¨ ater in den USA t¨ atig war. Die nach ihm benannte Architektur bildet die Grundlage f¨ ur die Arbeitsweise eines Großteils der heutigen Computer, wonach ein gemeinsamer Speicher sowohl Computerprogrammbefehle als auch Daten h¨alt. ¨ Demnach wird ein gemeinsamer Bus f¨ ur die Ubertragung von Programmbefehlen und Daten zwischen Speicher und Verarbeitungseinheit verwendet. Dies kann zum Engpass werden und beeintr¨ achtigt die Verarbeitungsgeschwindigkeit. Die Harvard-Architektur, benannt nach der US-amerikanischen Harvard-Universit¨at in Cambridge (Massachusetts), umgeht diesen Engpass dadurch, dass der Speicher in

3.3 Mikroprozessor-Grundlagen ADD r3,r0,r1 ADD r0,r1,#2 SUB r3,r0,r1 MUL r4,r4,r6 LDR ro,[r1] STR r3,[r4] ADR r1,a

; ; ; ; ; ; ; ;

27

Addiere Inhalt von (r0, r1) nach r3 Addiere Inhalt von r1 und die Zahl 2 nach r0 Subtrahiere Inhalt von (r0, r1) nach r3 Multipliziere Inhalt von r4 mit Inh. v. r1 nach r4 Laden von Speicher, Adresse steht in r1 ins Register r0 (indirekte Adressierung) Speichere Wert von r3 in den HS nach Adr. r4 Setze Adresse von Variable a in Register r1

Tabelle 3.1: Beispiel: Eine Auswahl von Assembler-Befehlen des ARM7T M -Prozessors [Wolf02].

ADR r4,a LDR r0,[r4] ADR r4,b LDR r1,[r4] ADD r3,r0,r1 ADR r4,x STR r3,[r4]

; ; ; ; ; ; ;

Setze Speicher-Adresse von a in Reg. 4 Lade Wert von a aus dem HS Setze Speicher-Adresse von b in Reg. 4 Lade Wert von b aus dem HS Addiere (a + b) nach r3 Setze HS-Adresse von x in Reg. 4 Speichere Wert von r3 in den HS nach Adr. r4

Tabelle 3.2: Beispiel der Assembler-Befehlsfolge f¨ ur eine Addition: x = a + b des ARM7. Die Variablen a und b stehen im Hauptspeicher (HS), das Ergebnis wird in den HS zur¨ uckgeschrieben [Wolf02].

Programm- und Datenspeicher aufgeteilt ist und durch zwei Busse getrennt addressierbar und auslesbar ist. Dadurch kann die Verarbeitungsgeschwindigkeit des Prozessors verglichen mit der Von-Neumann-Architektur wesentlich erh¨oht werden. Prozessoren mit Von-Neumann-Architektur sind eher geeignet f¨ ur steuerungsdominante Anwendungen (siehe Seite 176), Prozessoren mit Harvard-Architektur werden eingesetzt bei der Verarbeitung großer Datenmengen und bei Datenstr¨omen, d. h. bei datendominanten Anwendungen z. B. bei Digitalen Signalprozessoren (DSP). Wird die Prozessor-Architektur nach dem Befehlssatz eingeteilt, so kann zwischen RISCund CISC-Prozessoren unterschieden werden. Ein RISC-(Reduced Instruction Set Computer)-Prozessor verwendet k¨ urzere Befehle. Alle Befehle sind gleich lang. Dadurch ist der Decodieraufwand pro Befehl geringer, die Befehls-Ausf¨ uhrungsgeschwindigkeit kann h¨ oher sein als beim CISC-Rechner. RISC-Prozessoren eignen sich besser zur Fließbandverarbeitung (Pipelining) als CISC-Prozessoren (siehe sp¨ater). Der Befehlssatz eines CISC-(Complex Instruction Set Computer)-Prozessors zeichnet sich durch verh¨altnism¨ aßig leistungsf¨ ahige Einzelbefehle aus, die komplexe Operationen durchf¨ uhren k¨onnen. Der Vorteil ist, dass man mit insgesamt weniger Befehlen f¨ ur einen bestimmten Algorithmus auskommen kann, die Speicherbandbreite“ kann geringer sein als beim RISC” Rechner gleicher Leistung. Daher geht die Tendenz bei leistungsstarken Prozessoren heute oft wieder in Richtung CISC-Rechner. Die Load/Store-Architektur, auch als Register-Register Architektur bezeichnet, wird meist in RISC-Prozessoren angewendet. Bei dieser Architektur werden Daten-Speicher-

28

3 Mikroprozessor-Grundlagen

zugriffe ausschließlich mit speziellen Lade- (Load) und Speicher- (Store) Befehlen durchgef¨ uhrt. W¨ ahrend klassische CISC-Architekturen f¨ ur Befehle der ALU(ArithmetischeLogische Einheit) (etwa Addieren oder Multiplizieren) direkten Speicherzugriff erlauben, k¨ onnen ALU-Befehle von RISC-Prozessoren nur auf Register zugreifen. Daher ist der Registersatz bei RISC-Prozessoren u ¨blicherweise im Vergleich zu CISC-Systemen gr¨ oßer. Rn = Rx + Ry; Rn = PASS Rx; Fn = Fx + Fy; R0 = DM( a); DM( a) = R0; R0 = PM( b);

! ! ! ! ! !

Festkomma-Addition Reg-n = Reg-x + Reg-y Kopiere = Reg-x nach Reg-n Fließkomma-Addition Reg-n = Reg-x + Reg-y Lade Wert von a aus Data-Memory nach R0 Speichere R0 an den Speicherplatz von a Lade Wert von b aus Programm-Memory nach R0

Tabelle 3.3: Beispiel: Eine Auswahl von Assembler-Befehlen des SHARC-Prozessors [Wolf02].

Befehlsfolge des SHARC f¨ ur die Addition x = a + b R0 = DM( a); ! Lade Wert von a aus Data-Memory nach R0 R1 = DM( b); ! Lade Wert von b aus Data-Memory nach R1 R3 = R0 + R1 ! Addition, Wert nach R3 DM( x) = R3; ! Speichere R3 an den Speicherplatz von x Ausnutzung der Harvard-Architektur f¨ ur x = a + b R0 = DM( a); R1 = PM( b); ! Lade a aus Data-Memory nach R0 ! Lade b parallel aus Progr.-Memory nach R1 R3 = R0 + R1 ! Addition, Wert nach R3 DM( x) = R3; ! Speichere R3 an den Speicherplatz von x Tabelle 3.4: Oben: Befehlsfolge des SHARC f¨ ur eine Addition x = a + b. Unten: Befehlsfolge f¨ ur dieselbe Addition unter Ausnutzung der Harvard-Architektur [Wolf02].

Im Folgenden werden an Hand der Befehlss¨ atze zwei Prozessoren verschiedener Architekturen miteinander verglichen (aus dem Buch von Wayne Wolf [Wolf02]). Der erste Prozessor ist der ARM7T M , ein RISC-Processor mit Load-Store- und Von-NeumannArchitektur der Firma ARM. Die Firma ARM vertreibt IPs (Intellectual Property) f¨ ur ihre ARM-Familie von RISC-Prozessoren (siehe Abschnitt 3.4.3). Tabelle 3.1 zeigt eine Auswahl von Assemblerbefehlen des ARM7. R0, r1, r2 .. sind Registerbezeichnungen. Assemblerbefehle sind direkte“ Prozessorbefehle in einer sym” bolischen Sprache. Der Assembler“ u ¨bersetzt sie Eins zu Eins in Maschinenbefehle. Das ” Semikolon (;) in der Assemblerliste dient als Kommentarzeichen, danach folgt ein Kommentar bis zum Ende der Zeile. In Tabelle 3.2 ist als Beispiel die Assembler-Befehlsfolge des ARM7 f¨ ur die Addition x = a + b gezeigt. Die Variablen a und b werden zun¨achst aus dem Hauptspeicher (HS) in Register geladen, danach addiert und wieder an die Stelle x im HS zur¨ uckgeschrieben. Der ARM7 ben¨otigt daf¨ ur sieben Assemblerbefehle. Der zweite Prozessor den wir betrachten, ist der SHARCT M (Super-Harvard-Architecture) der Firma Analog Devices (AMD), ein Prozessor mit Harvard-Architektur und

3.3 Mikroprozessor-Grundlagen

29

RISC-Befehlssatz, der als Digitaler Signal-Prozessor eingesetzt wird. Er besitzt eine Festkomma- und Fließkomma-Einheit. Tabelle 3.3 zeigt oben eine Auswahl von Assemblerbefehlen des SHARC. Das Ausrufezeichen (!) dient als Kommentarzeichen, danach folgt ein Kommentar bis zum Ende der Zeile. In Tabelle 3.4 oben ist als Beispiel die Assembler-Befehlsfolge des SHARC f¨ ur die Addition x = a + b gezeigt. Die Variablen a und b werden zun¨achst aus dem Daten-Speicher (HS) in Register geladen, dies geschieht beim SHARC jeweils mit Hilfe eines Befehls. In Tabelle 3.4 unten ist die Assembler-Befehlsfolge des SHARC f¨ ur dieselbe Addition unter Ausnutzung der Harvard-Architektur gezeigt. Es ist m¨oglich, auch im Programmspeicher Daten unterzubringen. So liegt die Variable a im Daten-Speicher, die Variable b im Programm-Speicher. Da der Zugriff zum Daten- und zum Programm-Speicher parallel erfolgen kann, wird dies in der Programmierung ausgenutzt. Der SHARC ist so in der Lage, eine komplette Addition mit Operanden-Laden und -R¨ uckschreiben des Ergebnisses in drei Assemblerbefehlen auszuf¨ uhren. Setzt man die gleiche Taktfrequenz bei ARM7 und SHARC voraus, so ist dies im Vergleich zum ARM7 eine Geschwindigkeitserh¨ ohung um mehr als das Doppelte. Gerät (Device) Status-Register Prozessor Daten-Register

GeräteMechanismus

Abbildung 3.2: Schematische Darstellung der speicherabbildenden Ein-Ausgabe (Memorymapped I/O) (nach [Wolf02]).

3.3.2

Eingabe und Ausgabe durch Befehle, Register und Interrupts

Prozessor-Eingabe- und -Ausgabebefehle, Interrupts (Unterbrechungen) usw. erlauben es dem Prozessor bzw. dem Eingebetteten System mit der Außenwelt in Verbindung zu treten. Die Eingabe kann ein einzelnes Datum, z. B. ein Temperaturwert eines Temperaturreglers (siehe Seite 6) oder ein Datenstrom sein, z. B. die Lesedaten von einer Festplatte. Man spricht vom Lesen (Read) der Eingabedaten. Die Ausgabe ist ¨aquivalent: ein einzelnes Datum kann beim Temperaturregler der Stellwert f¨ ur den Mischer einer Heizanlage sein, bei der Festplatte sind es entsprechend die Schreibdaten. Man spricht vom Schreiben der Ausgabedaten. Eingabe und Ausgabe eines Prozessors von und zu externen Ger¨aten – man spricht von der Schnittstelle zur Außenwelt – k¨ onnen auf verschiedene Weise ausgef¨ uhrt werden:

30

3 Mikroprozessor-Grundlagen • Durch Ein-Ausgabebefehle (I/O-Commands) • Speicherabbildende Ein-Ausgabe (Memory-mapped I/O) • Ein-Ausgabe durch Unterbrechungen (Interrups)

Ein Beispiel f¨ ur Ein-Ausgabebefehle beim Intel-86-Prozessor sind die Befehle In(..) und Out(..). Abbildung 3.2 zeigt schematisch die speicherabbildende Ein-Ausgabe (Memory mapped I/O). Der Prozessor kann nacheinander mehrere Register lesen oder schreiben. Hier sind zwei Register dargestellt: Das Statusregister und das Datenregister. Tabelle 3.5 zeigt als Beispiel die Befehlsfolge f¨ ur die speicherabbildende Ein-Ausgabe beim ARM-Prozessor. DEV1 EQU 0x100 LDR r1,DEV1 LDR r0,[r1] ...... ...... LDR r0,#8 STR r0,[r1]

; ; ; ; ; ; ;

Definiere die Ger¨ateadresse Setze die Ger¨ ateadresse in Regiser r1 Lies ein Register aus dem Ger¨at Warten bis das Ger¨ateregister gelesen wurde Auswerten der Ger¨atedaten Setze den Schreibwert auf Speichere den Schreibwert in das Ger¨ateregister

Tabelle 3.5: Beispiel: Befehlsfolge des ARM7 f¨ ur einen speicherabbildenden LeseSchreibvorgang (Memory mapped I/O) [Wolf02].

Jedem Ger¨ at wird eine Ger¨ atenummer zugewiesen. Im Beispiel Tabelle 3.5 ist es die Nummer 0x100. Das Lesen eines Status-oder Datenregisters geschieht durch den Ladebefehl (LDR) von Ger¨ atenummer nach Register (hier r1). Das Schreiben wird durch den Speicherbefehl (STR) von Register nach Ger¨ atenummer ausgef¨ uhrt. In unserem Beispiel wird die Zahl 8 in das Ger¨ ateregister geschrieben. Die speicherabbildende Ein-Ausgabe ist sehr ineffizient, wenn der Prozessor darauf wartet, bis jeweils ein Byte gelesen oder geschrieben wird. Die Methode, diese Wartephase zu programmieren, nennt man Busy-Wait I/O (siehe [Wolf02]). Unterbrechungen (Interrupts) sind eine wesentlich effizientere Methode Synchroni” sation“ mit einem Kommunikationspartner, z. B. mit einem Ein/Ausgabeger¨at herzustellen. Unter Synchronisation versteht man in diesem Fall die Bereitschaft von Kom” munikationspartnern, Daten auszutauschen“ (siehe auch Kapitel Entwurfsmethodik). Der Interrupt-Mechanismus erlaubt Ger¨ aten, das gerade laufende Programm des Prozessors mit einem Interrupt-Signal zu unterbrechen. Damit wird die Ausf¨ uhrung eines bestimmten Programmteils, des Interrupt-Handlers erzwungen (siehe Abbildung 3.3). Wir nehmen an, der Prozessor setzt in einem Programm A einen Lesebefehl an das Ger¨ at ab. Anstatt im Programm A zu warten bis der Lesevorgang beendet ist, kann der Prozessor das Programm weiter abarbeiten. Hat das Ger¨at den Lesevorgang beendet, wird das Interrupt-Signal aktiviert, der Prozessor widmet sich dem Interrupt-Handler, der die gelesenen Daten speichert und danach wieder zum unterbrochenen Programm

3.3 Mikroprozessor-Grundlagen

31

Prozessor Programm A

Interrupt Interrupt Handler

Gerät (Device)

Interrupt ack. Status-Register

Daten

Daten-Register

Abbildung 3.3: Schematische Darstellung der Unterbrechungs-Methode. Das Ger¨ at kann das laufende Programm des Prozessors durch einen Interrupt-Befehl unterbrechen.

A zur¨ uckkehrt und zwar zu der Instruktion, die nach der Unterbrechung auf die Abarbeitung wartet. Das Programm A kann jetzt z. B. einen Schreibbefehl an das Ger¨at absetzen, der gleich behandelt wird wie der Lesebefehl. Etwas leistungsf¨ ahigere Prozessoren haben mehrere Interrupt-Leitungen und k¨onnen damit mehrere Ger¨ ate bedienen. Weiterhin ist es m¨oglich, dass Interrupt-Leitungen von mehreren Eingabe/Ausgabeger¨ aten gemeinsam genutzt werden (shared Interrupts, siehe Kapitel Entwurfsmethodik). Dies legt Interrupt-Priorit¨aten“ nahe, die eine Interrupt” ” Hierarchie“ erlauben. Schnellere“ Ger¨ ate wie z. B. Festplatten mit h¨oherem Datenauf” kommen erhalten eine h¨ ohere Priorit¨ at als langsamere“ Ger¨ate wie z. B. eine Tastatur. ” Ein Ger¨ at mit niedriegerer Priorit¨ at kann ein Ger¨at mit h¨oherer Priorit¨at nicht unterbrechen. Mit Hilfe von Interrupt-Maskierungen k¨ onnen Unterbrechungen verhindert werden. Dies ist wichtig, wenn ein Programm eine kritische Befehlsfolge“ ausf¨ uhrt, die ” nicht unterbrochen werden darf wie z. B. einen Speicherzugriff. Die kritische Befehlsfolge wird in diesem Fall mit einem mask“-Befehl eingeleitet und einem unmask“-Befehl ” ” beendet. Die Interrupt-Maskierung l¨ asst nur eine Ausnahme zu und zwar eine Unterbrechung mit h¨ ochster Priorit¨ at, die sofort ausgef¨ uhrt werden muss, ein sogenannter Non-Maskable-Interrupt“NMI, der nicht maskiert werden kann. Beispiele f¨ ur NMIs ” sind: Schwerwiegende SW-Fehler, sogenannte System-Fehler, Netzteil-Versagen (Power failure), der Akku ist leer und Daten sollten noch gesichert werden usw.

3.3.3

Speicher-Systeme

Speicher-Hierarchie Programmierer w¨ unschen sich unbegrenzten Speicher mit schnellem Speicherzugriff. Unbegrenzter Speicher ist nat¨ urlich nicht realisierbar, jedoch ist eine ¨okonomische L¨osung, diesem Wunsch nahe zu kommen eine Speicher-Hierarchie wie sie die Abbildung 3.4 darstellt. Unten im Bild liegt der Massenspeicher (meist eine Festplatte), mit einer Speicherkapazit¨ at von vielen Terabyte (TB) (1 TB = 1012 Byte) und einer Zugriffszeit von einigen ms. Dar¨ uber der Hauptspeicher mit vielen GigaByte (GB) bis einigen TB, der u ¨ber den I/O-Bus mit der Festplatte verbunden ist und eine Zugriffszeit von

32

3 Mikroprozessor-Grundlagen

Prozessor Register L1 Cache on Chip

L2 Cache L3 Cache

HauptSpeicher I/O-Bus

Massenspeicher (Festplatte)

Abbildung 3.4: Schema einer typischen Computer-Speicherhierarchie. Die kleinen und schnellen Cache-Speicher liegen nahe am Prozessor. Darunter liegt der Hauptspeicher, der u ¨ber den I/O-Bus an einen Massenspeicher (i. A. eine Festplatte) angeschlossen ist.

etwa 10 bis 50 ns (DRAM) aufweist. Dar¨ uber der Level 2 (L2), L3..)-Cache in der Gr¨ oßenordnung MB und einer Zugriffszeit von bis zu 10 ns. Der L2-Cache befindet sich oft im Prozessorgeh¨ ause (Prozessor-Package). Der L1-Cache liegt seit l¨angerer Zeit auf dem Prozessor-Chip und hat eine Speicherkapazit¨at in der Gr¨oßenordnung von einigen hundert kB und eine Zugriffszeit von einigen ns. Großrechner (Main Frames) k¨onnen bis zu zehn Cache-Ebenen (L1 bis L10) haben. Wozu brauchen wir Caches? Die Ausf¨ uhrungsgeschwindigkeit von Prozessoren steigt von Jahr zu Jahr, die Zugriffszeit zum Hauptspeicher wird nicht im gleichen Maße k¨ urzer und h¨alt den Prozessor auf. Caches sind relativ kleine schnelle Speicher mit aufw¨andigerer Technologie, die der Regel gen¨ ugen: smaller-is-faster“ (kleiner ist schneller) [HenPat07]. Kleinere Speicher ” haben geringere Signalverz¨ ogerungszeiten und ben¨otigen weniger Zeit um die Adresse zu dekodieren. Zudem gilt das Prinzip der Lokalit¨at der Bezugsdaten“ (locality of ” reference [HenPat07]), das besagt: Daten die gerade benutzt werden, werden sehr wahrscheinlich in n¨ achster Zukunft wieder ben¨ otigt und sollten in einem schnellen Speicher nahe dem Prozessor aufbewahrt werden: im Cache. Der Cache enth¨ alt einen Teil des Hauptspeichers als Kopie. Eine Cache-Steuereinheit“, ” der Cache Controller“ vermittelt zwischen Prozessor und dem Speichersystem. Ben¨otigt ” der Prozessor ein Programm oder Daten aus dem Speicher, so sendet er eine SpeicherAnforderung (Memory-Request) an den Cache Controller. Der schickt die Anforderung

3.3 Mikroprozessor-Grundlagen

33

an den Cache und an den Hauptspeicher weiter. Befinden sich die angeforderten Daten im Cache, so gibt der Cache Controller die Datenlokation an den Prozessor zur¨ uck und verwirft die Speicher-Anforderung. Wir sprechen von einem Cache Hit (Cache-Treffer). Befinden sich die gew¨ unschten Daten nicht im Cache, so bedeutet dies einen Cache Miss (Cache Fehlschlag). Man unterscheidet verschiedene Cache Misses [HenPat07]: • Ein Compulsory Miss“ (zwangsweiser Fehlschlag) oder Cold Miss“ tritt bei der ” ” ersten Speicheranforderung auf. Die geforderten Daten k¨onnen noch nicht im Cache sein. • Ein Capacity Miss“ wird dadurch verursacht, dass der Datensatz zu groß f¨ ur den ” Cache ist. • Ein Conflict Miss“ entsteht in Satz-assoziativen (Set associative) und direkt” abbildenden Caches (siehe unten), wenn in einem Satz (Set) nicht gen¨ ugend Platz ist, obwohl in anderen S¨ atzen noch freie Blockrahmen vorhanden sind und ein Block entfernt werden muss. Erscheint eine erneute Anfrage auf diesen entfernten Block, so wird dieser Fehlschlag als conflict miss bezeichnet. Die Cache-Hit-Rate h ist die Wahrscheinlichkeit, dass eine gegebene Speicherlokation im Cache ist. Damit ist 1 − h die Miss-Rate und die mittlere Zugriffszeit [Wolf02] ist dann: tav = htcache + (1 − h)tmain

(3.1)

wobei tcache die Zugriffszeit zum Cache ist. Sie liegt (im Jahre 2007) etwa bei 3 bis 5 ns. Die Zugriffszeit zum Hauptspeicher tmain liegt (2007) f¨ ur einen DRAM-Speicher bei eta 50 bis 60 ns. Die Hit-Rate h¨ angt von der Cache-Organisation, der Cache-Gr¨oße und vom Programm selbst ab. Cache-Organisationen Bei der Cache-Organisation unterscheidet man zwischen • Vollassoziativem Cache (Fully associative) • Direkt-abbildendem Cache (Direct mapped Cache) und • Satz-assoziativem (Set associative) Cache. Abbildung 3.5 zeigt oben von links nach rechts schematisch die drei genannten CacheOrganisationen, beispielhaft jeweils mit 8 Cache-Bl¨ocken zu typisch je 4kB [HenPat07]. Unten in Abbildung 3.5 ist schematisch der Hauptspeicher mit z. B. 32 Speicherbl¨ocken zu je 4kB gezeigt. Beim vollassoziativem Cache [HenPat07] k¨onnen sich die Daten einer Adresse in jedem beliebigen Block im Cache befinden. Die Assoziativit¨at n ist gleich der Anzahl der Bl¨ ocke im Cache. Soll z. B. der Speicher-Block Nr. 20, der im Bild 3.5 unten dunkel unterlegt ist, in den vollassoziativen Cache mit n=8 abgebildet werden, so kann er

34

3 Mikroprozessor-Grundlagen Vollassoziativ

Block-Nr.

0 1 2 3 4 5 6 7

Direktabbildend

Satz assoziativ

0 1 2 3 4 5 6 7

0 1 2 3 4 5 6 7

Cache

Set

Block-Nr.

0 1 2 3 4 5 6 7 8

0

1

2

3

9 10 11 12 …………16…………..20…………. 24………..…28……… 31

HauptSpeicher

Abbildung 3.5: Schematische Darstellung eines Hauptspeichers mit 32 Speicherbl¨ ocken (unten) und drei Caches mit je 8 Speicherbl¨ ocken und verschiedenen Cache-Organisationen. Der Cache oben links stellt schematisch den vollassoziativen Cache dar, der Cache in der Mitte oben zeigt einen direkt-abbildenden (direct mapped) Cache und der Cache oben rechts einen Set-assoziativen Cache (nach [HenPat07]).

dort in jeden beliebigen Block geladen werden (alle Bl¨ocke sind dunkel unterlegt). Bei einer Anfrage an den Cache ist es daher notwendig, alle Adressen (Tags) des Caches zu u ufen. Da Caches m¨ oglichst schnell sein m¨ ussen, wird dies parallel ausgef¨ uhrt, was ¨berpr¨ den notwendigen Hardwareaufwand an Komparatoren (Tag-Vergleichern) vergr¨oßert. Beim direkt-abbildenden (direct mapped) Cache [HenPat07] (Abbildung 3.5 oben Mitte) gibt es f¨ ur eine gegebene Adresse nur eine M¨oglichkeit bzw. einen Cache-BlockRahmen, in dem sich die Daten befinden k¨onnen, die Adresse ist genau auf einen Cacheblock-Rahmen abgebildet, daher der Name direkt abgebildet“. Der Blockrahmen, ” in den ein Hauptspeicherblock geladen wird, berechnet sich zu (Hauptspeicherblock) modulo (Cacheblockzahl). Im Beispiel Abbildung 3.5 ist die Cacheblockzahl = 8. Wir nehmen an, die Hauptspeicherblock-Adresse ist 20, dann wird er in den Cacheblockrahmen (20)modulo(8) = 4 geladen. Dasselbe gilt f¨ ur die Cache-Bl¨ocke Nr. 4, 12 und 28 die ebenfalls auf den Cache-Block Nr. 4 abgebildet werden. Auf die Adressierung des direkt-abbildenden Cache wird weiter unten ausf¨ uhrlich eingegangen. Der Satz-assoziative (set associative) Cache [HenPat07] ist sozusagen eine Mischung aus voll assoziativem Cache und direkt-abbildendem Cache. Im Beispiel Abbildung 3.5 oben rechts ist ein zweifach (zwei-Weg oder two-way) Satz-assoziativer Cache mit n = 2 und 4 S¨ atzen (sets) abgebildet, wobei die Assoziativit¨at n gleich der Anzahl der Wege“ ” ist. Eine gegebene Adresse kann nur in einem bestimmten Satz mit n M¨oglichkeiten abgebildet werden. Der Satz, in den ein Hauptspeicherblock geladen wird, berechnet

3.3 Mikroprozessor-Grundlagen

35

sich zu (Hauptspeicherblock) modulo (Satzzahl). In unserem Beispiel mit n=2 und 4 S¨ atzen berechnet sich dieser Satz f¨ ur den Hauptspeicherblock 20 zu: (20) modulo (4) = 0, d. h. im Satz 0 gibt es f¨ ur die Hauptspeicherbl¨ocke 4, 12, 20 und 28 zwei M¨ oglichkeiten der Speicherung (in Bild 3.5 oben rechts dunkel unterlegt). Zusammenfassend kann man sagen: Der Satz-assoziative Cache ist der Allgemeinfall. Der direkt-abbildende Cache ist ein Sonderfall des Satz-assoziativen Caches mit einer Assoziativit¨ at von Eins und so vielen S¨ atzen wie Cache-Blocks vorhanden sind. Ein vollassoziativer Cache ist ein Satz-assoziativer Cache mit einer Assoziativit¨at gleich der Anzahl der Cache-Blocks und nur einem Satz. Der vollassoziative Cache hat den Nachteil, dass bei der Blocksuche jeder einzelne Tag gepr¨ uft werden muss, die Blocksuche ist daher aufw¨andig. Der direkt-abbildende Cache ist relativ schnell und einfach zu realisieren, aber in der Performanz begrenzt; denn es k¨ onnen vermehrt Conflict Misses auftreten: Falls im Beispiel Abbildung 3.5 die Hauptspeicher-Bl¨ ocke 0 bis 10 in einen direkt-abbildenden Cache geladen werden, ist kein Platz mehr f¨ ur die Bl¨ ocke 8 bis 10. Der n-fach Satz-assoziative Cache hat Vorteile gegen¨ uber den anderen beiden Cache-Organisationen. Die Block-Suche wird dadurch vereinfacht, dass nur jeweils in einem Satz gesucht werden muss und durch die mehrfache Assoziativit¨ at treten weniger Cache Misses auf [HenPat07]. Index Valid Tag

100

1

010

Daten

Cache-Block Nr. 4

Adresse Tag

Index

Offset

= Treffer: Hit

Daten

Abbildung 3.6: Adressierung eines direkt-abbildenden Cache. Die Adresse enth¨ alt drei Felder: Das Tag-Feld, das Index-Feld und das Offset-Feld. Im Bild befindet sich der Speicherblock Nr. 20 im Cache, ist g¨ ultig und soll gelesen werden. Das Index-Feld enth¨ alt den Wert ’0x100’, das Tag-Feld enth¨ alt den Wert ’0x10’ (nach [Wolf02]).

Adressierung des direkt-abbildenden Cache Es werden immer gleiche Bereiche des Hauptspeichers in Cachegr¨oße in den direktabbildenden Cache geladen, in unserem Beispiel Bild 3.5 umfasst die Cachegr¨oße 8 Bl¨ ocke. Da es f¨ ur eine gegebene Adresse nur eine M¨oglichkeit bzw. Cache-Block-Rahmen gibt, die sich aus der Beziehung (Hauptspeicherblock)modulo(Cacheblockzahl) ergibt (siehe oben), muss bei einer Anfrage an den Cache auch nur jeweils ein Cache-Block gelesen werden, d. h. der zugeh¨ orige Tag“ u uft werden. Abbildung 3.6 zeigt sche¨berpr¨ ” matisch die Adressierung des direkt-abbildenden Caches. Die Cache-Adresse besteht

36

3 Mikroprozessor-Grundlagen

aus drei Feldern: Dem Tag-Feld, Index-Feld und dem Offset. Vor dem Tag-Feld des Cache-Blocks steht noch das Valid“-Bit, das anzeigt, ob der jeweilige Cache-Block ” g¨ ultig ist. Vor dem ersten Beschreiben des Cache stehen alle Valid-Bits auf Null. Die einzelnen Bl¨ ocke sind u ¨ber das Index- und Tag-Feld adressierbar. Das gesuchte Byte wird mit Hilfe des Offset-Feldes gefunden. In unserem Beispiel aus Abbildung 3.6 soll der Hauptspeicher-Block 20 aus dem direkt-abbildenden Cache gelesen werden. Das Index-Feld entspricht der Block-Adresse bzw. Block-Nr. 4 (’0x100’). Das TagFeld T wird errechnet aus der ganzzahligen Division ohne Rest mit der Cachegr¨oße: T = (Hauptspeicherblock)/8. In unserem Beitpiel ist T = 20/8 = 2, hexadezimal: ’T=0x010’. Stimmt das Tag-Feld der Adresse mit dem Tag-Feld des Speicherblocks im Cache u ¨berein, so haben wir einen Cache-Hit, der gesuchte Speicherblock befindet sich im Cache. Schließlich kann mit dem Offset-Feld ein einzelnes Byte aus dem 4 kByteBlock des Beispiels adressiert werden, es muss also 12 Bit breit sein. Cache-Verwaltungsstrategien Der Cache ist ein relativ teurer und kleiner Speicher, daher ist es sinnvoll, immer nur die Bl¨ ocke im Cache zu halten, auf die auch h¨ aufig zugegriffen wird. Es gibt verschiedene Strategien, Speicherbl¨ ocke wieder aus dem Cache auszulagern“, d. h. in den Haupt” speicher zur¨ uck zu schreiben, auch Verdr¨ angungsstrategien“ genannt: ” • Die LRU-Strategie (Least Recently Used). Eine h¨aufig verwendete Variante, die immer den Block zur¨ uck schreibt, auf den am l¨angsten nicht mehr zugegriffen wurde. • FIFO (First In First Out): Der jeweils ¨alteste Eintrag wird verdr¨angt. • LFU (Least Frequently Used): Der am wenigsten gelesene Eintrag wird verdr¨angt. Das Schreiben der Caches ist aufw¨ andiger als das Lesen; denn der Hauptspeicher muss ebenfalls neu geschrieben werden, wenn sich Daten im Cache ¨andern. Zum Gl¨ uck dominieren die Lesevorg¨ ange im Cache bei Weitem. Alle Instruktions-Zugriffe im Cache sind Lesevorg¨ ange. Schreibstrategien sind: • Das Write through“: Bei jedem Schreibvorgang wird sowohl der Cache als auch ” der Hauptspeicher beschrieben. • Das Write back“: Der Hauptspeicher wird nur zur¨ uckgeschrieben, wenn ein Cache” Block aus dem Cache entfernt wird. Beispiele f¨ ur Caches von etwas ¨ alteren Prozessoren: Der StrongARMT M -Prozessor der Firma ARM besitzt getrennte Instruktions- und Daten-Caches zu je 16 KB. Beide Caches sind 32-Weg-(16)-Satz-assoziative Caches mit 32 Byte Cache-Blocks [Wolf02]. Der OpteronT M der Firma AMD besitzt ebenfalls getrennte Caches f¨ ur Daten und Instruktionen. Sowohl der 64 kB Instruction-Cache als auch der 64 kB Daten-Cache ist ein 2-Weg-Satz-assoziativer-Cache mit 8 S¨ atzen (sets) [ChipArch03].

3.3 Mikroprozessor-Grundlagen

3.3.4

37

Hauptspeicher

Der Hauptspeicher oder Arbeitsspeicher, als n¨achste Komponente unterhalb des Cache in der Speicherhierarchie (siehe Abbildung 3.4), h¨alt die im Prozessor momentan ablaufenden Programme und die zugeh¨ origen Daten. Auf den Hauptspeicher greift einerseits der Cache zu, andererseits dient er als Schnittstelle f¨ ur die Ein- und Ausgabe zur Festplatte. Der Hauptspeicher ist in der Regel ein fl¨ uchtiger“ (volatile) Speicher mit ” wahlweisem Zugriff“ (Random Access Memory RAM) und kann sowohl beschrieben ” als auch ausgelesen werden. Fl¨ uchtiger Speicher bedeutet: Die gespeicherten Daten sind nach dem Ausschalten der Spannungsversorgung gel¨oscht. Wahlweiser Zugriff bedeutet: Auf jedes Datum im RAM kann direkt zugegriffen werden. Der Hauptspeicher wird charakterisiert durch • die Speicherkapazit¨ at, • die Datenbreite und • durch die Latenz bzw. Bandbreite. Aus Tradition wird die Latenz im Zusammenhang mit dem Cache aufgef¨ uhrt, w¨ahrend die Bandbreite als Charakteristikum f¨ ur die Ein-Ausgabegeschwindigkeit genannt wird. Die Latenz wird traditionell durch zwei Maße angegeben: die Speicher-Zugriffszeit (access time) und die Zykluszeit (cycle time) [HenPat96]. Die Zugriffszeit ist die Zeit zwischen Anlegen der Adresse und Verf¨ ugbarkeit der Daten. Die Zykluszeit ist die Mindestzeit zwischen zwei aufeinanderfolgenden Speicherzugriffen. Die Zykluszeit ist gr¨ oßer als die Zugriffszeit. Ein Grund daf¨ ur ist: Die Speicher-Adressleitungen m¨ ussen zwischen den Zugriffen stabil sein (siehe Abschnitt 4.2.2). Organisation des Hauptspeichers Hauptspeicher-Bausteine sind in verschiedenen H¨ohe/Breite-Ratios verf¨ ugbar. Ein 64 MB DRAM (Dynamic RAM)-Speicherbaustein kann angegeben werden als • 64 MB (Speicher-H¨ ohe) mit 8-Bit Wortbreite oder als • 16 MB mit 32 Bit Wortbreite Das Verh¨ altnis H¨ ohe/Breite wird als Aspect-Ratio [Wolf02] bezeichnet. Intern werden die Daten als zweidimensionales Feld von Speicherzellen mit Zeilen und Spalten (Array) organisiert wie Abbildung 3.7 zeigt. Die n-Bit-Adresse n kann ein einzelnes Speicherelement adressieren und wird aufgeteilt in eine Zeilenadresse r (row) und Spaltenadresse c (column) mit n = r + c. Die Datenworte werden mit einer bestimmten Datenbreite in den RAM geschrieben bzw. ausgelesen. In diesem Fall wird jeweils eine Untermenge von Spalten adressiert. Die Datenbreite kann folgende Werte betragen: (1), (4), 16, 32, 64, 128, (256) Bit. Die Werte 1 und 4 Bit sind heute nicht mehr u ¨blich. Datenbreiten von 256 Bit und mehr findet man z. B. bei Eingebetteten Systemen f¨ ur Multimediaanwendungen.

38

3 Mikroprozessor-Grundlagen

Adresse n

r c

Memory Array

R/W‘

Enable Daten

Abbildung 3.7: Innere Organisation einer Speicher-Komponente (aus [Wolf02]). Die Daten werden als Memory Array von Speicherzellen mit Zeile r (row) und Spalte c (column) organisiert, wobei die Adresse n = r+c ist.

Das R/W’-Signal (Read/Write, low aktiv, siehe auch Abschnitt 4.2.2), steuert die Datenrichtung (schreiben bzw. lesen). Das Enable-Signal in Abbildung 3.7 wird eingesetzt, um einzelne Speicherb¨ anke auszuw¨ ahlen, wenn gr¨oßere Speichereinheiten aus mehreren Speicherb¨ anken aufgebaut werden. Speicherbausteine Man unterscheidet grunds¨ atzlich zwischen Statischen RAM- (SRAM) und Dynamischen RAM-Bausteinen. SRAM-Bausteine sind schneller, wesentlich teurer als DRAMs und werden f¨ ur Caches und Hochleistungsrechner eingesetzt [RechPom02]. Jede Speicherzelle im SRAM (d. h. jedes Bit) wird durch ein FlipFlop (meist sechs Transistoren) realisiert. DRAM-Bausteine sind sehr viel einfacher aufgebaut als SRAM-Chips. Eine Speicherzelle besteht lediglich aus dem sehr kleinen Gate-Kondensator plus dem dazugeh¨origen CMOS-Transistor. Dadurch kann die Speicherdichte praktisch etwa acht mal gr¨oßer sein als bei SRAMs. Abbildung 3.8 nach [RechPom02] zeigt schematisch ein DRAM-Baustein der Gr¨ oße 4 M x 1 Bit. Die Zellen werden u ¨ber eine Zeilen- und Spaltenadresse angesprochen, die aus der Adresse A0..A10 plus den Signalen RAS’ (Row Address select), CAS’ (Column Address select) im ZAD (Zeilenadressdekoder) und SAD (Spaltenadressdekoder) dekodiert werden. Die Apostrophe an den Signal-K¨ urzeln bedeuten: Die Signale sind low aktiv“. Mit den Signalen WE’ (Write enable) und OE’ (Output enable) wird ” sowohl der Baustein ausgew¨ ahlt als auch die Datenrichtung (Schreiben/Lesen) angegeben. Mit der Zeilenadresse wird eine ganze Zeile ausgelesen bzw. geschrieben, die beim Auslesen zwischengespeichert wird. Mit der Spaltenadresse k¨onnen einzelne Bits gelesen bzw. geschrieben werden.

3.3 Mikroprozessor-Grundlagen

39

Speichermatrix 2048 x 2048 Bit RAS´

A0....A10

Z A R S A R

CAS´

Z A D

1-Bit-Zelle

. . . ....

Din

LSV .... SAD

WE´ OE´

ZAR .. Zeilenadressregister SAR .. Spaltenadressregister ZAD .. Zeilenadressdekodierer SAD .. Spaltenadressdekodierer LSV .. Lese-/Schreibverstärker LSS .. Lese-/Schreibsteuerung

LSS

Dout RAS´.. Row Addr. Select CAS´.. Column Addr. Select WE´.. Write Enable Oe´ .. Output Enable

Abbildung 3.8: Schematische Darstellung eines DRAM-Bausteins mit 4 M × 1 Bits ohne Refresh-Logik (nach [RechPom02]).

Ein Nachteil der DRAM-Bausteine ist, dass die Daten beim Auslesen zerst¨ort werden. Um die Daten zu erhalten, muss eine ausgelesene Zeile umgehend u ¨ber einen Lese/Schreibverst¨ arker (LSV) wieder zur¨ uckgeschrieben werden. Das besorgt die Lese/Schreibsteuerung (LSS). Durch die hohe Speicherdichte bei DRAMs droht zudem ein Datenverlust durch Leckstr¨ ome. Daher muss innerhalb bestimmter Zeitabst¨ande (8 bis 128 ms) der Speicherinhalt regeneriert werden (refresh). Die Zugriffszeit (s. o.) bei SRAM-Bausteinen betr¨agt ca. 6 ns (2002), bei DRAMs ca. 50 ns [RechPom02]. Die Zyklusszeit (s. o.) bei DRAM-Bausteinen ist etwa doppelt so groß wie die Zugriffszeit und betr¨ agt ca. 100 ns (2002). Bei SRAMs gilt etwa: Zyklusszeit = Zugriffszeit, also ca. 6 ns. Einige Sonderausf¨ uhrungen von DRAM-Bausteinen sind zu erw¨ahnen wie folgt: • SDRAM: Synchrone DRAMs werden synchronisiert mit dem Prozessor-Datenbus betrieben. Dadurch erh¨ alt man k¨ urzere Ansteuerzeiten. Insbesondere im Burst¨ Betriebsmodus (Ubertragung von Datenfolgen) wird Zeit eingspart. • DDR-SDRAM: Double Datarate SDRAM. Daten werden sowohl bei steigender als auch bei fallender Taktflanke u ¨bertragen. ¨ • RAMBus und DRAMs: RDRAMS : Uber einen schnellen“ Bus sind DRAM-Spei” cherb¨ anke parallel angeschlossen. Datenraten bis zu 1,6 GB/s bei 400 MHz Taktrate (2007) bei einer Busbreite von 16 Bit sind m¨oglich.

40

3 Mikroprozessor-Grundlagen

3.3.5

Festwertspeicher (ROM)

Festwertspeicher bzw. Read Only Memories (ROM) werden einmalig mit festen“ d. h. ” danach unver¨ anderbaren Daten geladen. Die Daten sind nach dem Laden nicht fl¨ uchtig (non volatile), d. h. bleiben auch nach dem Abschalten der Spannungsversorgung erhalten. Ein Beispiel f¨ ur ein ROM ist das Basic Input/Output System (BIOS) im PC. In Eingebetteten Systemen werden ROMs h¨ aufig verwendet, da oft gr¨oßere Programmteile und auch einige Daten u angere Zeiten unver¨andert bleiben k¨onnen. Fest¨ber l¨ wertspeicher sind gegen¨ uber Strahlung und St¨orungen sehr viel weniger empfindlich als volatile Speicher. ROMs sind daher f¨ ur den Einsatz in strahlungsbelasteter Umgebung wie z. B. in Weltraum-Labors, in Atomkraftwerken, Bergwerken usw. gut geeignet. Es gibt eine Vielfalt von Festwertspeichern. zun¨achst wird unterschieden zwischen • Hersteller-programmierten ROMs und • Feldprogrammierbaren ROMs (PROMs, EPROMS usw.). Hersteller-programmierte ROMs, auch Masken-programmierte ROMs genannt, werden beim Hersteller programmiert (factory-programmed) und lohnen erst bei großen St¨ uckzahlen. PROMs (programmable Read Only Memories) und EPROMs (eraseable PROMs) k¨ onnen beim Benutzer mit Hilfe von speziellen Ger¨aten programmiert werden. Auf die große Vielfalt der Festwertspeicher kann im Rahmen dieses Buches nicht eingegangen werden.

3.3.6

Befehls-Verarbeitungsmethoden

Eingebettete Systeme m¨ ussen in der Regel Echtzeitanforderungen erf¨ ullen. Bei Verwendung von Mikroprozessoren setzt das voraus, dass der Prozessor die Befehle innerhalb bestimmter Zeitgrenzen verarbeiten muss, d. h. die Performanz (siehe Abschnitt 5.6.3) des Prozessor ist wichtig. Folgende Befehls-Verarbeitungsmethoden bestimmen die Performanz: • Fließbandverarbeitung oder Pipelining • Superskalare Verarbeitung • Speichermethoden: Caching Der Entwickler von Eingebetteten Systemen muss mit Performanzanalysen und Simulationsmethoden (siehe Kapitel 5) u ufen, ob die geforderten Zeitgrenzen eingehalten ¨berpr¨ werden. Fließbandverarbeitung bzw. Pipelining Fließbandverarbeitung bzw. Pipelining ist die wirksamste Methode, um die BefehlsVerarbeitungsgeschwindigkeit von Prozessoren zu erh¨ohen. Praktisch alle leistungsf¨ ahigen Prozessoren haben vielstufige, hochentwickelte Pipelines.

3.3 Mikroprozessor-Grundlagen

IF

Instruktion i Instruktion i+1

41

ID

EX

MEM

WB

IF

ID

EX

MEM

WB

IF

ID

EX

MEM

WB

IF

ID

EX

MEM

WB

IF

ID

EX

MEM

Instruktion i+2 Instruktion i+3 Instruktion i+4

0

1

2

3

4

5

6

7

WB

8

9

Zeit (Taktzyklen)

Abbildung 3.9: F¨ unfstufige Pipeline des DLX-Prozessors aus Hennessy & Patterson [HenPat07]. Die einzelnen Pipeline-Stufen sind: IF: Instruction fetch, ID: Instruction decode, EX: Execute, MEM: Memory access, WB: Write back.

Pipelining kann mit der Fließbandverarbeitung in einer Automobilmontage verglichen werden. Die Montage des Automobils wird in viele Schritte aufgeteilt, wobei jeder Schritt nebenl¨ aufig zu den anderen Schritten ausf¨ uhrbar ist. In einer Prozessor-Pipeline werden die Instruktionen u uhrt, jeder ¨berlappt“ ausgef¨ ” Pipeline-Schritt f¨ uhrt einen Teil einer Instruktion aus. Damit die Pipeline-Schritte parallel ausf¨ uhrbar sind, ist daf¨ ur jeweils separate Hardware erforderlich, die Pipeline-Stufe genannt wird. Es ist ein Kompromiss (Trade-off) zwischen Hardware und Performanz: Mit erh¨ ohtem Hardware-Aufwand erkauft man h¨ohere Performanz. Die Beschleunigung (Speedup), die ein Prozessor durch Pipelining erh¨alt, entspricht in etwa der Anzahl der Pipeline-Stufen. Abbildung 3.9 zeigt die f¨ unfstufige Pipeline des DLX-Prozorrs aus Hennessy & Patterson [HenPat07], Abbildung 3.10 zeigt die dreistufige Pipeline des ARM-Prozessors und des Sharc-Prozessors aus [Wolf02]. Die einzelnen Pipeline-Stufen in Bild 3.9 sind: IF: Instruction fetch: Instruktion holen, ID: Instruction decode: Instruktion dekodieren, EX: Execute: Instruktion ausf¨ uhren, MEM: Memory Access: Speicher Zugriff, WB: Write back: Zur¨ uckschreiben des Ergebnisses in den Cache. Das Pipeline-Schema ist nur zu verwirklichen, wenn jede Stufe die gleiche Ausf¨ uhrungszeit aufweist. Man erreicht dies durch Anpassen der Ausf¨ uhrungszeiten der einzelnen Stufen an die Ausf¨ uhrungszeit der langsamsten“ Stufe. Im Fall der DLX-Pipeline ist die Ausf¨ uhrungszeit einer Stufe ” gleich einem Prozessor-Taktzyklus. In jedem Taktzyklus f¨ uhrt jede Stufe den gleichen Arbeitsschritt aus, z. B. holt die Instruction-fetch-Stufe einen Befehl aus dem Cache. Dies setzt eine erh¨ohte Speicher” bandbreite“ bei Pipeline-Prozessoren voraus, der Instruktions-Bus muss in der Lage sein, eine Instruktion pro Taktzyklus zu transportieren, dasselbe gilt f¨ ur den Datenbus, der in der Lage sein muss, in jedem Taktzyklus Daten und Ergebnisse weiter zu geben. Die Speicherbandbreite ist eine Kennzahl von Speicherbausteinen. Es ist sozusagen die

42

3 Mikroprozessor-Grundlagen

Add r0,r1,#5 Sub r2,r3,r6 Cmp r2,#3

fetch

decode

Exec add

fetch

decode

Exec sub

fetch

decode

Exec cmp

Zeit (Taktzyklen)

Abbildung 3.10: Dreistufige Pipeline des ARM7-Prozessors (nach [Wolf02]).

Datentransport-Geschwindigkeit f¨ ur das Lesen aus einem Speicher bzw. Schreiben von Datenmengen in einen Speicher und wird angegeben z. B. in MByte pro Sekunde, also (z. B. 8 MByte pro Sekunde). Die Instruktions-Abarbeitung in der Abbildung 3.9 zeigt einen stetigen Ablauf der Pipeline. Nach dem f¨ unften Taktzyklus wird jeweils eine komplette Instruktion pro Taktzyklus beendigt und dabei wird genau 1 Zyklus pro Instruktion (cycle per instruction: CPI) ben¨ otigt. CPI ist die Kennzahl, die den Daten-Durchsatz (Throughput) einer Pipeline angibt [HenPat07]. Dieser stetige Ablauf wie ihn Abbildung 3.9 zeigt, kann jedoch nicht dauernd anhalten. Es gibt Ereignisse Hazards“ genannt, die den ein-Zyklus-pro-Instruktions-Ablauf ” einer Pipeline st¨ oren und die Abarbeitung einzelner Instruktionen aussetzen lassen. Diese Aussetzer werden pipeline stalls“ genannt. Es gibt drei Klassen von Hazards ” [HenPat07]: 1. Struktur-Hazards (structural hazards) resultieren von Ressourcen-Konflikten. Die Hardware kann nicht alle m¨ oglichen Kombinationen von Instruktionen in gleich¨ zeitiger Uberlappung ausf¨ uhren. 2. Daten-Hazards treten bei Datenabh¨ angigkeiten auf. Eine Folgeinstruktion h¨angt von den Ergebnis-Daten der vorhergehenden Instruktion ab. 3. Control-Hazards treten bei Verzweigungen auf, wenn die Adresse der Folgeinstruktion von einer Bedingung in der vorhergehenden Instruktion abh¨angt. Ein Beispiel f¨ ur einen Daten-Hazard zeigt die Abbildung 3.11: Es ist die AssemblerCode-Sequenz des DLX-Prozessors nach [HenPat07] f¨ ur die Addition A = B + C. In der ersten Instruktion LW R1,B“ wird Variable B nach Register R1 geladen, da” nach in LW R2,C“ Variable C nach Register C. In der folgenden Instruktion ADD ” ” R3,R1,R2“ werden die Registerinhalte R1, R2 addiert und das Ergebnis nach R3 geladen. Allerdings ist zum Zeitpunkt der geplanten Ausf¨ uhrung (EX) des ADD-Befehls das Laden des Registers R3 noch nicht abgeschlossen und die Ausf¨ uhrung des Add-Befehls muss daher um einen Taktzyklus verz¨ ogert werden (stall). Dieser stall“ wirkt sich auf ” alle folgenden Instruktionen aus.

3.3 Mikroprozessor-Grundlagen

LW R1,B LW R2,C ADD R3,R1,R2

IF

43

ID

EX

MEM

WB

IF

ID

EX

MEM

WB

IF

ID

stall

EX

MEM

WB

IF

ID

EX

MEM

SW A, R3

WB

Abbildung 3.11: Beispiel f¨ ur einen Daten-Hazard: F¨ ur die Addition A = B + C ist die DLXCode-Sequenz dargestellt. LW R1,B“ bedeutet: Lade Variable B nach Register R1. ADD ” ” R3,R1,R2“ bedeutet: Addiere Registerinhalte R1, R2 und lade das Ergebnis nach R3. Software ” A,R3“ bedeutet: Speichere Registerinhalt R3 nach Variable A. Die Add-Instruktion muss um einen Taktzyklus verz¨ ogert werden, da die Lade-Instruktion noch nicht abgeschlossen ist (nach [HenPat07]).

Wie gesagt, treten Control-Hazards bei Verzweigungen (branches) auf. Wir betrachten den folgenden C-code eines Kontroll-Konstrukts:

if (a > b) x = a + b; else x = b − a; Die Instruktion a > b ist eine Compare“-Instruktion. Falls sie wahr ist, folgt eine Ad” dition, sonst eine Subtraktion. Welche Instruktion soll die Instruction-fetch-Stufe als n¨ achstes nach dem Compare laden? Die Instruktion, ob Addition oder Subtraktion, h¨ angt vom Ergebnis der Compare-Instruktion ab, das aber erst nach drei Taktzyklen beim DLX-Prozessor verf¨ ugbar ist. Eine Verz¨ogerung von drei Taktzyklen (branch penalty) bei Verzweigungen ist ein bedeutender Verlust und w¨ urde die Gesamtperformanz des Prozessors erheblich beeintr¨ achtigen. Daher wird z. B. beim DLX-Prozessor eine andere L¨ osung eingesetzt: Durch zus¨ atzliche Hardware wird das Ergebnis des Compare fr¨ uher ermittelt und die Folgeadresse (die Branch-Adresse“) entsprechend errech” net. Dadurch kann die Verz¨ ogerung auf einen Taktzyklus bei Verzweigungen reduziert werden. Eine andere M¨ oglichkeit, um die Verz¨ ogerung bei Control-Hazards zu verringern, ist die Sprungvorhersage (branch prediction). Das Ziel der Sprungvorhersage ist ein m¨ oglichst fr¨ uhes Erkennen eines Sprungbefehls und die Sprungzieladresse der Instruktion zu w¨ ahlen, die mit der gr¨ oßten Wahrscheinlichkeit als n¨achstes in der Pipeline an der Reihe ist. Man unterscheidet die statische und die dynamische Sprungvorhersage. Die statische Sprungvorhersage ¨ andert ihre Vorhersage w¨ahrend das Programmablaufs nicht und erreicht dadurch nur eine relativ geringe Vorhersagegenauigkeit. Diese Methode geht von bekannten Tatsachen aus. Beispielsweise ist die Wahrscheinlichkeit relativ hoch, dass bei While-Schleifen die n¨ achste Schleifeniteration gleich ist wie die vorhergehende, also der Aussprung (branch) aus der Schleife nicht genommen wird. Hat z. B. eine While-Schleife 30 Iterationen, so gibt es dreißig Mal keinen Sprung“ und erst beim 31. ” Mal den Aussprung. Hier wird man spekulativ zun¨achst als n¨achste Adresse nicht den

44

3 Mikroprozessor-Grundlagen

Sprung w¨ ahlen und diese Adresse auch f¨ ur die n¨achsten Iterationen beibehalten. Kommt dann schließlich der Sprung, so steht in der Pipeline die falsche Intsruktion, das heißt diese Instruktion und auch die Folgeinstruktionen werden gel¨oscht, man nennt das die Pipeline wird gesp¨ ult“ (Pipeline Flush). Die Sprungadresse wird errechnet und die ” entsprechende Instruktion plus Folgeinstruktionen werden in die Pipeline geholt. Die dynamische Sprungvorhersage geschieht nur zur Laufzeit. Sie benutzt verschiedene Techniken zur Erzeugung einer Vorhersage. Ihre Vorhersagegenauigkeit liegt wesentlich h¨ oher als die der statischen Methode. Als Beispiel f¨ ur mehrstufige Pipelines sei der AMD-AthlonT M -“Hammer“-Prozessor aufgef¨ uhrt, dessen Pipeline f¨ ur die Integer-Verarbeitung 13 Stufen enth¨alt. Die Pipeline f¨ ur die Fließkomma-Verarbeitungseinheit (Floating Poit Unit FPU) weist 17 Stufen auf [ChipArch01].

Register Steuereinheit

Befehl 1

BefehlsAusführungsEinheit

BefehlsAusführungsEinheit

Befehl 2

Abbildung 3.12: Schematische Darstellung der Befehls-Steuereinheit eines superskalaren Prozessors mit 2 Befehls-Ausf¨ uhrungseinheiten [Wolf02].

Superskalare Prozessoren W¨ ahrend skalare Architekturen“ maximal einen Befehl pro Taktzyklus ausf¨ uhren k¨on” nen, sind superskalare“ Prozessoren in der Lage, mehrere Befehle pro Taktzyklus zu ” verarbeiten. Das Prinzip des superskalaren Prozessors ist schematisch in Abbildung 3.12 dargestellt. Eine Steuereinheit verteilt die Befehle auf zwei Befehls-Ausf¨ uhrungseinheiten. Die Steuereinheit pr¨ uft dynamisch, ob eine parallele Verarbeitung der Befehle m¨oglich ist, d. h. es d¨ urfen keine Datenabh¨ angikeiten zwischen den Befehlen bestehen, die auf verschiedenen Ausf¨ uhrungseinheiten gleichzeitig verarbeitet werden. Prozessoren k¨ onnen beispielsweise 2-, 3-, 4-, 8-, 16-, 32-fach superskalar sein [BriUng10], das heißt sie k¨ onnen 3 bis 32 Befehls-Ausf¨ uhrungseinheiten besitzen. Der erste zweifach superskalare Prozessor war der Intel i960, ein RISC-Prozessor der 1990 in den Handel kam und sehr erfolgreich war [BriUng10]. Ein weiteres Beispiel ist der OpteronT M der Firma AMD, ein 3-fach superskalarer Prozessor der auf der Intel x86-Architektur basiert [ChipArch03].

3.3 Mikroprozessor-Grundlagen

45

Um superskalare und Mehrkernprozessoren (siehe Abschnitt 3.1) effektiv zu nutzen, m¨ ussen parallel ausf¨ uhrbare Programmbefehle bzw. Programmteile zur Verf¨ ugung stehen, die vom Compiler in einem sequenziell erstellten Programm als parallel ausf¨ uhrbar erkannt und gekennzeichnet werden. Man spricht von feink¨ orniger Parallelit¨ at. Brinkschulte/Ungerer [BriUng10] berichten von Untersuchungen die gezeigt haben, dass sequenzielle Programme nicht mehr als f¨ unf- bis siebenfache feink¨ornige Parallelit¨at aufweisen. Das bedeutet, dass vielfach superskalare Prozessoren und Mehrkernprozessoren nur dann effektiv genutzt werden k¨ onnen, wenn auf diesen mehrere Prozesse bzw. mehrere Prozessf¨ aden (Threads) parallel zur Ausf¨ uhrung zur Verf¨ ugung stehen. F¨ ur diesem Fall sind die mehrf¨ adigen“ Mikroprozessoren entwickelt worden. ” Bei Cache-Fehlzugriffen (Cache-Misses), wenn Caches u ¨ber einen Bus nachgeladen werden m¨ ussen, kann dies zu Verz¨ ogerungszeiten f¨ uhren, die um viele Gr¨oßenordnungen u uhrungszeit eines Mikroprozessors liegen [BriUng10]. Die Pipeline ¨ber der Befehls-Ausf¨ eines Prozessors muss aber st¨ andig mit Befehlen versorgt werden, um alle Einheiten des Prozessors auszunutzen. Eine Technik, die dies unterst¨ utzt, ist die Mehrf¨ adigkeit (Multithreading). Ein Prozess- bzw. Taskwechsel bringt neue Befehlsfolgen, ist aber in der Regel mit einem Kontextwechsel und mit dem Laden von Daten aus dem Speicher bzw. Cache verbunden. Dies kostet Zeit und verursacht Leerlauf des Prozessors. Deshalb wird der Kontext von zur Ausf¨ uhrung bereiten Prozessen bzw. Tasks bei mehrf¨adigen Prozessoren in zus¨ atzlichen Registers¨ atzen gespeichert. Die Verz¨ogerungszeiten werden dadurch verringert und die Pipeline des Prozessors kann weiterlaufen [BriUng10]. Virtuelle Speicherverwaltung Das Prinzip des Virtuellen Speichers“ (Virtual Memory) vermittelt einem Anwen” dungsprogramm den Eindruck, dass ihm kontinuierlicher Hauptspeicherplatz zur Verf¨ ugung steht, w¨ ahrend dieser tats¨ achlich physikalisch (in sogenannten pages) fragmentiert ist und eventuell sogar auf einen Sekund¨ arspeicher, meist auf die Festplatte, ausgelagert wird. Mit anderen Worten: Falls mehrere große Programme gleichzeitig im Hauptspeicher ge¨ offnet werden und der Hauptspeicher daf¨ ur zu klein ist, k¨onnen Programmteile auf einen Sekund¨ arspeicher – in der Regel die Festplatte – ausgelagert werden. Das organisiert die Memory Management Unit“, die MMU. ” Logische Adresse

Prozessor

SekundärSpeicher

Physikalische Adresse

MMU

HauptSpeicher

Daten

Abbildung 3.13: Prinzip der virtuellen Adressierung. Die Memory-Management Unit (MMU) u ¨bersetzt die logischen Adressen in physikalische Adressen und gibt diese an den Hauptspeicher weiter (nach [Wolf02]).

In Abbildung 3.13 ist das Prinzip der virtuellen Speicherverwaltung dargestellt. Der Prozessor arbeitet nicht mehr mit physikalischen Adressen“ des Hauptspeichers, son”

46

3 Mikroprozessor-Grundlagen

dern mit Logischen Adressen“, die an die MMU weitergegeben werden. Das heißt, ” die MMU bildet den logischen Adressraum eines Programms auf einen physikalischen Adressraum im Hauptspeicher ab. In modernen Prozessoren ist die MMU oft in die Cache-Steuerung integriert wie z. B. beim OpteronT M der Firma AMD [ChipArch03]. Alle modernen Vielzweck-(General Purpose)-Computer Betriebssysteme verwenden virtuelle Speichertechniken. Zum Beispiel unterst¨ utzt die ARM-Cortex A-Familie (siehe Abschnitt 3.4.3) eine virtuelle Speicherverwaltung.

3.3.7

Performanz und Energieverbrauch

Performanz Warum verwenden wir das unsch¨ one Fremdwort Performanz“, wenn wir die Re” chenleistung eines Computers charakterisieren wollen? Weil Rechenleistung“ die sehr ” verschiedenen Eigenschaften eines Computers in Bezug auf seine Leistungsf¨ahigkeit nur ungenau wiedergibt. Zum Beispiel: Wie hoch ist die Rechenleistung eines Mainframe“, also eines Groß” rechners der meist f¨ ur kommerzielle Anwendungen in Banken und Versicherungen eingesetzt wird? Die Rechenleistung von Mainframes gemessen in MegaFlops, GigaFlops oder TeraFlops (106 , 109 oder 1012 Floatingpoint Operations per second) ist relativ gering, verglichen mit so genannten Supercomputern“ (zum Beispiel einem CRAY” Computer). Der Mainframe ist auf einen m¨oglichst hohen Datendurchsatz und auf Zuverl¨ assigkeit ausgelegt, d. h. m¨ oglichst viele Transaktionen, also Eingabe/AusgabeOperationen pro Sekunde sehr zuverl¨ assig auszuf¨ uhren und kann damit in Bezug auf reine Rechenleistung mit einem Supercomputer nicht konkurrieren. Andererseits kann der bereits erw¨ ahnte Supercomputer, der f¨ ur wissenschaftliche Anwendungen verwendet wird, sehr viele arithmetische Vektoroperationen – meist Fließkomma-Operationen – pro Sekunde ausf¨ uhren. Diese Computer werden auch oft Numbercruncher“ (Zah” lenfresser) genannt. Ein Mikroprozessor f¨ ur Eingebettete Systeme muss in der Lage sein, komplizierte Berechnungen innerhalb gewisser Zeitgrenzen auszuf¨ uhren, falls er beispielsweise als Dekoder/Encoder f¨ ur Videodatenstr¨ ome eingesetzt wird. Computer-Performanz wird daher mit Hilfe von Benchmarks“ ( Richtwert“, in un” ” serem Sinne aber Vergleichstest“) gemessen. Die Standard Performance Evaluation ” ” Corporation“ (SPEC) [Spec] ist eine Non-Profit Organisation“, die Benchmarks, also ” Vergleichstests zur Leistungsbewertung von Computer-Hardware und auch von Software entwickelt. Der Benchmark selbst ist jedoch kostenpflichtig. Diese Benchmarks sind meist Benchmark Suites“, Sammlungen von verschiedenartigen Programmen, die den ” Computer nicht nur in Bezug auf Ganzzahl-Rechnungen, sondern auch FließkommaZahlen- und Vektor-Berechnungen testet. Die popul¨are SPEC92“-Suite [HenPat07] ” war einer der ersten Vergleichstests. Die SPEC bringt in bestimmten Zeitabst¨anden aktualisierte Benchmarks f¨ ur Prozessoren, Server usw. heraus. Wie wird beispielsweise ein CPU2006-Benchmark eingesetzt? Man l¨ aßt den zu testenden Prozessor die Benchmark, also die Test-Programm-Sammlung ausf¨ uhren, misst die Ausf¨ uhrungszeit, pr¨ uft die Ergebnisse und vergleicht beides mit anderen Prozessoren. Die Ergebnisse m¨ ussen nat¨ urlich gleich sein, aber die Art der Ausgabe kann verschieden sein.

3.3 Mikroprozessor-Grundlagen

47

Im Fokus des Benchmarking steht die Performanz bzw. die Ausf¨ uhrungszeit f¨ ur die L¨ osung einer bestimmten Aufgabe. Es k¨ onnen auch andere Metriken Ziel des Benchmarking sein wie z. B. der Energieverbrauch. Dabei ist wie oben bereits erw¨ahnt, darauf zu achten, dass zielgleiche Computer bzw. Prozessoren miteinander verglichen werden, also z. B. Mainframe mit Mainframe und Numbercruncher mit Numbercruncher, sonst sind die Ergebnisse irrelevant. Eine hohe Performanz wird erreicht durch Pipelining und superscalare, also parallele Befehls-Verarbeitung bei hoher Taktfrequenz (siehe Abschnitt 3.3.6), verbunden mit effektivem Caching“ (siehe Abschnitt 3.3.3). ” Energieverbrauch Vom physikalischen Standpunkt aus betrachtet, ist der Ausdruck Energieverbrauch“ ” falsch. Energie kann nicht verbraucht oder erzeugt, sondern nur umgewandelt werden. Trotzdem hat sich dieser Begriff eingeb¨ urgert und so wird er auch in diesem Buch verwendet. Bei elektronischen Systemen wird elektrische Energie verwendet, um Rechenleistung in einer bestimmten Zeitspanne zu generieren, physikalisch gesehen wird die elektrische Energie jedoch zu nahezu hundert Prozent in W¨aremenergie umgewandelt. Der Energieverbrauch von Computern und Eingebetteten Systemen erzeugt also ungewollt W¨ arme und kostet Geld. Computerzentren verbrauchen oft doppelt Energie, einerseits weil die Computer W¨ armeenergie erzeugen und andererseits weil diese Com¨ puter durch K¨ uhlung vor Uberhitzung gesch¨ utzt werden m¨ ussen. Tragbare Ger¨ ate wie z. B. Mobiltelefone, Laptops usw. sollen klein und leistungsf¨ahig (performant) sein, werden von Akkus gespeist und eine Akkuladung soll f¨ ur m¨oglichst viele Betriebsstunden ausreichen. Wie ist das zu realisieren, m¨oglichst ohne Einbuße an Performanz? Die Leistung in Watt eines Ger¨ ats berechnet sich zu: N (W att) = U ∗ I = U 2 /R

(3.2)

Die Energie in Wattstunden (Wh) die ein Ger¨ at ben¨otigt und die die Entladezeit eines Akkus bestimmt, wird berechnet zu:  P (W h) = N dt (3.3) Wenn N u ¨ber die Zeit konstant ist, vereinfacht sich die Gleichung 3.3 zu: P (W h) = N ∗ t

(3.4)

Aus Gleichung 3.2 sehen wir: der Energieverbrauch eines Ger¨ats h¨angt vom Quadrat der Versorgungsspannung des Prozessors und aller Schaltungsteile, aller Integrierten Schaltungen usw. ab. Fazit: Je kleiner die Versorgungsspannung eines Chips, desto geringer der Energieverbrauch. Beispiel: Eine Reduktion der Drainspannung Udd von 5 V auf 3,3 V bringt (5/3, 3)2 = 2,3, d. h. eine 2,3-fache Ersparnis des Energieverbrauchs. Dennoch darf die Versorgungsspannung nicht zu klein gehalten werden; denn zwischen der logischen 0

48

3 Mikroprozessor-Grundlagen

(Spannung 0V) und der logischen 1 (etwa Versorgungsspannung) muss ein f¨ ur den Logikbaustein sicher erkennbarer Unterschied sein, der auch durch Toleranzen in der Schwelle zwischen 0 und 1 nicht beeintr¨ achtigt wird. Die St¨orsicherheit der Schaltung h¨angt ebenfalls von der H¨ ohe der Versorgungsspannung ab. Je h¨oher die Drainspannung, desto h¨ oher die St¨ orsicherheit. Bei h¨ oherer Drainspannung m¨ ussen die St¨orimpulse h¨oher sein, die f¨ alschlicherweise in einem Logikgatter eine Umwandlung einer 0 in eine 1 – und umgekehrt – verursachen k¨ onnen. Bei Integrierten Schaltungen (ICs) in CMOS-Technologie verursacht eine Ladungs¨ande¨ rung die Anderung des Ausgangswerts eines Gatters von der logischen 0 nach 1 und umgekehrt, die einen Energieverbrauch bedeutet. Eine niedrigere Taktfrequenz ¨andert den gesamten Energieverbrauch f¨ ur einen bestimmten Programmablauf nicht, jedoch spart z. B. das Abschalten der Taktfrequenz im Leerlauf (clock gating) Energie. Die sogenannten Leckstr¨ ome sind eine weitere Ursache f¨ ur den Energieverbrauch eines IC: Ladungen fließen an den Gattern oder an den Drains“ von CMOS-Transistoren ab. ” Dies kann man nur verhindern durch Abschaltung oder Reduzierung der Versorgungsspannung in den Pausen. Um den Energieverbrauch von Computern und tragbaren Ger¨aten zu senken, wird ein Power Management“ bzw. ein Power Manager“ eingesetzt. Man unterscheidet zwi” ” schen statischem Power-Management“ und dynamischem Power-Manage” ” ment“. Das statische Power-Management schaltet beispielsweise durch eine Unterbrechung (Interrupt), den Computer/das Eingebettete System in den Power-down-Modus“, wenn ” der Prozessor eine bestimmte Zeit still steht. Beim dynamischen Power-Management werden Teile des Prozessors angehalten, wenn sie w¨ ahrend der Ausf¨ uhrung des Prozessors nicht ben¨otigt werden. Global System State G0 Working G1 Sleeping

Power Consumption Large Smaller

G2 Soft off

Very near zero

G3 Mechanical off

Zero

Description full on Sleeping has 5 substates: S1 ...S4 SW and OS is off OS restart required System switched off

Tabelle 3.6: Globale System-Zust¨ ande bei der Leistungsverbrauchs-Steuerung nach dem APCIStandard. SW bedeutet Software, OS: Operationg system. Modifiziert nach [APCI11].

Advanced Power Management (APM) und Advanced Configuration and Power Interface Specification (APCI) sind Standards die die LeistungsverbrauchsSteuerung (Power Management) f¨ ur den Personal Computer (PC) spezifizieren. Der altere APM-Standard aus dem Jahre 1990 wurde 1996 abgel¨ost durch die APCI-Spezi¨ fikation, der von mehreren Firmen zum Beispiel Hewlett Packard, Microsoft, Intel usw. herausgegeben und gepflegt wird [APCI11]. Die APCI-Spezifikation schließt das Betriebssystem in das Power Management mit ein und unterteilt das globale System“ in ”

3.3 Mikroprozessor-Grundlagen

49

Untersysteme zum Beispiel System Power Management, Device Management, Processor Management usw. Tabelle 3.6 zeigt die Globale Leistungs-Verbrauchs-Zust¨ande G0 bis G3. Je h¨ oher die Zustandsnummer, desto geringer ist der Leistungsverbrauch. G1, als Sleeping-Zustand bezeichnet, wird in die Unterzust¨ande S1 bis S4 unterteilt. Auch die Leistungsverbrauchs-Zust¨ ande f¨ ur den Prozessor, (CPU States C0 bis Cn) und f¨ ur die ¨ einzelnen Ger¨ ate (D0 bis D3) werden unterteilt. Uber das BIOS wird dem Betriebssystem in Tabellen Auskunft u ¨ber die angeschlossenen Ger¨ate, ihre LeistungsverbrauchsZust¨ ande und die Steuerbefehle gegeben, mit denen in die verschiedenen Zust¨ande geschaltet wird. Die APCI-Spezifikation ist eine Richtlinie nicht nur f¨ ur tragbare Ger¨ate wie Laptops und Notebooks, die besonders auf geringen Energieverbrauch angewiesen sind, sondern auch f¨ ur station¨ are, an die Stromversorgung angeschlossene PCs. Ein Personal Computer ist allerdings ein u ¨bergeordnetes System, das Untersysteme wie Monitor, Tastatur, Maus usw. enth¨ alt, deren Steuerungen Eingebettete Systeme sind. Prun = 400 mW

Run 10μs

90μs 10μs

Idle Pidle = 50 mW

160μs

90μs

Sleep Psleep = 0.16 mW

Abbildung 3.14: Leistungs-Zustands-Automat (Power State-Machine) des StrongARMT M SA-1100. Die Leistungs-Zust¨ ande sind: RUN“, Idle“ und Sleep“ ([Ben00], zitiert in ” ” ” [Wolf02]).

Beispiel: Power-Management beim StrongARMT M SA-1100 Die Leistungs-Spar-Modi eines Prozessors k¨ onnen durch eine Leistungs-Zustands-Auto” maten“ (Power State Machine [Ben00], zitiert in [Wolf02]) dargestellt werden (siehe Abbildung 3.14). Die Leistungs-Zust¨ ande und die dazugeh¨origen Leistungen sind: Run“: ” Normaler Ausf¨ uhrungsmodus: Leistung N=400 mW, Idle“: Leerlauf, N=50 mW und ” Sleep“: N=0,16 mW. Die Umschaltzeiten von einem Modus in den anderen sind an ” den Zustands¨ uberg¨ angen angegeben. Details der einzelnen Leistungs-Sparmodi sind: • Idle“: Leerlauf Modus: Der Prozessor-Takt ist abgeschaltet, folgende System” Einheiten bleiben eingeschaltet: Real-time clock: Echtzeit-Uhr, Operating System Timer: Zeitgeber f¨ ur das Betriebssystem, General Purpose I/O: MehrzweckEingabe/Ausgabe und Power-Manager. Der Prozessor kehrt zum Run“-Modus ” zur¨ uck durch ein Unterbrechungs-Signal (Interrupt) von einem der internen Sys-

50

3 Mikroprozessor-Grundlagen tem-Einheiten oder von einer peripheren Einheit oder durch einen Prozessor- Re” set“ (Der Prozessor wird zur¨ uckgesetzt). Dadurch wird der Prozessor-Takt wieder eingeschaltet und der Prozessor macht an dem Punkt weiter, an dem er in den Leerlauf geschaltet wurde. • Sleep“: Schlaf“-Modus: Alle Aktivit¨ aten auf dem Prozessor-Chip werden ausge” ” schaltet. Der Prozessor wird zur¨ uckgesetzt. Die Externe Logik erh¨alt ein Signal, das die Stromversorgung des Prozessors auf 0 V zur¨ uckgefahren werden soll. Eine separate I/O-Stromversorgung bleibt eingeschaltet und versorgt den PowerManager, damit der Prozessor wieder vom Sleep-Modus aufgeweckt werden kann. Ein langsamer Takt treibt den Power-Manager, sodass der Sleep-Modus erhalten werden kann.

3.3.8

Ein-Ausgabe-Ger¨ate und Schnittstellen

Im Rahmen dieses Buches kann auf Ein-Ausgabe(E/A)-Ger¨ate nicht ausf¨ uhrlich eingegangen werden. Wir beschr¨ anken uns auf die Aufz¨ahlung folgendender E/A-Ger¨ate und verweisen sonst auf die entsprechende Grundlagen-Literatur: • Zeitglieder (Timer) und Z¨ ahler: basieren auf Addierer- und Schieberegisterlogik. • Analog-Digital- (A/D) und D/A-Wandler werden sehr h¨aufig in Eingebetteten Systemen eingesetzt. Siehe Beispiel Abbildung 1.3, Seite 6. • Tastaturen (Keyboards) • Anzeigeger¨ ate – LEDs – Hexadezimal-Anzeigen – Br¨ uhrungs-Bildschirme (Touchscreens, siehe [Wolf02]) • Kartenleser – Magnetstreifen-Kartenleser (Beispiel f¨ ur eine Kartenleser-StateChart siehe Abbildung 5.28, Seite 165) – Chipkartenleser – Speicherkartenleser Schnittstellen zu E/A-Ger¨ aten: H¨ aufig sind die E/A-Ger¨ate an einem Bus angeschlossen (siehe Kapitel 4). Ein Beispiel f¨ ur die Schnittstellen-Anpassung an einen einfachen Bus zeigt Abbildung 3.15 nach [Wolf02]. Im Bild 3.15 links ist der Bus angedeutet mit der Steuerleitung RW’, dem Datenleitungsb¨ undel und dem Adressleitungsb¨ undel. Das Ger¨at, angedeutet rechts im Bild, hat 4 Register: Reg 0 bis Reg 3, die gelesen und geschrieben werden k¨onnen (siehe Abschnitt 3.3.8). Die Steuerleitung f¨ ur das Schreiben bzw. Lesen der Register: RW’ ist low aktiv“, ” d. h. ist die Leitung aktiviert, so steht sie auf der logischen Null“ sonst auf Eins“. Das ” ”

3.4 Mikrokontroller und Mikroprozessoren

51

Bus: R/W‘ Daten Adresse

Gerät

Register Lesen

& Adr.[0:1] Adr.

R/W‘

Reg 1 Reg-ID

=

Komparator: Geräte-Adr.

Transceiver (Bus-Treiber)

Reg 0

Reg 2 Reg 3

Reg-Value

R/W‘

Abbildung 3.15: Beispiel einer Schnittstellen-Anpassung eines E/A-Ger¨ ats (Glue-Logic, nach [Wolf02]).

Ger¨ at wird identifiziert u ateadresse, die an die Adressleitungen des Prozessor ¨ber die Ger¨ angelegt wird, wobei die niedrigsten beiden Bits der Adresse die Registernummer angeben. Die oberen Bits der Adresse werden von einem Komparator auf die Ger¨ateadresse u uft. Die Ger¨ ateadresse wird in der Regel u ¨berpr¨ ¨ber Mikroschalter am Ger¨at eingestellt. Erkennt der Komparator die Ger¨ ateadresse, so wird der Transceiver aktiviert, der je nach Polarit¨ at der RW’-Leitung Daten u ¨ber die Datenleitungen in die Register (Reg-Value) u agt oder umgekehrt [Wolf02]. ¨bertr¨

3.4

Mikrokontroller und Mikroprozessoren

Was versteht man unter Mikrokontrollern im Gegensatz zu Mikroprozessoren? Mikrokontroller (MK, Microcontroller, MCU, μController, μC) sind Mikroprozessoren auf einem Chip, die f¨ ur spezielle Anwendungen zugeschnitten sind. Sie werden in einem Eingebetteten System einmal daf¨ ur programmiert und behalten auf Lebenszeit diese Funktion bei [BriUng10]. Meist verf¨ ugt ein Mikrokontroller u ¨ber spezielle Peripheriefunktionen, der Arbeits- und Programmspeicher befindet sich ebenfalls teilweise oder komplett auf dem gleichen Chip. Die Grenze zwischen Mikrokontrollern und Mikroprozessoren ist fließend. In vielen F¨ allen wurden im Laufe der Entwicklung bei einem klassischen Mikroprozessor die sogenannten Unterst¨ utzungs- und Peripheriebausteine wie Takt- und ResetErzeugung, Interruptkontroller, Zeitgeber, Schnittstellenbausteine und zum Teil auch

52

3 Mikroprozessor-Grundlagen

Speicherkontroller in den Chip selbst integriert, so dass f¨ ur ein funktionsf¨ahiges Prozessorsystem oft nur noch ein Quarz (f¨ ur den Takt) und Speicherbausteine n¨otig sind. Mikrokontroller sind traditionell f¨ ur steuerungsdominante Anwendungen (siehe Seite 176) ausgelegt. Steuerungsdominante Anwendungen sind gekennzeichnet durch: • Das Kernprogramm ist in der Regel die Verhaltensbeschreibung eines Zustandsautomaten (FSM, siehe Abschnitt 5.7.5) und enth¨alt relativ viele Verzweigungen und Spr¨ unge. • Das Kernprogramm enth¨ alt wenig arithmetische Operationen, daf¨ ur h¨aufiger Bitund Logikoperationen • An die Geschwindigkeit werden meist keine hohen Anspr¨ uche gestellt Daher sind Mikrokontroller meist optimiert auf Bit- und Logikoperationen [TeiThi03].

3.4.1

Niedrigpreis-Mikrokontroller

Mikrokontroller werden h¨ aufig bei kleinen Board-Serien f¨ ur Eingebettete Systeme eingesetzt, die schnell auf den Markt kommen m¨ ussen. Die gefertigten St¨ uckzahlen f¨ ur Mikrokontroller sind hoch. Da wie gesagt, keine hohen Anspr¨ uche an die Geschwindigkeit gestellt werden, wird auch nicht die neueste Technologie verwendet und erm¨oglicht dadurch einen relativ geringen Preis. Bei einer Bestellung von sehr hohen St¨ uckzahlen kann der Preis eines einfachen Mikrokontrollers in der Gr¨oßenordnung von einigen Cent liegen. Die typischen Eigenschaften solcher Niedrigpreis-Mikrokontroller sind: • Die Wortbreite bei ¨ alteren Generationen betr¨agt 4, 8 bis 16 Bit. Ab 32 Bit spricht man von Mikrokontrollern h¨ oherer Leistung (siehe unten). • Im Befehlssatz sind Zugriffsoperationen auf die Peripherie integriert. • Die Register sind h¨ aufig im RAM realisiert. • Die Interruptverz¨ ogerungen sind relativ hoch, sie liegen im Bereich von 1 Mikrosekunde. • Die Rechnerleistung (Performanz) ist relativ gering, etwa im Bereich 1 Mikrosekunde/Befehl (Taktrequenz: 1MHz). Ein Klassiker unter den Niedrigpreis-Mikrokontrollern ist der Intel 8051. Die Architektur dieses Typs ist in vielen auf dem Markt befindlichen Mikrokontrollern in Abwandlungen und Erweiterungen realisiert, z. B. Siemens 88C166, Philips 83C552, Atmel ATC51xx, ARM-M0 als IP usw. Die Eigenschaften des 8051 sind [TeiThi03]: • Es ist ein 8-Bit CISC-Prozessor (siehe Abschnitt 3.3.1), die Register und die Daten sind 8 Bit breit. Die Adressbreite betr¨ agt 16 Bit.

3.4 Mikrokontroller und Mikroprozessoren

53

• Die Register liegen im RAM. Es sind 8 Registerb¨anke mit je 8 Registern. Die Umschaltung der Registerb¨ anke geschieht durch Interrupts oder Unterprogramme. • Eingabe/Ausgabeports haben ihren separaten Adressraum. Es gibt Spezialbefehle f¨ ur den Zugriff auf E/A-Ports, sogar auf einzelne Bits. • Es gibt mehrere Power-Down-Modi“. ”

3.4.2

Mikroprozessoren h¨oherer Leistung

Mikrokontroller h¨ oherer Leistung verf¨ ugen meist u ¨ber mehrere Prozessoren mit 32 oder 64-Bit Prozessorkernen. Sie sind konzipiert f¨ ur Systeme mit h¨oheren Berechnungsanforderungen z. B. f¨ ur Signalverarbeitung, Regelungstechnik, Echtzeitanforderungen und auch f¨ ur die Verarbeitung von Datenstr¨omen z. B. in steuerungsdominanten Aufgaben, Telekommunikation, in der Kraftfahrzeugtechnik, Multimedia-Anwendungen wie z. B. Video-Anwendungen hoher Qualit¨ at. usw. [TeiThi03]. Neben den Prozessoren enthalten Mikrokontroller h¨ oherer Leistung oft mehrere Busse, Speicherkomponenten: ROM, RAM, Flash-Speicher, EPROM sowie periphere Einheiten wie z. B. ZeitgeberEinheiten (Time Processing Unit), Serielle Eingabe/Ausgabe (Serial I/O), Direct Memory Access (DMA), usw. Jedes Systemhaus bietet unterschiedliche MikrokontrollerFamilien an. Digitalen Signalprozessoren DSPs F¨ ur datenflussdominante bzw. datendominante Systeme und Datenverarbeitung von Datenstr¨ omen wie z. B. bei Video- und Multimedia-Anwendungen werden Digitale Signalprozessoren (DSPs) eingesetzt. Sie m¨ ussen in der Lage sein, komplexe arithmetische Operationen, z. B. f¨ ur digitale Filter, Fast Fourier Transformation (FFT), MatrizenOperationen, Bildverarbeitung usw. in Echtzeit auszuf¨ uhren. Digitale Signalprozessoren sind optimiert f¨ ur [TeiThi03]: • Festkomma- u. Gleitkomma-Operationen, f¨ ur Multiplikationen. • Parallel-Befehle, Wortl¨ angen: 16, 32, 64 Bit. • Mehrprozessor-Syteme und Systeme mit Koprozessoren. Trends bei DSPs sind: VLIW (very long instruction word)-Architekturen.

3.4.3

Mikroprozessor-Familien

Im Folgenden nennen wir einige Beispiele von Mikroprozessoren mit ihren Eigenschaften. Die Autoren weisen darauf hin, dass es nicht in ihrer Absicht liegt, Werbung f¨ ur die genannten Firmen zu machen. Es soll vielmehr die Vielfalt der Eigenschaften von verf¨ ugbaren Mikroprozessoren und Mikrokontrollern gezeigt werden. Der Entwickler ist angehalten, sich auf dem Markt auch bei anderen Firmen kundig zu machen. Zudem wird nicht der Anspruch erhoben, dass die Auswahl der erw¨ahnten Prozessoren repr¨ asentativ ist. M¨ oglicherweise werden nach dem Erscheinen des Buches einige der erw¨ ahnten Prozessoren nicht mehr auf dem Markt verf¨ ugbar sein.

54

3 Mikroprozessor-Grundlagen

Performanz

Die ARM-Prozessorfamilie Bei Eingebetteten Systemen nimmt die Prozessorfamilie der Firma ARM eine f¨ uhrende Rolle ein. Die Firma ARM hat ihren Ursprung im britischen Unternehmen Acorn, in dem 1983 die sehr erfolgreiche Acorn Risc-Machine“-Architektur entwickelt wurde. ” Acorn gr¨ undete 1990 zusammen mit Apple und VLSI Technology die Firma Advanced Risc Machines Ltd. (ARM). Die Firma ARM produziert die Prozessor-Chips nicht selbst, sondern verkauft Intellectual-Property-Lizenzen (IP-Lizenzen) zusammen mit Entwicklungsdokumentation und Entwicklungswerkzeugen. Das heißt, der Kunde der eine ARM-Prozessor-Lizenz erwirbt, kauft die Beschreibung eines ARM-Prozessor-Typs mit der dazugeh¨ origen ARM-Peripherie in der Beschreibungssprache VHDL (siehe Abschnitt 6.1) oder in Verilog und entwickelt mit dem Prozessor und mit eigenen Komponenten ein Ein-Chip-System (SoC).

Cortex-A15 Für rechenintensive Anwendungen

Cortex-A9

Cortex-A5 Die klassische ARM-Familie Cortex-R7 ARM11 ARM9 ARM7

Cortex-R4 Cortex-M4

Cortex-M0

Für Echtzeitanwendungen ARM-Mikrokontroller Anzahl Funktionen

Abbildung 3.16: Die ARM-Prozessor-Familien, verk¨ urzt dargestellt (nach [ARM12]).

Ein Hinweis auf die Beliebtheit der ARM-Prozessoren sind die vielen ARM-Lizenznehmer in der Halbleiterindustrie. Beispiele daf¨ ur sind: Analog Devices, Atmel, Broadcom, Cirrus Logic, Energy Micro, Faraday Technology, Freescale, Fujitsu, Intel, IBM, Infineon, Nintendo, NXP Semiconductors, OKI, Qualcomm, Samsung, Sharp, STMicroelectronics, Texas Instruments. Die St¨ uckzahlen der bisher verkauften ARM-Lizenzen liegen im zweistelligen Milliardenbereich (2012). Die ARM-Prozessor-Architektur basiert auf einem 32-Bit-RISC-Prozessor mit Load/Store-Architektur (siehe Abschnitt 3.3.1) und einem relativ großen 16×32 Bit Registersatz. Beispiele des Befehlssatzes dieser Prozessor-Architektur zeigen die Tabellen 3.1, 3.2 und 3.5. Diese Befehlsfolgen sind auf allen ARM-Prozessoren ausf¨ uhrbar. Die Abbildung 3.16 zeigt eine vereinfachte Zusammenstellung der ARM-Prozessorfamilien (nach [ARM12]), eingezeichnet u ¨ber der Performanz und der Anzahl Funktionen die die einzelnen Prozessorfamilien aufweisen k¨ onnen.

3.4 Mikrokontroller und Mikroprozessoren

55

Die klassische ARM-Prozessorfamilie besteht aus den Typen ARM7 bis ARM11. Sie wurde etwa ab dem Jahre 2005 abgel¨ ost durch die ersten ARM-Cortex-Typen. Etwa j¨ ahrlich kommen neue Cortex-Typen hinzu. Die ARM-Cortex-Typen sind aufgeteilt in die Unterfamilien“ Cortex-M, Cortex-R und Cortex-A. Jede Unterfamilie ist durch ” einen bestimmten Prozessorkern gekennzeichnet, beispielsweise Cortex-M1 enth¨alt den Prozessorkern M1, Cartex-A15 ist ein Typ der Familie A mit den Dual- oder Quad-CoreProzessorkernen A-15. Jeder Prozessorkern unterscheidet sich in mehreren Punkten von den anderen Typen. Beispielsweise in der Stufenzahl der Pipeline (siehe Abschnitt 3.3.6), in der Anzahl der Caches, in der Cache-Anordnung usw. Im Folgenden werden die einzelnen Prozessorfamilien etwas n¨ aher beschrieben. Cortex-M0 Components

Cortex-M0 Processor Nested Vectored Interrupt Controller (NVIC)

+Wakeup Interrupt Controller (WIC)

+ Optionale Komponenten

Debug Cortex-M0 Processor core

+Breakpoint and Watchpoint Unit

Bus Matrix

+Debugger Interface

AHB-Lite Interface

+Debugg Access Port

Serial- or JTAG-Interface

Abbildung 3.17: Blockdiagramm des einfachsten Cortex-Prozessors, des Cortex-M0 (aus ARM-Datenbl¨ attern [ARM12]).

Die Cortex-M-Prozessoren Die Cortex-M-Familie umfasst die ARM-Mikrokontroller. Der Cortex-M0-Prozessor ist der kosteng¨ unstigste und der kleinste“ Prozessor der ARM-Familien, das heißt, nach ei” ner Synthese und Implementierung nimmt er die kleinste Chipfl¨ache ein, verglichen mit anderen Typen aus den Cortex-Familien. Verf¨ ugbar sind außer Typ M0 die Typen M1, M3 und M4 (2012). Die Pipeline der Cortex-M-Familie ist drei-stufig (siehe Abbildung 3.10). Die Abbildung 3.17 zeigt das Blockdiagramm des Cortex-M0-Prozessors. Die mit +“ bezeichneten Komponenten sind optional und k¨onnen f¨ ur zus¨atzliche Lizenzen bezo” gen werden. Der Cortex-M0-Prozessor enth¨ alt den Prozessor-Kern, die Unterbrechungssteuerung, den Nested Vectored Interrupt Controller NVIC“ und die Bus-Matrix, das ” heißt die Bus-Anschlussstelle, die die Schnittstelle zum AHB-Lite-Bus bildet. AHB steht f¨ ur Advanced High-Performance-Bus“, der ein Teil des AMBA-Bussytems ist (siehe ” ¨ Abschnitt 4.2.2). AHB-Lite ist eine Untermenge des AMBA-Systems. Uber den Bus kann zum Beispiel auf einen Speicherblock oder auf andere Komponenten zugegriffen werden. Die Debug-Einheit ist ebenso wie der Wakeup Interrupt Controller (WIC)“ ” optional. Der Wakeup Interrupt Controller weckt den Prozessor bei einem Interrupt auf, wenn dieser im Sleep“-Energiespar-Modus liegt (siehe Abschnitt 3.3.7). Der De”

56

3 Mikroprozessor-Grundlagen

bug Access Port kann an eine serielle Schnittstelle oder an eine JTAG-Test-Schnittstelle (siehe Abschnitt 5.11.4) angeschlossen werden. Die Cortex-M Prozessoren werden beispielsweise verwendet f¨ ur Haushaltsger¨ ate-Steuerungen, in der Automobilindustrie f¨ ur nicht-zeitkritische Steuerungen, f¨ ur einfache industrielle Kontrollsysteme, f¨ ur Spiele, Sensor-, Touch-Screen- und Power-Management-Anwendungen. Die Cortex-R-Prozessoren Die Cortex-R-Familie (R wie Real Time) wird f¨ ur Echtzeitsysteme eingesetzt. Der Prozessor, insbesondere die Pipeline-Steuerung ist so ausgelegt, dass die Ausf¨ uhrungszeiten der Instruktionen vorhersagbar sind und damit kann die Ausf¨ uhrungszeit f¨ ur BasisProgrammbl¨ ocke zuverl¨ assig berechnet werden. Verf¨ ugbar sind 2012 die Cortex-R-Typen R4, R5, R7. Die Prozessor-Taktrate reicht bis 1GHz. Die Cortex-R-Prozessoren basieren auf einer Protected Memory“ System-Architektur. Das heißt, dass die Speicher f¨ ur ” das Betriebssystem einschließlich sensitiver Daten und Tabellen in einem gesch¨ utzten Bereich liegen, so dass Benutzer und Benutzerprogramme darauf nicht zugreifen und den Systembetrieb st¨ oren k¨ onnen. Anwendungsbereiche f¨ ur die Cortex-R-Familie sind beispielsweise Echtzeitanwendungen im Automobilbau wie das Bremssystem und die Motorsteuerung, zuverl¨assige Systemsteuerungen in der Medizin, in Netzwerken, in Druckern, Ger¨atetreibern f¨ ur Festplattensteuerungen, Smartphones, PDAs usw. APB

ATB

Interrupts

Timer Events

Debug/CTI

Trace

GIC (optional)

Generic Timer Non-processor/miscellaneous

Processor 0

Processor 1

Processor 2

Processor 3

L1 L1 TLBs ICache DCache

L1 L1 TLBs ICache DCache

L1 L1 TLBs ICache DCache

L1 L1 TLBs ICache DCache

Slave

Snoop

Master

Snoop Tag RAM

L2 cache

Non-processor/Level 2

Abbildung 3.18: Beispiel-Blockdiagramm einer Mehrprozessor-Konfiguration des Cortex-M15 (aus ARM-Datenbl¨ attern [ARM12]).

Die Cortex-A-Prozessoren Die Cortex-A-Familie (A wie Application) zielt auf Eingebettete Systeme mit rechenintensiven Anwendungen und besteht aus den Typen A5, A7, A9 und A15 (2012). Sie basiert auf einer Mehrprozessor-Technologie mit zwei bis vier Prozessorkernen, auch Erweiterungen zu acht oder gr¨ oßeren Konfigurationen sind m¨oglich. Die Cortex-A-Familie

3.4 Mikrokontroller und Mikroprozessoren

57

unterst¨ utzt eine virtuelle Speicherverwaltung (Virtual Memory, siehe Abschnitt 3.3.6). Der Cortex-A15 schließt zur Zeit das obere Ende der Cortex-Familien mit h¨ochster Leistung und guter Energieeffiziez ab [ARM12]. Durch die 13-stufige Out-of-Order” Pipeline“-Steuerung kann die Reihenfolge der Instruktionen durch Umsortierung“ neu ” geordnet und dadurch optimiert werden, macht es aber andererseits unm¨oglich, f¨ ur komplexe Instruktionen eine zuverl¨ assige Ablaufzeit-Vorhersage durchzuf¨ uhren wie es f¨ ur Echtzeitanwendungen n¨ otig ist. Die Prozessor-Taktrate betr¨agt bis zu 2,5 GHz. Beispiele von Anwendungsbereichen f¨ ur die Cortex-A-Familie sind: • Mobiles Computing und Smartphones. • F¨ ur DSP-Anwendungen digitaler Heimger¨ate, zum Beispiel Set-top-Boxen und digitales Fernsehen (HDTV). • F¨ ur Laserjet-Drucker-Steuerungen. • Web 2.0 Server mit virtuellem Speichermanagement und Router. • Automotives Infotainement, Navigationssysteme. • Drahtlose Infrastruktur (z. B. WLAN) mit virtuellem Speichermanagement und Unterst¨ utzung f¨ ur bis zu 1 TB Daten. Die Abbildung 3.18 (aus [ARM12]) zeigt ein Beispiel-Blockdiagramm einer Multiprozessor-Konfiguration des Cortex-M15 mit vier Prozessorkernen. Die Abk¨ urzungen im Bild bedeuten: Der AMBA Peripherals Bus“ APB (siehe Abschnitt 4.2.2) ist die Schnittstel” le zu den Peripherie-Komponenten. ATB ist die AMABA-Bus-Schnittstelle f¨ ur Traces“ ” (siehe Abschnitt 5.9.6). GIC bedeutet Global Interrupt Controller“. Timer sind Zeit” geber, hier kann man Zeitintervalle vorgeben, zum Beispiel f¨ ur Sensorabfragen usw. Die Cortex-A-Familie verf¨ ugt u ¨ber zwei Caches (siehe Abschnitt 3.3.3), den Level 1und den Level-2-Cache. In der Abbildung ist f¨ ur den Level-1-Cache die Unterteilung in den Instruktions-Cache (ICache) und den Daten-Cache (DCache) gezeigt. ACE ist die Abk¨ urzung f¨ ur AXI Coherency Extension“, das bedeutet eine Schnittstelle des ” AMBA-AXI-Bus (siehe Abschnitt 4.2.2). ACP bedeutet Accelerator Coherency Port“ ” f¨ ur eine Slave-Schnittstelle“. Beide Schnittstellen (ACP und ACE) unterst¨ utzen eine ” Datenbreite von 64-Bit oder 128-Bit [ARM12]. onnen in diesem Rahmen nur einen kleinen Ausschnitt aus dem Sortiment der Wir k¨ ARM-Prozessor-IPs vorstellen. Wer sich weiter informieren will, kann die Internetseiten der Firma ARM [ARM12] besuchen. Die Prozessor-IPs von ARM sind f¨ ur die Integration in Ein-Chip-Systemen (SoCs) gedacht. Wer allerdings einen Prozessor f¨ ur sein Prototypen-Board ben¨ otigt, m¨ usste sich prim¨ ar bei den folgenden Prozessor-Familien umschauen, die Hardware-Module anbieten. Die Atmel-Prozessorfamilie Eine sehr beliebte Familie von Mikrokontrollern ist die Familie der AtmelT M -Prozessoren. Die Firma Atmel Corporation wurde im Jahre 1984 in San Jose in Kalifornien gegr¨ undet und begann seine Erfolgsserie mit Mikrokontrollern, die auf Intels 8051Architektur (siehe Abschnitt 3.4.1) basieren.

58

3 Mikroprozessor-Grundlagen

Atmel liefert Prozessormodule mit integrierten Peripheriekomponenten angefangen bei der sehr kleinen ATtiny“-Serie in Dual-in-Line-Modulen mit 2 × 3 Anschl¨ ussen (Pins) ” bis zu quadratischen Modulen mit mehr als 100 Pins. Atmel produziert zudem unter anderem nicht-fl¨ uchtige Halbleiterspeicher, ROMs und Flash-Speichers, die in AtmelProzessoren eingesetzt werden. Die Anwendungsgebiete sind: Automotive Anwendungen (z. B. CAN-Contoller siehe Abschnitt 4.5.2), Haushaltsger¨ ate, Heim-Multimedia, Industrie-Automation, Medizinische Ger¨ ate, Lichtsteuerungen, Mobilfunk-Ger¨ate, Messger¨ate und viele weitere. Atmel bietet auch einige Sondertypen an, Spezialmodelle, zum Beispiel zur Ansteuerung von Akkumulator-Ladeger¨ aten, LC-Displays und f¨ ur Motorensteuerungen. Atmel unterteilt das Lieferprogramm in [Atmel12]: • Mikrokontroller der 8051-Architektur. • Atmel AVR 8-Bit und AVR-32-Bit Prozessoren. • Mikrokontroller (MCUs) f¨ ur Mobilfunk-Ger¨ate. • ARM-based-Solutions: Prozessoren, die auf der ARM-M3- und ARM-M4-Architektur basieren (siehe Abschnitt 3.4.3). Mikrokontroller der ATMEL-8051-Architektur Die auf dem Intel 8051-basierenden Module der Bezeichnung ATP8LPxx“ werden ” Flash ISP - Single Cycle Core“-Module genannt. ISP steht f¨ ur In System Program” ” ming“, das heißt, der Prozessor kann beim Laden u ¨ber eine serielle, JTAG-(siehe Abschnitt 5.11.4) oder USB-Schnittstelle auf dem Board-System verbleiben. Flash“ steht ” f¨ ur einen nicht-fl¨ uchtigen Halbleiterspeicher, der wiederbeschreibbar ist und Single Cycle bedeutet, dass die meisten Instruktionen in einem Prozessortakt-Zyklus ausgef¨ uhrt werden, im Unterschied zum historischen 8051-Prozessor, der daf¨ ur 12 Taktzyklen ben¨otigte [Atmel12]. Beispiel: Der Prozessor AT89LP214 am kosteng¨ unstigen Ende“ der Atmel” 8051-Serie hat eine Taktfrequenz von 20 MHz, max. 12 I/O-Pins, einen UART (Universal Asynchrouneous Receive Transmit) als Daten¨ ubertragungsschnittstelle, zwei Zeitgeber (Timer) und 2 kBytes Flash-Speicher. Am oberen Ende der 8051-Reihe liegt der Prozessor AT89LP6440 mit unter anderem 64 KBytes Flash-Speicher, mit einer Taktfrequenz von ebenfalls 20 MHz, max. 38 I/O Pins, einem SPI (Serial Peripheral Interface)-Bus, einem I 2 C-Bus-Anschluss (siehe Abschnitt 4.5.1), einem UART, 8 ADC (Analog-Digital-Wandler)-Kan¨ale mit 10 Bit Aufl¨osung. Mikrokontroller der AVR 8-Bit und AVR 32-Bit-Architektur Die Atmel AVR-Serie basiert auf einer einfachen energieeffizienten RISC-Architektur. Die Atmel-AVR-Mikrokontroller erfreuen sich auch bei Programmierern großer Beliebtheit, weil sie leicht in der Programmiersprache C programmierbar sind und u ¨ber einen effektiven C-Compiler verf¨ ugen. Die Programme sind bei den meisten Typen In-System” Programming“-ladbar (siehe oben). Atmel teilt die AVR-8 und AVR-32-Typen wie folgt ein: ATtiny AVR 8-Bit-Typen, ATmega 8-Bit-Mega AVR, AXMega 8/16-Bit AVR und Atmel 32-Bit AVR. Bei den ATtiny AVR 8-Bit-Typen gibt es insgesamt etwa 35 Typen (2012). Es ist der Typ mit den

3.4 Mikrokontroller und Mikroprozessoren

59

kleinsten Chipabmessungen. Der kleinste Chip misst 1, 5 × 1, 4 mm und kann in kleine Systeme integriert werden. Am kosteng¨ unstigen Ende der Reihe steht zum Beispiel der 8-Bit-AVR-Mikrokontroller ATtiny4, als Steuerung f¨ ur einen ber¨ uhrungslosen Schalter mit 500 Bytes Flash-Speicher, 6 Pins am DIP-Modul, 12 MHz max. Taktfrequenz. Ein Beispiel am oberen Ende der Reihe ist der 8-Bit-AVR-Mikrokontroller ATtiny167 f¨ ur acht ber¨ uhrungslose Schalter mit 16 kBytes Flash-Speicher, 20 Pins, mit maximaler Taktfrequenz 16 MHz und 16 externen Interrupts. Auch die ATmega 8-Bit-Mega AVR-Typen sind f¨ ur ber¨ uhrungslose Schalter bestimmt. Sie haben mehr Schalterkan¨ ale, mehr Speicherplatz und mehr Anschluss-Pins. Es gibt davon u ¨ber 100 Typen. Die AXMega 8/16-Bit AVR-Mikrokontroller mit mehr als 40 Typen werden als Vielzweck-Mikrokontroller f¨ ur Echtzeitanwendungen eingesetzt. Die Ausf¨ uhrungszeit ist berechen- und vorhersagbar. Sie sind energieeffizient, haben DMA-Funktionalit¨at und einige Analog-Digital-Wandler. Integrierte Flash-Speicher- Speicherbausteine haben eine Kapazit¨ at von 16–384 kByte. Die Taktfrequenz betr¨agt bis zu 32 MHz. Die Atmel-32-Bit AVR-Mikrokontroller sind f¨ ur rechenintensive Anwendungen bestimmt und geh¨ oren zu einer Vielzweck-Mikrokontroller-Familie, die in sogenannte Se” ries“ aufgeteilt ist. Es gibt die A-, B-, C-, D-, L- und die Audio-Series mit jeweils 4 bis u ¨ber 10 Typen pro Serie. Zum Beispiel zielen die C-Series auf Industrieanwendungen und den Einsatz im Automobilbau ab. Die Typen k¨onnen unter anderem enthalten: eine Floating Point Unit (FPU), Ethernet-Unterst¨ utzung, Dual CAN- und LINSchnittstellen (siehe Kapitel 4), USB, PWM (Puls-Weiten Modulation), bis zu 16 AnalogDigital-Wandler und bis zu 4 Digital-Analog-Wandler (DACs). Die integrierten Speicherbausteine haben eine Kapazit¨ at von 16–512kB Flash-Speicher, 48–144 Anschluss-Pins und eine Taktfrequenz bis zu 66 MHZ. Atmel ARM-Prozessor-basierte Mikrokontroller Die Atmel ARM Based Solutions“ verwenden Prozessoren aus der ARM-Cortex-M3-, ” M4- und aus der ¨ alteren ARM9-Familie. Sie sind gedacht f¨ ur Anwendungen im Netzwerkbereich, Multimedia, Infotainment im Automobil usw. Es gibt ein zahlreiches Typenangebot mit 16 verschiedenen Unterfamilien (2012) mit der Bezeichnung SAMxx mit jeweils bis zu 14 Typen. ¨ Aus dem kleinen Uberblick u ¨ber die verschiedenen Atmel-Prozessoren, der bei weitem nicht vollst¨ andig ist, kann das umfangreiche Angebot der Atmel-Prozessor-Typen abgesch¨ atzt werden. Jeder Entwickler kann einen passenden Prozessor f¨ ur sein spezifisches Board-System finden. Philipps-Prozessoren Die Halbleitersparte der Firma Philips (Philips Semiconductors) bietet eine sehr große Menge verschiedener Halbleiterbausteine und Komponenten f¨ ur Eingebettete BoardSysteme an. Darunter sind auch eine Vielzahl von 8-Bit- und 32-Bit-Mikroprozessoren. Die preisg¨ unstigen LPC21xx-Typen implementieren einen ARM-7-Prozessorkern, die Peripherie, die Ein-Ausgabeports, die Zeitgeber, die Speicher usw. sind von Philips. Die Philips-Mikroprozessoren 80C522 und 83C522 basieren auf dem Intel-8051-Prozessorkern. Abbildung 3.19 zeigt schematisch eine vereinfachte Darstellung des Single-Chip Philips 83C552 mit wesentlichen Funktionsbl¨ ocken.

60

3 Mikroprozessor-Grundlagen Prozessor 80C51 15-Bit-Vektor Interrupt

8k8 ROM EPROM 256x8 RAM

Timer0 (16 bit)

A/D-C (10 Bit)

Timer1 (16 bit)

PWM

Timer2 (16 bit)

UART

Watchdog (T3)

I2C

W

A

T

Parallel Ports 1 - 5

Abbildung 3.19: Beispiel: Schematisch vereinfacht dargestellt: Der Single-Chip Mikrokontroller Philips 83C552 (nach [TeiThi03] und Philips-Datenbl¨ attern).

Der 83C522 ist beispielsweise gut einsetzbar, um automatisch in bestimmten Zeitabst¨anden Messungen aufzunehmen und die Messwerte in anderen Zeitabst¨anden weiter zu geben. F¨ ur die Bestimmung der Zeitabst¨ ande sind die drei Zeitgeber (Timer) zust¨andig. Der Interrupt-Vektor kann bei 15 verschiedenen Ereignissen den Prozessor unterbrechen. Beispiel f¨ ur Interrups: Von einem Kommunikationsmodul treffen Nachrichten ein oder verschiedene Sensoren setzen Informationen ab. Der Analog/Digital-Umsetzer (ADC) kann einen analogen Messwert abfragen und in einen digitalen Wert konvertieren. Die PWM-Funktion liefert einen Puls-Weiten-Modulations“-Ausgang (siehe Ab” bildung 3.19 rechts). Schickt man das PWM-Signal durch ein Tiefpassfilter, so ist die Pulsweite W proportional zu der Amplitude A des Analogsignals am Ausgang des Filters. Damit kann das PWM-Signal z. B. f¨ ur Motorsteuerungen oder f¨ ur regelbare Beleuchtungen verwendet werden. Der Watchdog“ setzt den Prozessor bei St¨ orungen oder wenn das laufende Programm ” in einer Endlosschleife verharrt, in den Anfangszustand zur¨ uck. Der UART-Ausgang ist ein serieller Port und der I2C (Inter Integrated Circuit)-Ausgang ein Anschluss an einen seriellen I2C-Bus (siehe Kapitel 4). Auf weitere Philips-Mikroprozessortypen k¨ onnen wir in diesem Rahmen nicht eingehen. Freescale-Prozessoren Die Firma Freescale (ehemals Motorola) bietet verschiedene Prozessorfamilien an, beispielsweise f¨ ur automotive Anwendungen, Mobilfunk, tragbare Medizintechnik, Druckersteuerungen usw. Die Prozessorfamilie MPC7450 mit den Typen MPC7447 bis MPC7457 basiert auf einem 32-Bit-Power-PC-RISC-Prozessorkern mit superskalerer Befehlsverarbeitung und drei Cache-Ebenen L1, L2 und L3.

3.5 Mehrprozessorsysteme

61

Ein anderes Beispiel ist der MC68322 der Firma Freescale. Es ist ein hochleistungsDrucker-Prozessor mit einem MC68000-kompatiblen EC000“-Prozessor, einem RISC” Grafik-Prozessor und einem Drucker-Video-Kontroller“ (Print Engine Video Control” ler). Er wird eingesetzt f¨ ur multifunktionale Drucker (Fax/Modem/Drucker), die sehr schnelle Bitmanipulationen erfordern (nach freescale.com). Prozessoren der Firma Texas Instruments Die Firma Texas Instruments (TI) bietet viele Mikroprozessor-Typen an, die auf ARMProzessoren basieren. TI sieht sich selbst als den gr¨oßten Produzenten von ARMbasierten Mikroprozessoren. Als Beispiel einer TI-Prozessorfamilie sei die traditionsreiche TMS320Cx-Familie herausgegriffen, die f¨ ur Digitale Signal-Prozessoren eingesetzt wird. Diese Familie besteht aus einigen verschiedenen Typen, angefangen von einfachen DSPs bis zum TMS320C80Mehrprozessor-Chip. Der Chip enth¨ alt f¨ unf voll programmierbare Prozessoren, einen 32-Bit RISC-Master-Prozessor und vier parallel laufende Prozessoren, die die Datenverarbeitungs-Aufgaben u ur Bildverarbei¨bernehmen. Der TMS320C80 wird eingesetzt f¨ tungs- und Multimedia-Anwendungen, 3-D-Grafiken, Audio-Video-Kompression und Telekommunikation. Der Compiler f¨ ur den TMS320C80 erkennt M¨ oglichkeiten f¨ ur Verarbeitungs-Parallelit¨at und plant die Abfolge der Befehle auf den Funktionseinheiten. Es wird auf geringen Energieverbrauch geachtet, Test- und Debug-Hilfen werden eingebaut. Die Programmentwicklung wird zunehmend in Hochsprachen ausgef¨ uhrt. Ein Beispiel f¨ ur den Einsatz eines Prozessors aus der TMS320Cx-Serie und eines ARM9Prozessors ist die OMAP-Entwicklungsplattform f¨ ur Ein-Chip-Systeme der Firma Texas Instruments (siehe Abschnitt 5.6.6). Infineon-Prozessoren Infineon ist z. B. mit dem TriCore-Prozessor-Familie (Drei-Kern-Prozessor) auf dem Markt. Es ist eine Mikrokontroller-Familie, die f¨ ur hohe Datenverarbeitungsleistungen, sowie sicherheitskritische Anwendungen z. B. im Automobilbereich, f¨ ur Echtzeitanwendungen und in Eingebetteten Systemen der Steuerungs-, Mess- und Regeltechnik eingesetzt wird. Der TriCore kombiniert die Befehlss¨atze eines RISC-Prozessors, eines Mikrokontrollers sowie eines DSP-Prozessors und enth¨alt neben einem 32-Bit Mikroprozessor einen Peripherieprozessor, der die Anbindung an verschiedene Sensorumgebungen erm¨ oglicht.

3.5

Mehrprozessorsysteme

Mehrprozessorsysteme bestehen aus mehreren Mikroprozessoren, die u ¨ber ein Verbingungssystem miteinander kommunizieren k¨ onnen. Warum werden Mehrprozessorsysteme eingesetzt? Manche Echtzeit-Aufgaben erfordern so viel Rechenleistung, dass sie auch mit einem sehr schnellen (und teuren) Mikroprozessor kaum l¨osbar sind. Die Verteilung der Rechenleistung auf mehrere Mikroprozessoren bzw. auf verteilte Systeme“ ” (siehe Kapitel 4) liefert in der Regel ein besseres Kosten/Performanzverh¨altnis sowie

62

3 Mikroprozessor-Grundlagen

Speicher MasterProzessor AdressGenerator

Speicher 1

Speicher 2

ProzessorElement 1 PE1

ProzessorElement 2 PE2

Speicher n

.....

ProzessorElement n PEn

...

...

... BusArbiter 1

BusArbiter n

SpeicherBank 1

...

SpeicherBank n

Abbildung 3.20: Schema eines Mehrprozessorsystems. Ein Standard-Prozessor als MasterProzessor koordiniert die Aufgaben mehrerer Hochleistungs-Prozessorelemente. Oft gibt es mehrere Busse, Speicherb¨ anke und Zusatzeinheiten wie z. B. Bus-Arbiter.

ein besseres Verh¨ altnis von Performanz zu Energieverbrauch (siehe Abschnitt 3.1) als eine L¨ osung mit einem einzelnen Prozessor. Abbildung 3.20 zeigt schematisch ein Mehrprozessorsystem wie es beispielsweise f¨ ur Hochleistungs-Digitale Signalprozessoren (DSPs) Anwendung findet. Ein Master-Prozes” sor“, meist ein RISC-Prozessor, koordiniert und verteilt die Aufgaben an die Prozessorelemente PE1 bis PEn. In unmittelbarer N¨ahe des Master-Prozessors befindet sich ein Speicherbaustein und ein Adressgenerator. Die Prozessorelemente sind oft Hochleistungsprozessoren oder Spezialprozessoren f¨ ur bestimmte Anwendungen, zum Beispiel Digitale Signalprozessoren. F¨ ur die Anbindung der Speicher an die Prozessoren gibt es verschiedene Philosophien. Die einzelnen Prozessorelemente k¨ onnen jeweils Zugriff auf einen eigenen Speicherblock haben wie im Beispiel des Cell-Processors (Abschnitt 3.5.1) oder es gibt gemeinsame Speicherb¨ anke, die u ur jeden Bus ¨ber ein oder mehrere Bussysteme zugreifbar sind. F¨ ist jeweils ein Arbiter n¨ otig. Die Aufgaben (die Rechenlast) sollten in einem Mehrprozessorsystem m¨oglichst gleichm¨ aßig an die einzelnen Prozessorelemente verteilt werden, d. h. ein guter Lastausgleich“ ” (load balancing) bringt erst die gew¨ unschte Effizienz der Datenverarbeitung. Beispiele f¨ ur den Einsatz von Mehrprozessorsystemen sind Grafik- bzw. Bildverarbeitung, Video- und Audioanwendungen, Steuerung und Verarbeitung von Datenstr¨omen, zum Beispiel in Fahrerassistenzsystemen. Weitere Beispiele f¨ ur Mehrprozessorsysteme sind der Mehrprozessor-Chip TMS320C80 von Texas Instruments (siehe Abschnitt

3.5 Mehrprozessorsysteme

63

3.4.3), der Cell-Prozessor (siehe n¨ achsten Abschnitt) und Entwurfsplattformen wie sie in Kapitel 5, Abschnitt 5.6.5 aufgef¨ uhrt sind.

3.5.1

Beispiel fu ¨r ein Mehrprozessor-System: Der Cell-Prozessor

Ein Beispiel f¨ ur ein hybrides Mehrprozessor-System ist der Cell-Prozessor, der in Zusammenarbeit der Firmen IBM, Sony und Toshiba entwickelt wurde [Blfd05] und im Jahre 2005 erstmalig zum Einsatz kam. Ein hybrides Mehrprozessor-System besteht aus Mikroprozessoren verschiedener Bauart. Die Architektur des Cell-Prozessors zeigt vereinfacht Abbildung 3.21. Der Cell Prozessor besteht im Wesentlichen aus einem 64-Bit PowerPC, dem PowerPC Processing ” Element“ (PPE) als Master“ bzw. Steuerprozessor und acht leistungsstarken Prozes” sorelementen, den Synergistic Processing Units“ (SPU). Der PPE, basierend auf dem ” Power5“-Doppelkern, verf¨ ugt u ¨ber einen L1- und einen 512 kByte L2-Cache, insgesamt ” u ur Gleitkomma¨ber 2,5 MByte Speicher. Er hat eine sogenannte VMX-Erweiterung“ f¨ ” berechnungen und kann zwei Programmthreads gleichzeitig bearbeiten, das bedeutet, dass er bei einem Pipeline stall“ in einem Thread im zweiten Thread weiterarbeiten ” kann. Die Taktfrequenz betr¨ agt ca. 3,2 GHz bis maximal 4,6 GHz f¨ ur alle Prozessoren.

PPE 64-Bit Power Core

SPE

L2

SPE RAM

SPECore

L1

RAM

8x Reg

.......

SPECore

Reg

EIB: Element Interconnect Bus

MemoryController

MemoryController

RAM

RAM

I/OController

I/OController

Abbildung 3.21: Stark vereinfachte Architektur des Cell-Prozessors (nach [Blfd05]).

Die SPUs sind nach der SIMD-(Single Instruction Multiple Data)-Methode organisiert und verzichten auf eine Cache-Hierarchie. Zu jeder SPU geh¨oren 128 Register mit je 128 Bit. Der Memory Flow Controller (MFC) steuert die Verbindung direkt zu ihren ¨ 256 kByte großen lokalen Speichern, zu anderen SPEs oder f¨ uhrt DMA-Ubertragungen zum Hauptspeicher aus.

64

3 Mikroprozessor-Grundlagen

Das Verbindungselement ist der Element Interconnect Bus (EIB)“ der als Ringbus“ ” ” (4x128-Bit) realisiert ist und eine Transferrate von 96 Byte pro CPU-Takt aufweist. Der Zugriff zum Hauptspeicher erfolgt u ¨ber zwei Memory Interface Controller (MIC), die eine Daten-Bandbreite von jeweils 12,8 GByte/sec, also insgesamt 25,6 GByte/sec erreichen. Eine ¨ ahnliche Anordnung haben die beiden I/O Controller, Dual configurable ”¨ High Speed I/O Channels“ genannt, mit einer gesamten m¨oglichen Ubertragungsrate von 76,8 GBytes/sec. Eine Rechenleistung von u ¨ber 256 GFlops soll der Cell-Prozessor in grafischen und visuellen Anwendungen leisten, ein Wert, der ihn im Jahre 2005 in die Top-Ten der schnellsten Supercomputer platzieren w¨ urde. Ein bei IBM in East Fishkill hergestellter Prototyp hat Taktgeschwindigkeiten bis zu 4,6 GHz erreicht [Heise05]. Der Cell-Prozessor wird in den Strukturabmessungen von 90 nm, 65 nm sowie 45 nm gefertigt. Die Chipfl¨ ache betr¨ agt bei 90 nm etwa 221 mm2 bei 234 Millionen Transistoren [Arst05]. Der Cell-Prozessor wird z. B. nicht nur in IBM Bladeservern, sondern auch in der Sony Playstation 3 mit 3,2 GHz Taktung (entspricht ca. 180 GFlops bei einfach genauen Fließkommazahlen) eingesetzt. Sollte sich in der Fertigung eine SPE als defekt herausstellen, so wird der Cell Prozessor mit 7 SPEs meist f¨ ur die Sony-Playstation 3 geliefert. Weitere Beispiele von Mehrprozessorsystemen werden im Kapitel 5, Abschnitt 5.6.6 erw¨ ahnt. Prozesse und Aktivierungsdaten Zustände eines Prozesses ausführend ausgewählt Start bereit

unterbrochen

erhält Daten (MP bereit)

Speicher Mikroprozessor

Prozess 3, Code

ProgrammZähler

Prozess 2, Code

Register

benötigt Daten erhält Daten wartend

Prozess 1, Code P. 3, Aktivierungs-D. P. 2, Aktivierungs-D. P. 1, Aktivierungs-D.

Abbildung 3.22: Links: Zust¨ ande eines Prozesses. Rechts: Prozesse und Aktivierungsdaten (nach [Wolf02]).

3.6

Prozesse und Betriebssysteme

3.6.1

Prozesse

Prozesse sind u ¨berschaubare Programme oder Programmteile, die helfen, die SoftwareKomplexit¨ at eines Systems u ¨bersichtlicher zu gestalten. Sie l¨osen meist eine bestimmte Datenverarbeitungs-Aufgabe, d. h. sie lesen Daten, verarbeiten sie und schreiben sie zur¨ uck.

3.6 Prozesse und Betriebssysteme

65

Prozesse oder Programme sollten reentrant (wiedereintrittsf¨ahig, ablaufinvariant) sein, das heißt, mehrere Instanzen reentranter Prozesse sind nebenl¨aufig ausf¨ uhrbar, ohne sich zu st¨ oren. Mit einfacheren Worten: Ein Prozess ist reentrant, wenn er, ohne ihn neu zu laden wiederholt ausf¨ uhrbar ist und jedes Mal dieselbe Aufgabe l¨ost. Beispiel: Ein Prozess, der reentrant ist, darf keine globale Variable, die den Prozessablauf beeinflusst, lesen und danach mit einem anderen Wert u ¨berschreiben. Non-reentrante-Prozesse bzw. Programme sind fehleranf¨ alliger [Wolf02]. Prozesse haben drei Zust¨ ande, die Ausf¨ uhrung betreffend, (siehe Abbildung 3.22, links): bereit, ausf¨ uhrend, wartend. Ein Prozess ist beim Start im Zustand bereit“ ” (ready). Wird der Prozess vom Betriebssystem zur Ausf¨ uhrung freigegeben, so geht er in den Zustand ausf¨ uhrend“ (executing). In den Warte-Zustand geht der Prozess ” beispielsweise, wenn er Daten ben¨ otigt und kehrt zur Ausf¨ uhrung zur¨ uck, wenn die Daten verf¨ ugbar sind. Ist ein Prozess im Warte-Zustand, so kann das Betriebssystem einen zweiten Prozess starten. Ein Prozess im Ausf¨ uhrungszustand kann unterbrochen werden und kehrt dann in den Zustand bereit“ zur¨ uck. ” Betriebssysteme machen es m¨ oglich, dass auf einem Mikroprozessor mehrere Prozesse scheinbar nebenl¨ aufig ausgef¨ uhrt werden. Dazu werden zu jedem Prozess sogenannte Aktivierungsdaten (activation records) geladen. Diese Aktivierungsdaten enthalten: Prozessdaten, Prozess-Zustand, Start- und R¨ uckkehr-Adresse, Registerinhalte usw. Abbildung 3.22 rechts zeigt schematisch einen Mikroprozessor in dessen Speicher drei Programme (Prozessor-Codes) und die dazugeh¨ origen Aktivierungsdaten geladen sind. Der Programmz¨ ahler (program counter) im Mikroprozessor in Abbildung 3.22 rechts zeigt auf Prozess 2, der gerade ausgef¨ uhrt wird. Die Aktivierungsdaten werden in die Register u oren zum Kontext“ des Prozesses. Das Um¨bernommen. Die Aktivierungsdaten geh¨ ” schalten von einem Prozess zum n¨ achsten, nennt man Kontextwechsel“ (Context ” Switching). Prozessen wird in der Regel ein eigener Speicherbereich zugewiesen, der in heutigen Betriebssystemen vor Zugriffen anderer Prozesse gesch¨ utzt ist (protected memory). Die Verwaltung solcher Speicherbereiche wird oft von Memory Management Units“ ” (MMUs) durchgef¨ uhrt. Will man beispielsweise in Eingebetteten Systemen den Aufwand f¨ ur MMUs sparen, so werden Light-Weight Processes“ oder Threads“ ” ” verwendet, die gemeinsamen Speicherplatz benutzen. Prozesse tauschen sehr h¨ aufig Daten untereinander aus. Man sagt: die Prozesse kommunizieren miteinander. F¨ ur die Prozess-Kommunikation gibt es verschiedene M¨oglichkeiten: • Datenaustausch u ¨ber gemeinsamen Speicherbereich (Shared Memory). • Datenaustausch u ¨ber Nachrichtenaustausch. (Message passing) Abbildung 3.23 oben zeigt schematisch den Datenaustausch u ¨ber einen gemeinsamen Speicherbereich (Shared Location). Prozess P1 schreibt Daten in diesen Bereich und Prozess P2 liest die Daten. Dauert das Schreiben und Lesen mehrere Taktzyklen, so muss sichergestellt werden, dass nicht genau w¨ahrend dieser Aktionen eine Unterbrechung (Interrupt) stattfindet. Das heißt, ein Interrupt muss ausgeblendet, maskiert“ ”

66

3 Mikroprozessor-Grundlagen

Speicher

P1

Gem. Bereich (Shared location)

P2

schreibt

liest

Msg P1

Msg P2

Abbildung 3.23: Oben: Datenaustausch zwischen Prozessen u ¨ber gemeinsamen Speicherbereich (shared memory). Unten Datenaustauschdurch durch Nachrichten (Messages): Message ” Passing“ (nach [Wolf02]).

werden (siehe Seite 30). Werden die Prozesse in verschiedenen Prozess-Elementen, zum Beispiel in verschiedenen Mikroprozessoren ausgef¨ uhrt, so muss u ¨ber einen wechsel” seitigen Ausschluss“ (siehe Abschnitt 5.7.2, Seite 162) bzw. u ¨ber eine Semaphore“ ” verhindert werden, dass auf die Shared Location“ gleichzeitig zugegriffen wird. Die” se Semaphore kann ein Bit sein: Der schreibende/lesende Prozess setzt die Semaphore aktiv. Das bedeutet, dass w¨ ahrend dieser Aktion kein weiterer Prozess auf den Speicherplatz zugreifen kann. In Abbildung 3.23 unten wird schematisch ein Datenaustausch u ¨ber Message passing“ ” gezeigt. Diese Methode wird oft angewendet, wenn Prozesse in verschiedenen ProzessElementen, z. B. in verschiedenen Mikroprozessoren ausgef¨ uhrt werden. Sind mehrere Prozesse daran beteiligt, eine Aufgabe zu l¨osen, so gibt es oft Datenabh¨ angigkeiten. Beispielsweise muss Prozess 2 darauf warten, bis Prozess 1 bestimmte Daten vorbereitet hat. Prozess 3 verarbeitet die Daten weiter, danach bekommt Prozess 1 diese Daten wieder. Man sagt: Die Prozesse m¨ ussen synchronisiert“ werden. ” Bringmann [Bring03] hat die Synchronisation von Multiprozess-Systemen analysiert.

3.6.2

Wozu Betriebssysteme?

Betriebssysteme sind Programme, die Anwendungsprogramme beim Zugriff auf die Hardware bzw. die Ressourcen des Prozessors unterst¨ utzen. Mit anderen Worten: Ein Betriebssystem (BS) stellt Programme zur Verwaltung und zur Ablaufsteuerung von Anwenderprogrammen zur Verf¨ ugung. Damit liefert es die Schnittstelle (API: Application

3.6 Prozesse und Betriebssysteme

67

Program Interface) zwischen Anwendungsprogrammen bzw. Anwender und dem Prozessor des Computer-Systems. Eingebettetes System Flüssigkeits-Sensoren Zentrale

CPU

Reg

Tank Timer

MP

z.B. I2C

Abbildung 3.24: Ein einfaches Beispiel f¨ ur ein Eingebettetes System mit einem Mikroprozessor (MP): Ein F¨ ullstandsmessger¨ at f¨ ur einen Tank.

Ben¨ otigen Eingebettete Systeme mit einem Mikroprozessor unbedingt ein Betriebssystem? Wir betrachten ein sehr einfaches Beispiel f¨ ur ein Eingebettetes System in Abbildung 3.24. F¨ ur einen Tank in der chemischen Industrie wird ein F¨ ullstandsmessger¨at ben¨ otigt. Die Aufgaben sind einfach: Am Tank sind vertikal von oben nach unten mehrere Fl¨ ussigkeitssensoren angebracht. Die Fl¨ ussigkeitssensoren werden in bestimmten ¨ Zeitabst¨ anden abgefragt und der F¨ ullstand wird in einem Register abgespeichert. Uber einen einfachen seriellen Bus, z. B. einen I2C-Bus (siehe Kapitel 4, Abschnitt 4.5.1), wird der Registerinhalt und damit der F¨ ullstand an die Zentrale weitergeleitet. F¨ ur dieses Beispiel k¨ onnen wir einen einfachen, preisg¨ unstgen Niedrigpreis-Mikrokontroller verwenden, in dem bereis ein Timer (Zeitgeber), I/O-Schnittstellen f¨ ur die Sensoren und f¨ ur den seriellen Bus vorhanden sind und der unterbrechungsf¨ahig“ (Interrupt” f¨ ahig) ist (siehe Abschnitt 3.4.1). F¨ ur dieses Beispiel ist kein m¨achtiges Betriebssystem wie z. B. Linux o. ¨ a. n¨ otig. Was wir hier brauchen, ist ein sogenanntes Bring-up“” System f¨ ur den Mikrokontroller: Es ist ein kleines Programm, das beim Einschalten folgende Aufgaben erledigt: • Selbst-Test des Mikrokontrollers: Einfache Befehlstests: z. B. Funktioniert die Addition 2 + 3 = 5 korrekt? • Speicher-Test: Schreib- und Lese-Test. Ein bestimmtes Bitmuster wird in jede Speicherzelle eingeschrieben, ausgelesen und gepr¨ uft. • Eingabe/Ausgabe-Test. • Initialisierungen, zum Beispiel Initialisierung des Interrupt-Handlers. • Start des Timers. Der Timer startet das Hauptprogramm.

68

3 Mikroprozessor-Grundlagen

Das Hauptprogramm fragt die Sensoren ab und speichert die Ergebnisse in ein Register. Danach gibt es den Registerinhalt, eingepackt in ein Nachrichtenpaket, auf den seriellen Bus und wartet wieder auf die n¨ achste Timerunterbrechung. Anstelle des Betriebssystems kann hier Interrupt-basiertes Multitasking“ (siehe Kapitel 5) verwendet werden. ” Der Treiber f¨ ur den seriellen Bus ist meist frei verf¨ ugbar. Nicht alle Anwendungsprogramme f¨ ur Eingebettete Systeme k¨onnen so einfach durch ein sequentiell ablaufendes Hauptprogramm repr¨asentiert werden. In unserem Einfachbeispiel gibt es keine Echtzeitanforderungen. Daher gen¨ ugt auch ein Minimal-Betriebssystem. Ein Video-Ger¨ at z. B. weist mit diffizileren Aufgaben auf: Es muss in Echtzeit folgende Aufgaben erledigen: • Einlesen und Dekomprimieren der Bildschirminhalte, der Frames“. ” • Anzeigen der Frames. • Auslesen und Dekomprimieren der Tonspur. • Abspielen der Tonspur. Diese Aufgaben werden durch verschiedene Prozesse wahrgenommen, die z. T. nebenl¨ aufig und unter Einhaltung von Zeitgrenzen ausgef¨ uhrt werden. Hier ist ein f¨ahiges Betriebssystem gefragt.

3.6.3

Aufgaben und Schichtenmodell eines Betriebssystems

Betriebssysteme erf¨ ullen eine oder mehrere der folgenden Aufgaben [RechPom02]: • Abstraktion. Darunter versteht man die Kapselung der Prozessor-Hardware, sodass sie vom Anwendungsprogramm nicht sichtbar ist. Zur Verwaltung der Hardware und damit zu den Abstraktionsaufgaben geh¨ort z. B. – Die Speicherverwaltung: Arbeitsspeicher, Caches, Peripheriespeicher. – Unterbrechungsbearbeitung (Interrupt administration). – Eingabe/Ausgabeverwaltung, Ansteuerung der E/A-Einheiten, die in den Treiberprogrammen realisiert ist. – Dateiverwaltung. – Fehlererkennung und Fehlerbehandlung. – Binden und laden von Programmen und Programmteilen. • Plattform f¨ ur Anwendungsprogramme. Das Betriebssystem definiert eine Menge von Programmierschnittstellen (APIs: Application Programming Interfaces), sodass die Dienste des Betriebssystems nutzbar sind. Diese Schnittstelle wird von vielen Betriebssystemen als ein Satz von Funktionen beispielsweise f¨ ur die Programmiersprachen C oder Java definiert. Wird C++ oder Java verwendet, so

3.6 Prozesse und Betriebssysteme

69

sind nicht nur objektorientierte Schnittstellen m¨oglich, sondern es k¨onnen auch Anwenderprogramme geschrieben werden, die vom Betriebssystem unabh¨angig sind. • Zeitablaufplanung bzw. Scheduling im Mehrprozessbetrieb. Darunter versteht man Koordination und Zuteilung von Ressourcen bei nebenl¨aufigen (konkurrierenden) Prozessen. • Schutz mehrerer aktiver Benutzer. Dies gilt f¨ ur Betriebssysteme, die f¨ ur Mehrbenutzersysteme (Multiuser) ausgelegt sind und trifft f¨ ur Eingebettete Systeme kaum zu. • Bedienungsschnittstelle f¨ ur Benutzer. Bei Rechnersystemen wird sie Oberfl¨ache“ ” oder Shell“ genannt. Bei Eingebetteten Systemen wird sie in manchen F¨allen in ” einfacher Form beispielsweise zur Fehlerdiagnose oder zum Test verwendet. Oft ist sie bei Eingebetteten Systemen nicht vorhanden.

Anwenderprogramme (Benutzertasks) Anwenderspezifische BS-Tasks (BS-T) Anwenderunabhängige BS-T Verwaltungsaufgaben

Nukleus

Schale des BS

Abbildung 3.25: Schichtenmodell eines Betriebssystems (BS). Die Programme der einzelnen Schichten werden als Tasks“ bezeichnet. ”

Betriebssysteme sind in Schichten“ aufgebaut. Abbildung 3.25 zeigt das Schichtenmo” dell eines Betriebssystems. Der Kern des Betriebssystems, der Nukleus ist meist resident im Hauptspeicher und enth¨ alt die grundlegenden Mechanismen f¨ ur die Bew¨altigung der Aufgaben des Betriebssystems wie: • Verwaltung der Betriebsmittel: Prozessor, Speicher, Ein/Ausgabe usw. • Unterbrechungsbehandlung • Ablaufplanung (Scheduling) und Umschaltung zwischen den Tasks“ ” • Kommunikation zwischen den Tasks

70

3 Mikroprozessor-Grundlagen

Um den Kern herum liegen die Schalen“ oder Schichten. Auf die Funktionen tieferge” legener Schichten kann von den Programmen oder Tasks zugegriffen werden, ohne deren Verhalten im Detail zu kennen. Tasks sind Programme oder Unterprogramme bzw. Funktionen der einzelnen Schichten des Betriebssystems. Ein Prozess kann aus mehreren Tasks bestehen. Auf den Schalen von innen nach außen liegen nacheinander die anwenderunabh¨ angigen Betriebssystem-Tasks, die anwenderspezifischen Betriebssystem-Tasks und die Anwenderprogramme selbst.

3.6.4

Echtzeitbetriebssysteme

Echtzeitbetriebssysteme (Real Time Operating Systems RTOS) in Eingebetteten Systemen m¨ ussen Aktionen innerhalb bestimmter Zeitgrenzen ausf¨ uhren. Man unterscheidet zwischen harten und weichen Echtzeitsystemen [RechPom02] [Kop97]: • Harte Echtzeitsysteme (Hard Real-Time Systems) sind solche, bei denen ein Fehler im Werte- und Zeitbereich katastrophale Folgen haben kann. Beispiele f¨ ur harte Echzeitsysteme sind Herzschrittmacher und ABS-Bremssteuerungen im Kraftfahrzeug. • Weiche Echtzeitsysteme (Soft Real-Time Systems) sind solche, bei denen die potentiellen Kosten eines Fehlers in der gleichen Gr¨oßenordnung liegen wie der Nutzen des Systems. Beispiel ist eine Briefsortiermaschine: Landet ein Brief auf Grund eines Zeitfehlers des Eingebetteten Systems in einem falschen Fach, so h¨alt sich der Schaden in Grenzen. Die Anforderungen an harte Echtzeitbetriebssysteme sind wie folgt: • Das Zeitverhalten muss vorhersagbar sein. • Das Betriebssystem muss eine pr¨ azise Zeitablaufplanung durchf¨ uhren k¨onnen. • Allgemein: Das Betriebssystem muss schnell“ sein, es muss Anwendungen mit ” harten Zeitgrenzen in Bruchteilen von ms unterst¨ utzen k¨onnen. Vorhersagbares Zeitverhalten erfordert, dass eine obere Zeitgrenze der Ausf¨ uhrungszeit (WCET, siehe Seite 218) garantiert wird, d. h. beispielsweise, f¨ ur einen Speicherzugriff muss ein Worst Case“ Zeitwert eingehalten werden. Der Worst Case“ ist der ” ” ung¨ unstigste Fall, der Fall mit den ung¨ unstigsten Randbedingungen. Weiterhin m¨ ussen Unterbrechungen ausgeschaltet werden oder d¨ urfen nur sehr kurz und von bekannter Dauer sein. Bei Echtzeitbetriebssystemen z¨ ahlt die Zeitablaufplanung zur Kernaufgabe, sie wird in den folgenden Abschnitten eingehender behandelt.

3.6.5

Zeitablaufplanung in Echtzeitbetriebssystemen

Die Zeitablaufplanung oder Scheduling“ besch¨aftigt sich mit Prozessen oder Teilen von ” Prozessen, die in der Ablaufplanung mit Tasks“ bezeichnet werden. Der Zeitablaufpla” ner oder k¨ urzer Scheduler“ genannt, nimmt die Aufgabe der Zeitplanung wahr, er teilt ”

3.6 Prozesse und Betriebssysteme

71

Echtzeit-Zeitablaufplanung

weiche Zeitgrenzen

harte Zeitgrenzen

aperiodisch

periodisch präemptiv statisch

dynamisch

non-präemptiv statisch

dynam.

präemptiv stat.

dyn.

non-präemptiv stat.

dyn.

Abbildung 3.26: Klassifizierung der Zeitablaufplan-Methoden (Scheduling-Methoden) f¨ ur Echtzeitbetriebssysteme bei verschiedenen Anforderungen [Mar07].

die einzelnen Tasks eines Systems einem oder mehreren Prozessoren zur Abarbeitung zu. Wir betrachten im Folgenden Einzelprozessor-Systeme. Eine Klassifizierung von Zeitablaufmethoden (Scheduling) f¨ ur Betriebssysteme nach Marwedel [Mar07] bei harten/weichen Zeitgrenzen und periodischen/aperiodischen Datenfl¨ ussen zeigt Abbildung 3.26. Uns interessieren haupts¨achlich die harten Zeitgrenzen, die in Echtzeitsystemen auftreten. Nach Abbildung 3.26 k¨onnen Tasks wie folgt eingeplant werden: • Periodisch: Tasks die alle Tp Zeiteinheiten ausgef¨ uhrt werden m¨ ussen, werden periodische Tasks genannt. Tp ist die Periode. • Aperiodisch sind alle Tasks, die nicht periodisch sind. •

Pr¨ aemptiv“ (auch pr¨ aemtiv, preemtive) bedeutet, eine Task kann vom Schedu” ler unterbrochen werden, wenn eine Task mit h¨oherer Priorit¨at gestartet werden muss. Um pr¨ aemptives Multitasking zu realisieren, wird der Unterbrechungsmechanismus (Interrupt, siehe Seite 30) eingesetzt. non-pr¨ aemptiv“ bedeutet, ” eine Task wird ohne Unterbrechung beendet.

• Beim Statischen Scheduler wird der Zeitablauf der einzelnen Tasks vor der Ausf¨ uhrung geplant. • Ein dynamische Scheduler f¨ uhrt die Zeitablaufplanung zur Laufzeit durch. Periodische Tasks treten in periodisch ablaufenden Systemen auf, in denen gleiche Aktionen in diskreten Zeitabst¨ anden wiederholt werden, z. B. bei Videosystemen oder Motorsteuerungen. Die Einzelbilder eines Videofilms (die Frames“) werden periodisch in ” einer bestimmten Taktfrequenz (beispielsweise konstant 100 Hz) angezeigt, damit beur die Verarbeitung eines Frames bis zur Anzeige tr¨ agt die Taktperiode Tp = 10ms, die f¨ bleibt. In dieser Zeit m¨ ussen z. B. die Tasks: laden, dekomprimieren, anzeigen eines Frames unbedingt abgearbeitet sein, damit der Film auf dem Bildschirm als bewegte Szene

72

3 Mikroprozessor-Grundlagen

erscheint. Etwas diffiziler ist die Zeitablaufplanung bei einer Motorsteuerung, da hier die Taktfrequenz nicht konstant bleibt, sie h¨angt von der Drehzahl des Motors ab, bleibt jedoch innerhalb bestimmter Grenzen. In diesem Fall muss die h¨ochste m¨ogliche Drehzahl des Motors in Betracht gezogen werden, das Scheduling muss noch bei dieser maximalen Drehzahl einwandfrei funktionieren. Aperiodische Daten treten beispielsweise bei einem ABS-System im Kraftfahrzeug auf, das System wartet auf das Ereignis Bremsen“ und tritt dann in Aktion. ” Statische und dynamische Scheduler Bei statischen Schedulern wird der Zeitablaufplan zur Entwurfszeit des Systems in einer Task Description List (TDL)“ festgelegt [Mar07]. In der TDL stehen die Start” zeiten und die maximalen Ausf¨ uhrungszeiten (WCET) der einzelnen Tasks. Der durch einen Zeitgeber (Timer) gesteuerte Dispatcher“ verwendt die TDL um die Tasks zu ” starten und zu stoppen. Systeme, die durch Timer und Dispatcher gesteuert werden, nennt man vollkommen zeitgesteuerte Systeme“ (Entirely Time Triggered Systems ” [Kop97], zitiert von Marwedel [Mar07]). Der Vorteil des statischen Scheduling ist, dass die Einhaltung der Zeitgrenzen durch Messungen u uft werden kann. In komplexen Systemen ist die Vorhersage der ¨berpr¨ Ausf¨ uhrungszeit schwierig und daher ist die statische Festlegung des Zeitablaufplans oft eine praktische L¨ osung. Der Nachteil ist, dass die Ausnutzung des Prozessors meist nicht sehr effizient ist, d. h. der optimale Zeitablaufplan wird in der Regel nicht erreicht [Mar07]. In Abschnitt 3.6.5 wird die statische Scheduling-Methode Rate Monotonic ” Scheduling“ RMS vorgestellt. Bei dynamischen Schedulern kann meist eine bessere Ausnutzung des Prozessors erzielt werden. In Abschnitt 3.6.5 wird die die dynamische Scheduling-Methode Earliest ” Deadline First“ EDF beschrieben. Rate Monotonic Scheduling (RMS) Rate Monotonic Scheduling, vorgestellt von Liu und Layland 1973 [Liu73], zititiert in [Mar07] und [Wolf02], ist eine der ersten Echtzeit-Scheduling-Methoden f¨ ur periodische Prozesse in Echtzeit-Systemen und wird noch heute viel eingesetzt. RMS ist eine statische Methode, die feste Priorit¨ aten verwendet. Sie baut auf folgendem stark vereinfachten Modell eines Systems mit mehreren nebenl¨aufigen Prozessen auf: • Alle Prozesse (Tasks) laufen periodisch auf einem Mikroprozessor. • In der Ausf¨ uhrungszeit ist das Kontext-Switching vernachl¨assigt. • Es gibt keine Datenabh¨ angigkeiten zwischen den Tasks. Die Tasks sind unabh¨angig. • Die Ausf¨ uhrungszeit f¨ ur eine Task ist konstant. • Die jeweilige Task-Zeitgrenze (Deadline) wird an das Periodenende gesetzt. • Die bereite Task h¨ ochster Priorit¨ at wird f¨ ur die n¨achste Ausf¨ uhrung ausgew¨ahlt. • Der Prozess (Task) mit der k¨ urzesten Periode hat die h¨ochste Priorit¨at.

3.6 Prozesse und Betriebssysteme

73

Als Deadline bzw. Deadlineintervall bezeichnet man das Zeitintervall zwischen dem Zeitpunkt, zu dem die Task Ti bereit (ready) ist und dem Zeitpunkt, zu dem die Ausf¨ uhrung dieser Task innerhalb der Periode Pi beendet sein muss. Der Name RMS ist aus der Priorit¨ atsfunktion der Tasks abgeleitet, die Priorit¨ at der Tasks ist eine monoton fallende Funktion ihrer Periode [Mar07], das heißt, der Prozess mit der k¨ urzesten Periode hat die h¨ ochste Priorit¨at. RMS ist eine pr¨aemptive Schedulingmethode, d. h. die Tasks m¨ ussen unterbrechbar sein. Task

Periode

T1

1

4

1

0

T2

2

6

2

2

T3

3

12

3

4

Gezeigt ist der „unrolled schedule“: Alle Tasks können eingeplant werden. Dieser Schedule ist erreichbar (feasible).

Priorität

T1

6 8

T2

T3 Unterbrechung

Ausf.Z

10 12

Zeit t

Abbildung 3.27: Einfaches Beispiel f¨ ur Rate monotonic Scheduling (RMS): Gezeigt ist der Zeitablauf dreier Tasks mit verschiedenen Perioden [Wolf02].

Abbildung 3.27 zeigt ein einfaches Beispiel f¨ ur einen RMS-Zeitplan mit drei Tasks, die unterschiedliche Perioden aufweisen [Wolf02]. In der Tabelle in Abbildung 3.27 links sind die Ausf¨ uhrungszeiten, die Perioden und die daraus abgeleiteten Priorit¨aten der einzelnen Tasks gezeigt. Task 1 (T1) hat die Ausf¨ uhrungszeit t1 = 1 Zeiteinheit (ZE), die Periode P1 = 4 ZE und daraus abgeleitet die Priorit¨at 1. Task 2 (T2) hat die Ausf¨ uhrungszeit t2 = 2 ZE, die Periode P2 = 6 ZE, die Priorit¨at 2. T3 hat die Ausf¨ uhrungszeit 3 ZE, die Periode 12 ZE und die Priorit¨at 3. Im Zeitablaufplan in Bild 3.27 rechts ist der abgerollte Zeitablaufplan“ (Unrolled Sche” dule [Wolf02]) gezeigt. Task T1 wird entsprechend seiner Priorit¨at zuerst eingeplant (zum Zeitpunkt 0), danach T2 und T3. T1 wird periodisch zu den Zeitpunkten 4, 8, 12 usw. ausgef¨ uhrt. Zum Zeitpunkt t = 4 wird T3 unterbrochen und T1 wird wieder eingeplant, danach kommt T3 im Zeitpunkt 5 wieder zum Zug, allerdings nur eine Zeiteinheit lang, da zum Zeitpunkt 6 Task 2 wieder eingeplant werden muss, usw. Dieser Zeitplan ist erreichbar (feasible). Tabelle 3.7 nach [Wolf02] zeigt einen nicht erreichbaren Zeitablaufplan. W¨ ahrend einer Periode von Task 3, die 12 Zeiteiheiten (ZE) dauert, muss T1 drei Mal, T2 zwei Mal und T3 ein Mal ausgef¨ uhrt werden. Insgesamt sind dies 3 ∗ 2 + 2 ∗ 3 + 3 = 15 ZE. Die Periodendauer von T3 betr¨ agt aber nur 12 ZE. Das bedeutet, dieser Zeitablaufplan ist nicht erreichbar.

74

3 Mikroprozessor-Grundlagen Task Task 1 (T1) Task 2 (T2) Task 3 (T3)

Ausf¨ uhrungszeit (ZE) 2 3 3

Periode (ZE) 4 6 12

Priorit¨at 1 2 3

Tabelle 3.7: Einfaches RMS-Beispiel f¨ ur einen nicht erreichbaren Zeitablaufplan. ZE“ be” deutet Zeiteinheit. (nach [Wolf02]).

Aus dem Beispiel Tabelle 3.7 kann man eine einfache Regel f¨ ur die Erreichbarkeit eines RM-Schedule ableiten, bei dem die l¨ angste Periodendauer ein ganzes Vielfaches der einzelnen Tasks ist (und die oben aufgef¨ uhrten Punkte f¨ ur das RMS-Systemmodell gelten): Sind n Tasks in ein RM-Schedule einzuplanen, bei dem die l¨ angste Periodendauer Pl jeweils ein ganzes Vielfaches der einzelnen Tasks ist, so darf die Summe der Ausf¨ uhrungszeiten aller n Tasks die l¨ angste Periode Pl nicht u ¨berschreiten. Die Prozessorauslastung U (Utilization) f¨ ur das RMS nach [Liu73], zitiert in [Mar07], uhrungszeiten Ti ist: f¨ ur eine Menge von n Tasks mit den Perioden pi und den Ausf¨ U=

n 

(Ti /pi ) ≤ n(21/n − 1)

(3.5)

i=1

Bei n=2 Tasks in der Formel 3.5 liegt die Prozessorauslastung U bei ca. 83%, d. h. der Prozessor ist ca. 17% der Zeit im Leerlauf. Bei einer hohen Anzahl von Prozessen n → ∞, geht U maximal gegen ln2 ≈ 0, 69. In unserem Beispiel Abbildung 3.27 ist die Prozessorauslastung U = 1/4 + 2/6 + 3/12 ≈ 0, 83. Das Beispiel Abbildung 3.27 ist ein Sonderfall: Die Periodendauer von T3 ist ein ganzzahliges Vielfaches der Perioden von T1 und T2. F¨ ur diesen Sonderfall kann eine h¨ohere Prozessorauslastung erreicht werden. Betrachtet man Abbildung 3.27 genauer, so sieht man, dass das Zeitintervall zwischen Zeitpunkt t = 10 und t = 12 nicht ausgenutzt ist, das heißt die Ausf¨ uhrungszeit von T3 k¨ onnte um 2 Zeiteinheiten auf 5 ZE verl¨angert werden. Setzt man die AZT 3 = 5ZE in Formel 3.5 ein, so ergibt sich die Prozessorauslastung zu: U = 1/4 + 2/6 + 5/12 ≈ 0, 95. Liu und Layland [Liu73] haben bewiesen, dass RMS f¨ ur Ein-Prozessorsysteme optimal ist, auch wenn die Prozessorauslastung nicht optimal ist. Das heißt, dass ein Zeitablaufplan mit RMS immer gefunden wird, wenn ein solcher erreichbar ist. Rate Monotonic Scheduling ist relativ einfach zu implementieren. Die Tasks werden nach Priorit¨at vor der Ausf¨ uhrung in einer Liste sortiert und der Scheduler sucht in der Liste nach der ersten bereiten Task [Wolf02]. Die Komplexit¨at des RMS-Algorithmus ist O(n). Earliest Deadline First Scheduling (EDF) Earliest Deadline First Scheduling (EDF), vorgestellt von Liu und Layland 1973 [Liu73] und Horn [Horn74], zititiert in [Mar07] und [Wolf02], ist eine optimale dynamische Scheduling-Methode f¨ ur periodische und nicht-periodische Prozesse in Echtzeit-Systemen. Die EDF-Methode ¨ andert die Task-Priorit¨aten w¨ahrend der Ausf¨ uhrung, basierend auf den Ankunftszeiten“ der Tasks, d. h. basierend auf den Zeiten, wann die ”

3.6 Prozesse und Betriebssysteme

Task

75

Ausf.-zeit

Deadline

T1

0

8

20

T2

4

3

15

T3

5

8

16

T1

T2

T3

0 2 4

Ankunft

Ankunft

6 8 10 12

16 18

Deadline

14

Zeit t 20

Abbildung 3.28: Einfaches Beispiel f¨ ur die EDF-Scheduling-Methode (EDF): Gezeigt ist der Zeitablauf dreier Tasks mit verschiedenen Ankunftszeiten“, Ausf¨ uhrungszeiten und Zeitgren” zen (Deadlines) (nach [Mar07]).

einzelnen Tasks bereit zur Ausf¨ uhrung werden. EDF ist eine pr¨aemptive SchedulingMethode. Bei der EDF-Methode werden die Priorit¨aten in der Reihenfolge der TaskZeitgrenze (Deadline) zugewiesen. Die Task, deren Deadline am n¨achsten liegt, erh¨alt die h¨ ochste, die Task, deren Deadline am weitesten entfernt ist, die niedrigste Priorit¨at. Die Tasks sind bei EDF in einer Liste gespeichert und nach jeder Task-Ankunftszeit bzw. Task-Beendigung werden die Priorit¨ aten neu berechnet und die Task mit der h¨ochsten Priorit¨ at wird eingeplant. Gegebenenfalls wird die gerade ausgef¨ uhrte Task unterbrochen, wenn sich bei der Berechnung zeigt, dass die Priorit¨at der neu angekommenen Task h¨ oher ist. Dadurch ist die Komplexit¨ at von EDF O(n2 ) [Mar07]. Bei EDF kann die Prozessorauslastung h¨ oher sein als bei RMS. Abbildung 3.28 zeigt ein einfaches Beispiel f¨ ur die EDF-Scheduling-Methode: In der Tabelle im Bild 3.28 sind drei Tasks T1 bis T3 mit verschiedenen Ankunftszeiten, Ausf¨ uhrungszeiten und Zeitgrenzen (Deadlines) gezeigt. Task T1 erscheint zum Zeitpunkt t = 0, hat eine Zeitgrenze bei t = 20 und eine Ausf¨ uhrungszeit von 8 Zeiteinheiten (ZE). Task T2 erscheint zum Zeitpunkt t = 4, hat eine Zeitgrenze bei t = 15 ZE und eine Ausf¨ uhrungszeit von 3 ZE. F¨ ur T3 gilt: Ankunft t = 5, Zeitgrenze t = 16, Ausf¨ uhrungszeit = 8 ZE. In Abbildung 3.28 rechts ist der Zeitablaufplan gezeigt: Zuerst erscheint T1, wird eingeplant, die Ausf¨ uhrung beginnt. Zum Zeitpunkt t = 4 erscheint die Task T2, die Zeitgrenze ist t = 15, also n¨aher“ als die von T1. Deshalb ” wird T1 unterbrochen und die Ausf¨ uhrung von T2 beginnt. Zum Zeitpunkt t = 5 trifft T3 ein. Die Zeitgrenze liegt bei t = 16, also darf T2 beendet werden und l¨auft bis t = 7. Danach wird T3 gestartet, da die Zeitgrenze n¨aher als bei T1 liegt. T3 wird bei t = 7 beendet. Danach wird schließlich T1 zu Ende ausgef¨ uhrt.

76

3 Mikroprozessor-Grundlagen 1. Beispiel: statisches RMS. Schedule wird erreicht Task Ausf.-Z

1. Beispiel: RMS T1

Periode Priorität

T1

2

5

1

0

T2

4

8

2

2

T3

1

15

3

4 6

2. Beispiel: Vergleich mit Dynamischer EDF: Schedule wird erreicht Task

Ausf.Z

Ankunft

T2

T3

2. Beispiel: EDF

T1

T2

T3

Unterbr.

8

Deadline

T1

2

0-5-10

5-10-15

T2

4

0-8-16

8 – 16

T3

1

0-15

15

10

Unterbr.

12 14 16

Abbildung 3.29: Vergleich von RM-Scheduling (Beispiel 1) und EDF-Scheduling (Beispiel 2). Beide Zeitablaufpl¨ ane werden erreicht (nach [Mar07]).

Abbildung 3.29 zeigt einen Vergleich von RM-Scheduling (Beispiel 1 oben) und EDFScheduling (Beispiel 2 unten). Die einzelnen Tasks werden bei den beiden SchedulingMethoden z. T. zeitlich verschieden eingeplant, jedoch werden f¨ ur unsere Beispiele die Zeitablaufpl¨ ane sowohl mit der statischen Scheduling-Methode RMS als auch mit der dynamischen Scheduling-Methode EDF erreicht. Liu und Layland [Liu73] zeigen, dass EDF eine Prozessorauslastung von 100% erreichen kann. Die Implementierung eines EDF-Schedulers ist relativ komplex [Wolf02]. Allgemein ist der Verwaltungsaufwand bei statischen Scheduling-Methoden geringer und die sichere Vorhersage des Zeitablaufplans ist ebenfalls ein Pluspunkt. Deshalb werden f¨ ur Eingebettete Systeme mit Echtzeit-Anforderungen statische Methoden bevorzugt [Ga09]. Weitere Scheduling-Methoden Marwedel [Mar07] beschreibt weitere Scheduling-Algorithmen wie Earliest Due Date“ ” (EDD) und Latest Deadline first“ (LDF). Da der Scheduler ein Teil des Betriebssystems ” ist, muss das Betriebssystem in der Lage sein, die Anforderungen des Schedulers zu unterst¨ utzen. Beispielsweise kann ein EDF-Scheduler nicht in einem Betriebssystem laufen, das nur statische Priorit¨ aten f¨ ur die Tasks unterst¨ utzt.

3.6 Prozesse und Betriebssysteme

3.6.6

77

Priorit¨atsumkehr und Priorit¨atsvererbung

Priorit¨ atsumkehr Bei der Zeitablaufplanung in Echtzeitbetriebssystemen f¨ ur einen Prozessor auf dem mehrere Tasks ausgef¨ uhrt werden, die auf eine gemeinsame Ressource zugreifen, kann es zu einem Problem kommen, das Priorit¨ atsumkehr (Priority Inversion) genannt wird [Mar07].

T1

T2

3. Beispiel

2. Beispiel

1. Beispiel T1

T2

T3

T1

T2

T3

0 2 4 6

krit. Abschn. Unterbr. PrioritätsVererbung

8

PrioritätsRücksetzung

10 12 14 16 Zeit T2 blockiert T1

Abbildung 3.30: Priorit¨ atsumkehr und Priorit¨ atsvererbung. Beispiel 1: Priorit¨ atsumkehr mit zwei Tasks. Beipiel 2: Priorit¨ atsumkehr mit drei Tasks. Beispiel 3: Priorit¨ atsvererbung (nach [Mar07]).

Im Beispiel 1 Abbildung 3.30 links ist ein Fall von Priorit¨atsumkehr bei zwei Tasks dargestellt. Die Task T1 hat die h¨ ohere, Task T2 die niedrigere Priorit¨at. Task T2 ist zum Zeitpunkt 0 bereit und wird ausgef¨ uhrt. Zum Zeitpunkt 3 greift T2 auf eine gemeinsame Ressource zu, man nennt dies wechselseitigen bzw. gegenseitigen Ausschluss oder die Task tritt in einen kritischen Abschnitt ein. Zum Zeitpunkt 5 ist Task T1 mit der h¨ oheren Priorit¨ at bereit und unterbricht T2 w¨ahrend der Ausf¨ uhrung im kritischen Abschnitt. T1 muss im Zeitpunkt 7 selbst auf die gemeinsame Ressource zugreifen und da diese von T2 belegt ist, darf T2 jetzt den kritischen Abschnitt zu Ende ausf¨ uhren. Die Priorit¨ at wird scheinbar umgekehrt. Sobald T2 den kritischen Abschnitt beendet hat, wird die Task T2 wieder unterbrochen und die Task T1 wird bis zum Ende ausgef¨ uhrt.

78

3 Mikroprozessor-Grundlagen

Wir betrachten Beispiel 2 in Abbildung 3.30, bei dem das Betriebssystem drei Tasks T1 bis T3 einplanen (schedulen) muss. T1 hat die h¨ochste, T3 die niedrigste Priorit¨at. Task T3 ist zum Zeitpunkt 0 bereit und wird ausgef¨ uhrt. Zum Zeitpunkt 2 tritt T3 in einen kritischen Abschnitt ein. Zum Zeitpunkt 4 ist Task T2 mit der h¨oheren Priorit¨at bereit und unterbricht T3 w¨ ahrend der Ausf¨ uhrung im kritischen Abschnitt. Die Task T1 mit der h¨ ochsten Priorit¨ at unterbricht T2 im Zeitpunkt 6, muss aber zum Zeitpunkt 8 auf die gemeinsame Ressource zugreifen, die gerade T3 belegt hat. T1 geht in den Wartezustand, aber T2 mit der h¨ oheren Priorit¨at als T3 nimmt die Ausf¨ uhrung bis zum Zeitpunkt 12 auf, an dem T2 terminiert oder selbst auf die gemeinsame Ressource zugreifen m¨ ochte. Damit gibt T2 die Kontrolle an die Task T3 ab, die jetzt den kritischen Bereich zu Ende ausf¨ uhren kann und danach die Priorit¨at an T1 zur¨ uck gibt, die zum Zeitpunkt 13 in den kritischen Bereich eintritt und zum Zeitpunkt 16 ihre Ausf¨ uhrung beendet. Zum Zeitpunkt 8, an dem T1 in den von T3 belegten kritischen Bereich eintreten m¨ ochte, u uhrung der h¨oher ¨bernimmt T2 die Kontrolle und blockiert die Ausf¨ priorisierten Task vom Zeitpunkt 8 bis 12. Diese Blockade kann dazu f¨ uhren, dass von der Task T1 eine Zeitgrenze nicht eingehalten wird. Das kann die Funktion des ganzen Systems beeintr¨ achtigen, im schlimmsten Fall zum Versagen eines wichtigen Systems f¨ uhren, wie dies zum Beispiel beim Mars-Pathfinder der Fall war ([Jon97] zitiert in [Mar07]). Priorit¨ atsvererbung Das Problem der Ausf¨ uhrungsverz¨ ogerung der Task mit der h¨ochsten Priorit¨at bei der Priorit¨ atsumkehr kann durch die Methode der Priorit¨atsvererbung vermieden werden [Mar07]. Im Beispiel 3 der Abbildung 3.30, rechte Seite wird das Prinzip der Priorit¨atsvererbung gezeigt. Die Task T3 mit der niedrigsten Priorit¨at beginnt zum Zeitpunkt 0 eine Ausf¨ uhrung und belegt zum Zeitpunkt 2 eine gemeinsame Ressource, das heißt sie tritt in einen kritischen Abschnitt ein. Task T3 wird im Zeitpunkt 4 von der Task T2 mit h¨oheren Priorit¨ at unterbrochen und im Zeitpunkt 6 startet T1 mit der h¨ochsten Priorit¨at die uhrung. Fordert nun T1 zum Zeitpunkt 8 die gemeinsame Ressource an, die T3 Ausf¨ belegt, so erbt“ T3 die Priorit¨ at der Task T1 und kann den kritischen Abschnitt ” zu Ende ausf¨ uhren. Danach wird die Priorit¨at wieder zur¨ uckgesetzt, T1 kann auf die gemeinsame Ressource zugreifen und beendet die Ausf¨ uhrung im Zeitpunkt 12. Da T3 die Priorit¨ at von T1 im Zeitpunkt 8 erbt, kann T2 die Ausf¨ uhrung von T3 nicht mehr blockieren wie in Beispiel 2 geschehen. Die Tasks T2 und T3 k¨onnen nach dem Zeitpunkt 12 ihre Ausf¨ uhrungen beenden. Beim Mars-Pathfinder konnte das Problem bei der Priorit¨atsumkehr von der Bodenstation u ¨ber Funk dadurch behoben werden, dass die Methode der Priorit¨atsvererbung im Betriebssystem VxWorks u ¨ber die Debugging-Schnittstelle eingeschaltet wurde [Mar07].

3.7 Zusammenfassung

3.7

79

Zusammenfassung

Mikroprozessoren werden mehr und mehr, vor allem in Mehrprozessorsystemen f¨ ur Eingebettete Systeme eingesetzt. Daher ist eine gute Kenntnis der Grundlagen wichtig. Weitere Grundlagen findet man im Kapitel 5 Entwicklungsmethodik, Abschnitt 5.8 Modellbasierte Entwicklungsmethode. Mikroprozessoren haben nicht nur den Vorteil kosteng¨ unstig zu sein, sie sind auch vielseitig, flexibel, erweiterungsf¨ ahig und beg¨ unstigen die Entwicklung von Produktfamilien. Wichtig ist hier, den geeignetsten Mikroprozessor einschließlich Speicher und Peripherie ¨ f¨ ur den Entwurf eines Eingebetteten Systems auszuw¨ahlen, wobei die kleine Ubersicht u ubliche Beispiele von Mikroprozessoren dem Leser die Suche erleichtern ¨ber handels¨ kann. Ein Abschnitt u autert, wann zus¨atzliche Hardware bzw. ¨ber Mehrprozessorsysteme erl¨ zus¨ atzliche Prozessoren einzusetzen sind. Abschließend wird das Thema Prozesse und Betriebssysteme behandelt. In Eingebetteten Systemen haben wir es meist mit Echtzeitbetriebssystemen zu tun, die in der Lage sind, eine effiziente und vorhersagbare Zeitablaufplanung (Scheduling) durchzuf¨ uhren. Scheduling-Methoden wie Rate Monotonic Scheduling (RMS) und Earliest Deadline First (EDF) werden kurz und anschaulich erkl¨ art.

4

Kommunikation, Busse, Netzwerke und verteilte Systeme

Unter Kommunikation verstehen wir hier den Datenaustausch zwischen Prozessoren, Komponenten oder Teilkomponenten von Prozessoren in Eingebetteten Systemen und verteilten Systemen. Kommunikation zwischen Computern wurde durch das ISO/OSI Referenzmodell relativ fr¨ uh standardisiert. Der Schichtenaufbau des Referenzmodells erlaubt eine Systematisierung der Kommunikation und tr¨agt dazu bei, die Komplexit¨at der einzelnen Kommunikationsschritte zu meistern und u ¨bersichtlicher darzustellen. Netzwerke sind uns aus dem Gebiet der Telekommunikation bekannt und bilden einen eigenen Fachbereich. Wir gehen in diesem Kapitel auf Netzwerke ein, die f¨ ur Eingebetteten Systeme wichtig sind, zum Beispiel bus¨ahnliche Netzwerke oder serielle Busse. Eine wichtige Methode der Kommunikation ist die Synchronisierung von Sender und Empf¨ anger, die einen Datenaustausch vorbereitet und mit Hilfe der so genannten Kommunikationsprimitive durchgef¨ uhrt werden kann. Die Kommunikationsprimitive werden im Folgenden behandelt. Dieses Kapitel basiert auf den B¨ uchern von Tanenbaum [Tan96], Wolf [Wolf02], Marwedel [Mar07], Bringmann [Bring03]. Weiter verwendete Literatur ist im Text zitiert. In Folgendem werden allgemeine Kommunikationsprinzipien besprochen. Zun¨achst wird auf den Schichtenaufbau des OSI-Referenzmodells eingegangen. Die Kommunikationsprimitive und parallele Busse, als R¨ uckgrat eines Prozessors oder als Verbindungselemente in Eingebetteten Systemen werden vorgestellt. Weiterhin lernen wir verschiedene Netzwerke und serielle Busse kennen wie sie beispielsweise im automotiven Bereich Verwendung finden.

4.1

Das ISO-OSI-Referenzmodell

Die Internationale Standardisierungsorganisation ISO hat 1983 die Kommunikation zwischen offenen Systemen“ im Open Systems Interconnection-Referenzmodell (OSI-RM), ” auch OSI-Schichtenmodell genannt, festgelegt. Offene Systeme sind solche, die f¨ ur die Kommunikation mit anderen Systemen offen sind. Einerseits hat das OSI-RM wie keine andere Norm zum Verst¨ andnis der Telekommunikation beigetragen und Grundlagen f¨ ur die Weiterentwicklung gelegt [Tan96], andererseits gibt es auch viel Kritik an dieser Norm und einige technische Implementierungen genau dieser Norm haben sich nicht durchgesetzt, weil sie zu langsam und zu komplex waren. Trotzdem ist es sinnvoll, das OSI-RM vorzustellen, da die Sprache und Begriffe des OSI-RM allgemein bekannt sind und nicht nur im Bereich Telekommunikation, sondern auch in der Kommunikation zwischen Computern und Eingebetteten Systemen verwendet wird.

82

4 Kommunikation, Busse, Netzwerke und verteilte Systeme

Das OSI-RM teilt die Funktionalit¨ at der Kommunikation von der Anwendung bis zur Bit¨ ubertragung in sieben Schichten auf. Wir beziehen uns von Anfang an auf die Kommunikation zwischen Computern bzw. Prozessorelementen. Jeder Schicht im OSI-RM, das schematisch in Abbildung 4.1 gezeigt ist, werden bestimmte Aufgaben, Dienste genannt, zugewiesen. Jede Schicht kann mit der benachbarten Schicht nach unten“ ” bzw. nach oben“ u ¨ber eine Schnittstelle kommunizieren. Im Laufe eines Datenaus” tauschs z. B. von einer Anwendung (Application) im Computer A zur Anwendung im Computer B, werden die Daten von einer Schicht zur anderen nach unten“ weiter” gegeben, bis sie schließlich in der Bit¨ ubertragunsschicht angekommen sind und von dort an das Physische Medium beispielsweise u ¨ber ein Kabel zum Computer B in die Bit¨ ubertragunsschicht des Computers B weitergereicht werden. Von dort aus werden die Daten wieder von Schicht zu Schicht nach oben“ bis zur Anwendungsschicht durchge” reicht. Computer A Schicht 7 6 5 4 3 2 1

Anwendung Application Darstellung Presentation Sitzung Session Transport Transport Vermittlung Network Datensicherung Data Link Bitübertragung Physical

Protokolle Anwenderprotokoll Darstellungsprotokoll Sitzungsprotokoll Transportprotokoll Vermittlungsprotokoll Datensicherungsprotokoll Bitübertragungsprotokoll

Computer B Anwendung Application Darstellung Anwendungsorientiert Presentation Sitzung Session Transport Transport Vermittlung TransportNetwork orientiert Datensicherung Data Link Bitübertragung Physical

Physisches Medium

Abbildung 4.1: ISO-OSI-Referensmodell oder OSI-Schichtenmodell.

Bei einer Daten¨ ubertragung unterscheiden wir zwischen verbindungslos“ und verbin¨ ” ¨” dungsorientiert“. Bei einer verbindungsorientierten Ubertragung wird vor der Ubertra¨ gung eine Verbindung aufgebaut, die w¨ ahrend der Ubertragung bestehen bleibt und danach wieder abgebaut wird. Ein Beispiel daf¨ ur ist eine Telefonverbindung. Bei einer ¨ verbindungslosen Ubertragung besteht diese Verbindung nicht. Beispielsweise werden hier Datenpakete mit einer Adresse in ein Netzwerk geschickt, die von Knoten zu Knoten u ¨bertragen werden. Jede Schicht des OSI-RM in Abbildung 4.1 wird im Folgenden kurz beschrieben [Tan96]. OSI-Schicht 1: Die Physikalische (Physical) oder Bit¨ ubertragungsschicht ist verantwortlich f¨ ur den Bitstrom zwischen physisch oder drahtlos verbundenen Systemen. Aus mechanischer Sicht wird hier z. B. das Kabel/das Medium, der Stecker usw. be-

4.1 Das ISO-OSI-Referenzmodell

83

stimmt. F¨ ur die Elektronik wird z. B. die Spannung, die Bitdauer usw. festgelegt. Pro¨ zedural wird als Beispiel die Ubertragungsart, z. B. unidirektional, bidirektional usw. definiert. OSI-Schicht 2: Die Daten-Sicherungsschicht (Data Link) ist verantwortlich f¨ ur die gesicherte Daten¨ ubertragung. Die Daten werden meist (bei einer Paketvermittlung) in nummerierte Pakete (Rahmen, Frames) zerlegt. Hier werden Fehler in der ¨ Ubertragung erkannt und eventuell korrigiert. F¨ ur lokale und auch f¨ ur drahtlose Netze, bei denen sich mehrere Knoten ein physisches Medium teilen, hat sich eine Untergliederung in Schicht 2a: Media Access Control (MAC) und Schicht 2b: Logical Link Control durchgesetzt [Ga09]. OSI-Schicht 3: In der Vermittlungs- oder Netzwerkschicht (Network) werden die Wege f¨ ur die einzelnen Datenpakete festgelegt, d. h. der Pakettransport von Endger¨at ¨ zu Endger¨ at wird gesteuert. Falls eine Uberlastkontrolle n¨otig ist, wird sie hier oder in der Transportschicht durchgef¨ uhrt. OSI-Schicht 4: Die Transportschicht (Transport) u ¨bernimmt die Daten von der Netzwerkschicht und bereitet sie f¨ ur die Sitzungsschicht vor. Werden Daten in die andere Richtung u ¨bertragen, u ¨bernimmt die Transportschicht die Daten von der Sitzungsschicht und bereitet sie auf den Transport vor. Eventuell m¨ ussen die Daten in kleinere Einheiten zerlegt werden. Die Transportschicht baut bei verbindungsorienterter Daten¨ ubertragung eine Netzverbindung auf. Die Transportschicht ist verantwortlich f¨ ur eine zuverl¨ assige Daten¨ ubertragung, d. h. sie muss f¨ ur die Gew¨ahrleistung der geforderten Dienstqualit¨ at (Quality of Service QoS) sorgen. Das bedeutet, falls ein hoher Datendurchsatz ben¨ otigt wird, k¨ onnen auch mehrere Netzverbindungen (parallel) aufgebaut ¨ werden, man nennt dies Flusskontrolle (Flow Control) und Uberlastkontrolle (Congestion Control). Die Transportschicht wird auch als eine echte Ende-zu-Ende-Schicht bezeichnet. F¨ uhrt ein Programm bzw. ein Betriebssystem auf dem Sende-Computer eine Daten¨ ubertragung mit einem ¨ ahnlichen Betriebssystem aus wie auf dem EmpfangsComputer, so werden bekannte Datenheader und Steuerdaten ausgetauscht. OSI-Schicht 5: Die Sitzungsschicht (Session) erm¨oglicht den Aufbau einer Sit” zung“. Eine Sitzung kann eine einmalige Daten¨ ubertragung mit m¨oglicherweise großen Datenmengen sein, die u angere Zeit hinweg andauert oder ein Dialog“, bei ¨ber eine l¨ ” dem sowohl Computer A als auch Computer B senden als auch empfangen darf. Die Sitzungsschicht u ¨bernimmt dabei den Dienst Dialogsteuerung“, d. h. sie legt fest, wer ” jeweils mit dem Senden an die Reihe kommt. Falls einen Sitzung beispielsweise durch eine abgebrochene Transportverbindung unterbrochen wird, kann die Sitzungsschicht diese Verbindung durch Einf¨ ugen von Check Points“ in den Datenstrom nahezu an der ” Stelle wieder aufsetzen, an der sie abgebrochen wurde. OSI-Schicht 6: Die Darstellungsschicht (Presentation) u ¨bernimmt die Kodierung von Daten f¨ ur die Anwendung. Die Daten k¨onnen in einer bestimmten Kodierungsart im Netzwerk u ¨bertragen werden, beispielsweise im Unicode UTF-8“. Zudem ” k¨ onnen im Anwendungsprogramm Datenstrukturen definiert werden. Ein Beispiel f¨ ur eine Datenstruktur ist die Sammlung von Personendaten, also Namen, Geburtstag, Geschlecht usw. Das heißt eine Sammlung verschiedener Datentypen. In der Darstellungsschicht werden die seriellen Daten, die aus der Schicht 6 u ¨bergeben werden wieder in eine Struktur umgesetzt und an die Schicht 7 zur Anzeige weitergereicht.

84

4 Kommunikation, Busse, Netzwerke und verteilte Systeme Computer A 7 6 5 4 3 2 1

Anwendung Application Darstellung Presentation Sitzung Session Transport Transport Vermittlung Network Datensicherung Data Link Bitübertragung Physical

Protokolle

Computer B AH Daten PH AH Daten

SH PH AH Daten TH SH PH AH Daten NH TH SH PH AH Daten DH NH TH SH PH AH Daten Bits

DT

Anwendung Application Darstellung Presentation Sitzung Session Transport Transport Vermittlung Network Datensicherung Data Link Bitübertragung Physical

Physisches Medium

Abbildung 4.2: Im ISO-OSI-Referensmodell setzen Protokolle in jeder Schicht ihren Header vor die Daten (nach [Tan96]).

OSI-Schicht 7: Die Anwendungsschicht (Application) enth¨alt eine Vielzahl anwenderbezogener Dienste und Protokolle, z. B. Elektronische Post, Dateitransfer usw. Die Schichten 1 bis 4 werden als transportorientierte Schichten“ bezeichnet, die Schich” ten 5 bis 7 als anwendungsorientierte Schichten“. ” Protokolle sind Datenverarbeitungs- und Darstellungsregeln die f¨ ur jede Schicht vereinbart werden. In Abbildung 4.1 sind diese Protokolle bezeichnet. Es gibt das Anwenderprotokoll auf Schicht 7, das Darstellungsprotokoll auf Schicht 6 usw. Jede Schicht muss ihr Protokoll genau kennen und einhalten, sonst ist eine Verbindung zwischen Computern bzw. Prozessoren nicht m¨ oglich. Jede Schicht generiert im Protokoll ein eigenes Kopfdatenfeld“, den Header“, der vor ” ” die Nutzdaten“ gesetzt wird (siehe Abbildung 4.2). Der Inhalt der Header muss ge” nau definiert werden. Ein einfaches, fiktives Beispiel f¨ ur das Anwenderprotokoll und das Darstellungsprotokoll eines Hello World“-Programms ist wie folgt denkbar: Die Anwen” derschicht setzt in unserem Fall eine Programmkennung HWP“ als Anwendungsheader ” (AH siehe Abbildung 4.2) vor die Daten (den Text) der Anwendungsschicht, wobei in unserem fiktiven Fall als Regeln f¨ ur den AH und den Text gilt: AH ist ein Feld mit drei ASCII-Zeichen, das Feld < T ext > = Hello World“ ist im Unicode UTF-8 kodiert. ” Folgende Daten werden in unserem Beispiel an die Darstellungsschicht weitergereicht: < AH > < T ext > = < HW P > < Hello W orld >. Die Darstellungsschicht setzt vor die Daten der Anwendungsschicht, noch ein Feld mit < T extlaenge >. Das Datenfeld der Schicht 6 besteht aus < T extlaenge > < HW P > < Hello W orld >, wobei das

4.2 Modellierung der Kommunikation

85

Feld < T extlaenge > 4 Byte lang und eine vorzeichenlose (unsigned) Hexadezimalzahl ist, die die L¨ ange des gesamten Datenfeldes der Anwendungsschicht darstellt. Wie oben erw¨ ahnt, wurde das OSI-Referentmodell vielfach wegen seiner Komplexit¨at kritisiert. Das TCP/IP (Transmission Control Protocol/Internet Protocol)-Referenzmodell kommt z. B. mit insgesamt vier Schichten aus, d. h. mit drei transportorientierten und einer anwendungsorientierten Schicht: der Anwendungsschicht. Das TCP/IP-Referenzmodell eignet sich allerdings nicht als allgemeines Referenzmodell um ein anderes offenes System zu erkl¨ aren. So w¨ are es beispielsweise praktisch unm¨oglich, das IBMKommunikationssystem SNA“ (System Network Architecture) zu beschreiben, mit dem ” OSI-Referenzmodell ist dies sehr wohl m¨ oglich [Tan96]. Tanenbaum [Tan96] verwendet in seinem Buch ein 5-schichtiges Referenzmodell. Im Vergleich zum OSI-Referenzmodell wird bei Tanenbaum die Sitzungs- und Darstellungsschicht in die Anwendungsschicht integriert.

4.2

Modellierung der Kommunikation

4.2.1

Kommunikationsprimitive

Um die Komplexit¨ at eines Software-Programms in einem Eingebetteten System mit Mikroprozessoren zu verringern, wird das Programm in u ¨berschaubare Module und Prozesse aufgeteilt. Einen Prozess kann man mittels eines Zustandsdiagramms wie in Abbildung 5.37 darstellen. Module, Prozesse oder Komponenten eines Eingebetteten Systems, die oft parallel oder quasiparallel ablaufen, tauschen in der Regel Daten aus. Die Daten werden physisch u uhrt, ¨ber Datenleitungen als elektrische Datensignale gef¨ wobei die Spannungspegel die logische 0 und die logische 1 repr¨asentieren. Wird ein Datensignal oder ein anders bezeichnetes Signal auf eine Leitung gegeben, so sagt man: Die Leitung wird aktiviert“. Es ist wichtig, dass der Datenaustausch zwischen den Pro” zessen nur dann stattfindet, wenn beide Prozesse dazu bereit sind, d. h. der Sendeprozess muss sich im Sendezustand, der Empfangsprozess im Empfangszustand befinden. Ist dies der Fall, dann sagt man, die Prozesse sind synchronisiert (siehe Abschnitt 5.8.3). Die Synchronisierung der Kommunikation zwischen Prozessen durch die sogenannten Kommunikationsprimitive“ zeigen die Abbildungen 4.3 und 4.4. ” Abbildung 4.3 zeigt das blockierende Senden und Empfangen“. mit zwei Prozes” sen: Dem Sende- und Empfangsprozess. Der Sendeprozess ist die Datenquelle“, von der ” Daten an den Empfangsprozess weitergegeben werden. Von beiden Prozessen wird nur jeweils ein Zustand dargestellt, d. h. man muss sich in beiden F¨allen weitere Zust¨ande oberhalb“ und unterhalb“ des Sende- und Empfangszustands vorstellen. Das blo” ” ” ckierende Senden und Empfangen“ ben¨ otigt neben dem Datensignal zwei Steuersignale. Das Valid-Signal“ (valid) und das Acknowledge-Signal“ (ack), die jeweils u ¨ber gleich” ” lautende Leitungen gef¨ uhrt werden. Die Datenleitung, die das Datensignal u ¨bertr¨agt, kann aus mehreren Einzelleitungen bestehen, beispielsweise aus 32 Leitungen bei einer Datenbreite“ von 32 Bit. Will der Sendeprozess Daten an den Empfangsprozess ” u ¨bertragen, so wird das Valid-Signal aktiviert, gleichzeitig werden die Daten auf die Datenleitung gegeben. Der Empfangsprozess wartet auf das Valid-Signal, er ist so lange

86

4 Kommunikation, Busse, Netzwerke und verteilte Systeme

Sendeprozess not ack

Empfangsproz. valid not valid data ack

ack

valid

Takt

Sendeprozess

valid data

Empfangsprozess

y und dem Namen myCh deklariert (Zeile 23) und die Methode ChCall am Port myCh (Zeile 27) aufgerufen. Die Task B2 (Zeile 30) wird als SC M odule deklariert. B2 enth¨alt 2 Instanzen von CH1: ch11 und ch12 (Zeile 31), ebenso enth¨alt B2 zwei Instanzen des Moduls B1 b11 und b12 (Zeile 32). Der Konstruktor von B2 (Zeile 33) teilt den Instanzen von B1 und den Instanzen der Channels Bezeichnungen zu und verbindet die Channel-Instanzen mit Ports. In der main-Methode von T askB2 werden sequenziell die main-Methoden von b11 und b12 aufgerufen (Zeilen 40 und 41). Das Ergebnis der Code-Generierung in ANSI-C nach den Regeln 1 bis 6, aus der Liste 5.1 Abbildung 5.52: ist wie folgt (nach Gajski et al. [Ga09]): Anwendung der Regel 1: Modul B1 (Zeile 21 bis 29) wird in Struct B1 konvertiert, ebenso der Channel CH1.

5.8 Modellbasierte Entwicklungsmethode 1 2 3

4 5 6 7 8 9 10 11 12 13 14 15 16 17

18 19 20

// Deklaration der Kanalklassen class iChannel : public sc_interface { public : virtual void chCall (int value) = 0; // Methode // deklariert } // Deklaration Hauptklasse CH1 class CH1 : public sc_channel, public iChannel { // Interface // „Konstruktor“: public : CH1 (sc_module_name name) : sc_channel( name ) {} virtual void chCall( int value ) { // Name check cout myCh, (This -> a)*2); } Regel 5: Die Methode main() in B1 wird konvertiert zur globalen Funktion (structB1 ∗ T his) und referenziert den Kontext. Das ist n¨ otig, um zwischen verschiedenen Instanzen zu unterscheiden (siehe oben). B1 main wird mit dem Zeiger auf die Instanzen (T his → b11) aufgerufen). Regel 6: Initialisierung von Task B2 und Verbindung von b11, b12 mit dem Port bzw. Channel ch11 bzw. ch12. void TaskB2_main(struct TaskB2 *This) { B1_main(& (This -> b11)); B1_main(& (This -> b12)); } Verbindung der Tasks b11, b12 mit den Ports und Aufruf der T askB2(): struct TaskB2 taskB2 = { {&(taskB2.ch11),0 /* a */ } /* b11 */, {&(taskB2.ch12),0 /* a */ } /* b12 */, {..} /*ch11*/, {..} /*ch12*/, }; void TaskB2() { TaskB2_main(&task1); } Alle Code-Teile, die die Regeln erl¨ autern, stammen aus dem Buch von Gajski et al. [Ga09]. Wie oben gesagt, ist die Sprachkomplexit¨at die gr¨oßte Herausforderung der Code-Generierung [Ga09], daher kann nur eine Untermenge von SLDL-Eigenschaften f¨ ur die Beschreibung zugelassen werden. Jedes Werkzeug wird zus¨atzlich Richtlinien vorgeben, damit der Parser die Beschreibungen sinngem¨aß interpretiert und das Werkzeug diese korrekt konvertiert. Multi-Task-Synthese Werden einem Prozessor mehrere Prozesse (Tasks) zugeteilt, so m¨ ussen diese eingeplant ( ge-schedult“) werden. Es gibt zwei M¨ oglichkeiten der Multi-Task-Synthese: ” • Echtzeitbetriebssystem-basiertes Multitasking oder k¨ urzer: RTOS-basiertes Multitasking. • Interrupt-basiertes Multitasking.

5.8 Modellbasierte Entwicklungsmethode

199

Das RTOS-basierte Multitasking wird haupts¨achlich f¨ ur gr¨oßere Eingebettete Systeme genutzt. Bei kleineren Systmen mit weniger Prozessen bzw. Tasks, wird auch das Interrupt-basierte Multitasking eingesetzt, bei dem die Anwendung auf einem nackten“ ” Prozessor ohne Betriebssystem implementiert werden kann, vorausgesetzt, der Prozessor hat Interrupt-F¨ ahigkeiten.

SW Anwendung Treiber RTOS Abstraction Layer RTOS HAL Interrupts

Abbildung 5.53: SW-Stack f¨ ur RTOS-basiertes Multitasking (nach [Ga09]).

Real Time Operation System (RTOS)-basiertes Multitasking Handels¨ ubliche Echtzeit-Betriebssysteme sind bei Entwicklern von Eingebetteten Systemen sehr beliebt, da sie flexibel und zuverl¨ assig sind. Die Abbildung 5.53 zeigt den Software-Stapel (Stack) f¨ ur ein RTOS-basiertes Multitasking-System [Ga09]. Die unterste Schicht des Stapels ist die HAL-Schicht (HardwareAbstraction Layer), sie passt die Hardware an das dar¨ uber liegende Echtzeit-Betriebssystem an. Die HAL-Schicht beinhaltet die Treiber f¨ ur die Kommunikation auf dem Bus, die Schnittstelle mit der programmierbaren Interrupt-Steuereinheit (PIC) und f¨ ur die ¨ Programmierung des Zeitgebers (Timer). Uber der HAL-Schicht liegt das RTOS. Das RTOS liefert die Dienste f¨ ur das Task-Management, f¨ ur die Kommunikation und f¨ ur das Zeitgeber-Management. Die RTOS-Anpassungs-Schicht RAL (RTOS Abstraction Layer) passt die Schnittstellen des RTOS, Application Programming Interfaces (APIs) genannt, an die Anwendung an. Es sind die Schnittstellen zum Beispiel f¨ ur die TaskGenerierung, die Semaphoren und Zeitgeber-Einstellungen, die je nach Betriebssystem verschieden sein k¨ onnen. Standardisierte APIs f¨ ur Echtzeit-Betriebssysteme gibt es bei den Systemen POSIX, OSEK, dagegen haben zum Beispiel die Betriebssysteme μCOS II, VXWorks, eCOS propriet¨ are APIs [Ga09]. Die Anwendungs-Software benutzt direkt die high-level“ Kommunikationstreiber (siehe ” Treiber“ in Abbildung 5.53) und das RAL. Die Treiber liefern Dienste f¨ ur die interne ” und externe Kommunikation, f¨ ur die Synchronisierung u ¨ber Interrupts, Bus-Zugriffe usw. Im Buch von Gajski et al. [Ga09] wird ein SystemC-Codebeispiel eines einfachen MultiTask-Systems beschrieben und die Generierung von entsprechendem C-Code als Ergebnis der Software-Synthese gezeigt. Interrupt-basiertes Multitasking Ein alternatives Verfahren zum RTOS-basierten Multitasking ist die Interrupt-basierte Methode f¨ ur kleinere Systeme mit weniger Prozessen, wenn das RTOS-basierte Verfahren zu aufw¨ andig scheint [Ga09]. Der Stack des Interrupt-basiertes Multitasking ist

200

5 Entwicklungsmethodik

beinahe identisch mit dem Stack in Abbildung 5.53 mit dem Unterschied, dass das RTOS fehlt und durch eine RTOS-Abstraction-Schicht (RAL) ersetzt wird, die eine relativ d¨ unne“ RTOS-Emulations-Schicht enth¨alt. Das RAL liefert hier kein Task” Management mehr, stattdessen muss der Code in den Tasks an das Interrupt-basierte Multitasking angepasst werden. C0 C1 S1

ST0

C0

ST1

C1

I1

I1 ST2

T1 C2

S1 T1 C2 I2

S2

I2

ST3

T2

S2 T2

Eingangs-Task

Ausgangs-Task als FSM

Abbildung 5.54: Zustandsfolgen der Eingangs-Task und die Ausgangs-Task als FSM (nach [Ga09]).

Das RTOS verf¨ ugt u ¨ber einen eigenen Stack und kann daher in jedem Punkt der Ausf¨ uhrung einer Task zu einer anderen Task wechseln, vorausgesetzt die Tasks sind pr¨ aemptiv“. Bei einem Taskwechsel wird der Kontext der aktuellen Task auf dem ” Stack gespeichert. Das RTOS holt sich den Kontext der neuen Task und f¨ahrt mit der Ausf¨ uhrung fort. Beim Interrupt-basierten Multitasking teilen die Tasks einen gemeinsamen Stack, der nicht f¨ ur die Speicherung verschiedener Kontexte verwendet werden kann. Die L¨ osung des Problems funktioniert nach Gajski et al. [Ga09] wie folgt: die Tasks werden in einzelne Zust¨ ande aufgebrochen, die in einem endlichen Automaten (FSM) ausgef¨ uhrt werden. Interrupts werden nur an den Zustandsgrenzen zugelassen. Damit merkt sich die einzelne Task im Zustandsregister selbst den Zustand, in dem sie unterbrochen wurde. In Abbildung 5.54 wird dieses Verfahren erl¨autert. Die Eingangs-Task besteht aus Anwendungs-Programmteilen f¨ ur die Berechnung (im Bild C wie Computation) und Aufrufe f¨ ur den Kommunikationstreiber. Der Treibercode enth¨alt einen Synchronisa¨ tionsteil S und einen Ubertragungsteil T . Unter der Annahme, dass jede Task aus Sequenzen der Codeteile C, S, T besteht, ist im Bild die Eingangs-Task in C1, S1, T 1 und C2, S2, T 2 aufgeteilt, danach kehrt die Ausf¨ uhrung zu C1 in einer Schleife zur¨ uck. In den Synchronisationsteilen S1 und S2 wird jeweils ein Interrupt ausgef¨ uhrt.

5.8 Modellbasierte Entwicklungsmethode

201

Die Hauptfunktion (main-Funktion) der Ausgangs-Task kann in eine FSM mit verschiedenen Zust¨ anden aufgeteilt werden wie in Bild 5.54 gezeigt. Im Bild sind es vier Zust¨ ande, ST 0, ST 1 bis ST 3. Der Zustand ST 0 enth¨alt die Initialisierung C0. Der Zustand ST 1 enth¨ alt die Berechnung C1 nach der die Task (die FSM) durch den Interrupt I1 unterbrochen werden kann. Im Zustandsregister merkt sich die FSM den Zustand ST 2 als Folgezustand. Es kann ein Taskwechsel stattfinden. Wenn nach dem Taskwechsel die Synchronisation S1 erfolgt, l¨ auft die Ausgangs-FSM im Zustand ST 2 weiter, bis die Berechnung C2 beendet ist und erneut durch einen Interrupt I2 unterbrochen werden kann usw. Bei diesem Verfahren muss auf die lokalen Variablen geachtet werden. Innerhalb des Zustands k¨ onnen sie verwendet werden, jedoch bei einem Zustandswechsel kann der Wert derselben verloren gehen. Daher m¨ ussen lokale Variable in globale Variable u uhrt ¨berf¨ werden. Die Task-FSM wird im Interrupt-Handler ausgef¨ uhrt.

Task B2

c1 c2

B1

Task B3

CPU

Task B3

Task B2

RTOS

Treiber

B1

Treiber

IPC: TLM mit abstrakten Kanälen

IPC: Abstrakte Kanäle werden durch RTOS-Primitive ersetzt

Sem1 Sem2

Abbildung 5.55: Linke Seite: Im TLM wird die Kommunikation u ale darge¨ber abstrakte Kan¨ stellt. Rechte Seite: In der Prozessor-Software wird die Kommunikation u ¨ber RTOS-Primitive durchgef¨ uhrt (nach [Ga09]).

Interne Inter-Prozess-Kommunikation (Interne IPC) Unter interner Inter-Prozess-Kommunikation“ versteht man die Kommunikation zwi” schen Prozessen, die auf demselben Prozesser ausgef¨ uhrt werden. Im Beispiel Abbildung 5.55 ist auf der linken Seite die Kommunikation u ¨ber die abstrakten Kan¨ale c1 und c2 gezeigt und kann so in einem TLM beschrieben werden. In der Software-Synthese werden diese abstrakten Kan¨ ale durch RTOS-Primitive, zum Beispiel durch Semaphoren und Events“ (Ereignisse, hier Aufruf-Signale“) ersetzt wie auf der rechten Seite in ” ” Abbildung 5.55 gezeigt [Ga09].

202

5 Entwicklungsmethodik

F¨ ur einen einzelnen Single-Handshake“-Verbindungsaufbau findet man in [Ga09] ein ” kurzes Beispiel. F¨ ur den Halbkanal c1 (siehe Abbildung 5.55) wird ein C-Struct definiert, in dem die Semaphoren-Funktionen in folgender Reihenfolge aufgerufen werden: 1. Initialisierungs-Funktion mit dem Semaphoren-Aufruf sem init(). 2. Sende-Funktion mit dem Semaphoren-Aufruf sem post() und einem Zeiger auf die zu u ¨bertragenden Daten. 3. Empfangs-Funktion (receive) mit dem Semaphoren-Aufruf sem wait() und einem Zeiger auf Variablen-Speicher f¨ ur die Empfangs-Daten. Kommunikation mit externen Prozessen Unter externer Kommunikation versteht man die Kommunikation zwischen einem Prozess auf einem Prozessor A“ und einem Prozess, der auf einem anderen Prozessorele” ment B“ l¨ auft. Das Prozessorelement B“ kann zum Beispiel ein externer Speicher, ein ” ” Rechenbeschleuniger oder ein Kommunikationselement sein. Das TLM kommuniziert über abstrakte Kanäle CPU

B1

HW2

B5 Task B2

c1 c2

HW1

B4

Task B3

c3 c4

Abbildung 5.56: Im Beispiel-TLM wird die externe Kommunikation u ¨ber die abstrakten Kan¨ ale c3 und c4 dargestellt.

In der Abbildung 5.56 kommuniziert z. B. die Task B2 u ¨ber den externen Channel c3 mit Task B4 auf dem Hardware-Prozessorelement Hardware1 und die Task B3 mit Task B5 auf Hardware2 u ¨ber den externen Channel c4. Im Protokoll-TLM Abbildung 5.50 ist die Kommunikation etwas detaillierter u ¨ber Halbkan¨ale dargestellt, in die Treiber und MAC eingef¨ ugt sind. F¨ ur die Software-Beschreibung in C werden folgende Informationen ben¨ otigt, die das TLM enth¨ alt [Ga09]: • Netzwerkauslegung (bedeutet: das Netzwerk-TLM wird ben¨otigt). • Anzahl der Kan¨ ale.

5.8 Modellbasierte Entwicklungsmethode

203

• Paketgr¨ oße und • Informationen u ubertragung (Routing und Switching). ¨ber die Art der Daten¨ Datenformatierung Zwischen heterogenen kommunizierenden Prozessor-Elementen muss in der Regel eine Datenformatierung durchgef¨ uhrt werden. Dies gilt sowohl f¨ ur Nachrichten als auch f¨ ur Daten (Variablen). Folgende Datenformate m¨ ussen bei der Daten¨ ubertragung angepasst werden [Ga09]: (1) Byte-Reihenfolge (Endianess): Man unterscheidet Big-Endian“ und Little Endi” ” an“. (1.1) Bei Big-Endian“ wird das Byte mit dem h¨ochsten Stellenwert zuerst, an die ” niedrigsten“ Speicherstellen (vorne) gespeichert. Beispiel Uhrzeit: Std:Min:Sek. ” (1.2) Bei Litttle-Endian“ wird das Byte mit dem niedrigsten Stellenwert zuerst, an die ” niedrigsten“ Speicherstellen gespeichert. Ein Beispiel ist die deutsche Schreibweise f¨ ur ” das Datum: Tag.Monat.Jahr. (2) Datenbreite auf Bit-Ebene, z. B. 32 Bit (4 Bytes). (3) Padding: Wird ein Datenelement mit n Bit in eine Datenstruktur mit der Datenbreite m Bit eingegeben und ist m > n, so wird das Datenelement meist rechtsb¨ undig eingegeben und die vorderen m − n Stellen mit einem Padding-Zeichen gepaddet, d. h. aufgef¨ ullt. Beispiel: Wird die Ganzzahl 123“ mit 3 Bytes in eine Speicherstelle mit der ” Breite 32 Bit (4 Bytes) rechtsb¨ undig eingespeichert, so wird in der Regel das erste Byte mit Nullen gepaddet“, d. h. aufgef¨ ullt. ” Der Prozess der Konvertierung des Anwendungs- bzw. Prozess-Datenformats zum Netzwerk-Datenformat wird Marshalling“ genannt, bei dem die Nutzdaten in einen fla” ” chen“ (sequenziellen), typfreien Datenstrom umgewandelt werden. Der umgekehrte Prozess, also die Umwandlung des flachen Datenstroms in Anwender-Datenformate nennt man Demarshalling“. Marshalling und Demarshalling wird in der Regel in der Pr¨asen” ” tierungsschicht“ (Schicht 6 des ISO/OSI-Referenzmodells, siehe Kapitel 4) durchgef¨ uhrt [Ga09]. In dem Buch von Gajski [Ga09] findet man ein Codebeispiel f¨ ur einen MarshallingProzess. Paketierung Der typfreie Datenstrom, der im Marshalling-Prozess erzeugt wird, kann beliebig lang sein. Dieser Datenstrom wird entsprechend den Erfordernissen des Netzwerks, zum Beispiel entsprechend der begrenzten Speicherm¨ oglichkeit in einem Kommunikationselemnt (Transducer), in Pakete aufgeteilt und durch die Netzwerkschicht u ¨bertragen. Ein Codebeispiel f¨ ur die Paketierung findet man in dem Buch von Gajski [Ga09]. Synchronisierung Das Wort Synchronisierung“ kommt aus dem Griechischen ( syn“: zusammen, chro” ” ” nos“ die Zeit) und bedeutet soviel wie Abstimmen der Zeit“. Synchronisierung in der ” Kommunikation bedeutet die Herstellung der Bereitschaft der Kommunikationspartner ” zur Daten¨ ubertragung“ [Ga09]. Im ISO/OSI-Referenzmodell geschieht die Synchronisierung in der Link-Schicht (siehe Abschnitt 4.1 und 4.2.1).

204

5 Entwicklungsmethodik

Falls das Bus-Protokoll die Synchronisierung nicht einschließt, kann der Benutzer zwischen interruptbasierter Synchronisierung“ und pollingbasierter Synchronisierung“ ” ” w¨ ahlen. Die Wahl der Methode h¨ angt davon ab, ob der in Frage kommende Prozessor interruptf¨ ahig“ ist und ob die Verz¨ ogerungen tolerierbar sind, die bei den verschiedenen ” Synchronisierungsmethoden auftreten [Ga09]. Interruptbasierte Synchronisierung Die interruptbasierte Synchronisierung verwendet eine zus¨atzliche Leitung, die IR” Leitung“, um das asynchrone Interrupt-Signal von einer Hardware-Einheit zu einem Prozessor zu senden. Wird ein Interrupt-Signal empfangen, unterbricht der Prozessor den laufenden Prozess und startet den Interrupt-Handler (IH), der daraufhin die Kommunikation mit der Hardware initiiert. Das vom Hardware-Prozessorelement kommende Interrupt-Signal l¨ auft im programmierbaren Prozessor durch die sogenannte Interrupt-Kette“ (siehe Abbildung 5.50), die in unserem Beispiel aus den Interrupt” Handler-Gliedern Sysint, INTC und Userint2 besteht. Der Semaphoren-Channel Sem2 verbindet den Interrupt Handler mit dem Treiber, der gestartet wird, um die Kommunikation durchzuf¨ uhren. Prozessor Kern TASKB2 t0 t1 t2 t3 t4 t5

Zeit

TASKB3

PIC

IH

HW1 B4

HW2 reg

B5

reg

Sem1 Preempt. by Int. 1 Which Int? 2 Int. Source?

Int

Int

3 4

Sem2.send( )

Datenübertragung

Abbildung 5.57: Schematische Darstellung des Zeitablaufs der interruptbasierten Synchronisierung (nach [Ga09]).

Der Ablauf der interruptbasierten Synchronisierung wird in der Hardware-dependent Software (HdS) durchgef¨ uhrt und ist in Abbildung 5.57 schematisch dargestellt [Ga09]. Zum Zeitpunkt t0 erwartet die Task B3 eine Nachricht von Task B5 und er¨offnet daf¨ ur eine Semaphore Sem1. B3 setzt aus und B2 mit niedrigerer Priorit¨at wird zun¨achst weitergef¨ uhrt. Zum Zeitpunkt t1 hat B5 die Nachricht bereit und schickt ein Interrupt-Signal zum Programmable Interrupt Controller (PIC) der den Interrupt setzt“, d. h. u ¨ber die Leitung ” zum Prozessor sendet. Das l¨ ost folgende Kette von Aktionen aus, die in den Schritten 1 bis 4 abl¨auft [Ga09]: Schritt 1: Der Low-Level IH“ unterbricht (preempts) die Task B2. Der Kontext wird ” auf dem Stack gespeichert und danach der IH aufgerufen.

5.8 Modellbasierte Entwicklungsmethode

205

Schritt 2: Zeitpunkt t2: Der System-IH Sysint“ fragt den PIC: Welcher IR?“ PIC ” ” antwortet: High Priority IR“ von Hardware1 oder Hardware2. Danach ruft er den ” anwendungsspezifischen IH INTC“ auf. ” Schritt 3: Zeitpunkt t3: Der IH INTC liest beide Status-Register sowohl von Hardware1 als auch von Hardware2, pr¨ uft diese und erkennt, dass der Prozess B5 auf Hardware2 den Interrupt ausgel¨ ost hat. Schritt 4: Zeitpunkt t4: INTC ruft den User Interrupt Handler“ USRint2 f¨ ur B3 auf. ” Userint2 ruft die Semaphore Sem2 auf und gibt den Treiber-Code frei, der seinerseits Task B3 frei gibt. Task B3 wird wieder bereit zur Ausf¨ uhrung. Der IH terminiert nach Freigabe der Semaphore. Zeitpunkt t5: Die Task B3 liest die Daten von B5. Damit ist der Datentransfer von B5 nach B3 beendet. Die Hardware dependent Software-Synthese (HdS-Synthese) generiert den Code f¨ ur die interruptbasierte Synchronisierung basierend auf dem UserInt2-Code im TLM. F¨ ur die Software-Synthese werden verschiedene RTOS-spezifische Code-Teile ben¨otigt, z. B. der Low-Level IH“ und der Sysint-Code, der ein Element des Hardware Abstraction Layer ” HAL ist. Beide Teile sind in der Software-Datenbasis vorhanden.

Prozessor Kern TASKB2 t0

HW2

TASKB3

reg 1

Ready?

2

Ready?

3

Ready?

t1 t2 t3 t4

Zeit

B5 Pollingperiode ready

4 Datenübertragung

Abbildung 5.58: Schematische Darstellung des Zeitablaufs der pollingbasierten Synchronisierung (nach [Ga09]).

Pollingbasierte Synchronisierung Die Pollingbasierte-Synchronisierung funktioniert ohne Interrupt und ist weniger aufw¨ andig als die interruptbasierte Synchronisierung. Sobald der Master bereit zur Daten¨ ubertragung ist, fragt er periodisch den Slave, ob er ebenfalls die Daten¨ ubertragung durchf¨ uhren kann. Zu diesem Zweck setzt der Slave, also in unserem Beispiel die Task B5 in der Hardware-Einheit, eine Flag“, das entspricht einem Registerwert, der die ” Bereitschaft zur Daten¨ ubertragung signalisiert [Ga09]. Als Beispiel f¨ ur die pollingbasierte Synchronisierung wird dieselbe Daten¨ ubertragung wie bei der Interrupt-Synchronisierung gew¨ ahlt. Abbildung 5.58 zeigt den Zeitablauf.

206

5 Entwicklungsmethodik

Schritt 1: Zum Zeitpunkt t0 erwartet die Task B3 eine Nachricht von Task B5. Der Treibercode fragt (pollt) die Status-Flag (das Register) in Hardware2 ab, um zu pr¨ ufen, ob die Nachricht verf¨ ugbar ist. Sie ist es nicht und TaskB3 geht in den Wartezustand. Die TaskB2 mit der niedrigeren Priorit¨ at wird aktiviert. Schritt 2: Zum Zeitpunkt t1 ist die Polling-Periode abgelaufen, TaskB3 wacht wieder auf, um den Status erneut abzufragen. Da die Nachricht noch nicht da ist, setzt B3 wieder aus und u asst B2 den Prozessor. ¨berl¨ Schritt 3: Zum Zeitpunkt t2 ist die Nachricht bereit, die Status-Flag wird ge¨andert. TaskB3 merkt dies jedoch nicht sofort. Zum Zeitpunkt t3 pollt B3 die Status-Flag wieder und stellt fest, dass die Nachricht verf¨ ugbar ist. Die Polling-Loop terminiert und die Task geht zum Datentransfer u ¨ber. Zum Zeitpunkt t4 (Schritt 4) ist die Daten¨ ubertragung abgeschlossen. Wie das Beispiel zeigt, gibt es durch das Polling eine Verz¨ ogerung zwischen der aktuellen Verf¨ ugbarkeit der Nachricht (Zeitpunkt t2) und seiner Entdeckung (t3). Diese Verz¨ogerung betr¨agt maximal eine Polling-Periode. Durch eine k¨ urzere Polling-Periode wird die maximale Verz¨ ogerung kleiner, daf¨ ur steigen auch die Anzahl der Status-Abfragen, ( Polls“) und ” damit wird die Busbelastung und der System-Overhead“ gr¨oßer. Es gibt daher einen ” Kompromiss zwischen der Polling-Verz¨ ogerung und dem System-Overhead. Eine schlechte Alternative zur Interrupt-basieren und pollingbasierten Synchronisierung ist das Polling ohne Verz¨ ogerung“ oder Busy Waiting“, bei der der Prozessor auf die ” ” Nachricht wartet (ohne eine andere Task zu aktivieren) und solange auch den Bus belegt. Dadurch wird aber wertvolle Prozessor- und Bus-Zeit verschwendet und daher wird diese Methode in der Regel vermieden [Ga09]. Ob interruptbasierte oder pollingbasierte Synchronisierung gew¨ahlt wird, h¨angt von der Anwendung und den System-Charakteristika ab. Interruptbasierte Synchronisierung wird im Allgemeinen bevorzugt, wenn die Voraussetzungen daf¨ ur vorhanden sind [Ga09]. Media Access Control (MAC) Der MAC-Treiber im Hardware Abstraction Layer (HAL) ist die unterste Schicht im Kommunikationsstapel f¨ ur die externe Inter-Prozess-Kommunikation. Er ist spezifisch ¨ f¨ ur das verwendete physikalische Ubertragungsmedium und erm¨oglicht den Zugriff zu diesem Medium, im unseren Falle zum Bus [Ga09]. Das heißt der MAC-Treiber muss das Bus-Protokoll kennen und beispielsweise die Pakete aus dem Paketierprozess (siehe Abschnitt 5.8.3) in Bus-Primitive“, d. h. Buspakete“ aufteilen. ” ” Der MAC-Treiber-Code kann relativ kompliziert sein, beispielsweise bei seriellen Bussen wie z. B. I2C oder CAN-Bussen. Er kann sehr einfach sein, wenn der Prozessor-Bus an einen Zugriff auf den Prozessor-Speicher angepasst ist. In diesem Fall ist der Code ahnlich dem Paketierungs-Code (siehe [Ga09]). Der MAC-Treiber Code wird typischer¨ weise der Datenbank f¨ ur den Bus entnommen [Ga09]. Starter-Programm und Bin¨ arcode-Generierung Bin¨ arcode-Generierung Die Bin¨ arcode-Generierung ist der letzte Schritt der Software-Synthese. Der komplette ausf¨ uhrbare Programm-Code f¨ ur den bzw. die Zielprozessoren oder f¨ ur ein PrototypenBoard wird erzeugt [Ga09].

5.8 Modellbasierte Entwicklungsmethode

207

TLM Software-Synthese Generierter Code HdS-Code

Anwendung

RTOS IH

Treiber HAL RAL

Startup

Build & Configure

Makefile Cross Compiler

Linker

SW DB -RTOS -HAL -Technologie - Libraries

Binärcode

Abbildung 5.59: Die Schritte der Bin¨ ar-Code-Generierung. SW DB: Software Datenbank (modifiziert nach [Ga09]).

Abbildung 5.59 zeigt die einzelnen Schritte der Bin¨arcode-Generierung. Die Eingabe in die Bin¨ arcode-Generierung ist das endg¨ ultige TLM. Die Software-Synthese erzeugt Code f¨ ur die Anwendung und f¨ ur die Hardware dependent Software (HdS)“, die z. B. das ” Echtzeit-Betriebssystem (RTOS), die Treiber f¨ ur das RTOS, den Hardware-Adaption Layer (HAL), den Interrupt-Handler (IH), den RTOS-Adaption Layer (RAL) und den Starter-Code enth¨ alt. Zus¨ atzlich wird ein Build-und-Configure-Schritt durchgef¨ uhrt und f¨ ur jeden Prozessor eine Makefile erzeugt. Anhand der Makefile wird der Cross-Compiler gestartet, der aus der Software-Datenbank die n¨otigen Teilprogramme bezieht. Dabei sind Abh¨ angigkeiten zwischen den einzelnen Programmteilen zu ber¨ ucksichtigen, zum Beispiel zwischen RTOS, RAL, Compiler, zwischen RTOS und HAL. Der Linker verbindet wichtige Bibliotheken (Libraries) aus der Software-Datenbank (SW-DB) mit dem kompilierten Code. F¨ ur einen reibungslosen Synthesefluss ist wichtig, dass die Eintr¨age in der Datenbank gut geordnet und die entsprechenden Informationen effektiv greifbar sind [Ga09]. Das Starter-Programm (Startup Code) verbindet nach dem Einschalten des Eingebetteten Systems alle Hardware- und Software-Komponenten, einschließlich aller Prozessoren und initialisiert sie [Ga09]. Im Starter-Programm werden folgende Programmteile initialisiert: • Das Basis-Support-Programm (BSP) initialisiert die Hardware. Gestartet wird zum Beispiel der Zeitgeber (Timer), der programmierbare Interrupt Controller (PIC) usw.

208

5 Entwicklungsmethodik

• Das RTOS-Betriebssystem. • Die Semaphoren werden erzeugt, die f¨ ur die externe Kommunikation zwischen Interrupt-Handler und OS-Treiber Verwendung finden. • Dem Interrupt-Handler werden die User Interrupt Request-Register“ zugewiesen. ” Das Betriebssystem wird gestartet, es generiert die einzelnen Tasks und beginnt mit dem Multitasking [Ga09].

ISS SLDL Wrapper

Core

HW1

HW2

B4

B5

Treiber

Treiber

MAC

MAC

ISS Libary Process

Drivers RTOS Abstraction Layer RTOS Interrupts

HAL

Protocol

SW Application

TLM

PIC INT

INTA INTB INTC

Source

Timer

Control

Status

Load

Mask

Value

Abbildung 5.60: ISS-basierte virtuelle Plattform (nach [Ga09]).

Ausf¨ uhrung des synthetisierten Systems: Das Eingebettete System, das aus der Hardware-, Software- und Schnittstellen-Synthese entstanden ist, wird auf eine Zielplattform mit FPGA’s oder auf eine virtuelle Plattform“ geladen, ausgef¨ uhrt und ve” rifiziert bzw simuliert. Die schematische Darstellung einer Instruktionssatz-basierten (Instruction Set Simulator-(ISS)-basierten) virtuellen Plattform zeigt Abbildung 5.60 aus [Ga09], die die Verifikationsplattform f¨ ur das Beispiel-TLM aus Abbildung 5.50 darstellt. Links im Bild ist der programmierbare Prozessor-Kern dargestellt mit integriertem ISS einschließlich Programmable Interrupt Controller (PIC) und Zeitgeber (Timer). Der ISS ist in einen SLDL-Wrapper“ eingepackt“. Die gesamte synthetisierte Software ein” ” schließlich RTOS, HAL usw. wird in den ISS geladen und vom Wrapper auf Zyklus-Basis aufgerufen. Der Wrapper erkennt Bus-Zugriffe vom ISS und u ¨bersetzt diese. Interrupts werden vom Wrapper erkannt und an den ISS weiter geleitet. Die Verifikation auf der Basis des ISS-Modells (ISM) ist relativ genau in Bezug auf die Ausf¨ uhrungszeit der Software und der Funktionalit¨at. Die Genauigkeit der Ausf¨ uhrungszeit bezogen auf das gesamte System ist allerdings nicht h¨oher als etwa 80% [Ga09]. Der Nachteil ist der hohe Zeitaufwand f¨ ur die Simulation. Beispielsweise betr¨agt die Simulationszeit f¨ ur ein MP3-Decoder-Modell auf ISS-Basis einige Stunden [Ga09].

5.8 Modellbasierte Entwicklungsmethode

209

Zusammenfassung Automatisierung erh¨ oht die Produktivit¨ at, daher ist eine automatische Generierung von Software, d. h. eine Software-Synthese, wichtig. Software-Generierung wird in Compilern schon seit langer Zeit praktiziert, sie ist jedoch bei der Entwicklung von Eingebetteten Systemen noch relativ selten. Gajski et al. [Ga09] haben einen l¨ uckenlosen Weg der Software-Synthese f¨ ur programmierbare Prozessoren aufgezeigt, die in den vorhergehenden Abschnitten verk¨ urzt wiedergegeben ist. Die Software-Synthese, nicht nur f¨ ur die Anwendung, auch f¨ ur die Kommunikation mit Hardware-Prozessoren wird Schritt f¨ ur Schritt erl¨ autert. Gajski et al. zeigen Programmteile f¨ ur die einzelnen Synthese-Schritte, die als Schablonen f¨ ur die Code-Generierung dienen k¨onnen. Die Software-Synthese f¨ uhrt folgende Aufgaben automatisch durch: • C-Code-Generierung aus einem System-TLM, einschließlich des Betriebssystems, das in einer System-Level Description Language geschrieben ist, zum Beispiel SystemC. • Generierung der Kommunikations-Software mit Treibern und Synchronisierung (interrupt- oder pollingbasiert). • Multi-Tasking-Generierung und Synthese. • Erzeugung der gesamten Bin¨ ar-Datei.

5.8.4

Das ESE-Werkzeug von Gajski et al.

Das ESE (Embedded System Environment)-Werkzeug, entwickelt von Professor Gajski und seinen Mitarbeitern, beschrieben in seinem Buch [Ga09], ist ein akademisches Werkzeug, das die Modellbasierte Entwicklungssmethode (siehe Abschnitt 5.8) anschaulich demonstriert. Abbildung 5.61 zeigt die Benutzeroberfl¨ ache des ESE-Werkzeugs. Es besteht aus zwei Hauptteilen: dem Front-End und dem Back-End. Das Front-End erzeugt nach Eingabe der modellbasierten Spezifikation bzw. eines System-Modells in Form einer Process State Machine (PSM) ein zeitmarkiertes TLM (Timed TLM), das zur Exploration des Entwurfsraums, insbesondere zur Absch¨atzung der Ausf¨ uhrungszeit des Systems dient. Je nach Beschreibung des Systems k¨onnen damit auch andere Metriken wie zum Beispiel der Energieverbrauch usw. abgesch¨atzt werden. Das Timed TLM wird mit Hilfe des Validation User Interface“ verifiziert, nach ” Bedarf optimiert und wieder ins Front-End eingegeben. Dieser Verfeinerungs-Zyklus“ ” (Refinement) wird wiederholt, bis ein zufriedenstellendes, endg¨ ultiges TLM erreicht ist. Das endg¨ ultige TLM wird im Back End weiter synthetisiert und zwar wird eine Softwareund eine Hardware-Synthese automatisch durchgef¨ uhrt. Das Ergebnis des Back-End und damit des gesamten Werkzeugs ist ein pin- und zyklusgenaues Modell (PCAM) auf RTEbene, das durch herk¨ ommliche Werkzeuge weiter in ein FPGA und/oder in ein ASIC implementiert werden kann.

210

5 Entwicklungsmethodik

Decision User Interface (DUI)

Front-End System Capture + Platform Development

Stiumulate

Timed TLM

Select

Verify

Partition

Compile

Compile Debug

Create

Map

Validation User Interface (VUI)

Back-End SW Development + HW Development

Replace

Check Siumulate

CAM

Application Tools: Compilers/Debuggers

Cycle accurat e Compile

Verify

Commercial Tools: FPGA, ASIC

Abbildung 5.61: Die Benutzerober߬ ache des ESE-(Embedded Systems Environment)Werkzeugs (nach [Ga09]).

Mit dem ESE-Werkzeug wird im Buch von Gajski et al. [Ga09] die Entwicklung eines MP3-Dekoders demonstriert und die Vorteile der Entwurfsautomatisierung, ausgehend von der System-Ebene (Electronic System Level Design) anschaulich dargestellt.

5.9

Software-Entwicklung fu¨r Eingebettete Systeme

Die Zielsetzung der Software-Entwicklung f¨ ur Eingebettete Systeme ist anders als die f¨ ur große Software-Systeme. F¨ ur beide Systeme gilt die Forderung nach Zuverl¨assigkeit d. h. Qualit¨ at, Robustheit und Wartbarkeit (siehe Abschnitt 5.2). Eingebettete Systeme sind jedoch meist Echtzeitsysteme, sie werden oft in tragbare Ger¨ate eingebaut mit Platzbeschr¨ ankungen und Forderungen nach niedrigem Energieverbrauch. Diese Forderungen wirken sich auch auf die Software aus. Platzbeschr¨ankungen k¨onnen Speicherbegrenzungen bedeuten und Einsparungen beim Energieverbrauch erfordern eine genaue Analyse der Performanz und der Struktur der Programme. Die Tendenz in der Entwicklung von Eingebetteten Systemen geht hin zur automatischen Generierung nicht nur der Hardware mit Hilfe der High-Level-Synthese, sondern auch der Software. Dies trifft voll zu f¨ ur die automatische Erzeugung von Unterst¨ utzungscode von Anwenderprogrammen wie z. B. die Hardware dependent Soft” ware HdS“ (siehe oben). Jedoch wird die Entwicklung von Programmcode f¨ ur Berechnungsmodelle (Models of Computation MoC, siehe oben), sowie f¨ ur Algorithmen als kreative Handlung noch lange von Hand durchgef¨ uhrt werden.

5.9 Software-Entwicklung f¨ ur Eingebettete Systeme

211

In den folgenden Abschnitten werden wir die Themen: Entwicklungsmethodik, Entwurfsmuster, Programm-Modelle (DFG, CDFG) sowie die Optimierung der Programme auf Performanz, Gr¨ oße und Energieverbrauch betrachten.

5.9.1

Programmentwicklung

Wie weiter oben ausgef¨ uhrt, beginnt die Entwicklung eines Eingebetteten Systems mit Anforderungsdokument, Architekturfestlegung, Spezifikation, Generierung eines SystemVerhaltensmodells bzw. Modellierung der Algorithmen des Systems in einem oder mehreren Berechnungsmodellen. F¨ ur neu zu entwickelnde Eingebettete Systeme mit vielen geplanten Funktionen sollte die Entwicklungsmethodik nach dem Spiralmodell, Abschnitt 5.4.2 gelten. F¨ ur Eingebettete Systeme wird die Programmiersprache C empfohlen, jedoch wo immer m¨ oglich, sollten auch h¨ ohere Programmiersprachen wie zum Beispiel C++ oder Java zur Anwendung kommen. Eine verbreitete Methode ist die Modellierung von Programmcode mit Klassendiagrammen. Falls Software nicht als Intellectual Property (IP) eingekauft werden kann, wird der Entwickler sich f¨ ur Software-Eigenentwicklung und zum Beispiel f¨ ur Objekt-orientierten Hochsprachen entscheiden. Bei Software-Eigenentwicklung und der Verwendung von Objekt-orientierten Hochsprachen wird zun¨achst der Entwurf mit Hilfe von Klassendiagrammen durchgef¨ uhrt (siehe n¨achsten Abschnitt). Wo immer m¨ oglich, sollten Entwurfsmuster (Design Patterns, siehe Abschnitt 5.9.3) verwendet werden. Zeitkritische Programmteile werden oft in Assembler geschrieben und auf Ausf¨ uhrungszeit optimiert (siehe Abschnitt 5.9.6). Ist ein Programm f¨ ur den Einsatz in einem tragbaren Ger¨ at gedacht, wird es in der Regel auf Energieverbrauch optimiert (siehe Abschnit 5.9.6).

5.9.2

Entwickeln von Klassendiagrammen mit CRC-Karten

Die CRC-Karte (Class-Responsibility-Collaboration-Karte) ist ein Hilfsmittel nicht nur f¨ ur objektorientierte Entwicklung, sondern auch allgemein f¨ ur Eingebettete Systeme. Das Konzept wurde 1989 von Beck und Cunningham vorgestellt [BeCun89]. Das Grundprinzip besteht darin, f¨ ur jede Klasse eine Karteikarte zu erstellen und auf dieser deren Eigenschaften zu notieren. F¨ ur CRC-Karten gibt es keine Norm. Es bieten sich daf¨ ur Registrierkarten etwa der Gr¨ oße 3 × 5 (7,5 cm × 12,5 cm) an. Diese bestehen aus drei Bereichen (siehe Abbildung 5.62): • Oben links steht der Name der Klasse. • In die linken Spalte schreibt man die Verantwortlichkeiten der Klasse. • In der rechte Spalte stehen die Klassen, mit denen die beschriebene Klasse zusammenarbeitet (kollaboriert). Es gibt eine Vielzahl von Erweiterungen des urspr¨ unglichen Konzepts, die zus¨atzliche Bereiche hinzuf¨ ugen und teilweise auch die R¨ uckseiten der Karten verwenden. Der Vor-

212

5 Entwicklungsmethodik

Namen der Klasse

Kollaboriert mit (Klasse)

Verantwortlichkeiten (Responsibilities): Zuständigkeiten Eigenschaften Funktionen (Methoden)

Abbildung [Wolf02]).

5.62:

Beispiel einer CRC-(Class-Responsibility-Collaboration)-Karte (nach

teil der CRC-Karten liegt in der einfachen Handhabung. Man kann problemlos Informationen hinzuf¨ ugen oder streichen. Auf Grund des einfachen Ansatzes ist man auch unabh¨ angig von verwendeten Programmiersprachen und -werkzeugen. Der begrenzte Platz zwingt die Entwickler zus¨ atzlich dazu, sich auf die wesentlichen Aufgaben einer Klasse zu konzentrieren. Relationen zwischen den Klassen kann man wie folgt veranschaulichen: Der Namen der kollaborierenden Klassen stehen bereits auf der Karte, man kann nun z. B. die Karten an eine Tafel heften und Bezugslinien zwischen den Karten zeichnen, so erh¨ alt man das Klassendiagramm. Das Verfahren scheint zun¨achst trivial zu sein, es ist aber sehr wirkungsvoll, wenn es in einer Gruppe von Entwicklern und Spezialisten des Gebiets, wof¨ ur das System entwickelt werden soll, gespielt“ wird. Der ” Vorteil dieser anerkannten Methode ist, dass mehrere versierte Personen, auch NichtComputer-Fachleute, v¨ ollig informal miteinander kommunizieren und kreative Ideen einbringen k¨ onnen. Eine objektorientierte (OO) Klasse enth¨ alt Funktionalit¨at und kann ein reales Objekt oder ein Hilfsobjekt innerhalb der Architektur des Systems repr¨asentieren. Eine OOKlasse hat einen inneren Zustand und eine funktionale Schnittstelle. Die funktionale Schnittstelle beschreibt die F¨ ahigkeiten der Klasse. Die Liste der Verantwortlichkeiten auf der CRC-Karte ist eine informale Art, diese Funktionen bzw. die funktionalen Schnittstellen zu beschreiben, ohne auf die Implementierung einzugehen. Die Kollaborateure sind einerseits die Klassen, die Daten an die betrachtete Klasse weitergeben und andererseits die Klassen, die die Methoden, d. h. die Funktionen der betrachteten Klasse nutzen. So kann eine CRC-Karte in eine Klassen-Definition einer OO-Sprache u ¨bertragen werden. In einer CRC-Karten-Sitzung sollte man folgende Punkte abarbeiten [Wolf02]: 1. Entwickle eine initiale Liste aller Klassen, d. h. einen initialen Kartenstapel von CRC-Karten. Jedes Entwickler-Team-Mitglied sollte f¨ ur eine oder mehrere Klassen (Karten) verantwortlich zeichnen.

5.9 Software-Entwicklung f¨ ur Eingebettete Systeme

213

2. Entwickle jeweils eine initiale Liste von Verantwortlichkeiten (responsibilities) und Kollaborateuren f¨ ur jede Klasse, d. h. f¨ ur jede CRC-Karte. Diese Listen sollen sp¨ ater verfeinert werden. 3. Als n¨ achstes m¨ ussen alle m¨ oglichen Ablauf-Szenarien des Systems aufgelistet werden. Die Szenarien beginnen meist mit einem Anstoß (einem Ereignis) von außen. Beispiel f¨ ur ein solches Szenario ist eine Geldabhebung an einem GeldausgabeAutomaten (siehe Sequenz-Diagramm Abbildung 5.31). 4. Gehen Sie gr¨ undlich jedes einzelne Szenario mit der Entwicklergruppe durch (Walk Through). W¨ ahrend des Walkthrough pr¨asentiert jede Person seine Klassen mit deren Verantwortlichkeiten. Dabei werden die Eintr¨age auf den CRC-Karten erg¨ anzt und verfeinert. Wenn n¨ otig, sollten neue Klassen hinzugef¨ ugt und andere Klassen gestrichen werden. 5. Eventuell muss ein zweiter Walkthrough ¨ ahnlich dem vorhergehenden durchgef¨ uhrt ¨ werden, wenn u bei den Szenarios, den Klassen, den Ver¨bergreifende Anderungen antwortlichkeiten und den Kollaborateuren durchgef¨ uhrt wurden. 6. F¨ uge Klassen-Beziehungen hinzu. Sobald die CRC-Karten verfeinert werden, wer¨ den Unter- und Uberklassen klarer und k¨onnen den Karten hinzugef¨ ugt werden. Die CRC-Karten k¨ onnen direkt die Vorlage f¨ ur die Implementierung des Programms sein. Sie k¨ onnen aber auch zun¨ achst die Vorlage f¨ ur eine formales Modell des Systemverhaltens mit Hilfe eines UML-Diagramms (siehe Abschnitt 5.7.3), z. B. eines UMLKlassendiagramms oder eines Sequenz-Diagramms (Abbildung 5.31) sein, die die Grundlage f¨ ur das Entwurfsdokument des Systems darstellen k¨onnen. Struktur einer verketteten Liste LE (1)

LE (2)

LE (n)

....

List

create() add-element() delete-element() find-element() destroy()

1

*

List-Element (LE) name() vorname() telefon() pointer-nextel()

Entwurfs-Muster: Verkettete Liste als UML-Klasse

Abbildung 5.63: Beispiel eines Entwurfsmusters. Oben: Struktur einer verketteten Liste. Unten: Beschreibung der verketteten Liste als UML-Klasse (nach [Wolf02]).

214

5.9.3

5 Entwicklungsmethodik

Entwurfsmuster

Entwurfsmuster (Design Patterns)) sind eine verallgemeinerte Beschreibung einer bestimmten Klasse von Probleml¨ osungen [Wolf02]. Zum Beispiel kann ein Entwickler CCode f¨ ur eine Verkettete Liste als Datenstruktur selbst schreiben oder die Beschreibung einer Entwurfsmuster-Sammlung entnehmen. Der letztere Weg ist die bessere Methode; denn auch ein Programmierer sollte m¨ oglichst viele Programme wiederverwenden. Abbildung 5.63 zeigt oben die Datenstruktur einer verketteten Liste (VL). Zur Erinnerung: Eine verkettete Liste ist sehr n¨ utzlich, um beispielsweise ein Telefonbuch oder die Liste aller Angestellten einer Firma anzulegen. Jedes List-Element (LE) ist eine Datenstruktur, bei einem einfachen Telefonbuch enth¨alt das List-Element Namen, Vornamen und Telefonnummer einer Person. Jedes List-Element ist mit seinem Vorg¨anger und Nachfolger u ¨ber Zeiger verbunden. Die verkettete Liste, beispielsweise als UMLKlasse, enth¨ alt die Methoden, die auf eine verkettete Liste angewendet werden k¨onnen (unten im Bild 5.63). Diese Methoden sind z. B. create(): generiere ein List-Element, add-element(), delete-element(), find-element() usw. Das List-Element ist selbst eine Klasse, die im Beispiel Namensfelder, ein Nummernfeld und einen Zeiger f¨ ur das n¨achste List-Element enth¨ alt. Ein Entwurfsmuster kann erweitert werden, d. h. es kann an die W¨ unsche des Benutzers angepasst werden. Aus Entwurfsmustern kann sich ein Programmierer ein Subsystem zusammenstellen. Ein typisches, bekanntes Entwurfsmuster ist das in der Programmiersprache Smalltalk vorgestellte Model View Controller MVC. Dabei u ¨bernimmt das Model die Repr¨ asentation der Daten, das View-Objekt beschreibt die Darstellung der Daten z. B. auf einem Bildschirm und das Controller-Objekt ist f¨ ur die Benutzereingabe zur Behandlung der Daten zust¨ andig [RechPom02]. Entwurfsmuster f¨ ur Eingebettete Systeme sind z. B. Entwurfsmuster f¨ ur Digitale Filter, f¨ ur endliche Automaten (siehe DEA bzw. FSM, Abschnitt 5.7.5), zirkulare Puffer (FIFOs) f¨ ur die Verarbeitung von Datenstr¨ omen usw. Zustandsmaschinen k¨ onnen f¨ ur die Beschreibung von steuerungsdominanten- oder re” aktiven“ Systemen eingestzt werden. Ein Beispiel daf¨ ur ist die Zustandsbeschreibung einer Waschmaschine (siehe Bild 5.37). Eine Waschmaschine reagiert auf eine Programmeinstellung, den Startknopf, das Erreichen einer Wassertemperatur, auf Zeitgeber usw. Zirkulare Puffer bzw. FIFOs (circular buffer) werden f¨ ur die Verarbeitung von Datenstr¨ omen eingesetzt. Bei der Verarbeitung von Datenstr¨omen kommen die Daten in regelm¨ aßigen Zeitabst¨ anden an und m¨ ussen in Echtzeit abgearbeitet werden. Programmierbeispiele f¨ ur Entwurfsmuster in den Programmiersprachen C oder Java findet man in Entwurfsmuster-Sammlungen und -Katalogen, wie zum Beispiel in [Gam96], zitiert in [RechPom02].

5.9.4

Programm-Modelle

Programm-Modelle sind unabh¨ angig vom verwendeten Quell-Code. Mit ProgrammModellen ist ein Programmablauf nicht nur u utzlich ¨bersichtlich darstellbar, sie sind n¨ bei der Programmanalyse und -Optimierung.

5.9 Software-Entwicklung f¨ ur Eingebettete Systeme

215

Eine Programmanalyse wird mit dem Ziel durchgef¨ uhrt, beispielsweise um folgende Optimierungen durchzuf¨ uhren: [Wolf02]: 1. Ermitteln der Operationen, die unabh¨ angig voneinander sind, um eventuell diese Operationen nebenl¨ aufig oder in anderer Reihenfolge auszuf¨ uhren. 2. Ermitteln der Operationen, die Datenabh¨angigkeiten haben und an eine bestimmte Reihenfolge gebunden sind. 3. Optimierung von Schleifen. 4. Verringerung von Speicher¨ ubertragungen (Memory Transfers) oder externe Eingaben/Ausgaben. Die Zielsetzungen k¨ onnen z. B. sein: Ausf¨ uhrungszeit-Minimierung, Programmgr¨oßenMinimierung oder Energieverbrauchs-Minimierung (siehe auch Abschnitt 5.9.5). Die einzelnen Maßnahmen werden im Folgenden beschrieben. Unsere grundlegenden Programm-Modelle sind der Datenflussgraf (DFG) und der Kontroll-Datenflussgraf (Control Data Flow Graph: CDFG) [Wolf02] [Bring03]. Der Datenflussgraf ist ein azyklischer, gerichteter Graf und beschreibt einen Basisblock (Basic Block BB) eines Programms. Die Knoten des Datenflussgrafen stellen die Operationen dar, die Kanten die Datenfl¨ usse von einer Operation zur n¨achsten oder zu einer Variablen. Die Kanten sind mit den Variablenwerten beschriftet. Beispiel: Basisblock x := x + dx; u := u - (3*x*u*dx) - (3*y*dx); y := y + (u*dx);

1

2 x1

Basisblock in single-assignment Form (SAF) x1 := x + dx; u1 := u - (3*x*u*dx) - (3*y*dx); y1 := y + (u*dx);

u

x dx 3 3

y

dx

4 dx

5 y

7

8

6 u

y1

9 10 u1

Datenflussgraf für den BB in SAF

Abbildung 5.64: Beispiele f¨ ur einen allgemeinen Basisblock (BB): linke Seite oben. Derselbe Basisblock ist darunter in Single Assignement Form“ (SAF) dargestellt. Rechts im Bild ist ” der Datenflussgraf (DFG) f¨ ur die SAF des BB gezeigt (nach [Wolf02]).

Ein Basisblock ist eine Operationsfolge ohne Kontrollstrukturen (if .. then .. else). Azy” klisch“ bedeutet, der Graf hat einen Eingang und Ausgang, es gibt z. B. keine Kante, die vom Ausgang wieder zum Eingang zeigt, mehrere Zuweisungen zur gleichen Variablen sind nicht erlaubt.

216

5 Entwicklungsmethodik

In Abbildung 5.64 ist oben links als Beispiel der Basisblock des Differentialgleichungsl¨ osers aus Kapitel 8 gezeigt. Die Zuweisungen enthalten auf der linken und rechten Seite teilweise die gleichen Variablen, z. B. x := x + dx; das macht den Basisblock zyklisch. F¨ ur die Programmanalyse ist jedoch die azyklische Form des Basisblocks g¨ unstiger, die in der Single-Assignment-Form SAF“ realisiert ist. ” Die Operationen sind im Datenflussgrafen nummeriert. Aus dem Datenflussgrafen ist leicht ersichtlich, dass die Reihenfolge der Operationen Nr. 1, 2, 3, 4 und 5 keine Rolle spielt, sie k¨ onnten parallel oder in anderer Reihenfolge ausgef¨ uhrt werden. Lediglich im Falle von Datenabh¨ angigkeiten wie es in unserem Beispiel f¨ ur die Operationen 2, 6, 9, 10 und 3, 6, 9, 10 sowie 4, 7, 10 der Fall ist, muss eine bestimmte Reihenfolge eingehalten werden. Man sagt: der Datenflussgraf definiert eine partielle Ordnung“ (partial order) ” der Operationen. Dies ist ein Vorteil der Datenflussgrafen-Darstellung von Programmen. Datenfluss-Sprachen, (im Sinne von Programmiersprachen) wie z. B. Id (Irvine data flow language), Lucid oder Lustre nutzen diesen Vorteil des Datenflussgrafen aus [Wolf02]. Beispiel: CDFG eines C-Code Blocks

t test1

if (test1) basic_block_1( ); else basic_block_2( ); basic_block_3( ); switch (test2){ case b1: basic_block_4( ); break; case b2: basic_block_5( ); break; case b3: basic_block_6( ); break; }

basic_block_1( )

f basic_block_2( )

basic_block_3( )

b1

test2

b3

b2 basic_block_4( )

basic_block_5( )

basic_block_6( )

Abbildung 5.65: Beispiel eines Kontroll-Datenflussgrafen (CDFG). Links das Beispiel eines C-Code-Blocks, rechts der dazugeh¨ orige CDFG. t, f bedeuten true“, false“ (nach [Wolf02]). ” ”

Der Kontroll-Datenflussgraf enth¨ alt im Gegensatz zum Datenflussgrafen eine oder mehrere Kontrollstrukturen. Abbildung 5.65 zeigt auf der linken Seite das Beispiel eines CCode-Blocks, rechts den dazugeh¨ origen Kontroll-Datenflussgrafen. Die rautenf¨ormigen Knoten im CDFG stellen die Kontrollstrukturen dar, zuerst die if-Kontrollstruktur“, ” danach die Fallunterscheidung switch ()...case b1 bis b3“. Die Basisbl¨ocke k¨onnen durch ” Funktionsaufrufe ersetzt werden [Wolf02].

5.9 Software-Entwicklung f¨ ur Eingebettete Systeme

5.9.5

217

Compiler fu ¨r Eingebettete Systeme

Abbildung 5.66 zeigt die Erzeugung eines ladbaren Programms, das in einer h¨oheren Programmiersprache wie C oder Java geschrieben wurde. Der Generierungsprozess geschieht meist in mehreren Schritten. Der Compiler erzeugt zun¨achst den leicht verst¨andlichen Prozessor-spezifischen Assembler-Code, der vom Assembler in den bin¨aren ObjektCode u ugt mehrere Objekt-Code-Dateien zusammen, gene¨bersetzt wird. Der Linker f¨ riert die Instruktions-Adressen und erzeugt ausf¨ uhrbaren (executable) Code. Der Lader (Loader) schließlich l¨ adt das ausf¨ uhrbare Programm in den Hauptspeicher des Mikroprozessors. Ein Standard-Compiler, beispielsweise f¨ ur die Programmiersprache C und f¨ ur einen bestimmten Mikroprozessor ist meist relativ preisg¨ unstig oder frei erh¨altlich. F¨ ur Eingebettete Systeme mit speziellen Anforderungen lohnt es sich in der Regel, einen optimierenden Compiler zu verwenden, wenn er f¨ ur den ausgew¨ahlten Mikroprozessor verf¨ ugbar ist. Es gibt Compiler mit verschiedenen Optimierungszielen [Mar07], z. B. Compiler f¨ ur: • die Optimierung der Ausf¨ uhrungszeit. • die Optimierung des Energieverbrauchs. • f¨ ur digitale Signalverarbeitung. • f¨ ur VLIW-Prozessoren. • f¨ ur Netzwerkprozessoren. • f¨ ur Multicore-Prozessoren. Wie oben angedeutet, gibt es nicht f¨ ur jeden Mikroprozessor den passenden Compiler mit der gew¨ unschten Optimierungsmethode, d. h. in vielen F¨allen ist noch Optimierung ” von Hand“ gefragt. Auf Compiler-Optimierungsmethoden kann im Rahmen dieses Buches nicht eingegangen werden. Wir verweisen auf Abhandlungen in [Mar07] und die dort erw¨ahnte weiterf¨ uhrende Literatur. Im folgenden Abschnitt wird auf manuelle Programm-Optimierungsm¨oglichkeiten etwas n¨ aher eingegangen.

5.9.6

Programm-Optimierungen

Optimierung der Ausf¨ uhrungszeit Mikroprozessor-Programme in Eingebetteten Systemen m¨ ussen meist in Echtzeit ablaufen und damit bestimmte Zeitgrenzen einhalten, das heißt, die Ausf¨ uhrungszeit eines Programms muss bekannt sein. Leider ist die Ausf¨ uhrungszeit durch Programmanalyse praktisch nicht exakt bestimmbar, da diese mit den Werten der Eingabedaten variiert. Auch die Performanz des Cache und der Pipeline ist abh¨angig von den Eingabedaten und den sich daraus ergebenden Datenabh¨ angigkeiten.

218

5 Entwicklungsmethodik

HLL-Code

Compiler

AssemblerCode

ObjectCode

Z. B. Code in C oder Java

Linker

Ausführbarer Code

Lader

Mikroprozessor

Abbildung 5.66: Generierung eines ladbaren Programms, das in einer h¨ oheren Programmiersprache wie C oder Java geschrieben wurde (nach [Wolf02]).

Die Konsequenz daraus ist, dass die Ausf¨ uhrungszeit durch Messungen und durch Simulation ermittelt werden muss (siehe TLM-basierte Performanz-Absch¨atzung“, Ab” schnitt 5.8.2). Wir unterscheiden folgende verschiedene Arten der Ausf¨ uhrungszeiten von Programmen [Wolf02]: • Durchschnittliche AZ (Average Case Execution Time): Ausf¨ uhrungszeit f¨ ur typische“ Werte von Eingangsdaten. Typische Eingangsdaten sind oft schwierig ” zu definieren. • K¨ urzeste AZ (Best Case Execution Time, BCET). Die k¨ urzeste Ausf¨ uhrungszeit ist interessant, z. B. f¨ ur periodisch ablaufende Vorg¨ange wie sie bei Motorsteuerungen im Kfz auftreten. • Die maximale Ausf¨ uhrungszeit, die sogenannte Worst Case Execution Ti” me WCET“ muss in Systemen bekannt sein, die harte Zeitgrenzen“ einhalten ” m¨ ussen wie z. B. in sicherheitsrelevanten Systemen [Mar07]. Auf die Absch¨ atzung der Ablaufzeit durch Profiling, Simulation und Messung wird im Abschnitt 5.8.2 n¨ aher eingegangen. In vielen F¨allen kann durch eine Programmoptimierung ein Programm, dessen Ausf¨ uhrungszeit etwa um den Faktor 2 zu lang ist, als die harte Zeitgrenze es zul¨ asst, durch Programmoptimierung bis zu einem Faktor 3 oder 4 verk¨ urzt werden, vorausgesetzt, ein bestimmtes Optimierungspotenzial ist im Programm vorhanden ([Lam91], zitiert in [Mar07]). Vor der Programm-Optimierung steht die Programmanalyse. Eine M¨oglichkeit ist die Ablaufverfolgungs-Analyse“ oder k¨ urzer der Trace“ des Programms (Trace-driven ” ” Performance Analysis, siehe [Wolf02]). Ein Trace-Programm liefert die Aufzeichnung des Pfades als Liste der ausgef¨ uhrten Befehle, die das Programm w¨ahrend seiner Ausf¨ uhrung

5.9 Software-Entwicklung f¨ ur Eingebettete Systeme

219

nacheinander abarbeitet. Traces k¨ onnen sehr groß werden, sie k¨onnen mehrere GBytes betragen. Eine Auswertung des Trace kann daher langwierig sein und bedarf einiger Erfahrung. Programm-Optimierung auf h¨ oherer Ebene Die Optimierung eines Programms beginnt auf h¨oherer Ebene, d. h. beim Schreiben des Programms in einer h¨ oheren Programmiersprache. Danach kann die Optimierung auf Assembler-Ebene weitergef¨ uhrt werden. Letztere setzt nicht nur gute Assemblerkenntnisse des verwendeten Mikroprozessors voraus, sondern auch Compilerund Linker-Kenntnisse (siehe Abschnitt 5.9.5). Mit anderen Worten: Falls die Compiler¨ ubersetzung eine Ausf¨ uhrungszeit liefert, die zu lang ist, kann das Assemblerprogramm von Hand optimiert werden. Es gibt folgende M¨ oglichkeiten, bereits auf h¨ oherer Programmebene eine Optimierung zu erzielen z. B. durch: • Verwendung von Festkomma- statt Gleitkomma-Datentypen. • Schleifenoptimierung. Verwendung von Festkomma- satt Gleitkomma-Datentypen In Signalverarbeitungs-Algorithmen (z. B. MPEG-2) in der Programmiersprache C werden meist Gleitkomma-Datentypen verwendet [Mar07]. Bei vielen Anwendungen kann der Qualit¨ atsverlust, der durch das Ersetzen der Gleitkommatypen durch Festkommatypen entsteht, akzeptiert werden, z. B. falls bewegte Bilder oder Spiele auf Mobiltelefonen oder auf kleineren Bildschirmen gezeigt werden. Dadurch kann z. B. bei einem MPEG-2 Videokompressions-Algorithmus eine Verk¨ urzung der Ausf¨ uhrungszeit und Verringerung des Energieverbrauchs um etwa 75% erreicht werden [Mar07]. Durch das Werkzeug FRIDGE (Fixed Point Programming Design Environment)“, ” das kommerziell in der SynopsysT M System Studio Tool-Suite“ erh¨altlich ist, kann ” die Umwandlung von Gleitkomma- zu Festkommatypen teilweise automatisiert werden [Mar07]. Schleifenoptimierung Schleifen (loops) kosten viel Ausf¨ uhrungszeit und sind ein wichtiges Ziel f¨ ur die Optimierung. Im Folgenden sind eine Auswahl von Regeln der Schleifenoptimierung aus [Wolf02] aufgef¨ uhrt: • Code-Verlagerung (Code Motion). • Abrollen von Schleifen (Loop Unrolling). • Verringerung der Cache-Misses bei Matrixverarbeitung durch entsprechende Schleifenanpassung und durch blockweise Verarbeitung. • Ausnutzen des Optimierungspotenzials im Befehlssatz des verwendeten Mikroprozessors.

220

5 Entwicklungsmethodik

Folgende kleine C-Code-Beispiele aus dem Buch von Marwedel [Mar07] zeigen eine einfache M¨ oglichkeit der Code-Verlagerung:

Beispiel 1: for (i=0; i< n*m; i++) z[i]=a[i]+b[i];

Beispiel 2: temp = n*m; for (i = 0; i < temp; i++) z[i]=a[i]+b[i];

Im Beispiel 1 wird das Produkt n ∗ m bei jedem Schleifendurchlauf neu berechnet, obwohl es sich nie ¨ andert. Besser ist es, die Multiplikation vor die Schleife zu setzen und das Produkt einer Variable, z. B. temp“ zuzuweisen wie das C-Code-Beispiel 2 zeigt. ” Nehmen wir im Beispiel n ∗ m = 8 ∗ 8 Schleifendurchl¨aufe an, so k¨onnen durch diese Methode n ∗ m − 1 = 63 Schleifendurchl¨ aufe eingespart werden, was eine merkliche Performanzverbesserung bringt. Die erste Regel ist: In der Schleife nur das berechnen, was unbedingt n¨ otig ist. Konstanten-Berechnungen usw. aus der Schleife nach außen verlagern. Das Abrollen von Schleifen ist m¨ oglich, wenn die Anzahl der Schleifendurchl¨aufe konstant und bekannt ist. Dadurch wird die Schleifenverwaltung eingespart, die pro Schleifendurchlauf zwei Operationen kostet. Allerdings erh¨oht das die Code-Menge. Beispiel 3 zeigt eine Schleife f¨ ur n = 4 Schleifendurchl¨aufe, im Beispiel 4 rechts ist die gleiche Schleife abgerollt in vier Zeilen dargestellt.

Beispiel 3: n = 4; for (i=0; i