Post on 05-Apr-2015
transcript
1Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
3.4 Auswahlkriterien für den Einsatz von Mikrocontrollern
(aus der reichhaltigen verfügbaren Palette)
Aufgabenstellung Messen Steuern Regeln Überwachen Mensch-Maschine-Schnittstelle Kombination obiger Punkte
2Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
allgemeine Leistungsmerkmale
CISC- oder RISC-Architektur
Von-Neumann oder Harvard-Architektur
Wortbreite (4, 8, 16, 32 Bit)
Adressraum
3Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Architekturmerkmale des Prozessorkerns
Welche Befehlsarten stehen zur Verfügung/werden benötigt ?
Lade- und Speicher-Operationen logische & arithmetische Operationen Multiplikation & Division Schiebeoperationen, Barrel-Shifter Bit-Testoperationen Gleitkomma-Operationen
4Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Architekturmerkmale des Prozessorkerns (fortg.)
Welche Adressierungsarten sind erforderlich?
Unmittelbar Direkt Register Registerindirekt Registerindirekt mit Autoinkrement, Autodekrement Registerindirekt mit Verschiebung Indiziert Indiziert mit Verschiebung Relativ komplexere Adressierungsarten
5Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Architekturmerkmale des Prozessorkerns (fortg.)
Welche Datenformate werden benutzt ?
Ganzzahlen (16, 32, 64 Bit) Gleitkommazahlen (32, 64, 80 Bit) Einzelbit-Datentypen Zeichen und Zeichenketten Felder
6Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Speichermerkmale
Wieviel Programm- und Datenspeicher benötigt die Anwendung?
Reicht die Größe des internen Daten- und Programmspeichers?
Ist ein externer Busanschluss vorhanden?
Was ist die max. externe Speichergröße?
7Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Peripheriemerkmale
Anzahl der:
parallelen E/A-Kanäle seriellen E/A-Kanäle Interrupt-Eingänge Zähler/Zeitgeber A/D-Wandler D/A-Wandler DMA-Controller Echtzeitkanäle speziellen Peripherie wie CAN, I2C, ...
8Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Merkmale zur Ereignisbehandlung
die Anzahl der Unterbrechungseingänge,
eine Prioritäten-Steuerung bei mehrfachen Unterbrechungen,
frei wählbare oder starre Prioritäten,
das Sperren einzelner Unterbrechungen und
die Reaktionszeit auf eine Unterbrechung.
9Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Weitere technische Merkmale
Taktfrequenz
Taktzyklen pro Befehl
Möglichkeit zum Anschluss langsamer Peripherie
Energiebedarf
Abwärme
Stromspar-Modus
10Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Ökonomische Merkmale
Preis
Verfügbarkeit
Produktpflege
Kundenunterstützung (Support)
11Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
3.5 Softwareentwicklung
In der Regel:
Cross-Development
Versions-Verwaltung
Editor
Übersetzer
Binder
integrierteEntwicklungs-umgebung
Quelldateien
freigegebene Quelldateien
geänderte Quelldateien
Objekt-Dateien
Ausführbare Datei
Entwicklungssystem: PC Zielsystem:Mikrocontroller
Anwendungsprogramm
Download
DebuggerTestSymbole
12Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Da die Entwicklung bis auf den letzen Schritt auf einem leistungsfähigen PC stattfindet
=> die Entwicklungsumgebung ist zunächst ähnlich zur PC-
Programmentwicklung:
Versionsverwaltung, Editoren, Übersetzer, Debugger
Es gibt jedoch Unterschiede!
13Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Programmiersprachen
Früher Assembler
heute meist C, nur zeitkritische Teile in Assembler
bei leistungsfähigeren Mikrocontrollern auch C++, erfordert aber mehr Ressourcen und erzeugt mehr Dynamik
Java in der Regel zu ressourcen-intensiv
Es existieren jedoch einige Forschungsbemühungen in diese Richtung (siehe später)
14Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Speicherbedarf
hier liegt ein wesentlicher Unterschied zur Programmentwicklung auf dem PC
bei Mikrocontrollern ist Speicher eine knappe Ressource
Übersetzer optimieren meist in Richtung Speicherbedarf (selten Geschwindigkeit)
Speichersparende Algorithmen sind gefragt
Algorithmen, die vor 10-20 Jahren für den PC entwickelt
wurden, können hier interessant werden (zu dieser Zeit hatten PCs etwa den Speicherumfang heutiger Mikrocontroller)
15Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Adressfestlegung beim Binden
bei PCs: dynamische Adressfestlegung zur Laufzeit
nur so können mehrere Programme gleichzeitig bearbeitet werden
bei Mikrocontrollern: statische Festlegung der Adressen beim Binden (Locator)
Die Adressen müssen an das Speicherabbild (Memory Map) des Mikrocontrollers angepasst werden:
Programm -> Festwertspeicher Daten -> Schreiblesespeicher Erste Programm-Instruktion, Interrupttabellen, ... , müssen an die richtige Stelle gelegt werden
16Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Beispiel einer
Memory Map 4 KByte Festwertspeicher
3 KByte Schreib-/Lesespeicher
E/A-Adressbereich
unbelegt
unbelegt
0
0FFF
8000
8BFF
FE00
FFFF
Code,Größe 3217 Bytes
Einsprungadresse 0
Daten,Größe 625 Bytes
Stack, Größe 325 Bytes
Peripherie
17Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Laden und Testen
– Simulator auf dem Entwicklungssystemgrober Test, da Zeitverhalten anders und
Zielperipherie nicht vorhanden
– Test auf dem Zielsystem mittels Download und Monitor
näher am Zielsystem (Zeitverhalten, Peripherie), immer noch komfortables Testen, Monitor verändert aber Systemverhalten (Initialisierungen, Speichertypen, ...)
– Test auf dem Zielsystem ohne Monitorendgültige Zielumgebung, Programm im
Festwertspeicher (ext. Programmieren oder Flash-Code-Loader),
Ladezeiten lang, Test schwierig
18Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Download o. Programmieren von int.oder ext. EPROMs, Flash-RAMs, ...
Download,z.B. über serielleSchnittstelle
Contr. Debug-Monitor
HW-Interface
PC-Interface
Test-Hardware
Mikrocontroller
Ziel-Hardware
Mikrocontroller-Testsystem
Mikrocontroller-Zielsystem
Mikrocontroller-Simulator(Software)
Entwicklungs-PC
19Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
3.6 Forschungstrends
3.6.1 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!
20Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Interessante SoC Forschungsrichtungen:
Methoden für eine systematische SoC Entwicklung
Prozessorkerne als Benutzerbibliotheken
Rekonfigurierbare SoCs
Integration verschiedener Prozessorkerne
21Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
3.6.1.1 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
Heutige Hardware-Beschreibungssprachen (VHDL, Verilog) bewegen sich auf niederer Ebene im Vergleich zu Sprachen der Software-Entwicklung
22Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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)
23Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Beispiele:
SystemC: Open systen C Initiative
www.systemc.org
SuperLog: S2K Superlog Organization
www.superlog.org
CynApps: Forte Design Systems
www.ForteDS.com
24Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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
25Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
SoC Entwicklung mit einer Hochsprache
High Level Design(z.B. in SystemC)
Verifikation
Low Level Design(z.B. in VHDL)
Verifikation
Platzieren und Routen
FPGA, ASIC
Korrekturen
Korrekturen
Test
26Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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
27Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
3.6.1.2 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
28Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Erstellung eines SoC mit einer Prozessorkern-Bibliothek:
Prozessorkern-Bibliothek(in VHDL)
Anwendercode
(in VHDL)
Chip(ASIC oder FPGA)
erstellen bzw.programmieren
29Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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
30Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
3.6.1.3 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
31Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Prozessor-Kern
SpeicherProgrammierbare Hardware, FPGA
Speicher Ein-/Ausgabe
32Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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
33Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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
34Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Semi-statisch Rekonfigurierbar
Kann das FPGA schneller (Millisekunden) rekonfiguriertwerden
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
35Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Dynamisch Rekonfigurierbar
Neue FPGA Arrays ermöglichen eine sehr schnelleRekonfiguration (Mikrosekunden)
Ein andere Möglichkeit ist die “Vorab-Konfiguration”bestimmter Teile des Arrays und das Umschalten
durch einKonfigurations-Register
Das FPGA kann ‘on-the-fly’ rekonfiguriert werden
• Feinköringe Rekonfiguration
• Das FPGA kann während der Ausführung einer Prozessorkern-Instruktion rekonfiguriert werden
36Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Beispiele rekonfigurierbarer SoC
FIPSOC (SIDSA coorp. www.sidsa .com)
• statisch rekonfigurierbar
• 8051 Prozessorkern
• FPGA Array mit digitalen und analogen Zellen
• Analoge Zellen enthalten
– konfigurierbare Verstärker
– Vergleicher
– Signal-Konverter
37Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
FIPSOC
On ChipMemory
80251Core
CellInterface
AnalogCells
LogicCells
ConfigMemory
To Other FIPSOCsTo External Memory
Dig
ital
I/O
Ana
log
I/O
38Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
MorphoSys (UCI)
• dynamisch 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
39Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
3.6.1.4 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
40Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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
41Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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
42Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Sogar einfache Signalprozessoren ermöglichen den direkten Zugang zu ihren internen Komponenten:
43Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Jeder Teil kann direkt durch das Instruktions-Wort gesteuert werden
Program-Control
ALU-Control
Operand-Selection
Multiplier-Control
RAM Addr.-Control
ROM Addr.-Control
Bit 0Bit n
Ein harmonische Integration beider Konzepte ist eine interessante Aufgabe
VLIW oder EPIC könnten einen vielversprechenden Ansatz darstellen
44Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
3.6.2 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
45Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Hauptwege zur Reduktion des Enerieverbrauchs:
Verringerung der Taktfrequenz
Verringerung der Versorgungsspannung
Optimierung der Mikroarchitektur
46Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Reduktion der Taktfrequenz
Einfach und effektiv
Für CMOS Schaltungen gilt: E ~ f
Das bedeutet: Halbierung der Taktrate entspricht einer Halbierung des Energieverbrauchs
Problem: die Verarbeitungsgeschwindigkeit wird ebenfalls reduziert
47Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Reduktion der Versorgungsspannung
Nach dem Ohm’schen Gesetz gilt: E ~ V2
Dies bedeutet: 70% Versorgungsspannung bewirken 50% Energieverbrauch
Zusätzlich sind Versorgungsspannung und Taktfrequenz nicht unabhängig.
Es gilt: f ~ V
48Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Reduktion der Versorgungsspannung und der Taktfrequenz
Bei gleichzeitiger Reduktion von Versorgungsspannung und Taktfrequenz gilt nach den vorigen Zusammenhängen:
E ~ f * V 2 ~ f 3 ~ V 3
Kubus-Regel
49Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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 Vearbeitungsgeschwindigkeit und damit der Energiebedarf reduziert werden
Ist die Deadline nahe, werden die maximale Taktfrequenz und Versorgungsspannung genutzt
Ein geschlossener Regelkreis kann Taktfrequenz und Versorgungsspannung steuern
50Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Optimierung der Mikroarchitektur
Die bisher beschriebenen Ansätze reduzieren auch die Verarbeitungsgeschwindigkeit
Ein vielversprechende Idee: Optimierung der Mikroarchitektur zur Reduktion des Energiebedarfs ohne gleichzeitige Reduktion der Verarbeitungsleistung
Ansatzpunkte der Optimierung:
• Reduktion externer Busaktivitäten
• Statisches Power-Management
• Dynamisches Power-Managementmanagement
• Erhöhung der Code-Dichte
51Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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
52Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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)
53Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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 Energieeinsparung deaktiviert werden
54Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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
55Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Weitere Forschungsansätze zur Einsparung von Energie
Die vorigen Sektionen haben gezeigt: es besteht ein komplexer Zusammenhang zwischen Architektur, Mikroarchitektur und Energiebedarf
Es wäre günstig, so früh wie möglich während der Entwicklung eines Mikrocontrollers Abschätzungen des Energieverbrauchs vorzunehmen
Heute: Energieabschätzung auf Grundlage der Register-Transfer- und Gatter-Ebene
Künftig: Energieabschätzungen auf Mikroarchitekturebene
56Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Idee: man nehme einen taktgenauen Mikroarchitektur-Simulator (zur Abschätzung der Verarbeitungsgeschwindigkeit)
Man füge Energiemodelle zur Abschätzung des Energieverbrauchs hinzu
Diese Energiemodelle schätzen den Energieverbrauch jeder Mikroarchitektur-Komponente für
• jeden Taktzyklus und
• jeden Zustand
Ein Standard-Simulator enthält nur Mikroarchitektur-Parameter
Energiemodelle beinhalten zusätzlich Technologie-Parameter
57Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Beispiel:
Taktschritt-orientierter
Mikroarchitektur-simulator
Energiemodelle
Mikroarchitektur-parameter
Schaltkreistechnolgie-parameter
Energiebedarfs-Abschätzung
Verarbeitungs-geschwindigkeits-Abschätzung
Programm
58Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
3.6.3 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
59Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Java Pakete für eingebettete Systems (Sun):
Personal Java
für einfache Geräte mit GUI und Netzwerk
Embedded Java
für kleine Systeme mit wenig Speicher und schwacher Verarbeitungsleistung
Java Card
zur Programmierung von Smart Cards
60Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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
61Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Lösungen:
Hybride Java Systeme
Echtzeit-Java
Java-Prozessoren
62Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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), Java for OS-9 (Microware Systems) oder JavaOS (Integrated Systems)
63Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Echtzeit-Java Systeme:
machen Java selbst echtzeitfähig
Spracherweiterungen, z.B. zur Definition von Echtzeit-Threads, Synchronisation oder Speicherbereinigung sind erforderlich
Derzeit zwei wesentliche Standards:
The Real-time Specifications for Java (Sun)
Real-time Core extensions for Java (JConsortium)
64Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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
Beispiel: PERC (NewMonics)
Problem: langsame Ausführung im Vergleich zu C
wegen Interpretation
65Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
2. Man benutzt einen nativen Compiler
Java wird zu nativem Maschinencode übersetzt
Dies erlaubt eine schnelle Ausführung
Beispiel: JBed (Oberon Microsystems)
Probleme: Verlust der Bytecode-Vorteile wie
Portabilität
Kein dynamisches Klassenladen
66Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
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)
67Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
4. Java Prozessoren
Führen Java Bytecode direkt in Hardware aus
Optimiert für spezielle Java Eigenschaften wie
Stack-basierte Bytecode Operationen
Garbage Collection
Synchronisation
=> Hohe Verarbeitungsgeschwindigkeit für Bytecodes
Beispiele: PicoJava II (Sun), JEM (aJile systems), Delft (TU Delft) , PCS1000(Patriot Coorp.), JSM (Universität Rostock), Komodo (Universitäten Karlsruhe/Augsburg)
68Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Der Komodo-Mikrocontroller:
Java
einfacheProgrammierung,
Threads
Echtzeit
Zeitbedingungen,Scheduling
MehrfädigeProzessortechnik
schnellerKontextwechsel
Komodo Mikrocontroller
Java Prozessor,mehrfädige Hardware,
Thread-basierteUnterbrechungsbehandlung,
Middleware
69Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer
3. Mikrocontroller
Das Komodo-Projekt ist in fünf Ebenen gegliedert
Der Mikrocontroller ist die niedrigste Ebene
Middleware OSA+
Anwendung
Heap
Traps
GarbageCollection Mem.
KlasseEthreads.Klasse
Driver.KlassenStandard Klassen
Signal EinheitPrioritäts-Manager
Multithreading I/O Einheit
Komodo-Mikrocontroller