esKap22 - Goethe

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!
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
1
2.2 Systems-on-Chip (SoC)
Interessante SoC Forschungsrichtungen:
 Methoden für eine systematische SoC Entwicklung
 Prozessorkerne als Benutzerbibliotheken
 Rekonfigurierbare SoCs
 Integration verschiedener Prozessorkerne
 Selbstorganisation
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
2
2.2 Systems-on-Chip (SoC)
Methoden für eine systematische SoC Entwicklung
Notwendige Schritte: Design, Verifikation & Test
 SoC kombinieren oft digitale und analoge Komponenten
 Diese Komponenten müssen entwickelt, integriert und getestet
werden
 Klassische Hardware-Beschreibungssprachen (VHDL, Verilog)
bewegen sich auf niederer Ebene im Vergleich zu Sprachen der
Software-Entwicklung
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
3
2.2 Systems-on-Chip (SoC)
Idee: man übertrage die Erfahrungen aus der
Software-Entwicklung auf die HardwareEntwicklung
Man definiert “High-Level-Hardware-Beschreibungssprachen”,
die folgende aus der Software-Entwicklung bekannte Konzepte
einzuführen:



Objektorientierung (object orientation)
Vererbung (inheritance)
Wiederverwendung (resuse)
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
5
2.2 Systems-on-Chip (SoC)
SystemC ist sehr ähnlich zu C++
Vorteile:
 Hardware-Komponenten können als Objekte mit Schnittstellen
(interfaces) und Funktionalität (functionality) definiert werden
 ähnliche Sprachen zur Soft- und Hardware-Entwicklung ermöglichen
zusätzliche Synergie-Effekte
 Es können gemeinsame Werkzeuge für Soft- und Hardware
verwendet werden
 Der Datenaustausch wird erleichtert
 Der Aufwand für das Erlernen durch den Benutzer wird verringert
 Formale Hochsprachen erlauben eine Verifikation auf hoher Ebene
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
6
2.2 Systems-on-Chip (SoC)
SoC Entwicklung mit einer
Hochsprache
High Level Design
(z.B. in SystemC)
Korrekturen
Verifikation
Low Level Design
(z.B. in VHDL)
Platzieren und Routen
Korrekturen
Verifikation
FPGA, ASIC
Test
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
7
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
8
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
9
2.2 Systems-on-Chip (SoC)
Erstellung eines SoC mit einer Prozessorkern-Bibliothek:
ProzessorkernBibliothek
(in VHDL)
erstellen bzw.
programmieren
Chip
(ASIC oder FPGA)
Anwendercode
(in VHDL)
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
10
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
11
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
12
2.2 Systems-on-Chip (SoC)
ProzessorKern
Speicher
Programmierbare Hardware, FPGA
Speicher
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
Ein-/Ausgabe
13
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 FPGATechnologie
 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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
14
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
15
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
16
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
17
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)
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
18
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)
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
19
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
20
2.2 Systems-on-Chip (SoC)
 HoneyComp (Universität Karlsruhe)
HoneyComb Architecture
start node
routing node
occupied paths
adaptivly routed connection of distance i
 Dynamisch adaptive und rekonfigurierbare Datenpfade
zwischen Zellen (Rechenzellen, Speicherzellen,
Ein-/Ausgabezellen)
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
21
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 Berechnungen auf Datenströmen mit
maximalem Durchsatz
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
22
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
23
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
24
2.2 Systems-on-Chip (SoC)
Sogar einfache Signalprozessoren ermöglichen den direkten
Zugang zu ihren internen Komponenten:
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
25
2.2 Systems-on-Chip (SoC)
Jeder Teil kann direkt durch das Instruktions-Wort gesteuert
werden
ProgramControl
ALUControl
MultiplierControl
OperandSelection
RAM Addr.- ROM Addr.Control
Control
Bit n
Bit 0
 Ein harmonische Integration beider Konzepte ist eine
interessante Aufgabe
 VLIW oder EPIC könnten einen vielversprechenden
Ansatz darstellen
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
26
2.2 Systems-on-Chip (SoC)
Selbstorganisation
 Neuer Forschungsaspekt
 Betrifft nicht nur SoC
 Daher gesonderter Abschnitt später
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
27
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
28
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: Leistung
Energie
kg • m2 / sec3 = Joule / sec = Watt
kg • m2 / sec2 = Joule = Wattsekunde
 Auf elektrische Geräte bezogen:
Leistung ist aufgenommene bzw. verbrauchte Energie pro Zeit
(Leistungsaufnahme, Verlustleistung)
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
29
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 Leistungsaufnahme sind verwandte, jedoch nicht identische Ziele
 Zur Verlängerung der Batterielebensdauer
=> Optimierungsziel Verringerung des Energieverbrauchs
 Zur Reduktion der Temperatur
=> Optimierungsziel Verringerung der Leistungsaufnahme
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
30
2.3 Energiespar-Techniken
Hauptwege zur Reduktion des
Energieverbrauchs bzw. der Leistungsaufnahme:
 Verringerung der Taktfrequenz
 Verringerung der Versorgungsspannung
 Optimierung der Mikroarchitektur
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
31
2.3 Energiespar-Techniken
Reduktion der Taktfrequenz
 Einfache Maßnahme
 Für CMOS Schaltungen gilt idealerweise:
P = cd  F ~ F
 Das bedeutet: Halbierung der Taktrate entspricht einer
Halbierung der Leistungsaufnahme
 Auf konstante Zeit Tk gesehen ist auch der
Energieverbrauch proportional zur Taktrate
Ek = P  Tk = cd  F  Tk ~ F
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
32
2.3 Energiespar-Techniken
Reduktion der Taktfrequenz
 Problem: die Verarbeitungsgeschwindigkeit wird ebenfalls
reduziert
 Die Zeit Ta zur Erfüllung einer Aufgabe ist umgekehrt
proportional zur Taktrate
Ta = ca / F ~ 1 / F
 Der Energieverbrauch zur Erfüllung einer Aufgabe ist daher
unabhängig von der Taktrate
Ea = P  Ta = cd  F  Ta = cd  F  ca / F = cd  ca = konstant
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
33
2.3 Energiespar-Techniken
Reduktion der Taktfrequenz
 Für CMOS Schaltungen gilt realerweise:
P = Ps + Pd = cs + cd  F
 Zusätzliche Verlustleistung Ps durch Leckströme, unabhängig
von der Taktfrequenz, wachsen mit zunehmender
Integrationsdichte1)
 Es folgt für den Energieverbrauch
Ea = P  Ta = (cs + cd  F)  ca / F = cs ca /F + cd  ca
 Mit abnehmender Taktfrequenz sinkt die Leistungsaufnahme,
der Energieverbrauch wächst jedoch
1)
bei Mikrocontrollern meist noch vernachlässigbar 34
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
2.3 Energiespar-Techniken
Reduktion der Versorgungsspannung
 Nach dem Ohm’schen Gesetz gilt:
P = U  I = U2 / R ~ U2
 Dies bedeutet: 70% Versorgungsspannung bewirken
50% Leistungsaufnahme
 Hält man die Taktfrequenz zunächst konstant, so gilt für
den Energieverbrauch über eine Zeit Tk bzw. zur
Erfüllung einer Aufgabe in der Zeit Ta:
Ek = P  Tk ~ U2
Ea = P  T a ~ U 2
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
35
2.3 Energiespar-Techniken
Reduktion der Versorgungsspannung und Taktfrequenz
 Variiert man Versorgungsspannung und Taktfrequenz
gemeinsam, so gilt (Leckströme vernachlässigt):
P = cg  F  U2 ~ F  U2
 Versorgungsspannung und Taktfrequenz sind jedoch nicht
unabhängig, für die maximale Taktfrequenz gilt:
F = cf  U ~ U
 Daraus erhält man die Kubusregel für die Leistungsaufnahme:
P
=
=
cg  cf  U3
cg / cf2  F3
~ U3
~ F3
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
 Auf konstante Zeit Tk betrachtet gilt für den Energieverbrauch
ebenfalls:
Ek = P  T k ~ U 3 ~ F 3
 Zur Erfüllung einer Aufgabe ergibt sich durch die umgekehrte
Proportionalität der Ausführungszeit Ta zur Taktfrequenz:
Ea = P  Ta = cg  cf  U3  ca / F = cg  cf  U3  ca / (cf  U)
= cg  ca  U2
= cg / cf2  F3 ca / F = cg ca / cf2  F2 ~ F2 ~ U2
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
37
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
38
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
39
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
40
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)
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
41
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
42
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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
43
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-Transferund Gatter-Ebene
 Künftig: Abschätzungen auf Mikroarchitekturebene
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
44
2.3 Energiespar-Techniken
 Idee: man nehme einen taktgenauen MikroarchitekturSimulator (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
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
45
2.3 Energiespar-Techniken
Beispiel:
Programm
Taktschrittorientierter
Mikroarchitektursimulator
VerarbeitungsgeschwindigkeitsAbschätzung
Mikroarchitekturparameter
Energie- und
Leistungsmodelle
Schaltkreistechnolgieparameter
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
EnergiebedarfsAbschätzung
46
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
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 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
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
Probleme mit eingebetteten Echtzeitsystemen:
 Die ursprüngliche Java-Sprachdefinition enthält keinerlei
Echtzeit-Elemente
 niedere Verarbeitungsgeschwindigkeit bei interpretierter JVM
 Schlechtes Best-/Worst-Case Intervall für die Ausführungszeit
bei JIT-compiler basierter JVM
 Leistungsfähige Hardware für Flash-Compiler erforderlich
 Verlust der Portabilität bei nativem Compiler
 Garbage Collection wirft zusätzliche Probleme auf
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
Lösungen:
 Hybride Java Systeme
 Echtzeit-Java
 Java-Prozessoren
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
Hybride Java Systeme:
 Kombinieren Java mit einem Standard-Echtzeit-OS
 Java selbst ist nicht echtzeitfähig
 Die Echtzeit-Anteile einer Anwendung werden in C oder
C++ geschrieben
 Beispiele: JWorks (WindRiver) oder Java for OS-9
(Microware Systems)
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
Echtzeit-Java Systeme:
 machen Java selbst echtzeitfähig
 Spracherweiterungen, z.B. zur Definition von Echtzeit-
Threads, Synchronisation oder Speicherbereinigung sind
erforderlich
 Standard:
The
Real-time Specifications for Java (RTSJ)
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
Wie realisiert man Echtzeit-Java ?
1. Man benutzt eine echtzeitfähige JVM

Interpretation von Java Bytecode wie bei Standard Java

Garantierte Ausführungszeiten

Zusätzliche Funktionen für Echtzeiterweiterungen

Beispiele: PERC (Aonix), Jamaica (Aicas), SimpleRTJ

Problem: langsame Ausführung im Vergleich zu C
wegen Interpretation
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
2. Man benutzt einen nativen Compiler

Java wird zu nativem Maschinencode übersetzt

Dies erlaubt eine schnelle Ausführung

Beispiel: JBed (Esmertec)

Probleme:
Verlust der Bytecode-Vorteile wie
Portabilität
Kein dynamisches Klassenladen
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
3. JIT oder Flash Compiler

JIT (Just in Time) Compiler übersetzen den Code, wenn
er gebraucht wird

Problem: Ausführungszeiten sind schwer abzuschätzen,
großes Best-case Worst-case Intervall

Flash Compiler übersetzen die ganze Klasse, bevor sie
geladen wird

Problem: der Compiler muss auf dem Zielsystem laufen
=> erhöht den Speicherbedarf beträchtlich (auch für JIT)
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
4. Java Prozessoren
 Führen Java Bytecode direkt in Hardware aus
 Optimiert für spezielle Java Eigenschaften wie
Stack-basierte
Garbage
Bytecode Operationen
Collection
Synchronisation
=> Hohe Verarbeitungsgeschwindigkeit für Bytecodes
 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)
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
Der Komodo-Mikrocontroller:
Java
einfache
Programmierung,
Threads
Echtzeit
Zeitbedingungen,
Scheduling
Mehrfädige
Prozessortechnik
schneller
Kontextwechsel
Komodo Mikrocontroller
Java Prozessor,
mehrfädige Hardware,
Thread-basierte
Unterbrechungsbehandlung,
Middleware
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
Das Komodo-Projekt ist in fünf Ebenen gegliedert
Anwendung
Middleware OSA+
Standard Klassen
Garbage
Collection
Traps
Driver.Klassen
Mem.
Klasse
Ethreads.
Klasse
Heap
PrioritätsManager
Multithreading
Signal Einheit
KomodoMikrocontroller
I/O Einheit
Der Mikrocontroller ist die niedrigste Ebene
Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
58