Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 1 2.2 Systems-on-Chip (SoC) SoC sind die konsequente.

Präsentation zum Thema: "Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 1 2.2 Systems-on-Chip (SoC) SoC sind die konsequente."—  Präsentation transkript:

1 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 1 2.2 Systems-on-Chip (SoC) SoC sind die konsequente Fortsetzung der grundlegenden Mikrocontroller-Idee: Aufbau eines Systems mit einer minimalen Anzahl externer Komponenten SoC: realisiere das ganze System mit einem einzigen Chip Diese Idee ist Gegenstand vieler verschiedener Forschungsrichtungen!

2 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 2 2.2 Systems-on-Chip (SoC) Interessante SoC Forschungsrichtungen: q Methoden für eine systematische SoC Entwicklung q Prozessorkerne als Benutzerbibliotheken q Rekonfigurierbare SoCs q Integration verschiedener Prozessorkerne q Selbstorganisation

3 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 3 2.2 Systems-on-Chip (SoC) Methoden für eine systematische SoC Entwicklung Notwendige Schritte: Design, Verifikation & Test q SoC kombinieren oft digitale und analoge Komponenten q Diese Komponenten müssen entwickelt, integriert und getestet werden q Klassische Hardware-Beschreibungssprachen (VHDL, Verilog) bewegen sich auf niederer Ebene im Vergleich zu Sprachen der Software-Entwicklung

4 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 4 2.2 Systems-on-Chip (SoC) Idee:man übertrage die Erfahrungen aus der Software-Entwicklung auf die Hardware- Entwicklung Man definiert “High-Level-Hardware-Beschreibungssprachen”, die folgende aus der Software-Entwicklung bekannte Konzepte einzuführen:  Objektorientierung (object orientation)  Vererbung (inheritance)  Wiederverwendung (resuse)

5 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 5 2.2 Systems-on-Chip (SoC) Beispiele: SystemC:Open System C Initiative www.systemc.org SystemVeriLog:System Verilog Organization www.systemverilog.org Cynthesizer:Forte Design Systems www.ForteDS.com

6 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 6 2.2 Systems-on-Chip (SoC) SystemC ist sehr ähnlich zu C++ Vorteile: q Hardware-Komponenten können als Objekte mit Schnittstellen (interfaces) und Funktionalität (functionality) definiert werden q ähnliche Sprachen zur Soft- und Hardware-Entwicklung ermöglichen zusätzliche Synergie-Effekte q Es können gemeinsame Werkzeuge für Soft- und Hardware verwendet werden q Der Datenaustausch wird erleichtert q Der Aufwand für das Erlernen durch den Benutzer wird verringert q Formale Hochsprachen erlauben eine Verifikation auf hoher Ebene

7 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 7 2.2 Systems-on-Chip (SoC) SoC Entwicklung mit einer Hochsprache

8 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 8 2.2 Systems-on-Chip (SoC) Das Testen kann unterstützt werden durch:  eingebettete Teststrukturen  Sichtbarmachung interner Hardware-Zustände  eingebauten Selbsttests  Herausforderung: die Entwicklung effizienter Selbsttests für analoge und digitale Teile eines SoC mit geringen Kosten und geringer zusätzlicher Fläche  Design for Testability. Denke bereits während der Entwicklung an den Test

9 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 9 2.2 Systems-on-Chip (SoC) Prozessorkern-Bibliotheken Grundidee:liefere einen Prozessor nicht als Hardware, sondern als Bibliothek aus.  Der Anwender kann den Prozessorkern dann leicht in seine eigene FPGA oder ASIC Entwicklung integrieren  Viele Prozessorkerne sind bereits als ASIC-Bibliothek verfügbare, z.B. ARM PowerPC 80251 Kern

10 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 10 2.2 Systems-on-Chip (SoC) Erstellung eines SoC mit einer Prozessorkern-Bibliothek:

11 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 11 2.2 Systems-on-Chip (SoC) Gegenwärtige Herausforderungen an die Forschung:  Versuche das Gleiche mit FPGAs  Für kleine Stückzahlen ist eine FPGA-Entwicklung deutlich preiswerter als eine ASIC-Entwicklung  FPGA-Lösungen können “im Haus” erstellt werden  Wegen der geringeren Logikdichte von FPGAs sind bisher aber erst kleine Prozessorkerne (z.B. 8051) verfügbar

12 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 12 2.2 Systems-on-Chip (SoC) Rekonfigurierbare SoC Umkehrung der Idee der Prozessorkern-Bibliotheken Ein rekonfigurierbarer SoC besteht aus  einem Prozessorkern  Speicher  einem FPGA Array Während der Prozessorkern und der Speicher unveränderlich sind, kann der FPGA-Anteil rekonfiguriert werden

13 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 13 2.2 Systems-on-Chip (SoC)

14 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 14 2.2 Systems-on-Chip (SoC) Dieser Ansatz ist in doppelter Hinsicht ein guter Kompromiss:  Prozessorkern und Speicher können in optimaler Weise realisiert werden Nur der rekonfigurierbare Anteil nutzt die hinsichtlich Geschwindigkeit und Logikdichte weniger optimale FPGA- Technologie  Der Anwender kann die Menge an “Spezial-Hardware” für eine gegebene Anwendung selbst bestimmen Der rekonfigurierbare Teil kann so personalisiert werden, dass er eine Aufgabe viel schneller als mittels Software lösen kann

15 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 15 2.2 Systems-on-Chip (SoC) Es können drei Typen von rekonfigurierbaren SoC unterschieden werden:  Statisch Rekonfigurierbar Die Rekonfiguration benötigt längerer Zeit (Sekunden bis Minuten) Das SoC wird einmal statisch für eine Aufgabe konfiguriert Diese Konfiguration ändert sich zur Laufzeit niemals

16 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 16 2.2 Systems-on-Chip (SoC)  Semi-statisch Rekonfigurierbar Kann das FPGA schneller (Millisekunden) rekonfiguriert werden  Das System kann zur Laufzeit rekonfiguriert werden Eine Aufgabe kann dann in Unteraufgaben zerlegt werden Diese Unteraufgaben werden nach dem Pipeline-Prinzip durchgeführt Während eine Unteraufgabe in Software ausgeführt wird, kann das FPGA für die nächste Unteraufgabe rekonfiguriert werden

17 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 17 2.2 Systems-on-Chip (SoC)  Dynamisch Rekonfigurierbar Neue FPGA Arrays ermöglichen eine sehr schnelle Rekonfiguration (Mikrosekunden) Ein andere Möglichkeit ist die “Vorab-Konfiguration” bestimmter Teile des Arrays und das Umschalten durch ein Konfigurations-Register  Das FPGA kann ‘on-the-fly’ rekonfiguriert werden Das FPGA kann während der Ausführung einer Prozessorkern-Instruktion rekonfiguriert werden

18 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 18 2.2 Systems-on-Chip (SoC) Weiterhin zu unterscheiden:  Feinkörnig Rekonfigurierbare SoC Rekonfiguration auf Gatterebene, die Verschaltung von Gattern und Registern kann verändert werden.  Grobkörnig Rekonfigurierbare SoC Rekonfiguration auf Ebene von Funktionseinheiten (ALU, Speicher, …). Diese können neu vernetzt oder im Funktionsumfang verändert werden. (Schneller und einfacher als feinkörnige Rekonfiguration)

19 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 19 2.2 Systems-on-Chip (SoC) Beispiele rekonfigurierbarer SoC  AT94X Reihe von Atmel statisch feinkörnig rekonfigurierbar AVR8 Prozessorkern FPGA Array mit bis zu 40k Gattern Bei einigen Modellen (AT94S) geschützter Konfigurationsspeicher (Ausleseschutz)

20 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 20 2.2 Systems-on-Chip (SoC)  MorphoSys (UCI) dynamisch grobkörnig rekonfigurierbar 32-Bit-TinyRISC-Prozessorkern 64 reconfigurierbare Zellen Jede Zelle enthält –Logik –ALU –Register File Die Rekonfiguration “on the fly” in der Geschwindigkeit des Prozessorkerns geschieht durch Umschalten vorgesetzter Kontext-Wörter Anwendung: Bildbearbeitung

21 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 21 2.2 Systems-on-Chip (SoC) HoneyComb Architecture start node routing node occupied paths adaptivly routed connection of distance i  HoneyComp (Universität Karlsruhe)  Dynamisch adaptive und rekonfigurierbare Datenpfade zwischen Zellen (Rechenzellen, Speicherzellen, Ein-/Ausgabezellen)

22 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 22 2.2 Systems-on-Chip (SoC) Integration unterschiedlicher Prozessorkerne  Kombination von Mikrocontrollern und Signalprozessoren  Eine Möglichkeit, die große Anzahl heute verfügbarer Transistoren auf einem Chip zu nutzen  Aufgaben des Mikrocontroller-Teils:Ausführung von Steuer- und Regelanwendungen in Echtzeit Signalprozessor-Teils: optimierte Ausführung von Berech- nungen auf Datenströmen mit maximalem Durchsatz

23 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 23 2.2 Systems-on-Chip (SoC) Beispiele: TriCore, TriCore 2 (Infineon, www.infineon.com) TriCore kombiniert drei Teile: ein RISC Prozessorkern mit Mikrocontroller-Peripherie und einer Hochgeschwindigkeits-Multiplizier-/Addier-Einheit  Daher ist TriCore ein erster Schritt  Er integriert Teile eines Signalprozessors in einen Mikrocontrollerkern  Es gibt immer noch einen einzigen Kern

24 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 24 2.2 Systems-on-Chip (SoC) Die Integration eines vollständigen Mikrocontrollerkerns mit einem Signalprozessor ist immer noch eine Herausforderung, da:  die Programmausführung eines Mikrocontrollers und eines Signalprozessors total unterschiedlich ist  ein Mikrocontroller versteckt seine interne Mikrorachitektur durch eine Architektur-Ebene (wie bei Mikroprozessoren)  die Parallelität ist unter Kontrolle des Prozessorkerns  ein Signalprozessor offenbart dem Anwender seine Mikroarchitektur  für maximale Effizienz ist die Parallelität unter Kontrolle des Anwenders

25 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 25 2.2 Systems-on-Chip (SoC) Sogar einfache Signalprozessoren ermöglichen den direkten Zugang zu ihren internen Komponenten:

26 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 26 2.2 Systems-on-Chip (SoC) Jeder Teil kann direkt durch das Instruktions-Wort gesteuert werden  Ein harmonische Integration beider Konzepte ist eine interessante Aufgabe  VLIW oder EPIC könnten einen vielversprechenden Ansatz darstellen

27 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 27 2.2 Systems-on-Chip (SoC) Selbstorganisation  Neuer Forschungsaspekt  Betrifft nicht nur SoC  Daher gesonderter Abschnitt später

28 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 28 2.3 Energiespar-Techniken  Microcontroller werden mehr und mehr in kleinen, mobilen Geräten genutzt (Ubiquitous Computing, Pervasive Computing)  Die verfügbare Energie wird durch eine Batterie begrenzt  Hauptanforderung: Erzielung einer maximalen Betriebszeit mit der verfügbaren Energie  Wärmeabgabe ist ein anderer Grund, den Energieverbrauch zu reduzieren

29 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 29 2.3 Energiespar-Techniken Präzisierung der Begriffe:  Energie (Energy) und Leistung (Power)  Leistung (P) ist Energiefluss (E) pro Zeit (T) P = E / T bzw. E = P T  Einheiten:Leistungkg m 2 / sec 3 = Joule / sec = Watt Energie kg m 2 / sec 2 = Joule = Wattsekunde  Auf elektrische Geräte bezogen: Leistung ist aufgenommene bzw. verbrauchte Energie pro Zeit (Leistungsaufnahme, Verlustleistung)

30 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 30 2.3 Energiespar-Techniken Beispiel:  Mikrokontroller mit Leistungsaufnahme 10 Watt => jede Sekunde werden 10 Wattsek. Energie verbraucht nach 1 Minute wurden 600 Wattsek verbraucht  Verringerung des Energieverbrauchs und der Leistungs- aufnahme sind verwandte, jedoch nicht identische Ziele  Zur Verlängerung der Batterielebensdauer => Optimierungsziel Verringerung des Energieverbrauchs  Zur Reduktion der Temperatur => Optimierungsziel Verringerung der Leistungsaufnahme

31 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 31 2.3 Energiespar-Techniken Hauptwege zur Reduktion des Energieverbrauchs bzw. der Leistungsaufnahme:  Verringerung der Taktfrequenz  Verringerung der Versorgungsspannung  Optimierung der Mikroarchitektur

32 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 32 2.3 Energiespar-Techniken Reduktion der Taktfrequenz  Einfache Maßnahme  Für CMOS Schaltungen gilt idealerweise: P = c d  F ~ F  Das bedeutet: Halbierung der Taktrate entspricht einer Halbierung der Leistungsaufnahme  Auf konstante Zeit T k gesehen ist auch der Energieverbrauch proportional zur Taktrate E k = P  T k = c d  F  T k ~ F

33 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 33 2.3 Energiespar-Techniken Reduktion der Taktfrequenz  Problem: die Verarbeitungsgeschwindigkeit wird ebenfalls reduziert  Die Zeit T a zur Erfüllung einer Aufgabe ist umgekehrt proportional zur Taktrate T a = c a / F ~ 1 / F  Der Energieverbrauch zur Erfüllung einer Aufgabe ist daher unabhängig von der Taktrate E a = P  T a = c d  F  T a = c d  F  c a / F = c d  c a = konstant

34 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 34 2.3 Energiespar-Techniken Reduktion der Taktfrequenz  Für CMOS Schaltungen gilt realerweise: P = P s + P d = c s + c d  F  Zusätzliche Verlustleistung P s durch Leckströme, unabhängig von der Taktfrequenz, wachsen mit zunehmender Integrationsdichte 1)  Es folgt für den Energieverbrauch E a = P  T a = (c s + c d  F)  c a / F = c s  c a /F + c d  c a  Mit abnehmender Taktfrequenz sinkt die Leistungsaufnahme, der Energieverbrauch wächst jedoch 1) bei Mikrocontrollern meist noch vernachlässigbar

35 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 35 2.3 Energiespar-Techniken Reduktion der Versorgungsspannung  Nach dem Ohm’schen Gesetz gilt: P = U  I = U 2 / R ~ U 2  Dies bedeutet: 70% Versorgungsspannung bewirken 50% Leistungsaufnahme  Hält man die Taktfrequenz zunächst konstant, so gilt für den Energieverbrauch über eine Zeit T k bzw. zur Erfüllung einer Aufgabe in der Zeit T a : E k = P  T k ~ U 2 E a = P  T a ~ U 2

36 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 36 2.3 Energiespar-Techniken Reduktion der Versorgungsspannung und Taktfrequenz  Variiert man Versorgungsspannung und Taktfrequenz gemeinsam, so gilt (Leckströme vernachlässigt): P = c g  F  U 2 ~ F  U 2  Versorgungsspannung und Taktfrequenz sind jedoch nicht unabhängig, für die maximale Taktfrequenz gilt: F = c f  U ~ U  Daraus erhält man die Kubusregel für die Leistungsaufnahme: P=c g  c f  U 3 ~ U 3 =c g / c f 2  F 3 ~ F 3

37 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 37 2.3 Energiespar-Techniken Reduktion der Versorgungsspannung und Taktfrequenz  Auf konstante Zeit T k betrachtet gilt für den Energieverbrauch ebenfalls: E k = P  T k ~ U 3 ~ F 3  Zur Erfüllung einer Aufgabe ergibt sich durch die umgekehrte Proportionalität der Ausführungszeit T a zur Taktfrequenz: E a = P  T a = c g  c f  U 3  c a / F = c g  c f  U 3  c a / (c f  U) = c g  c a  U 2 = c g / c f 2  F 3  c a / F = c g  c a / c f 2  F 2 ~ F 2 ~ U 2

38 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 38 2.3 Energiespar-Techniken Forschungsansätze:  Optimierung der Taktfrequenz für die Anwendung  z.B. für Echtzeitsysteme: Anpassen der Taktfrequenz und Versorgungsspannung an die Deadlines  Ist die Deadline noch weit entfernt, kann die Verarbeitungsgeschwindigkeit und damit der Energiebedarf bzw. Leistungsaufnahme reduziert werden  Ist die Deadline nahe, werden die maximale Taktfrequenz und Versorgungsspannung genutzt  Ein geschlossener Regelkreis kann Taktfrequenz und Versorgungsspannung steuern

39 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 39 2.3 Energiespar-Techniken Optimierung der Mikroarchitektur  Die bisher beschriebenen Ansätze reduzieren auch die Verarbeitungsgeschwindigkeit  Ein vielversprechende Idee: Optimierung der Mikroarchitektur zur Reduktion der Leistungsaufnahme ohne gleichzeitige Reduktion der Verarbeitungsgeschwindigkeit  Ansatzpunkte der Optimierung: Reduktion externer Busaktivitäten Statisches Power-Management Dynamisches Power-Management Erhöhung der Code-Dichte

40 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 40 2.3 Energiespar-Techniken Reduktion der externen Busaktivitäten:  RISC Load-/Store Architekturen arbeiten hauptsächlich mit den internen Registern  Die Bus-Schnittstelle wird so für viele Operationen nicht benötigt und kann abgeschaltet werden  Ein umfangreicher interner Registersatz hilft, externe Buszugriffe zu reduzieren  Unterstützung für schmale Datentypen kann dies ebenfalls  Während eines 8-Bit Transfers können die oberen 24 Bit einer 32-Bit Busschnittstelle abgeschaltet bleiben

41 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 41 2.3 Energiespar-Techniken Statisches Power Management:  Spezielle Instruktionen deaktivieren gerade nicht benötigte Komponenten wie Nicht-flüchtigen Speicher Ein-/Ausgabeeinheiten Teile der ALU  Flüchtige Speicher können im Schlaf-Modus betrieben werden (z.B. durch Reduktion der Versorgungsspannung auf den zum Aufrechterhalten der Information notwendigen minimalen Level)  Schlaf-Modus des Prozessorkerns (z.B. durch statisches Steuerwerk mit 0 Hz minimaler Taktfrequenz)

42 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 42 2.3 Energiespar-Techniken Dynamisches Power Management:  Der Prozessor deaktiviert automatisch nicht benötigte Komponenten  Dies kann z.B. in der Pipeline durchgeführt werden  Wenn schmale Datentypen unterstützt werden, können Teile der ALU und der internen Datenpfade deaktiviert werden  Für einen 8-Bit Datentyp werden z.B. die oberen 24 Bit einer 32 Bit ALU nicht gebraucht und können zur Leistungs- und Energieeinsparung deaktiviert werden

43 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 43 2.3 Energiespar-Techniken Erhöhung der Code-Dichte:  Code-Dichte: Anzahl benötigter Befehle um eine Anwendung zu schreiben  Eine hohe Code-Dichte bedeutet, weniger Befehle sind notwendig  Dies spart aus zwei Gründen Energie: Weniger Speicher wird gebraucht Weniger Buszyklen zur Ausführung der Anwendung sind nötig  Von diesem Standpunkt aus ist CISC besser als RISC

44 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 44 2.3 Energiespar-Techniken Weitere Forschungsansätze  Die vorigen Sektionen haben gezeigt: es besteht ein komplexer Zusammenhang zwischen Architektur, Mikroarchitektur und Leistungsaufnahme bzw. Energiebedarf  Es wäre günstig, so früh wie möglich während der Entwicklung eines Mikrocontrollers Abschätzungen des Energieverbrauchs und der Leistungsaufnahme vorzunehmen  Heute: Abschätzung auf Grundlage der Register-Transfer- und Gatter-Ebene  Künftig: Abschätzungen auf Mikroarchitekturebene

45 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 45 2.3 Energiespar-Techniken  Idee: man nehme einen taktgenauen Mikroarchitektur- Simulator (zur Abschätzung der Verarbeitungsgeschwindigkeit)  Man füge Energie- und Leistungsmodelle zur Abschätzung hinzu  Diese Modelle schätzen den Energieverbrauch und die Leistungsaufnahme jeder Mikroarchitektur-Komponente für jeden Taktzyklus und jeden Zustand  Ein Standard-Simulator enthält nur Mikroarchitektur-Parameter  Energiemodelle beinhalten zusätzlich Technologie-Parameter

46 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 46 2.3 Energiespar-Techniken Beispiel:

47 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 47 2.4 Java und Java-Prozessoren für eingebettete Systeme Java bietet viele Vorteile für eingebettete Systeme:  Einfache Programmierung  Wiederverwendbarkeit  Robustheit  Reicher Satz von Standard-Klassenbibliotheken Java Bytecode ist  portabel  klein  sicher

48 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 48 2.4 Java und Java-Prozessoren für eingebettete Systeme Java Pakete für eingebettete Systems (Sun):  Java Micro-Edition zum Programmieren einfacher Geräte mit grafischer Oberfläche, ggf. vernetzt  Java Wireless Toolkit  Connected Device Configuration  Connected Limited Device Configuration  Embedded Java  Java Card zur Programmierung von Smart Cards

49 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 49 2.4 Java und Java-Prozessoren für eingebettete Systeme Probleme mit eingebetteten Echtzeitsystemen: q Die ursprüngliche Java-Sprachdefinition enthält keinerlei Echtzeit-Elemente q niedere Verarbeitungsgeschwindigkeit bei interpretierter JVM q Schlechtes Best-/Worst-Case Intervall für die Ausführungszeit bei JIT-compiler basierter JVM q Leistungsfähige Hardware für Flash-Compiler erforderlich q Verlust der Portabilität bei nativem Compiler q Garbage Collection wirft zusätzliche Probleme auf

50 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 50 2.4 Java und Java-Prozessoren für eingebettete Systeme Lösungen: q Hybride Java Systeme q Echtzeit-Java q Java-Prozessoren

51 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 51 2.4 Java und Java-Prozessoren für eingebettete Systeme Hybride Java Systeme: q Kombinieren Java mit einem Standard-Echtzeit-OS q Java selbst ist nicht echtzeitfähig q Die Echtzeit-Anteile einer Anwendung werden in C oder C++ geschrieben q Beispiele: JWorks (WindRiver) oder Java for OS-9 (Microware Systems)

52 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 52 2.4 Java und Java-Prozessoren für eingebettete Systeme Echtzeit-Java Systeme: q machen Java selbst echtzeitfähig q Spracherweiterungen, z.B. zur Definition von Echtzeit- Threads, Synchronisation oder Speicherbereinigung sind erforderlich q Standard: m The Real-time Specifications for Java (RTSJ)

53 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 53 2.4 Java und Java-Prozessoren für eingebettete Systeme Wie realisiert man Echtzeit-Java ? 1. Man benutzt eine echtzeitfähige JVM m Interpretation von Java Bytecode wie bei Standard Java m Garantierte Ausführungszeiten m Zusätzliche Funktionen für Echtzeiterweiterungen m Beispiele: PERC (Aonix), Jamaica (Aicas), SimpleRTJ m Problem: langsame Ausführung im Vergleich zu C wegen Interpretation

54 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 54 2.4 Java und Java-Prozessoren für eingebettete Systeme 2. Man benutzt einen nativen Compiler m Java wird zu nativem Maschinencode übersetzt m Dies erlaubt eine schnelle Ausführung m Beispiel: JBed (Esmertec) m Probleme:Verlust der Bytecode-Vorteile wie Portabilität Kein dynamisches Klassenladen

55 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 55 2.4 Java und Java-Prozessoren für eingebettete Systeme 3. JIT oder Flash Compiler m JIT (Just in Time) Compiler übersetzen den Code, wenn er gebraucht wird m Problem: Ausführungszeiten sind schwer abzuschätzen, großes Best-case Worst-case Intervall m Flash Compiler übersetzen die ganze Klasse, bevor sie geladen wird m Problem: der Compiler muss auf dem Zielsystem laufen => erhöht den Speicherbedarf beträchtlich (auch für JIT)

56 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 56 2.4 Java und Java-Prozessoren für eingebettete Systeme 4. Java Prozessoren q Führen Java Bytecode direkt in Hardware aus q Optimiert für spezielle Java Eigenschaften wie m Stack-basierte Bytecode Operationen m Garbage Collection m Synchronisation => Hohe Verarbeitungsgeschwindigkeit für Bytecodes q Beispiele: PicoJava II (Sun), JEM (aJile systems), Delft (TU Delft), PCS1000(Patriot Coorp.), JSM (Universität Rostock), JOP (Universität Wien), Komodo (Universitäten Karlsruhe/Augsburg)

57 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 57 2.4 Java und Java-Prozessoren für eingebettete Systeme Der Komodo-Mikrocontroller:

58 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 58 2.4 Java und Java-Prozessoren für eingebettete Systeme Das Komodo-Projekt ist in fünf Ebenen gegliedert Der Mikrocontroller ist die niedrigste Ebene