2.2 Systems-on-Chip (SoC)

Transkript

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! 1

2 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 2

3 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 3

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) 4

5 2.2 Systems-on-Chip (SoC) Beispiele: SystemC: Open System C Initiative SystemVeriLog: System Verilog Organization Cynthesizer: Forte Design Systems 5

6 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 6

7 2.2 Systems-on-Chip (SoC) SoC Entwicklung mit einer Hochsprache High Level Design (z.b. in SystemC) Verifikation Korrekturen Low Level Design (z.b. in VHDL) Platzieren und Routen Korrekturen Verifikation FPGA, ASIC Test 7

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 8

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 Kern 9

10 2.2 Systems-on-Chip (SoC) Erstellung eines SoC mit einer Prozessorkern-Bibliothek: Prozessorkern- Bibliothek (in VHDL) Anwendercode (in VHDL) erstellen bzw. programmieren Chip (ASIC oder FPGA) 10

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 11

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 12

13 2.2 Systems-on-Chip (SoC) Prozessor- Kern Speicher Programmierbare Hardware, FPGA Speicher Ein-/Ausgabe 13

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 14

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 15

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 16

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 17

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) 18

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) 19

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 20

21 2.2 Systems-on-Chip (SoC) HoneyComb (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) 21

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: Signalprozessor-Teils: Ausführung von Steuer- und Regelanwendungen in Echtzeit optimierte Ausführung von Berechnungen auf Datenströmen mit maximalem Durchsatz 22

23 2.2 Systems-on-Chip (SoC) Beispiele: TriCore, TriCore 2 (Infineon, 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 23

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 24

25 2.2 Systems-on-Chip (SoC) Sogar einfache Signalprozessoren ermöglichen den direkten Zugang zu ihren internen Komponenten: 25

26 2.2 Systems-on-Chip (SoC) Jeder Teil kann direkt durch das Instruktions-Wort gesteuert werden Program- Control ALU- Control Multiplier- Control Operand- Selection RAM Addr.- Control ROM Addr.- Control Bit n Bit 0 Ein harmonische Integration beider Konzepte ist eine interessante Aufgabe VLIW oder EPIC könnten einen vielversprechenden Ansatz darstellen 26

27 2.2 Systems-on-Chip (SoC) Selbstorganisation Neuer Forschungsaspekt Betrifft nicht nur SoC Daher gesonderter Abschnitt später 27

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 28

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: Leistung kg 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) 29

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 Leistungsaufnahme sind verwandte, jedoch nicht identische Ziele Zur Verlängerung der Batterielebensdauer => Optimierungsziel Verringerung des Energieverbrauchs Zur Reduktion der Temperatur => Optimierungsziel Verringerung der Leistungsaufnahme 30

31 2.3 Energiespar-Techniken Hauptwege zur Reduktion des Energieverbrauchs bzw. der Leistungsaufnahme: Verringerung der Taktfrequenz Verringerung der Versorgungsspannung Optimierung der Mikroarchitektur 31

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 32

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 33

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 34

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 35

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 f2 F 3 ~ F 3 36

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 f2 F 3 c a / F = c g c a / c f2 F 2 ~ F 2 ~ U 2 37

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 38

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 39

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 40

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) 41

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 42

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 43

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-Transferund Gatter-Ebene Künftig: Abschätzungen auf Mikroarchitekturebene 44

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 45

46 2.3 Energiespar-Techniken Beispiel: Programm Energie- und Leistungsmodelle Verarbeitungs- geschwindigkeits- Abschätzung Taktschrittorientierter Mikroarchitektursimulator Mikroarchitekturparameter Schaltkreistechnolgieparameter Energiebedarfs- Abschätzung 46

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 47

48 2.4 Java und Java-Prozessoren für eingebettete Systeme Java Pakete für eingebettete Systems (Sun): Java Micro-Edition für einfache Geräte mit graphischer Oberfläche, ggf. Netzwerk, wie z.b. SetTop Boxen, Mobiltelefone, PDAs Java StandardEdition für leistungsfähigere eingebettete Systeme Java Card zur Programmierung von Smart Cards 48

49 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 49

50 2.4 Java und Java-Prozessoren für eingebettete Systeme Lösungen: Hybride Java Systeme Echtzeit-Java Java-Prozessoren 50

51 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) 51

52 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) 52

53 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: Java Real-Time (SUN), PERC (Aonix), Jamaica (Aicas), SimpleRTJ Problem: langsame Ausführung im Vergleich zu C wegen Interpretation 53

54 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 (Myriad) Probleme: Verlust der Bytecode-Vorteile wie Portabilität Kein dynamisches Klassenladen 54

55 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) 55

56 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 Bytecode Operationen Garbage Collection Synchronisation => Hohe Verarbeitungsgeschwindigkeit für Bytecodes Beispiele: PicoJava I + II, MicroJava, UltraJava (Sun), JEM (ajile systems), Delft (TU Delft), PCS1000(Patriot Coorp.), JSM (Universität Rostock), JOP (Universität Wien), Komodo (Universitäten Karlsruhe/Augsburg) 56

57 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 57

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 58