Evaluierung des Lernverfahrens XCS im Entwurf von Systems-on-Chip

DIPLOMARBEIT
Evaluierung des Lernverfahrens XCS
im Entwurf von Systems-on-Chip
Dirk Fritz
Ausgeführt an der Fakultät für Informations- und Kognitionswissenschaften am
Wilhelm-Schickard-Institut für Informatik
der Universität Tübingen
Betreuer:
Dipl.-Inform. Andreas Bernauer
1. Gutachter:
Prof. Dr. Wolfgang Rosenstiel
Eidesstattliche Erklärung
Hiermit versichere ich, diese Arbeit selbstständig verfasst und nur die angegebenen Quellen benutzt zu haben.
Tübingen am 15. Januar 2008
Dirk Fritz
Kurzfassung
In dieser Diplomarbeit wird das Leraning-Classier-System XCS evaluiert. Die Evaluierung ndet mit dem Hintergrund statt, dass der XCS im Bereich System-on-Chip zum
Einsatz kommen soll. Dabei soll es helfen, den Chip möglichst optimal einzustellen. Der
XCS kann dabei die Spannung und Frequenz ändern. Das Optimierungziel wird über die
Reward-Funktion des XCS beschrieben. Ein Ziel könnte z.B sein, das System mit maximaler Taktfrequenz und minimalem Energieaufwand zu betreiben. Im weiteren wird
geprüft, ob der XCS auf äuÿere Veränderungen wie ein Temperaturanstieg reagieren
kann. Für die Evaluierung ist eine Simulationsumgebung entwickelt worden, mit der die
Gröÿen wie Temperatur und Verlustleistung simuliert werden können. Auÿerdem wurden
Modelle implementiert, die Fehlermechanismen aufgrund zu hoher Temperatur, zu hoher
Frequenz oder zu niedriger Spannung nachbilden.
Danksagungen
An dieser Stelle möchte ich mich bei allen bedanken, die zum Gelingen dieser Arbeit
beigetragen haben. Besonderer Dank gilt dabei meinem Betreuer Andreas Bernauer, der
trotz schwieriger Umstände mit Rat und Tat zur Seite stand. Weiter möchte ich mich
bei Herrn Professor Dr. Wolfgang Rosenstiel für die Ermöglichung der Diplomarbeit und
die interessante Themenstellung bedanken.
Inhaltsverzeichnis
1 Einführung
1
1.1
Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Aufbau der Arbeit
3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Learning-Classier-System: XCS
4
2.1
Allgemeines zu Learning-Classier-Systeme
. . . . . . . . . . . . . . . . .
4
2.2
Überblick über den XCS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.1
Interaktion mit der Umgebung
. . . . . . . . . . . . . . . . . . . .
5
2.2.2
Single-Step und Multi-Step Probleme . . . . . . . . . . . . . . . . .
6
2.3
2.4
Formale Beschreibung des XCS
. . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.1
Die Sets des XCS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.2
Ablauf eines Single-Step Experiments
. . . . . . . . . . . . . . . .
7
2.3.3
Einfügen neuer Classier . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.4
Zusammenfassen von Classiern . . . . . . . . . . . . . . . . . . . .
11
2.3.5
Vorgehensweise des GAs . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.6
Löschen von Classiern
. . . . . . . . . . . . . . . . . . . . . . . .
12
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
Zusammenfassung
3 Modellierung von SoCs
3.1
3.2
3.3
Berechnung der Verlustleistung
13
. . . . . . . . . . . . . . . . . . . . . . . .
13
3.1.1
Modell zu Berechnung der statischen Verlustleistung
. . . . . . . .
14
3.1.2
Modell zu dynamischen Verlustleistung . . . . . . . . . . . . . . . .
15
3.1.3
Gesamte Verlustleistung . . . . . . . . . . . . . . . . . . . . . . . .
15
Modellierung der Temperatur auf einem SoC
. . . . . . . . . . . . . . . .
16
3.2.1
Grundlagen zur Berechnung der Temperatur . . . . . . . . . . . . .
16
3.2.2
Ermittlung der Temperatur mit HotSpot . . . . . . . . . . . . . . .
17
Modell aufgrund von Zeitverletzungen
. . . . . . . . . . . . . . . . . . . .
19
Inhaltsverzeichnis
3.3.1
Analytisches Modell zu Berechnung der Verzögerungszeit eines Invertes
3.4
3.6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2
Temperatureinuÿ auf die Schaltzeit
3.3.3
Gesamte Schaltzeit eines Inverters
3.3.4
Berechnung der Verzögerungszeit der Pipeline-Stufe
20
. . . . . . . . . . . . . . . . .
21
. . . . . . . . . . . . . . . . . .
22
. . . . . . . .
22
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.4.1
Grundlagen zu Soft Errors . . . . . . . . . . . . . . . . . . . . . . .
24
3.4.2
Einuÿ der Spannung auf die SER
25
3.4.3
Fehlermodell für Soft Errors von Dakai Zhu
3.4.4
Fehlermodell für Soft Errors von Peter Hazucha und Christer Svens-
Soft Errors
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . .
26
son . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
Stochastische Grundlagen der SER . . . . . . . . . . . . . . . . . .
28
Hard Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.5.1
Beziehung zwischen Temperatur und Langlebigkeit eines Prozessors
30
3.5.2
Elektronenmigration . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.4.5
3.5
V
Zusammenfassung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Implementierung der Modelle und Beschreibung des Testsystems
32
33
4.1
Implementierung der Modelle
. . . . . . . . . . . . . . . . . . . . . . . . .
33
4.2
Beschreibung des Testsystems . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.2.1
Technische Daten des Opteron Prozessors
. . . . . . . . . . . . . .
40
4.2.2
Modellierung des Opteron Quad-Core
. . . . . . . . . . . . . . . .
41
4.2.3
Beschreibung des Opterons mit asoc-sim . . . . . . . . . . . . . . .
42
4.2.4
Trace-File für das Testsystem . . . . . . . . . . . . . . . . . . . . .
43
4.2.5
Verikation des Testsystems . . . . . . . . . . . . . . . . . . . . . .
48
4.3
XCS-Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.4
Zusammenfassung
50
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Evaluierung des XCS
51
5.1
Beschreibung der Umgebung und Aktionen
. . . . . . . . . . . . . . . . .
51
5.2
Single-Step oder Multi-Step
. . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.3
Generierung von Classiern
. . . . . . . . . . . . . . . . . . . . . . . . . .
53
Beschreibung der Rewardfunktion . . . . . . . . . . . . . . . . . . .
54
5.3.1
5.4
Steuerung der Cores durch den XCS
. . . . . . . . . . . . . . . . . . . . .
56
5.5
Reaktion auf äuÿere Temperatureinüsse . . . . . . . . . . . . . . . . . . .
57
5.6
Lernen mit initialen Classiern
59
5.7
Optimierung eines Kernes bei einer DualCore-Anwendung
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . .
62
Inhaltsverzeichnis
VI
5.8
Steuerung der Speicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.9
Zusammenfassung
66
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Zusammenfassung und Diskussion
67
6.1
Zusammenfassung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
6.2
Diskussion und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
A Wichtige Herleitungen
69
A.1
Dynamische Verlustleistung
. . . . . . . . . . . . . . . . . . . . . . . . . .
69
A.2
Schaltzeit eines Inverters . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
B Parameter XCS
B.1
Die Parameter des XCS im Überblick . . . . . . . . . . . . . . . . . . . . .
Literaturverzeichnis
73
73
75
Abbildungsverzeichnis
1.1
Design Methode und autonome SoC Architektur [18] . . . . . . . . . . . .
3
2.1
Interaktion des XCS mit der Umgebung [4]
. . . . . . . . . . . . . . . . .
6
2.2
Ablauf bei einem Schritt [30]
. . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1
Dynamische Verlustleistung
. . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.2
Verschiedene Schichten bei HotSpot [14]
3.3
thermische Ersatztschaltung bei HotSpot [14]
. . . . . . . . . . . . . . . .
18
3.4
System mit Pipeline nach [27] . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.5
Pipeline-Stufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.6
Temperaturabhänigkeit der Verzögerungszeit eines Invertes [10]
. . . . . .
22
3.7
Arten von Prozessorfehlern nach [19] . . . . . . . . . . . . . . . . . . . . .
23
3.8
Vorgang bei Einschlag eines Alpha-Partikel [19] . . . . . . . . . . . . . . .
25
3.9
90nm CMOS Testship
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.10 Poisson-Prozess
. . . . . . . . . . . . . . . . . . .
3.11 Fehlerrate von elektronischen Schaltungen nach [25]
. . . . . . . . . . . .
3.12 typische Verteilungsfunktion von elektronischen Schaltungen nach [25]
18
31
. .
32
4.1
Auszug aus dem Klassendiagramm der implementierten Modelle . . . . . .
34
4.2
Auszug aus dem Klassendiagramm der implementierten Parametermodelle
35
4.3
Mögliche Vernetzung von Modellen . . . . . . . . . . . . . . . . . . . . . .
35
4.4
Implementiertes Verlustleistungsmodell . . . . . . . . . . . . . . . . . . . .
36
4.5
Schnittstelle für HotSpot . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.6
Einschwingphase Temperatur
. . . . . . . . . . . . . . . . . . . . . . . . .
37
4.7
Timing-Error Modell mit C_mteHotSpot als Temperaturmodell . . . . . .
37
4.8
Vernetzung zur Simulation eines Soft-Errors . . . . . . . . . . . . . . . . .
38
4.9
Aufbau des Opteron Prozessors . . . . . . . . . . . . . . . . . . . . . . . .
39
4.10 Floorplan des Opteron Prozessors [21]
4.11 Floorplan für HotSpot
. . . . . . . . . . . . . . . . . . . .
40
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Abbildungsverzeichnis
VIII
4.12 Modellierung des Opteron mit asoc-sim . . . . . . . . . . . . . . . . . . . .
44
4.13 Ausführung einer Trace-Primitive . . . . . . . . . . . . . . . . . . . . . . .
44
4.14 Einbindung des C-XCS in asoc-sim . . . . . . . . . . . . . . . . . . . . . .
49
5.1
Ablauf der Lernphase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.2
Temperaturschwankung von 500MHz, 0.8V nach 3000MHz, 1.3V
. . . . .
54
5.3
Timing-Error bei einer Frequenz von 2000 MHz (1 ist ein Fehler . . . . . .
55
5.4
Reaktion des XCS nach zufälligen Parametereinstellungen (LR-Zerlegung)
56
5.5
Reaktion des XCS nach zufälligen Parametereinstellungen (Matrix-Multiplikation) 57
5.6
Frequenzänderung und Spannungänderung bei allen vier Cores
. . . . . .
58
5.7
◦
Reaktion des XCS auf einen Temperaturanstieg von 15 C
. . . . . . . . .
59
5.8
◦
Reaktion des XCS auf einen Temperaturanstieg von 20 C
. . . . . . . . .
60
5.9
Ablauf der Lernphase zur Laufzeit
. . . . . . . . . . . . . . . . . . . . . .
61
5.10 Frequenz-/Spannungänderungen zur Laufzeit
. . . . . . . . . . . . . . . .
61
5.11 Verhalten des XCS nach Neulernen einer Reward-Funktion und simulierter
Temperaturanstieg von
20◦ C
. . . . . . . . . . . . . . . . . . . . . . . . .
5.12 Frequenz-/Spannungänderungen Optimierung Core2
62
. . . . . . . . . . . .
64
5.13 Spannungsänderung durch den XCS bei einem Cache . . . . . . . . . . . .
65
A.1
Zeiten bei Schaltvorgang in einem Transitor nach [27] . . . . . . . . . . . .
70
A.2
Stromstärke in Abhängigkeit der Ausgangsspannung nach [27] . . . . . . .
71
Tabellenverzeichnis
3.1
Parameterwerte für das statische Verlustleistungsmodell
. . . . . . . . . .
15
4.1
Parameterwerte für die Opteron Simulation
. . . . . . . . . . . . . . . . .
42
5.1
Parameterwerte des XCS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
Kapitel 1
Einführung
Dieses Kapitel gibt eine Einführung in den Hintergrund dieser Arbeit. Danach wird die
Aufgabenstellung und Aufbau der Arbeit beschrieben.
1.1 Hintergrund
System-on-Chips (SoCs) haben sich schon seit Jahren im Bereich eingebetteter Systeme
etabliert. Bei SoCs handelt es sich um Chips die eine Vielzahl von Systemfunktionen
auf einem Chip integrieren. Dabei kann sich ein solches System aus unterschiedlichen
Komponenten zusammensetzen. Im Prinzip können daher auf einem Chip unabhänige Komponenten wie CPU, GPU, DSP oder Speicher miteinander verbunden sein. Mit
der Entwicklung und Verbreitung von Multi-Core-Systemen hat sich ein weiterer Teilbreich bei den SoCs gebildet. Neben den eigebetteten Systemen nehmen SoCs nun auch
im Server- und Konsumerbereich eine wichtige Stellung ein. Diese Systeme werden als
Multi-Processor-System-on-Chips (MPSoC) bezeichnet.
Der Trend zu immer schnelleren und komplexeren Systemen ist nach wie vor ungebrochen.
Das
Mooresche Gesetz
sagt aus, dass sich die Anzahl an Transistoren auf einem handels-
üblichen Prozessor alle achtzehn Monate verdoppelt. Die Erhöhung von der Transistorzahl bringt aber eine erhöhte Energieraufnahme mitsich. Eine hohe Energieaufnahme hat
aber unweigerlich eine hohe Temperatur zur Folge. Die Temperatur ist ein entscheidender
Faktor bzgl. der Zuverlässigkeit eines Chips. Ist die Temperatur zu hoch, kommt es zu
Fehlverhalten oder der Chip kann dabei sogar zerstört werden.
Auÿerdem werden die Transistoren ständig verkleinert. Der 65nm Fertigungsprozess ist
gegenwärtig Standard. Die Firma Intel ist bereits dabei den 45nm Prozess zu etablieren.
Die ständige Verkleinerung der Transistoren führt aber zu einer Reihe von Problemen.
Kapitel 1 Einführung
2
Zum einen entstehen dabei Schwierigkeiten bei Leistungaufnahme, zum anderen nehmen
Fehler aufgrund energiegeladener Teilchen eine immer gröÿere Bedeutung an.
Diese Diplomarbeit entstand im Rahmen des Autonomic-System-On-Chip Projekts (ASoC)
am Wilhelm-Schickard-Institut für Informatik der Universität Tübingen. Das Ziel des
Projektes ist, die Probleme durch die ständige Verkleinerung der Transistoren und den
zunehmend komplexeren Schaltungen bei SoCs mit Hilfe von biologischen Grundsätzen
(Organic-Computing) zu lösen. Dabei wurden bereits erste Grundlagen für eine Design
Methode und eine autonome SoC Architektur entwickelt [18]. In Abbildung 1.1 werden
diese beiden Konzepte dargestellt. Die Architektur teilt sich dabei in eine funktionale
und autonome Schicht auf. Die funktionale Ebene beinhaltet dabei IP-Komponenten sowie funktionale Elemente (FEs) wie z.B CPUs oder Speicher. Die autonome Schicht wird
durch autonome Elemente (AE) gebildet. Jedes dieser Elemente besitzt einen Evaluator,
Monitor und Aktuator. Der Monitor stellt den aktuellen Zustand der FE dem Evaluator zur Verfügung. Aufgrund dieses Zustandes trit der Evaluator Entscheidungen um
z.B. auf Fehler zu reagieren, die er dem Aktuator mitteilt. Der Aktuator führt die Aktionen des Evaluators auf der FE aus. Die AEs sind dafür verantwortlich, dass die FEs
möglichst optimal arbeiten. Durch FE- und AE-Bibliotheken werden diese Architekturen
entworfen. Bei den Bibliotheken handelt es sich um parametrisierte Templates. Die Parameter dienen zur unabhänigen Beschreibung von spezischen Eigenschaften einer FE
wie Bitbreite oder Leistung. Die Templates dienen zum Überdecken von verschiedenen
autonomen Elementen. Die AEs können sich z.B. in der Art des Selbstorganisationsalgorithmus unterscheiden. Das resultierende FE/AE-Modell kann dazu benutzt werden um
das System zu optimieren [2].
1.2 Aufgabenstellung
Ziel der Diplomarbeit war es, zu evaluieren, ob sich das Learning-Classier-Verfahren
XCS als Hilfsmittel im Entwurf von Systems-on-Chip eignet. Die Parameter die der XCS
dabei verändern kann sind Frequenz und Spannung. Zur Durchführung der Evaluierung
ist es nötig eine Siumlationsumgebung zu entwickeln, die es erlaubt, die Auswirkungen
dieser zwei Parameter zu modellieren. Bei den Modellen handelt es sich um Temperatur-,
Verlustleistung- und Fehlermodelle die untersucht und implementiert wurden. Anhand
dieser Modelle muÿ der XCS evaluiert werden, ob er z.B. optimale Betriebspunkte eines
SoCs nden kann. Weiter ist zu untersuchen wie der XCS auf äuÿere Einüÿe z.B. ein
Kapitel 1 Einführung
3
Abbildung 1.1: Design Methode und autonome SoC Architektur [18]
Temperaturanstieg reagiert. Die Evaluierung soll an einer konkreten Beispielanwendung
durchgeführt werden.
1.3 Aufbau der Arbeit
In Kapitel 2 wird eine Einführung in Lerning-Classier-System XCS gegeben. Dabei sind
grundlegende Kenntisse über Learning-Classier-Systeme vorteilhaft aber nicht notwendig. Kaptiel 3 stellt Modelle für Temperatur, Verlustleistung sowie Fehlerverhalten eines
SoC vor. Das Kapitel 4 befasst sich mit der Implementierung dieser Modelle. Auÿerdem
wird darin das Testsystem beschrieben, mit dem die Evaluierung des XCS durchgeführt
wurde. In Kapitel 5 wird schlieÿlich der XCS evaluiert, ob es in der Lage ist, als Evaluator eines autonomes Element eingesetzt werden zu können. Im letzten Kapitel werden
dann die gewonnenen Ergebnisse zusammengefaÿt und Schluÿfolgerungen zum Einsatz
des XCS in einem SoC gezogen.
Kapitel 2
Learning-Classier-System: XCS
XCS (Extended-Classier-System) ist ein
Learning-Classier-System
(LCS). Dieses Ka-
pitel stellt eine Einführung in die Funktionsweise von XCS dar. Abschnitt 2.1 und 2.2
geben einen kurzen Überblick über Learning-Classier-Systeme und XCS. Während Abschnitt 2.3 detailiert die Arbeitsweise des XCS erklärt.
2.1 Allgemeines zu Learning-Classier-Systeme
Bei Learning-Classier-Systeme handelt es sich um maschinelle Lernverfahren die auf
Regeln (Classiern) basieren. Eine Regel besteht aus einer Bedingung und einer Aktion.
Dabei besitzt ein LCS ein Interface über das es mit Informationen aus der
Umgebung
(Environment) versorgt wird. Diese Informationen werden für gewöhnlich mit einem IF
Bedingung = Information THEN Aktion Konstrukt bearbeitet. Das bedeutet, falls die
Bedingung einer Regel zutrit, dann wird deren Aktion ausgeführt. Nachdem die Aktion
ausgeführt wurde, wird der Classier belohnt, abhänig davon, wie gut die Aktion in der
jeweiligen Situation war. Die Regeln werden mit Hilfe eines
genetischen Algorithmus (GA)
generiert und verändert. Das Ziel dabei ist, dass möglichst allgemeine Regeln entstehen
die eine hohe
Belohnung
(Reward) bekommen. Learning-Classier-Systeme wurden zum
ersten Mal formal beschrieben von Holland in [13]. Eine klassische Aufgabe für ein solches
System ist das Animat-Problem, welches 1987 von Wilson in [28] vorgestellt wurde. Bei
dieser Aufgabe soll sich ein Tier (oder mobiler Roboter) in einer Umgebung zurechtnden
können. Dabei ist es mit grundlegenden Aktionen wie der Bewegung (vorwärts, rückwärts,
links, rechts) sowie Sensoren zur Wahrnehmung der Umgebung ausgestattet. Mit diesen
Mitteln muÿ das Tier versuchen in der Umgebung zu überleben. Das LCS wird also
durch ein Tier repräsentiert, das lernen sollte z.B. Fressbares von nicht Fressbares zu
Kapitel 2 Learning-Classier-System: XCS
5
unterscheiden. Weiter wäre es vorteilhaft, wenn das Tier gute Futterplätze möglichst
schnell von beliebigen Orten in der Umgebung erreicht.
2.2 Überblick über den XCS
Das Learning-Classier-System XCS wurde 1995 von Wilson in [29] vorgestellt. Bei XCS
handelt es sich um ein Learning-Classier-System, das sich in mehreren Punkte von dem
traditionellen Ansatz eines LCS unterscheidet. Die bis dahin vorhandenen LearningClassier-Systeme, hatten in den meisten Fällen, für die Güte eines Classiers einen
Stärke Parameter. Dieser Parameter dient als Schätzer für die entsprechende Belohnung
und repräsentiert gleichzeitig den Fitnesswert des genetischen Algorithmus. Bei XCS gibt
es zwar auch einen solchen Parameter, der versucht die zu erwartende Belohnung vorherzusagen, die Fitness berechnet sich hier allerdings aus der Genauigkeit dieser Vorhersage.
Auÿerdem arbeitet der genetische Algorithmus ausschlieÿlich auf seinem Action-Set, anstatt auf der gesamten Population. Der XCS besitzt keine Nachrichtenliste und ist daher
theoretisch nur für Markov Umgebungen geeignet. Die weiteren Ausführungen halten sich
an [4] und [5].
2.2.1 Interaktion mit der Umgebung
Die Umgebung versorgt dabei das System mit einer Reihe von Sensordaten. Dabei handelt es sich um ein n-Tupel
σ(t) ∈ {0, 1}L ,
wobei
L
für die Anzahl der Bits steht, die
benötigt werden, um jede Situation zu beschreiben. Aufgrund dieser Sensordaten führt
das System eine Aktion
Skalar
ρ(t)
α(t) ∈ {a1 , ..., an }
aus. Jede dieser Aktionen wird mit einem
belohnt, der durchaus auch Null sein kann. Grundsätzlich gibt es zwei ver-
schiedene Problemarten:
1. Single-Step-Probleme
2. Multi-Step-Probleme
Das Flag
eop
markiert das Ende eines Problems. Bei XCS gibt es neben der Umgebung
noch eine weitere Komponente: das
Reinforcement-Programm
(reinforcement-program).
Diese Komponente ist für die Verteilung der Belohnung zuständig. Die Trennung von
der Umgebung ist logisch, da die Belohnung nicht zwingend eine vererbte Eigenschaft
der Umgebung ist, sondern zum Beispiel vom System selbst festgesetzt werden kann.
Abbildung 2.1 verdeutlicht das Zusammenspiel der einzelnen Elemente.
Kapitel 2 Learning-Classier-System: XCS
6
Abbildung 2.1: Interaktion des XCS mit der Umgebung [4]
2.2.2 Single-Step und Multi-Step Probleme
Der Unterschied zwischen einem Single-Step und Multi-Step Problem ist:
1. Bei einem Single-Step Problem hängen die aufeinanderfolgenden Aktionen nicht
voneinander ab. Nach der Ausführung einer Aktion liefert das ReinforcementProgramm die entsprechende Belohnung
ρ
und setzt das Flag
eop.
2. Bei einem Multi-Step Problem hängen alle aufeinanderfolgende Aktionen voneinander ab. Eine Belohnung gibt es nur in bestimmten Situationen. Auÿerdem muÿ
das Reinforcement-Programm signalisieren, dass eine Aufgabe erfüllt ist.
Ein Beispiel für ein Single-Step-Problem ist ein Multiplexer. Die Eingabedaten in den
Multiplexer hängen nicht voneinander ab und das Ergebnis kann sofort abgefragt werden. Der XCS bekommt daher von der Umgebung die Eingabedaten geliefert und gibt als
Aktion das Ergebnis an die Umgebung zurück. Die Eingabedaten sind Werte der Steuerund Datenleitungen des Multiplexers. Stimmt das vorhergesagte Ergebnis mit dem tatsächlichen Ergebnis überein, so gibt das Reinforcement-Programm eine hohe Belohnung
an den XCS zurück. Das bereits angesprochene Animat-Problem hingegen, läÿt sich einfacher als Multi-Step-Problem lösen. Das heiÿt, die gewählten Bewegungen des Tieres in
der Umgebung hängen voneinander ab. Wenn sich z.B. feste Futterstellen in der Umgebung benden, gibt es von jeder Position einen kürzesten Pfad. Es ist also entscheidend,
wann bzw. welche Aktion von einer bestimmten Position ausgeführt wird. Falls eine Fut-
Kapitel 2 Learning-Classier-System: XCS
7
terstelle erreicht wird, setzt das Reinforcement-Programm das
eop
Flag und berechnet
die entsprechende Belohnung. Ein Multi-Step-Problem wird durch eine feste Anzahl an
Schritten begrenzt.
2.3 Formale Beschreibung des XCS
Die Classier des XCS bestehen wie allgemein üblich aus einer Bedingung und einer
Aktion. Alle Classier werden in einer sogenannten Population verwaltet. Genauer beschreibt sich ein solcher Classier wie folgt: die Bedingung
tion
A ∈ {a1 , ..., an }.
Die möglichen Situationen
s
C ∈ {0, 1, ]}L
stammen aus
und der Ak-
S ⊆ {0, 1}L ,
möglichen Sensordaten repräsentiert. Der Vorhersagewert (prediction)
ρ
die alle
schätzt die zu
erwartende Belohnung ab. Zusätzlich gibt es für jeden Classier noch weitere Parameter:
der Vorhersagefehler
Parameter
ε
ε
(error), die Fitness
F
exp.
(tness) und der Erfahrungswert
Der
gibt dabei den geschätzten Fehler einer Vorhersage der Belohnung an. Die
Fitness schätzt die Genauigkeit der Belohnungsvorhersage
ρ ab. Der Erfahrungswert exp
ist ein Zähler, wie oft ein Classier seit seiner Entstehung in das Action-Set gelangte.
Der Ziel des XCS ist es, die erhaltene Belohnung auf lange Sicht zu maximieren. Um dieses
Ziel zu erreichen lernt der XCS eine Action-Value Funktion die ein Zustands-Aktion Paar
auf eine reele Zahl abbildet (Belohnung). Der Zustand ist hierbei die aktuelle Situation
der Umgebung.
2.3.1 Die Sets des XCS
Bei XCS gibt es vier verschiedene Arten von Sets. Das erste ist die Population
alle vom XCS erstellten Classier enthält. Das Match-Set
enthält alle Classier die zu einer gegenwärtigen Situation
das Action-Set
[A]
[M ]
bildet sich aus
σ(t)
passen. Aus
[P ],
das
[P ]
und
[M ]
wird
berechnet und fasst alle Classier zusammen, die die selbe Aktion
beschreiben. Zuletzt gibt es noch das Previous-Action-Set
[A]−1
was dem Action-Set des
vorherigen Ausführunszeitpunktes entspricht.
2.3.2 Ablauf eines Single-Step Experiments
Der XCS interagiert bei einem Single-Step Problem mit der Umgebung wie folgt. Wenn
das System eine Eingabe von der Umgebung bekommt, dann erstellt es ein Match-Set
Kapitel 2 Learning-Classier-System: XCS
[M ].
8
Darin sind alle Classier enthalten, deren Bedingung mit der Eingabe übereinstim-
men. Falls
[M ]
weniger als
θmna
(einstellbare Schranke) Classier mit unterschiedlichen
Aktionen enthält, dann werden neue Classier erstellt. Diese neuen Classier haben eine
passende Bedingung zu der Eingabe und eine zufällige Aktion. Das Verfahren wird auch
als Covering bezeichnet. Bei den neuen Classiern wird mit einer Wahrscheinlichkeit von
P]
(einstellbarer Parameter) das Don't-Care Symbol
gesetzt. Für jede Aktion in
[M ]
] bei jedem Attribut der Bedingung
wird dann eine System Wahrscheinlichkeit
net, mit der die Belohnung abgeschätzt wird, falls die Aktion
P (α)
berech-
α ausgeführt werden sollte.
Diese Wahrscheinlichkeit berechnet sich wie folgt:
P
P (α) =
cl.a=a
V
cl.p × cl.F
cl∈[M ]
P
cl.a=a
dabei ist
cl.F
cl.a
die Aktion,
cl.p
die Fitness des Classiers
V
(2.1)
cl.F
cl∈[M ]
die Wahrscheinlichkeit (der möglichen Belohnung) und
cl. Aus diesen Werten wird das Prediciton-Array gebildet.
Daraus wird dann entweder die Aktion gewählt, mit der höchsten Belohnung (ExploitPhase) oder eine zufällige Aktion ausgeführt (Explore-Phase). Alle Classier in
der ausgewählten Aktion werden in das Action-Set
[A]
[M ]
mit
geladen. Danach wird die Aktion
an die Umgebung gesendet, die daraufhin die Belohnung für die Aktion an das System
zurückliefert.
Während jedem Zyklus aktualisiert der XCS anhand der Belohnung
jedes Classiers in
[A].
R
die Parameter
Die neue Vorhersage des Classiers berechnet sich mit
p ← p + β(R − p),
dabei ist
β (0 < β ≤ 1)
die Lernrate. Der Vorhersagefehler
← + β(|R − p| − ).
Die Aktualisierung der Classier Fitness
igkeit
κ
F
(2.2)
errechnet sich aus:
(2.3)
ist komplizierter. Als Erstes wird die Genau-
0
und die relative Genauigkeit κ der Classier mit

1
κ=
α( )−v
0
falls
< 0 ,
sonst
(2.4)
Kapitel 2 Learning-Classier-System: XCS
9
κ
κ0 = P
(2.5)
κx
x∈[A]
berechnet. Der Parameter
1)
und
v (v > 0)
Vorhersagefehler
0
steuert die Toleranz des Vorhersagefehlers,
κ
sind Konstanten von
> 0
ist. Die Fitness
F
α (0 < α <
welche die Abnahme bestimmen, falls der
läÿt sich nun daraus mit
F ← F + β(κ0 − F )
(2.6)
berechnen. Die Fitness der Classier ist daher eine Schätzung der Genauigkeit relativ zu
den anderen Classiern in
[A],
und verhält sich invers zu dessen Fehler der Vorhersage
der Belohnung. Fehler unterhalb der Schranke
0
werden betrachtet als ob sie die gleiche
Genauigkeit besitzen.
In Abbildung 2.2 wird der ganze Vorgang verdeutlicht. Dabei laufen folgende Schritte
ab:
Die Umgebung liefert eine Situation an die Sensoren (detectors) des XCS. Der XCS prüft
nun welche Classiern in der Population mit der Situation übereinstimmen. Alle Classier
die zu der Situation passend sind, werden ins Match-Set geladen. Danach wird aus allen
Classier im Match-Set
P (α) berechnet, diese Werte bilden das Prediction-Array. Da ein
XCS-Schritt immer aus zwei Teilschritten besteht (Explore-/Exploit-Schritt) kann nun
folgendes passieren. Im Exploit-Schritt werden die Classier in das Action-Set geladen
(aus dem Match-Set), welche die höchsten
Wahrscheinlichkeit
P (α) haben. Im Explore-Schritt wird mit einer
P] eine zufällige Aktion ausgewählt. Dann kommen alle Classier (aus
dem Match-Set) in das Action-Set die diese Aktion besitzen. Wenn bei einem Single-Step
Problem bzw. einem Multi-Step-Problem das Ende erreicht ist, dann muÿ die Umgebung
in eine neue zufällige Situation zurückversetzt werden. Im Falle des Animat-Problems
wäre dies eine zufällige Position in der Umgebung.
Der GA kann in
[A]−1
oder
[A]
zum Einsatz kommen, der GA wird daher auch als
Nischen-GA bezeichnet. In der ersten Version des XCS arbeitete der GA auf dem MatchSet, während in früheren Learning-Classier-Systemen wurde der GA immer auf die
gesamte Population angewendet. Der Vorteil des Nichen-GA liegt darin, dass möglichst
genaue und allgemeine Classier erstellt werden [30]. In Abbildung 2.2 wird auch klar, wie
die Parameter bei Multi-Step Problemen aktualisiert werden. Bei Multi-Step-Problemen
werden nur die aktuellen Classier in
[A]
und die letzten in
[A]−1
aktualisiert. Mit genü-
gend vielen Interationen verteilt sich also die Belohnung auf alle beteiligten Classier.
Kapitel 2 Learning-Classier-System: XCS
Abbildung 2.2: Ablauf bei einem Schritt [30]
10
Kapitel 2 Learning-Classier-System: XCS
11
2.3.3 Einfügen neuer Classier
Bei XCS wird auÿerdem eine Macro-Classier Technik angewendet. Ein Macro-Classier
repräsentiert eine Menge an Classiern, welche die selbe Aktion und Bedingung haben.
Wenn ein neuer Classier durch den GA erstellt wird, dann wird als erstes die Population
[P ]
durchsucht. Falls ein Classier bereits existiert der über die selbe Bedingung
und Aktion verfügt, so wird nur dessen Numerosität um Eins erhöht. Der neu erstellte
Classier wird daraufhin verworfen, ansonsten wird er in
[P ]
eingefügt. Wenn ein Classi-
er gelöscht werden soll, dann wird seine Numerosität um Eins dekrementiert. Erst wenn
seine Numerosität Null erreicht, wird er aus
[P ]
gelöscht. Dabei ist weiter wichtig, dass
die Summe aller Numerositäten der maximalen Anzahl der erlaubten Classiern in einer
Population entspricht.
2.3.4 Zusammenfassen von Classiern
Bei der Zusammenfassung von Classiern werden bei XCS zwei Verfahren angewendet:
1. Bei der Zusammenfassung im GA wird ein Nachkomme überprüft, ob dessen Bedingung von der Bedingung der Eltern Classier überdeckt wird. Eine Vereinigung
kann nur stattnden, wenn der Eltern-Classier über eine hohe Genauigkeit und
Erfahrung verfügt. Falls ja, so wird ausschlieÿlich die Numerostität des jeweilgen
Eltern Classiers erhöht.
2. Bei der Zusammenfassung im Action-Set wird ein möglichst allgemeiner Classier
gesucht, der zusätzlich noch eine hohe Genauigkeit und Erfahrung besitzt. Gegen
diesen Classier werden dann alle anderen Classier im Action-Set getestet. Falls
einer dieser Classier mit allgemeinen Classier vereinigt werden kann, dann wird
dieser aus der Population gelöscht.
2.3.5 Vorgehensweise des GAs
Der GA erzeugt seine Kinder indem er mit Wahrscheinlichkeit
Ps (cl)
zwei Classier aus
seinem Action-Set auswählt. Dabei ist
Ps (cl) = P
cl.f
cl0 ∈[A] cl
0 .f
.
(2.7)
Kapitel 2 Learning-Classier-System: XCS
12
Der GA besitzt zwei Möglichkeiten wie er die Mutation durchführt: freie Mutation und
Nischen-Mutation. Bei der freien Mutation werden beliebige Stellen einer Bedingung
mutiert, hingegen bei der Nischen-Mutation muÿ die erzeugte Bedingung zu der aktuellen
Situation
s
passen.
2.3.6 Löschen von Classiern
Der Löschvorgang von Classiern läuft nach folgendem Schema ab. Mit einer Wahrscheinlichkeit, die proportional zur geschätzten Gröÿe der Action-Sets
aus
[P ]
as
ist, werden Classier
ausgewählt. Für den Fall, dass der Classier unerfahren ist, und seine Fitness
unterhalb der durchschinttlichen Fitness liegt, wird seine Löschwahrscheinlichkeit erhöht.
Erreicht die Population die maximale Gröÿe, so werden mit Hilfe dieser Wahrscheinlichkeit Classier gelöscht. Der Parameter
as
berechnet sich durch
cl.as ← cl.as + β (|| [A] || − cl.as) .
(2.8)
2.4 Zusammenfassung
Dieses Kapitel hat eine Einführung in das Learning-Classifer-System XCS gegeben. Die
Abschnitten 2.1 und 2.2 beschäftigten sich mit Grundprinzip von Learning-ClassierSystemen und XCS. Sie behandelten auch den Unterschied zwischen Multi-Step und
Single-Step Problemen. Wähernd in Abschnitt 2.3 der detailierte Ablauf bei einem SingleStep Experiment im Vordergrund stand.
Kapitel 3
Modellierung von SoCs
Das Ziel dieser Arbeit ist es zu prüfen, ob ein XCS einen SoC steuern kann. Wie in Kapitel 2 beschrieben, erhält ein XCS seine Eingabedaten aus einer Umgebung. Der SoC
Spannung und Frequenz, sowie durch
elektrische Leistung und Temperatur. Zwischen diesen vier
deniert selbst die Umgebung durch die Parameter
die physikalischen Gröÿen
Komponenten besteht ein direkter Zusammenhang, ob ein SoC fehlerfrei arbeitet oder
nicht. Dieses Kapitel stellt deshalb Modelle vor, die Temperatur, Leistungaufnahme und
Fehlerverhalten beschreiben. Als erstes werden die Modelle zur Verlustleistung und Temperatursimulation beschrieben. Danach werden Fehlermodelle und ihre Ursachen näher
untersucht.
3.1 Berechnung der Verlustleistung
Die Verlustleistung von CMOS-Schaltungen wird in dynamische und statische Verlustleistung unterteilt. Beeinuÿt wird die dynamische Verlustleistung hauptsächlich durch
die Kapazität des Transistors und den Widerständen der Anschlüsse. Auÿerdem spielen
die Kapazitäten der darauolgenden Transistoren eine wichtige Rolle. Die Ursachen für
den statischen Leistungsverlust sind die sogenannten Leckströme, die in jedem Transistor auftreten. Der wichtigste ist der Leckstrom zwischen Source und Drain. Leckströme
entstehen durch freie Ladungsträger im Halbleiter [6].
Die Abbildung 3.1 verdeutlicht das Auftreten der dynamischen Verlustleistung. Wenn ein
Transistor schaltet, dann ieÿt der Saturations-Strom
IDsat
in die Kapazität
C.
Dieser
Strom ist abhängig von der angelegten Spannung als auch von der Zeit. Je stärker der
Kondensator geladen ist, desto kleiner wird der Strom.
Kapitel 3 Modellierung von SoCs
14
Abbildung 3.1: Dynamische Verlustleistung
3.1.1 Modell zu Berechnung der statischen Verlustleistung
Das von Butts et al. entwickelte Modell zielt drauf ab, in High-Level-Simulationen zum
Einsatz zu kommen. Allgemein verhält sich die statische Verlustleistung wie folgt: Für
kleine Ströme ist
IDsat
proportional zu
des Transistors. Der Strom
IDsat
VDD − Vt .
Dabei ist
Vt
die Schwellwertspannung
hängt aber noch von weiteren Parametern ab, wie z.B.
von der Kanallänge in einem Transistor. Dadurch verringert sich die Stromstärke weitaus
stärker bei einer Verkleinerung des Transistor. Dem entgegen wirkt aber der Driftstrom
der sich bei einer Verkleinerung stark erhöht. Daher muÿ auch die Schwellwertspannung
Vt
herabgesenkt werden, um eine bessere Performanz zu erzielen. Durch immer weitere
Herabsenkung der Schwellwertpannung
Vt
nehmen die Leckströme eine enorme Bedeu-
tung an. Der Leckstrom in Abhänigigkeit von der Schwellwertspannung
Vt
kann durch
−qVt
IDsub = ke akB T .
beschrieben werden. Dabei sind
und
k
q
und
kB
sind Kenngröÿen des Bausteins und
(3.1)
physikalische Konstanten. Die Parameter
T
a
ist die absolute Temperatur. Darin sieht
man auch, dass der Leckstrom exponentiell zunimmt, falls die Temperatur ansteigt oder
Vt
abgesenkt wird.
Das Modell nähert die statische Verlustleistung durch
Ps = VDD × N × kdesign × ktech × 10
−Vt
St
(3.2)
Kapitel 3 Modellierung von SoCs
15
an. Dabei werden die drei technologieabhängigen Parameter (ktech , St und
Vt )
in einer
Technolgiekonstante zusammengefaÿt. Dies führt zu folgenden Ansatz:
Ps = VDD × N × kdesign × Iˆleak
Bei
Iˆleak
(3.3)
handelt es sich um den normalisierten Leckstrom. Der Vorteil daran ist, dass
für eine feste CMOS Technologie verschiedene Leckströme angenommen werden können,
allerdings führt dies zu einer schlechteren Schätzung als wenn
ktech , Vt
und
St
berück-
sichtigt werden würden.
Schaltung
N
kdesign
D Flip-Flop
22/bit
1.4
D Latch
10/bit
2.0
2-input mux
2 / bit/input
1.9
CAM cell
13 /bit
1.7
Static logic
2/gate input
11(9)
Tabelle 3.1: Parameterwerte für das statische Verlustleistungsmodell
Die Parameter für das Modell sind in Tabelle 3.1 angegeben [6].
3.1.2 Modell zu dynamischen Verlustleistung
Die dynamische Verlustleistung wird im allgemeinen mit
2
Pd = CL VDD
fp
modelliert, wobei
CL
die Lastkapazität und
fp
(3.4)
die Taktfrequenz. Diese Formel wird auf
der Grundlage eines Inverters hergeleitet (siehe Appendix A.1). An dieser Formel ist zu
erkennen, dass die Leistung linear mit der Frequenz ansteigt, aber unabhängig von den
Geräte Parametern ist [27].
3.1.3 Gesamte Verlustleistung
Wenn die Kurzschlussverlustleistung vernachlässigt wird, kann die gesamte Verlustleistung aus Formel 3.3 und 3.4 mit
Ptotal = Ps + Pd
(3.5)
Kapitel 3 Modellierung von SoCs
16
berechnet werden. Da es aber bei der dynamischen Verlustleistung stark darauf ankommt,
welche Schaltelemente überhaupt arbeiten, wird im allgemeinen folgende Vereinfachung
angenommen.
Pd =
Der Parameter
α
mit
(0 ≤ α ≤ 1)
2
α ∗ CT otal VDD
tp
(3.6)
beschreibt die Signalaktivität, also die prozentua-
le Anzahl der Schaltvorgänge in einer Schaltung und
Ctotal
die gesamte Kapazität der
Schaltung [27]. Diese Methode wird oft zur Schätzung der Leistungsaufnahme verwendet. In [8] wurde dies z.B. von der Firma Intel verwendet um den Prozessor Pentium M
stromsparender zu machen. Darin wurde die Signalaktivität ( engl. activity factor) als
die durchschnittliche Anzahl von 0 nach 1 Übergängen deniert. Die Extraktion der Signalaktivität wurde über eine Logiksimulation vorgenommen. Genauso kann dabei auch
mit einer maximalen Signalaktivtät gearbeitet werden, um ein Worst-Case-Szenarium zu
simulieren, denn die Signalaktivität ist bei jedem Programm verschieden.
3.2 Modellierung der Temperatur auf einem SoC
Die Temperatur hängt bei SoCs in erster Linie von der Leistungsaufnahme der einzelnen
FEs ab. Dabei kommt es auch zu einer Wechselwirkung zwischen den FEs. Auÿerdem
müssen vorhandene Kühlsysteme berücksichtigt werden.
3.2.1 Grundlagen zur Berechnung der Temperatur
Bei Transistoren müssen unbedingt gewisse Grenzwerte eingehalten werden, da sie ansonsten zerstört werden. In den Datenblättern wird daher eine höchstzulässige Sperrschichttemperatur
TJmax
und bei Silizium bei ca.
angegeben. Der Grenzwert liegt bei Geranium bei ca.
200◦ C .
100◦ C
Da es schwierig ist, diese Temperatur direkt zu messen
wird zusätzlich noch die maximale Verlustleistung als Grenzwert angegeben. Die maximal
Ptotmax wird meist auf eine Gehäusetempera◦
tur von 25 C bezogen. Bei höheren Gehäusetemperaturen gelten geringere Werte, die
höchstzulässige Transistorverlustleistung
aus einer Lastminderungskurve zu entnehmen sind. Die Lastminderungskurve gibt die
maximale zulässige Verlustleistung abhängig von der Gehäusetemperatur
TG
an.
Aus der Lastminderungskurve kann der thermische Widerstand des Transistors berechnet
werden:
Kapitel 3 Modellierung von SoCs
17
RthJG =
Die tatsächliche Verlustleistung
Ptotal
∆P
.
∆TG
(3.7)
muÿ geringer sein als
Ptotmax .
Damit eine festge-
legte Gehäusetemperatur gehalten werden kann, ist meist der Einsatz eines Kühlkörpers
nötig. Die Berechnung kann mit einer thermischen Ersatzschaltung durchgeführt werden.
Eine thermische Schaltung besitzt die gleichen Elemente wie eine elektrische Schaltung.
Der Wärmewiderstand
peraturstufen
T
Rth
ist das Gegenstück zum elektrischen Widerstand
entsprechen den elektrischen Potenzialen
mit dem elektrischen Strom
I
ϕ.
R. Die Tem-
Der Wärmestrom
PV
kann
verglichen werden [31].
In vergangener Zeit wurde diverese Modelle entwickelt, um die Temperatur von Chips
zu schätzen. Ein Modell wurde in [20] bereits vorgestellt. Ein weiteres ist HotSpot [14],
welches sich zu einem Standard im akademischen Umfeld entwickelt hat.
3.2.2 Ermittlung der Temperatur mit HotSpot
Mit HotSpot wurde von Skadron et al. ein Temperatursimulator entwickelt, der Temperaturen auf einem Chip sehr genau berechnen kann. Bei HotSpot wird ein Chip in
verschiedene Ebenen unterteilt. Die Wärme wird dabei von der aktiven Silizium Schicht
erzeugt. Diese Schicht ist verbunden über den Silizum-Bulk mit dem Thermal-InterfaceMaterial, dem Kühlerhalter und dem Kühlkörper selbst. Weiter gibt es noch einen zweiten Wärmeuss, der die Wärme an die Platine überträgt. In Abbildung 3.2 sind die alle
Schichten zu sehen die HotSpot modelliert.
HotSpot kann dabei beide Wärmeüsse modellieren, wobei jede Ebene unterteilt ist in
Blöcke. Beispielsweise kann der Silizum-Bulk in ein unstrukturiertes Gitter unterteilt
werden, auf Basis der FEs. Falls die Temperaturbestimmung feinkörniger sein soll, ist
es auch möglich, die Ebene in ein feiner strukturiertes Gitter aufzuteilen. Jeder Block
bzw. jede Gitterzelle wird einem Knoten eines thermischen Ersatznetzwerks zugeordnet. Dabei besitzt jeder Block oder jede Zelle einen vertikalen thermischen und mehrere
laterale Widerstände. Abbildung 3.3 zeigt das thermische Ersatznetzwerk. Der thermische Widerstand modelliert dabei die Wärmeübertragung nach oben und unten. Er wird
beschrieben durch:
Rvertical =
t
k∗A
(3.8)
Kapitel 3 Modellierung von SoCs
Abbildung 3.2: Verschiedene Schichten bei HotSpot [14]
Abbildung 3.3: thermische Ersatztschaltung bei HotSpot [14]
18
Kapitel 3 Modellierung von SoCs
19
Abbildung 3.4: System mit Pipeline nach [27]
Dabei ist
t
die Dicke der Schicht, k die thermische Konduktivität und
A
die Fläche des
Blocks. Die Berechnung der lateralen Widerstände ist komplizierter. Die Ableitungen und
Formeln können in [17] und [23] gefunden werden. Für die mit der Umgebung verbundenen Schichten wird ein konstanter Wärmeübertragskoezient angenommen. Diese Annahme führt zum folgenden Ansatz des korrespondierenden thermischen Widerstands:
Rconvection =
1
,
hA
(3.9)
dabei ist A die Oberäche [14].
3.3 Modell aufgrund von Zeitverletzungen
Fehler die aufgrund von Zeitverletzungen entstehen werden auch
Timing-Errors genannt.
Die Ursache sind zu lange Schaltzeiten von Schaltelementen. Haupteinuss auf solche
Fehler hat die Verzögerungszeit der Logik. Diese wird hauptsächlich von der Spannung
beeinuÿt, aber auch von der Temperatur. Abbildung 3.4 zeigt diesen Sachverhalt bei
einem System welches Piplines benutzt. Bei solchen Systemen wird die Ausgabe der Logik
bis zum nächsten Takt in Registern zwischengespeichert [27]. Ist nun die Verzögerungszeit
der Logik zu lange, dann sind in den Registern nicht die korrekten Werte. Dadurch
entsteht ein Timing-Error. .
Timing-Errors zu modellieren ist sehr schwierig, da sie auch davon abhängen, welchen
Weg ein Signal durch die Logik nimmt. Deshalb wurde in dieser Arbeit ein sehr einfaches Timing-Error Modell entwickelt, welches auf einer Reihenschaltung von Invertern
besteht:
Das Modell beschreibt eine Pipline-Stufe mit 10 Inverter die in Reihe geschaltet sind. In
Kapitel 3 Modellierung von SoCs
20
Abbildung 3.5: Pipeline-Stufe
Abbildung 3.5 ist der Aufbau skizziert. Ist das Signal nicht innerhalb eines Taktes am
Eingang des Latches angekommen, dann wird ein Timing-Error injiziert. Ein ähnliches
Modell welches zur Schätzung der Soft-Error-Rate angewendet worden ist ndet sich in
[24].
3.3.1 Analytisches Modell zu Berechnung der Verzögerungszeit eines
Invertes
In [27] wird ein analytisches Modell vorgestellt mit dessen Hilfe sich die Verzögerungszeit
eines Inverters in Abhängigkeit von der Spannung berechnen läÿt (Herleitung Appendix A.2). Die Schaltgeschwindigkeit eines CMOS-Gates wird dabei von der Lade- und
Entladezeit der Kapazität abhänig gemacht, wobei in drei Zeiten unterschieden wird:
1.
tr
beschreibt die Zeit, die das Ausgangssignal eines Transistors benötigt, um von
10%
2.
tf
td
90%
seines stationären Wertes anzusteigen.
beschreibt die Zeit, die das Ausgangssignal eines Transistors benötigt, um von
90%
3.
auf
auf
10%
seines staionären Wertes abzufallen.
ist die Verzögerungszeit, von dem Zeitpunkt an, bei dem das Eingangsignal
und das Ausgangsignal
50%
50%
erreicht.
In dem Modell ergibt sich die gesamte Fallzeit durch
2CL
tf =
βn VDD (1 − n)
β
(n − 0.1) 1
+ ln (19 − 20n) .
(1 − n)
2
ist dabei der Steilheitskoezient und
n =
(3.10)
|vtn |
VDD . Aus den Formeln ist zu erkennen,
dass die Verzögerungszeit proportional von der Ladekapzität des Transistors abhängt.
Auÿerdem ist sie antiproportional zur angelegten Spannung. Falls die Spannung erhöht
wird vermindert sich die Verzögerungszeit.
Kapitel 3 Modellierung von SoCs
21
Berechnung der Zeit für einen Signalanstieg in einem Inverter
Durch die Symmetrie eines CMOS-Inverter kann für die Anstiegszeit
tf
eine ähnliche
Näherung wie bei der Fallzeit angenommen werden, so dass sich der folgende Ansatz
ergibt:
2CL
tr =
βp VDD (1 − p)
mit
p=
(p − 0.1) 1
+ ln (19 − 20p)
(1 − p)
2
(3.11)
|vtp |
VDD .
Für gleich groÿe NMOS- und PMOS-Transistoren kann
βn = 2βp angenommen werden.
Berechnung der Verzögerungszeit
Bei den meisten CMOS Schaltungen wird die Verzögerungszeit hauptsächlich durch Fallund Anstiegzeit des Ausgangssignal bestimmt. Daher berechnet sich die Verzögerungszeit
mit
tdr =
tr
2
(3.12)
tdf =
tf
.
2
(3.13)
und
Daraus ergibt sich als durchschnittliche Verzögerungszeit
tav =
tdf + tdr
.
2
(3.14)
3.3.2 Temperatureinuÿ auf die Schaltzeit
Die herrschende Temperatur hat auf die Verzögerungszeit der Logik einen entscheidenden
Einuÿ. In [10] wurden die Fall- und Anstiegszeiten bei einem Inverter, in Abhänigkeit
von der Temperatur gemessen. Wie in Abbildung 3.6 zu sehen ist, steigt die Verzögerungszeit ungefähr linear an. Auÿerdem ist sie im Vergleich zu
218K
bei
428K
mehr als
zweimal so hoch.
Dieses Verhalten der Verzögerung wurde bei unterschiedlichen Frequenzen festgestellt.
Kapitel 3 Modellierung von SoCs
22
Abbildung 3.6: Temperaturabhänigkeit der Verzögerungszeit eines Invertes [10]
3.3.3 Gesamte Schaltzeit eines Inverters
Damit auch die Temperatur berücksichtigt werden kann, wird in dieser Arbeit aufgrund
3.3.2 die Verlängerung der Schaltzeit als linear angenommen. Diese Annahme führt zu
folgendem Ansatz bei der Berechnung dieser Zeit:
ttempdelay (T ) =
T − 218K
∗ tg ,
418K − 218K
wobei ist tg der gesamte zeitliche Unterschied von
218K
zu
418K
(3.15)
ist. Das heiÿt ttempdelay
ist die Verlängerung der Schaltzeit aufgrund einer erhöhten Temperatur. Das Modell
berechnet deshalb die durchschnittliche Schaltzeit mit
tav =
tdf + ttempdelay + tdr + ttempdelay
.
2
(3.16)
3.3.4 Berechnung der Verzögerungszeit der Pipeline-Stufe
Die Zeit
tav
wird benutzt um für jeden Inverter der Pipeline-Stufe die Schaltzeit zu be-
rechnen. Ist also die gesamte Verzögerungszeit der 10 Inverter länger als die Taktperiode,
dann liegt bei diesem Modell ein Timing-Error vor. Dieses einfache Modell ist ausreichend
um Timing-Errors für die Evaluierung des XCS zu beschreiben.
Kapitel 3 Modellierung von SoCs
23
Abbildung 3.7: Arten von Prozessorfehlern nach [19]
3.4 Soft Errors
Bei Soft-Errors handelt es sich um Single-Event-Eects (SEE), die keinen destruktiven
Einuÿ auf die Hardware haben. Durch das Zurücksetzen der Hardware in einen alten
Zustand, kann die Hardware in ein normales Arbeitsverhalten zurückgeführt werden. Im
Vergleich dazu stehen Hard-Errors, die zu dauerhaften Fehlern führen. In Abbildung 3.7
sind die verschiedenen Arten von Prozessorfehler zu sehen. Die Gründe für das Auftreten
von Soft-Errors liegen hauptsächlich an externer radioaktiver Strahlung, die auch als
Single-Event-Upsets (SEU) bekannt sind. Sie führen zu transienten und inkonsistenten
Fehlern der Daten, welche nicht in Verbindung mit Fabrikationsfehlern stehen. Genauer
handelt es sich dabei entweder um Single-Bit-Upsets (SEU) oder Multiple-Bit-Upsets
(MBU). Bei einem SEU dreht sich genau ein Bit, während bei MBUs werden mehrere
Bits gedreht.
SEUs sind zufällig und führen zu groÿen Schwierigkeiten, gerade bei Anwendungen, die
durch fehlerhafte Speicherinhalte gesteuert werden. Denn dann sind nicht nur die Anwendungsdaten fehlerhaft, sondern auch die Anwendung selbst ist nicht mehr funktionsfähig,
was zu systemkritischen Fehlern führen kann [19].
Kapitel 3 Modellierung von SoCs
24
3.4.1 Grundlagen zu Soft Errors
Die Hauptquellen der SEUs sind:
1. nieder-energetische Alpha-Teilchen,
2. hoch-energetische kosmische Teilchen,
3. und thermische Neutronen.
Alpha-Partikel entstehen bei radioaktivem Zerfall von Uranium-238 und Thorium-232.
Durch diesen Vorgang werden Alpha-Partikel zwischen 2 und 9 MeV freigesetzt. Die
benötigte Energie für ein Elektronen-Loch-Paar beträgt bei Silizium 3.6 eV, weshalb ein
Alpha-Partikel ca
106
Elektronen-Loch-Paare erzeugen kann. Dringt der Alpha-Partikel
in die Silizium Schicht ein, so verändert er die gegenwärtige Ladung (Abbildung 3.8),
da er die erzeugten Elektronen-Lochpaare mitzieht. Je nach Geometrie des Eindringens
und der Höhe der sogenannten kritischen Ladung
Qcrit
kann dies zur einer Fehlschaltung
führen. Die geschieht genau dann, wenn die von dem Alpha-Partikel erzeugte Ladung die
kritische Ladung übersteigt. Dadurch wird ein Störimpuls erzeugt, der zum Drehen eines
Bits führt. Diese Störladung ist:
Z
∞
Qa =
Ia (t) dt.
(3.17)
t=t0
Dabei ist
Ia
der durch das Ion induzierte Strom und t0 der Einschlagzeitpunkt des Alpha-
Partikels. Ist
Qa > Qcrit
dann entsteht ein interner Fehler. Die kritische Ladung be-
schreibt also wie resistent eine Schaltung gegen Soft-Errors ist [16]. Eine höhere kritsche
Ladung führt zu weniger Soft-Errors, was wiederum zu einem höheren Energieverbrauch
und langsameren Schaltungen führt. Neben Alpha-Partikeln gibt es noch zwei weitere
Quellen für das Auftreten von Soft-Errors. Hochenergetische kosmische Teilchen reagieren mit der oberen Atmosphäre der Erde. Dadurch entstehen hochenergetische Neutronen
(10 bis 800 MeV) und Protonen (30 MeV). Da Neutronen keinerlei Ladung haben, interagieren sie nicht direkt mit dem Halbleiter Baustein. Kolidiert ein solches Neutron mit
dem Silizium Atomkern, so können Alpha-Partikel und weitere schwere Ionen entstehen.
Dadurch entstehen wiederum Elektronen-Loch-Paare mit weitaus gröÿeren Energien. Der
Einuss von Neutronen ist ortsabhängig, da die Durchuÿrate vom Schildeekt der Atmosphäre beeinuÿt wird.
Kapitel 3 Modellierung von SoCs
25
Abbildung 3.8: Vorgang bei Einschlag eines Alpha-Partikel [19]
Thermische Neutronen tragen einen groÿen Anteil an Soft-Errors Sie besitzen Energie
von ca. 25 meV und können allerdings leicht vermieden werden, wenn im Chip kein
Boron-Phosphor-Silicate-Glas verwendet wird.
Durch stetige Verfeinerung des Produktions-Prozess (von 0,25
µm
bis zu 45 nm) ver-
ringert sich auch die Versorgungsspannung und die Kapazität. Dadurch verringert sich
auch die kritische Ladung und womit ein radioaktives Teilchen die Zelle leichter beeinuÿen kann. Beschrieben wird das Fehlverhalten durch die Soft-Error-Rate (SER), die
in FITs (Failures-In-Time) gemessen wird. Ein FIT ist die Anzahl der Fehler in einer
Milliarde Betriebsstunden. D.h. bei einer gemessenen SER von 1000 FITs beträgt der
MTTF (Mean-Time-To-Failure) ca. 114 Jahre. Die SER bleibt allerdings keineswegs in
einem aktzeptablen Rahmen, z.B. wurde nachgewiesen, dass bei einem Notebook mit 2
GBit Speicher in 35000 Fuÿ über dem Alantik die SER von 600 FITs auf 100000 FITS
ansteigt. Das bedeutet einen durchschnittlichen Fehler alle fünf Stunden. Das Absenken
der Versorgungsspannung verschärft dieses Verhalten weiter [19].
3.4.2 Einuÿ der Spannung auf die SER
In [11] wird der Einuÿ der Spannung auf die SER näher untersucht. Dabei wurden ausgehend von einem 90-nm CMOS Test-Chip (Abbildung 3.9) Messungen unternommen.
Kapitel 3 Modellierung von SoCs
26
Abbildung 3.9: 90nm CMOS Testship
Auf dem Chip wurde eine Schaltung aus Latches verbaut, die ein SRAM darstellen. Ausgehend von einer SER bei einer Spannung von 1,2V konnte folgender Zusammenhang
festgestellt werden: steigt die Spannung von 1,2V nach 0,8V, 1,2V nach 1,0V und 1,2V
nach 1,3V ändert, dann skaliert die SER mit +100%,+33% und -9%. Das heiÿt im Durchschitt erhöht sich die SER um 18 % bei einer Reduktion von 10% der Spannung. Weiter
konnte festgestellt werden, dass die SER linear von der Gröÿe der Diode abhängt. Der
Trend bei SRAMs zeigt, dass sich die Spannung von Generation zu Generation um 13%
vermindert hat. Wird davon ausgegangen, dass sich dieser Trend fortsetzt, so erhöht sich
die SER um 8% bei einer festen Spannungsänderung von 14% pro Chipgeneration.
3.4.3 Fehlermodell für Soft Errors von Dakai Zhu
Im allgemeinen werden transiente Fehler durch eine Poisson-Verteilung mit einer durchschnittlichen Ereignisrate
λ beschrieben. Um den Einuÿ der Spannungsänderung zu be-
rücksichtigen, wird in diesem Modell die durchschnittliche Ereignisrate von der Spannung
und der Frequenz abhängig gemacht. Da nach Zhu die Spannung bei Speicherbausteinen
in enger Verbindung mit der Frequenz
f
steht, wird
λ
wie folgt modelliert:
λ(V, f ) = λ(f ) = λ0 g(f )
Wobei
Vmin ≤ V ≤ Vmax
und
fmin ≤ f ≤ fmax
ist. Der Parameter
(3.18)
d
fälligkeit einer Schaltung bzgl. Soft-Errors modellieren. Weiter sind
soll dabei die An-
fmax
und
vmax
die
Kapitel 3 Modellierung von SoCs
27
normalisierten maximalen Frequenzen und Spannungen. Dabei beschreibt
schnittliche Ereignisrate für die maximale Frequenz, d.h.
λ0
die durch-
g(Vmax , fmax ) = 1. Die kritische
Ladung nimmt mit einer Senkung der Versorgungsspannung ab. Dadurch können auch
nieder-energetische Teilchen Soft-Errors verursachen. In [22] wurde gezeigt, dass sich die
kritische Ladung proportional zur Versorgungsspannung verhält. Allerdings ist die Anzahl der nieder-energetischen Teilchen weitaus höher als die höher-energetischen Teilchen.
In diesem Modell wird die durchschnittliche Ereignisrate daher exponentiell skaliert.
d(1−f )
λ(f ) = λ0 g(f ) = λ0 10 1−fmin .
Die Fehlerrate
λ
(3.19)
kann zwischen 1000 unnd 100000 FITs/Megabit liegen.
3.4.4 Fehlermodell für Soft Errors von Peter Hazucha und Christer
Svensson
Das Modell von Hazucha et al. ([12]) beschreibt den Einuss von Neutronen
> 1 MeV auf
die SER. Dabei wird auch der Ort berücksichtigt, da es einen groÿen Unterschied macht,
ob der Neutronenuss in Bodennähe oder in einer bestimmte Flughöhe gemessen wird.
Dies ist sowohl für kombinatorische Logik als auch für Speicherbausteine anwendbar. Das
Modell beschreibt die Fehlerrate mit
λ ∝ Nf lux × CS × e
wobei
Nf lux
CS
der Neutronenuÿ,
kritische Ladung und
−Qcrit
Qs
der Querschnitt des Schaltungsknoten,
(3.20)
Qcrit
die
Qs die Ladungssammlung am pn-Übergang ist, welche laut Hazucha
stark von der Dotierung und
VDD
Für die Technologiegrösse 0.6
µm wurde die Parameter mit Hilfe des Neutronenstrahl im
abhängt.
Los Alamos National Laboratory gemessen.
Damit
QCRIT
modelliert werden kann, ist neben der Versorgungsspannung noch eine
zeitliche Komponente
T
nötig. Der Störstrom wird in diesem Modell durch
I(t) =
angenähert, während der Parameter
wurde.
T
2
√
T π
r
t ( −t )
e T
T
(3.21)
jeweils für p- und n-Drains getrennt gemessen
Kapitel 3 Modellierung von SoCs
Für
Qs
28
wurden für die verschiedenen Technologiegröÿen Skalierungsfaktoren entwickelt,
mit denen das Modell auch auf andere Schaltungen angewendet werden kann, die nicht
im 0.6
µm
Prozess gefertigt wurden.
3.4.5 Stochastische Grundlagen der SER
Der Soft-Error-Rate liegt immer die Poisson-Verteilung zur Grunde. Mit der PoissonVerteilung kann die Wahrscheinlichkeit berechnet werden, dass genau
r
Ereignisse in
einem Zeitintervall auftreten. Charakterisiert wird diese Verteilung über die durchschnittliche Ereignisrate
λ.
Die mathematischen Grundlagen wurden aus [9] entnommen.
Poisson-Verteilung
Für
λ≥0
heiÿt das Wahrscheinlichkeitsmaÿ
Pλ
Pλ ({k}) =
die Poisson-Verteilung zum Parameter
mit
e−λ λk
k!
(3.22)
λ.
Poisson-Prozess
Setzt man voraus, dass es unendlich viele unabhängige Zufallsvariablen mit vorgegebener
Verteilung gibt, dann ist mit dem Poisson-Prozess eine Modellierung rein zufälliger Zeitpunkte möglich. Mit Hilfe des Poisson-Prozesses ist es auÿerdem möglich, ein einfaches
Verfahren zur Simulation von poissonverteilten Zufallsvariablen zu implementieren.
Die Wartezeiten bis zum ersten Fehler sind bei Poissonverteilungen exponentialverteilt.
was zu folgendem Ansatz führt: Sei
gemäÿ
λ
λ > 0
und
(Li )i≥1
eine Folge von unabhängigen,
exponentialverteilten Zufallsvariablen und
Nt =
X
1]0,t] (Tk )
(3.23)
k≥1
die Anzahl der Punkte im Intervall
Punkte in
]0, t].
Für
s < t
ist dann
Nt − Ns
die Anzahl der
]s, t].
Eine solche Familie
zu Intensität
(Nt )t≥0 (Abbildung 3.10) von Zufallsvariablen ist ein Posisson-Prozess
λ > 0.
Kapitel 3 Modellierung von SoCs
29
Abbildung 3.10: Poisson-Prozess
Simulationsverfahren
Die Simulation von Exponential-Verteilungen verläuft folgendermaÿen. Seien
unabhängige auf dem Intervall
sind die Zufallsvariablen
für alle
c>0
gilt
[0, 1]
uniform verteilte Zufallsvariablen und
Xi = −(log Ui )/λ
P (Xi ≥ c) = P (Ui ≤
zum Parameter
e−λc )
=
λ
Ui , i ≥ 1,
λ > 0.
Dann
exponentialverteilt, denn
e−λc .
Dieser Algortihmus simuliert also jeden einzelnen Fehler aufgrund einer Fehlerrate
α
deren die Poisson-Verteilung zugrunde liegt. Da die einzelnen Fehlereintritte bei einer
Poisson-Verteilung exponentialverteilt sind.
3.5 Hard Errors
Bei Hard Errors handelt es sich um permanente Fehler in einem Prozessor. Die sogenannte Hard-Error-Rate verhält sich invers proportional zu der Lebenszeit eines Prozessors,
woraus sich direkt die Lebenszeit eines Chips ableiten läÿt. Bei Hard-Errors wird zwischen
zwei Arten von Fehlern unterschieden, den
1. extrinsische Fehlern
2. intrinsische Fehlern.
Kapitel 3 Modellierung von SoCs
30
Bei extrinsischen Fehlern handelt es sich um Schäden, die durch Fertigungsfehler entstehen. Sie treten meistens in einer frühen Lebensphase eines Prozessors auf. Intrinsische
Fehler treten selbst dann auf, wenn der Prozessor unter seinen spezizierten Bedingungen
betrieben wurde. Sie hängen vorallem vom Material und der zugrundeliegenden Produktionsmethode ab. Die Fehlerrate steigt bei diesen Fehler mit zunehmenden Alter an. Daher ist es wichtig, dass diese Fehler erst nach einer festgelegten Lebenszeit auftreten. Die
Hard-Error-Rate wird deshalb auch mit einer Badewannenkurve dargestellt (Abbildung
3.11). Diese Kurve wird in drei Abschnitte unterteilt, die jeweils durch einen Fehlertyp
charakterisiert werden. In der frühen Lebensphase sind vorallem extrinsische Fehler für
die Ausfälle verantwortlich. Das Auftreten dieser Fehler sinkt sehr schnell mit der Zeit
ab. In der nützlichen Lebensphase ist das Auftreten von Fehlern zufällig, daher lassen
sich diese auch schwer beschreiben. In der Verschleiÿphase sind hingegen die intrinsischen
Fehler für das starke Ansteigen der Kurve verantwortlich. Hard-Errors sollten möglichst
nie in der nützlichen Lebensphase auftreten. Daher ist die Lebenszeit von Prozessoren
fast ausschlieÿlich von intrinisischen Fehlern abhängig [25].
3.5.1 Beziehung zwischen Temperatur und Langlebigkeit eines Prozessors
Fast alle intrinsische Fehler hängen von der Temperatur ab. Diese Beziehung wird im
allgemeinen über die Arrhenius-Beziehung beschrieben, die chemische Reaktionen in Abhänigkeit von der Temperatur beschreibt. Wenn man animmt, dass bis auf die Temperatur
alle andere Einüsse konstant sind, dann kann die Fehlerrate mit
Ea
λ ∝ e kT
berechnet werden. Dabei ist
Boltzmannkonstante (8, 62
×
Ea
(3.24)
k
die Aktivierungsenergie des Fehlermechanismus,
10−5 Ke ) und
T
die
die Temperatur des Chips. An diesem Zu-
sammenhang erkennt man, dass die Ausfallrate mit einem Ansteigen der Temperatur
exponentiell erhöht wird [25].
Die Fehlerrate
λ
wird immer in FITs angegeben (Failure-in-Time), daraus läÿt sich die
MTTF (Meantime-to-Failure) berechnen. Die MTTF wird berechnet mit
MTTF =
1
λ
(3.25)
und beschreibt die durchschnittliche Zeit bis zum ersten Fehler. Der Parameter
2
meist aus χn (Binomialverteilung) abgeleitet [15]. Für
n=2
λ
wird
geht diese Verteilung in die
Kapitel 3 Modellierung von SoCs
31
Abbildung 3.11: Fehlerrate von elektronischen Schaltungen nach [25]
Exponentialverteliung über. In Abbildung 3.12 ist eine typische Verteilungsfunktion für
elektronische Schaltungen zu sehen [25].
Wenn heutztage die Lebenszeit untersucht wird, dann ndet dies in der Regel mit Hilfe
eines sogenannten Beschleunigungsfaktors statt. Dieser Faktor beschreibt dabei, um wieviel sich die Ausfallrate erhöht, wenn die Temperatur
Tt
zu einer festen Temperatur
Ts
ansteigt. Der Beschleunigungsfaktor deniert sich durch
Ea
λt
AT =
= e kT
λs
“
1
− T1
Tt
s
”
.
(3.26)
Dadurch lassen sich im Labor die langen Ausfallzeiten simulieren. Eine gute Übersicht
über alle Fehlermechanismen gibt [15] und [3].
3.5.2 Elektronenmigration
An dieser Stelle soll stellvertretend ein Modell genannt werden, dass den Fehlermechanismus der Elektronenmigration beschreibt. Sie tritt vorallem bei Gebrauch von Aluminium
als Leiterbahnmaterial auf. Der Grund ist hierfür, dass sich Elektronen aus Metallatomgitter lösen und sich an anderer Stelle wieder ablagern. Dies führt zu Lücken und Verdichtungen, was wiederum zu einem erhöhten Wiederstand der Leiterbahn führt. Beschrieben
Kapitel 3 Modellierung von SoCs
32
Abbildung 3.12: typische Verteilungsfunktion von elektronischen Schaltungen nach [25]
wird die Elektronenmigration über
Ea
M T T F = A (J − Jcrit )−n e kT ,
dabei ist
A
eine emprisch bestimmte Konstante,
J
die Stromdichte im Leiter,
kritische Stromdichte damit Elektronenmigration stattnden kann und
rungsenergie. Weiter ist
k
die Boltzmannkonstante,
(3.27)
T
Ea
Jcrit
die
die Aktivie-
die Temperatur in Kelvin und
n
eine empirische Konstante die abhängt von dem Leiterbahnmaterial [15].
3.6 Zusammenfassung
In diesem Kapitel wurden Modelle zur Beschreibung von SoCs vorgestellt. An erster Stelle kamen Modelle zur Berechnung der Verlustleistung. Bei der Verlustleistung wird zwischen dynamischen und statischen Verlustleisung unterschieden, für beide Fälle wurde
ein Modell angeführt. Abschnitt 3.2 beschreibt das Grundprinzip von HotSpot. HotSpot ist ein sehr populärer Temperatursimulator für Prozessoren. Die Modellierung von
Timing-Errors ist sehr schwierig, deshalb wurde in Abschnitt 3.3 ein sehr einfaches selbst
entwickeltes Modell erläutert. Das Modell basiert auf den Schaltzeiten von Invertern
in einer Pipline-Stufe. Abschnitt 3.4 gab eine kurze Einführung in das Phänomen der
Soft-Errors und Modellierungsmöglichkeiten an. Fehler welche die Lebenzeit von elektronischen Schaltungen beeinuÿen (Hard-Errors), ist in Abschnitt 3.5 geschildert worden.
Kapitel 4
Implementierung der Modelle und
Beschreibung des Testsystems
Dieses Kapitel beschreibt welche Modelle in den Simulator asoc-sim integriert wurden
und bilden damit die notwendige Grundlage für die Modellierung eines Testsystems. Das
Testsystem soll dazu benutzt werden, die Evaluierung des XCS durchzuführen.
4.1 Implementierung der Modelle
Mit dem SystemC Simulator asoc-sim können sowohl funktionale Elmente (FE), als auch
autonome Elemente (AE) der ASoC Architektur beschrieben werden. Ein autonomes
Element besteht aus einem Monitor, Aktuator und einem Evaluator. Der Evaluator wird
durch den XCS repräsentiert. Der Monitor sammelt die gesamten modellierten Daten, wie
Leistungsaufnahme, Temperatur und die entstandenen Fehler. Der Monitor stellt diese
Daten dem Evaluator zur Verfügung. Der Aktuator übersetzt die Aktionen des XCS, in
eine kompatible Form für die jeweilige FE. Die Modelle wurden so gestaltet, dass sie in
einer FE instanziiert werden können. Jedes Modell bietet dabei eine spezische Schnittstelle an, über die, die berechneten Werte abgerufen werden. In Abbildung 4.1 und 4.2
sieht man einen Auszug aus dem Klassendiagramm. Darin erkennt man, dass es für jedes C_model eine Oberklasse gibt, die eine möglichst allgemeine Schnittstelle anbietet.
Ein spezisches Modell erweitert dann diese Schnittstelle entsprechend. Dadurch können
beliebig viele Modelle und Modelltypen hinzugefügt werden. Jedes Modell besitzt eine
Methode evntChanged(), über die ein Event abgefragt werden kann, der dann immer eintritt, wenn das Modell seine Werte neu berechnet hat. Nachdem die Modelle instanziiert
wurden, wird von SystemC die Methode end_elaboration() aufgerufen. In dieser Phase
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
34
Abbildung 4.1: Auszug aus dem Klassendiagramm der implementierten Modelle
initialisieren sich die Modelle selber, d.h. wenn zum Beispiel ein Fehlermodell zur Berechnung seiner Daten die Temperatur benötigt, dann holt sich das Modell einen Zeiger
auf das Temperaturmodell über eine SystemC Schnittstelle. Danach wird der jeweilige
Event abgefragt und zu einem SC_METHOD-Thread zugeordnet. Falls nun ein Modell
seine Daten ändert, dann wacht dieser Thread auf und veranlaÿt sein Modell ebenfalls
die Daten neu zu berechnen. Die Modelle bilden daher eine Art Netzwerk um Daten zu
beziehen. Ihre eigenen Daten stellen sie dann anderen Modellen wieder zu Verfügung.
In Abbildung 4.3 wird eine mögliche Vernetzung von verschiedenen Modellen dargestellt.
Auÿerdem wird das Zusammenspiel zwischen den autnomen und funktionalen Elementen
gezeigt. Wenn z.B. die Frequenz geändert wird, dann wird das Modell Power-Estimation
und das Fehlermodell davon benachrichtigt. Die Power-Estimation informiert das Temperaturmodell, welches wiederum das Error-Modell informiert. Durch dieses Netzwerk
halten die Modelle immer den aktuellen Zustand eines FE.
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
35
Abbildung 4.2: Auszug aus dem Klassendiagramm der implementierten Parametermodelle
Abbildung 4.3: Mögliche Vernetzung von Modellen
Berechnung der elektrischen Leistung
Das Modell für die Abschätzung der Verlustleistung basiert auf Formel 3.5. Dabei wurden
für
Pd
und
Ps
des Modells.
die Formel 3.4 und 3.3 benutzt. Abbildung 4.4 zeigt die Abhängigkeiten
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
36
Abbildung 4.4: Implementiertes Verlustleistungsmodell
Temperaturberechnung
Für die Berechnung der Temperatur wurde eine Schnittstelle entworfen, die den Temperatursimulator HotSpot integriert. Die HotSpot-Parameter und der Floorplan müssen über eine Datei an HotSpot übergeben werden. Die Schnittstelle muÿ mit einem
Frequenz-Modell und Verlustleistungsmodell vernetzt werden. Abbildung 4.5 zeigt dies
am Beispiel des implementierten Verlustleistungsmodell C_mpcSimple und dem Frequenzmodell C_frequency.
Abbildung 4.5: Schnittstelle für HotSpot
Das HotSpot-Tool liegt mittlerweile in Version 4.0 vor. Allerdings bietet die Schnittstelle lediglich Unterstützung auf Basis der unstrukturierten Gittereinteilung an. Eine
Unterstützung des feineren strukturierten Gitter macht in diesem Fall nur wenig Sinn,
da hierfür der genaue Ort der Energieaufnahme bekannt sein muÿ. Das HotSpot-Tool
ist in der Lage
transiente
Temperaturen zu berechnen. Dabei handelt es sich um ein
Temperaturverlauf in Abhängigkeit der zeitlichen Leistungaufnahme. HotSpot benötigt
dafür die verbrauchte Leistung für jeden Zeitabschnitt. Das bedeutet sobald sich Leistungaufnahme sich ändert muÿ HotSpot aktiviert werden, um die neue Temperatur zu
berechnen. Bei Start einer Simulation und konstanter Leistungsaufnahme benötigt die
Temperatur allerdings ca 50 sek. bis sie sich stabilisiert hat. Der Grund ist hierfür, dass
die Wärmeleitung des Kühlkörpers temperaturabhängig ist. In Abbildung 4.6 wird dieses
Verhalten noch verdeutlicht.
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
37
Abbildung 4.6: Einschwingphase Temperatur
Timing-Errors
Die Modellierung von Timing-Errors basiert wie schon in Abschnitt 3.3 beschrieben auf
einer Simulation von einer einzelnen Pipeline-Stufe. Dieses einfache Modell ist ausreichend um die Timing-Errors für die Evaluierung des XCS zu beschreiben. Damit das
Modell benutzt werden kann, muÿ neben Spannung und Frequenz auch die Temperatur
zu Verfügung gestellt werden (Abbildung 4.7).
Abbildung 4.7: Timing-Error Modell mit C_mteHotSpot als Temperaturmodell
Soft-Errors
Bei der Modellierung von Soft-Errors muÿ zwischen kombinatorischer Logik und Speicher
unterschieden werden. Für die Modellierung von SRAM wurde Formel 3.19 herangezogen.
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
38
Allerdings wurde nicht wie im Orginal-Paper mit der Frequenz skaliert sondern mit der
Spannung. Da die Fehlerrate poissonverteilt ist, wurde der Algorithmus aus Abschnitt
3.4.5 implementiert. Sobald die Fehlerrate nach einer Spannungsänderung angepaÿt wurde, aktualisiert sich die Exponential-Verteilungssimulation. Die Zufallsvariable (randomvariable) ist im Prinzip die Wartezeit zum nächsten Fehler. In C_merTimes läuft ein
Thread der für diese Zeit immer einschläft. Nach Aufwachen injiziert C_merTimes den
Fehler und holt sich von C_merExponential eine neue Zufallsvariable.
Abbildung 4.8: Vernetzung zur Simulation eines Soft-Errors
Die Simulation von Soft-Errors in kombinatorische Logik ist mit dem Modell aus Abschnitt 3.4.4 zwar möglich, aber äuÿert kompliziert. Der Grund hierfür ist, dass nicht
jeder Alpha-Partikel Einschlag zwingend zu einem Soft-Error führen muÿ: denn der dabei
enstehende Störstrom muÿ sich im Normalfall über mehrere logische Gatter fortsetzen,
was nicht immer der Fall ist. Weiter ist die Abhängigkeit von der Spannung bei dem
Parameter
Qs
nicht genügend genau untersucht. Weil der XCS verschiedene Spannungen
einstellen soll, kann dieses Modell nicht verwendet werden.
Hard-Errors
Hard-Errors zu simulieren macht keinen Sinn, da die Zeit bis zum Auftreten des ersten
Fehler mehrere Jahre betragen kann. Hinsichtlich der Evaluierung des XCS wäre es zwar
möglich den Beschleunigungsfaktor in die Reward-Funktion einieÿen zu lassen: jedoch
würde dies den Sachverhalt unnötig verkomplizieren. Hard-Errors gehen daher in diese
Arbeit nur indirekt ein, indem eine maximale Temperaturobergrenze festgelegt wird, die
nicht überschritten werden sollte. Damit wird also im Prinzip ein fester MTTF-Wert
festgelegt.
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
39
Abbildung 4.9: Aufbau des Opteron Prozessors
4.2 Beschreibung des Testsystems
Damit der XCS evaluiert werden kann, ist es notwendig, ein SoC/MPSoC mit asocsim zu modellieren und die implementierten Modelle zu kongurieren. Die Entscheidung
el auf einen bereits existierenden MPSoC: den AMD Opteron (Barcelona) Prozessor.
Der Grund hierfür ist, dass bei einem realen Chip möglichst viele Parameter für die
Simulation mit asoc-sim zu Verfügung stehen. Für dieses System wurden mit Hilfe von
Trace-Files vier Anwendungen nachempfunden. Bei dem aktuellen Opteron Prozessor
handelt es sich um ein Quad-Core-System. Dabei sind vier separate Kerne auf einem Die
untergebracht. Der Prozessor ist bereits in der Lage, die Frequenz jedes einzelnen Kernes
separat einzustellen. Im Vergleich zu anderen Quad-Core Prozessoren ist der gemeinsame
L3-Cache eine wichtigte Neuerung. Das heiÿt alle Kerne besitzen einen eigenen L1-Cache
und L2-Cache. Der L2-Cache besitzt eine Anbindung an die Northbridge. Der L3-Cache
dient dem Austausch gemeinsamer Daten und erleichert dem Chip die L1-, L2-Caches
kohärent zu halten. In Abbildung 4.9 ist der grundsätzliche Aufbau des Chips skizziert
[26] [7].
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
40
Abbildung 4.10: Floorplan des Opteron Prozessors [21]
4.2.1 Technische Daten des Opteron Prozessors
Der Prozessor wird momentan im 65nm Prozess gefertigt. Die Die-Gröÿe liegt bei
285mm2 ,
welche im Vergleich zu anderen Prozessoren sehr groÿ ist. In dem Chip wurden ca. 463
Millionen Tansistoren verbaut. Der L3-Cache beträgt
2048KB
und ist je nach Anwen-
dungsgebiet erweiterbar. Die L2-Caches haben jeweils eine Gröÿe von 512KB. Bei den
L1-Caches stehen
64KB für Daten und 64KB für Instruktionen zur Verfügung. Dabei sind
sowohl die L1- und L2-Caches mit der Prozessorfrequenz getaktet. Der L3-Cache wird
auch mit der Prozessorfrequenz angegeben, aber seine Latenz ist deutlich höher. Die Taktfrequenz liegt zwischen
1700 − 2000MHz
bei einer Betriebspannung von
1, 15 − 1, 20V .
Abbildung 4.10 zeigt den Aufbau des Prozessors. Die Caches sind 2-, 16- und 32-fach
assoziativ. Das heiÿt eine Cache-Block ist
Byte [7].
32KB
groÿ und eine Cache-Zeile umfaÿt 64
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
41
Abbildung 4.11: Floorplan für HotSpot
4.2.2 Modellierung des Opteron Quad-Core
Anhand der technischen Daten wurden die Parameter für die Simulation abgleitet. Als
erstes muÿte für HotSpot ein Floorplan beschrieben werden. Durch die Fläche des Dies
und des Bildes in Abbildung 4.10 wurde für HotSpot der in Abbildung 4.11 gezeigte
Floorplan erstellt. Wie in der Abbildung zu sehen ist, wurde die Northbridge bei der
Temperatursimulation mit HotSpot nicht berücksichtigt. Dies ist notwendig, da keine
Abschätzungen der Singalaktivität für die Verlustleistungsberechnung vorlagen. Für eine
genaue Temperaturberechnung ist es wichtig, dass die Leistungsverteilung auf dem Chip
bekannt ist. Deshalb wurden die Signalaktivitäten nur auf die Cores angepaÿt, um möglichst die
Thermal Design Power
(TDP) und
Average CPU Power
(ACP) anzunähern.
Die darin enthaltenen Transistoren wurden deswegen den einzelnen Cores zugeordnet.
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
42
Parameter
Core
L1-Cache
L2-Cache
L3-Cache
Num. Transistoren
59126896
9
1 ∗ 10−8
1.5 fF
115 µA
V2
0, 2V
0, 035 ns
25165824
1, 2
1 ∗ 10−8
1.5 fF
115 µA
V2
0, 2 V
0, 035 ns
786432
1, 2
1 ∗ 10−8
1.5 fF
115 µA
V2
0, 2 V
0, 035 ns
100663296
1, 2
1 ∗ 10−8
1.5 fF
115 µA
V2
0, 2V
0, 035 ns
kdesign
Iˆ
C
pro Transistor
β
Vtp u.Vtn
◦
Delay bei 428 K
Tabelle 4.1: Parameterwerte für die Opteron Simulation
Um die Transistorzahl der Caches zu berechnen, wurde weiter angenommen, dass es sich
bei dem Speicher um 6T-SRAM Zellen handelt. Die L1-Caches wurden bei der Temperaturberechnung nicht extra berücksichtigt, allerdings als eigene FE modelliert. Weitere
wichtige angenommenen Parameter für die implementierten Modelle nden sich in Tabelle 4.1. Die Werte von
β , Vtp
und
Vtn
wurden allerdings so gewählt, dass mit dem
einfachen Timing-Error Modell auch Fehler erzeugt werden. Sie liegen aber durchaus in
realistischen Bereichen.
Modellierung der Cache-Speicher
Da es sich bei der Simulation um eine High-Level Simulation handelt, wird das Verhalten
der Caches nur ganz einfach abgebildet. Die Latenz der Speicher wurde mit
Takte bei
3, 15
und
45
2000MHz angenommen [7]. Da die Arbeitsweisen der Caches nicht bekannt und
für die Evaluierung auch nicht wichtig ist, wird der Cache wie folgt modelliert. Bei einem
Miss in einem Cache wird solange gewartet bis eine Zeile geladen wurde. Danach fängt
der Prefetcher an den gesamten Block nachzuladen. Für diese Zeit wird der Cache und
dadurch sämliche Zugrie blockiert. Der Cache benutzt die Last-Recently-Used Methode
zum Ersetzen von Blöcken.
4.2.3 Beschreibung des Opterons mit asoc-sim
Anhand der technischen Daten und den angenommenen Parameter konnte eine Simulation mit asoc-sim durchgeführt werden. Abbildung 4.12 stellt das entwickelte ProzessorModell dar. Bei den FEs handelt es sich um C++ Objekte. Bei den Cores wurde eine
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
43
spezielle FE-Klasse vom Typ FE_traced verwendet. Diese Klasse ermöglicht das Ausführen von Trace-Files auf einer FE. Innerhalb des Trace-Files benden sich sogenannte
Trace-Primitiven. Die Trace-Primitiven sollen die Vorgänge auf den FEs abstrahieren,
damit nicht jeder Befehl einzeln simuliert werden muÿ. Die Cachezugrie werden beispielsweise wie folgt damit abgebildet. Der Code für die Trace-Primitiven ist in Listing
4.1 dargestellt.
LOAD
CACHE
LOAD
CACHE
STORE CACHE
STORE CACHE
MEM
L3
MEM
L3
0.02
0
0.02
1
0.02
8
0.02
8
Listing 4.1: Trace-Primitiven für den Cachezugri
Der erste Parameter ist der Name des Ports an den die FE die Anfragen stellt. Da alle
Cores direkt an den L1-Cache angebunden sind, greifen auch alle auf den Port CACHE
zu. Der zweite Parameter ist der Ort, wo die benötigten Daten abgelegt und gespeichert
werden. Allerdings wird bei LOADs nur dann auf den Speicher zugegrien, wenn es in
L1- und L2-Cache zu einem Miss kommt. Der dritte Parameter beschreibt die Signalaktivität für Verlustleistungsberechnung. Bei den STORE-Primitiven beschreibt der letzte
Parameter wieviel Cache-Zeilen geschrieben werden sollen. Während bei den LOADS
der letzte Parameter aussagt, ob ein neuer Block geladen werden soll. Abbildung 4.13
beschreibt den Vorgang bei Ausführung der Trace-Primitive LOAD mit den Parametern
CACHE, MEM, 0.02 und 0. Für Caches wurde eine eigene FE vom Typ FE_cache und
für die Northbridge eine vom Typ FE_bridge implementiert. Weiter ist zu sehen, dass
es in den Caches zu einem Miss kommt, deshalb muÿ solange gewartet werden, bis über
die Northbridge die Daten aus dem Speicher geladen wurden. Danach werden die Daten
in die Caches geschrieben (rote Pfeile).
4.2.4 Trace-File für das Testsystem
Damit der Einuÿ verschiedener Programme bei der Steuerung durch den XCS untersucht werden kann, existieren vier verschiedene Traces. Bei dem ersten Programm handelt
es sich um eine LR-Zerlegung eines linearen Gleichungssysstem. Die Anwendung ist angelehnt an den bekannten Benchmark
Linpack. Die zweite Applikation modelliert einen
Video-Stream, auf den ein Rauschlter angewendet wird. Als drittes werden mehrere
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
Abbildung 4.12: Modellierung des Opteron mit asoc-sim
Abbildung 4.13: Ausführung einer Trace-Primitive
44
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
45
Matrix-Multiplikationen simuliert. Das letzte Programm ist eine synthetische DualCoreAnwendung.
LR-Zerlegung
Bei einer LR-Zerlegung handelt es sich um ein ein numerisch stabiles Verfahren um ein
Gleichungssystem
Ax = b zu lösen. Der Algorithmus läuft in folgendender Weiÿe ab [32]:
Als erstes wird A in
A = LR
zerlegt. Danach werden die Gleichungsysteme
Ly = b
Rx = y
gelöst. Bei
L
und
R
handelt es sich um ein oberes bzw unteres Dreiecksystem. Der Al-
gorithmus teilt sich daher in zwei Teile auf: 1. die Berechnung der LR-Zerlegung und 2.
die Berechnung der Dreiecksysteme. Bei dem Rechenauwand werden nur Multiplikationen und Divisionen berücksichtigt. Die Anzahl der Multiplikationen und Divisionen zur
Elimination der k-ten Variablen bei der LR-Zerlegung ist:
(n − k)
Berechnung der lik ,
+ (n − k)2
Wobei
lik
die Elemente von
L
Berechnung der
und
aij
i = k + 1, ...., n
aij , i, j = k + 1, ..., n
die Elemente von
R
sind. Daraus ergibt sich die
Gesamtzahl der Multiplikationen und Divisionen mit
n−1
X
2
(n − k) + (n − k)
=
k=1
n−1
X
k=1
1
1
k + k 2 = n3 − n.
3
3
(4.1)
Der Aufwand zur Lösung der Dreiecksysteme berechnet sich mit
n
X
k=1
(k − 1) +
n−1
X
(n − k) + n = n2 .
k=1
Zwei Trace-Primitiven beschreiben diese zwei Schritte (Listing 4.2).
(4.2)
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
LR
25
63
0.06
LRB 25
63
0.06
46
Listing 4.2: Trace-Primitiven für die LR-Zerlegung
Die erste Zier ist die Anzahl der benötigten Zykeln für eine Multiplikation/Division. Die
zweite ist die Zeilenlänge des Gleichungsystem und die dritte beschreibt die durchschnittliche Signalaktivität. Aus Formel 4.1 und 4.2 kann die Rechenzeit berechnet werden. Der
in Listing 4.3 gezeigte Auszug aus dem Trace-File beschreibt den Programmablauf zur
Lösung von einem Gleichungssystem. Auÿerdem belegt der Algortihmus, durch die Wahl
von
n = 63,
für ein Gleichungssystem fast einen kompletten Cache-Block.
LOAD CACHE MEM 0 . 0 2
LR 3
63
LRB 3
1
0.06
63
0.06
STORE CACHE MEM 0 . 0 2
8
Listing 4.3: Programmablauf für eine LR-Zerlegung
Als erstes lädt der Core die erste Cache-Line aus dem Arbeitsspeicher. Danach beginnen
die Caches sofort mit Prefetchen. Auÿerdem wird davon ausgegangen, dass es zu keinem
weiteren STALL in den Load/Store Einheiten kommt. Nachdem nun
L und R vorhanden
sind, können die Dreiecksysteme berechnet werden. Anzumerken ist auch noch, dass bei
einer LR-Zerlegung die berechneten Variablen von
L
und
R
an die alten Stellen von
A
gespeichert werden.
Video-Stream
Bei dem Video-Stream wird jedes Bild mit einem diskreten 3x3-Filter gefaltet. Das bedeutet, es müssen pro Pixel 1 Division und 8 Multiplikationen angewandt werden. Hierzu
wurde wieder eine Trace-Primititive erstellt (Listing 4.4).
GR
25
11000
0.06
Listing 4.4: Trace-Primitive für den 3x3 Filter
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
47
In einen Cache-Block passen ca. 11000 Pixel. Dies führt zu einem Trace-File wie in Listing 4.5.
VIDEO :
LOAD CACHE MEM 0 . 0 2
GR 3
11000
1
0.06
STORE CACHE MEM 0 . 0 2
512
LOOP VIDEO 2 8
Listing 4.5: Programmablauf für ein Bild des Video-Streams
Bei 11000 Pixel pro Block müssen bei einer Bildgröÿe von 640x480 ca. 28 Blöcke geladen
werden. Sobald der L1-Cache die Daten geladen hat, führt der Prozessor die Filterung
durch. Um die Bilder sofort von der Grakkarte weiterverarbeiten zu lassen, werden sie
direkt in das RAM zurückgeschrieben.
Matrix-Multiplikation
Dieses Trace-File bildet eine Matrix-Multiplikation ab. Der Aufwand zur Berechnung einer Multiplikation ist
n2 .
Die Berechnung benötigt daher gleich viele Multiplikationen
wie die Lösung der Dreiecksysteme bei der LR-Zerlegung. Für eine 63x63 Matrix muÿ
wieder ein kompletter Cache-Block geladen werden. Danach kann die Trace-Primitive
der Dreiecksysteme ausgeführt werden. Der 63-zeilige Ergebnisvektor belegt acht CacheZeilen, die in den Speicher zurückgeschrieben werden (Listing 4.6).
LOAD CACHE MEM 0 . 0 2
LRB 3
63
1
0.06
STORE CACHE MEM 0 . 0 2
8
Listing 4.6: Programmablauf für die Matrix-Multiplikation
DualCore-Anwendung
Dieses Programm ist eine Anwendung die auf zwei Kernen ausgeführt wird, wobei Prozess
1 auf Daten von Prozess 2 warten muÿ. Prozess 2 wurde dabei so gestaltet, dass er
gegenüber Prozess 1 deutlich früher am Rendevouzpunkt zum Nachrichtenaustausch ist.
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
48
In Listung 4.7 und 4.8 werden die beiden Trace-Files gezeigt. Die Trace-Primitive ACT
setzt für die angegebenen Takte (erster Parameter) die entsprechende Signalaktivität und
wartet entsprechend. Weiter wurde noch zwei Trace-Primitiven READY und WAIT_ON
implementiert, die zur Synchronisation von den Cores dienen.
PARA:
LOAD CACHE MEM 0 . 0 2
1
LOAD CACHE MEM 0 . 0 2
0
LOAD CACHE MEM 0 . 0 2
0
ACT 4 0 0 0 0 0 0 0 0 0
0.5
READY c o r e 2
LOAD CACHE L3
0.02
ACT 1 0 0 0 0 0 0 0 0
0.3
1
STORE CACHE MEM 0 . 0 2
32
LOOP PARA 2 0 0 0 0 0 0
Listing 4.7: DualCore-Anwendung: Prozess 1
PARA:
LOAD CACHE MEM 0 . 0 2
ACT 2 0 0 0 0 0 0 0 0 0
0.5
STORE CACHE L3
0.02
ACT 0 . 0
1
512
0.0
WAIT_ON c o r e 1
LOOP PARA 2 0 0 0 0 0 0
Listing 4.8: DualCore-Anwendung: Prozess 2
4.2.5 Verikation des Testsystems
Die Trace-Files wurden eine Sekunde lange mit asoc-sim simuliert, wobei in jeder TracePrimitive ein Zähler implementiert wurde. Die Anwendungen werden dabei ständig wiederholt. Wenn auf einem Core die LR-Zerlegung ausgeführt wird und die anderen Cores idlen, dann werden in einer Sekunde 7417 Gleichungsysteme gelöst. Bei dem VideoStream werden ca. 231 Bilder pro Sekunde berechnet. Läuft auf einem Core ausschlieÿlich die Matrix-Multiplikation, dann berechnet der Core 101698 solcher Multiplikationen. Wird auf Core1 die Matrix-Multiplikation, auf Core2 der Video-Stream und auf
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
49
Core3/Core4 die LR-Zerlegung ausgeführt, dann werden 91917 Matrix-Multiplikationen,
223 Bilder pro Sekunde und jeweils 7311 LR-Zerlegungen berechnet. Daran sieht man,
dass der gemeinsame Zugri auf den Hauptspeicher zum Flaschenhals wird, und sich
die Anwendungen gegenseitig ausbremsen. Der Leistungsverbrauch liegt bei diesem Anwendungsfall bei ca. 83 Watt und die Temperatur beträgt ca.
55◦ C
auf jedem Core.
Im IDLE-Modus beträgt die Verlustleistung ca. 26 Watt. Diese Werte sind durchaus
realistisch wie ein Vergleich mit [1] zeigt.
4.3 XCS-Wrapper
Der XCS stand als C-Programm zu Verfügung, welches von Butz selbst entwickelt worden
ist. Damit der XCS auch als Evaluator in asoc-sim eingesetzt werden konnte, muÿte ein
Wrapper entwickelt werden. Dieser Wrapper stellt das Verbindungsstück zwischen dem
Evaluator und dem C-XCS dar. Den Zugri auf die gemeinsame Ressource des C-XCS
überwacht die Klasse XCSArbiter. Die Klasse steuert auch die Aufrufe in die Umgebung
(also in den Evaluator). Dadurch ist es möglich für jede FE einen XCS-Evaluator mit
eigener Population zu betreiben. Abbildung 4.14 verdeutlich diesen Zusammenhang.
Abbildung 4.14: Einbindung des C-XCS in asoc-sim
Auÿerdem unterstützt die Klasse XCSArbiter noch die folgenden Funktionen:
1. Vor jedem Experiment können eigene initiale Classier in die Population geladen
werden.
2. Bereits abgeschlossene Experimente können wieder aufgenommen werden.
3. Zur Laufzeit sind Parameteränderungen wie z.b. die Lernrate möglich
Kapitel 4 Implementierung der Modelle und Beschreibung des Testsystems
50
Damit diese Punkte umgesetzt werden konnte war eine intensive Analyse des C-Codes
nötig.
4.4 Zusammenfassung
Dieses Kapitel beschrieb wie die in Kaptiel 3 vorgestellen Modelle implementiert wurden.
Bei der Implementierung wurde darauf geachtet, dass die entworfene Simulationumgebung möglichst exibel und erweiterbar ist. Auÿerdem wurde der Aufbau des Testsystems
gezeigt mit dem die folgende Evaluierung durchgeführt wurde. Für das Testsystem wurden Trace-Files entwickelt. die Programmabläufe simulieren sollen. Im letzten Abschnitt
wurde kurz umschrieben wie der XCS in asoc-sim integriert worden ist.
Kapitel 5
Evaluierung des XCS
In diesem Kapitel wird das Learning-Classier-System XCS bewertet, ob es für den Einsatz im Bereich SoC/MPSoC geeignet ist. Dabei muÿ als erstes eine geeignete Beschreibung der Umgebung, des Reinforcement-Programmes und den ausführbaren Aktionen
gefunden werden. Der XCS muÿ in der Lage sein, aus dieser Beschreibung lernen zu
können. Für die Evaluierung wird der Quad-Core aus Abschnitt 4.2 benutzt.
5.1 Beschreibung der Umgebung und Aktionen
Die Beschreibung der Umgebung, also die von den Sensoren gelieferten Situationen, und
die Möglichkeiten der Reaktion auf eine Situation sind entscheidene Faktoren, damit
der XCS erfolgreich arbeitet. Die Sensorendaten des XCS werden im asoc-sim durch
den Monitor repräsentiert. Mit den implementierten Modelle standen folgende Daten zu
Verfügung:
1. aktuelle Temperatur
2. Leistungsverbrauch
3. fand ein Timing-Error statt (nur Logik)
4. aktuelle Frequenz
5. aktuelle Spannung
6. Anzahl der Soft-Errors (nur Speicher)
Kapitel 5 Evaluierung des XCS
52
Der Ansatz für die Beschreibung der Umgebung und den Aktionen sieht wie folgt aus:
Die Anzahl der einstellbaren Frequenzen auf jedem Core wurde auf 11 festgelegt und die
wählbaren Spannungen auf 6. Der Frequenzbereich verläuft von 500MHz bis 3000MHz
und der Spannungsbereich liegt zwischen 0,8V und 1,3V. Diese zwei Parameter wurden
mit 4 und 3 Bit quantisiert und stellen den ersten Teil der Umgebungsbeschreibung dar.
Zum Beispiel steht
C = 0001100
für 750MHz und einer Spannung von 1,2V. Der zweite
Teil ist der Temperaturbereich zwischen
50◦ C
und
90◦ C , der mit 5 Bit quantisiert wurde.
Auÿerdem wurde noch ein Fehlerbit hinzugefügt, falls ein Soft- oder Timing-Error aufgetreten ist, wird dieses Bit auf 1 gesetzt. Eine Situation hat daher z.B. die folgende Form:
C = 1001010001100.
Die Aktionen des XCS beschränken sich auf die Veränderung der
Spannung und der Frequenz. Das Problem wurde als Single-Step Problem angegangen, so
dass eine Aktion eine Änderung der Spannung und der Frequenz bedeutet. Eine Aktion
ist daher:
(s, f )
wobei
s
mit
s ∈ {0..5}
eine konkrete Spannung und
f
und
f ∈ {0..10} ,
eine konkrete Frequenz ist. Die Gesamtzahl der
Aktionen beträgt dadurch 66 Stück. Das heitÿt eine Aktion
1000MHz,
(5, 10)
(5.1)
(0, 2)
entspricht 0,8V und
bedeutet eine Einstellung von 1,3V und 3000MHz.
5.2 Single-Step oder Multi-Step
Ein wichtiger Punkt ist: ob das Problem als Multi-Step oder Single-Step Experiment angegangen werden soll. Denn je nach Problemart hat jedes dieser Experimenttypen seine
Vorteile. Der Vorteil daran die Aufgabe als Single-Step-Experiment durchzuführen ist,
dass der Reward sofort berechnet werden kann. Die Alternative dazu ist ein Multi-StepExperiment, bei dessen es keine kombinierten Einstellungen von Frequenz und Spannung
gibt. Jede Aktion steht nur für eine Parameteränderung. Das heiÿt es würden nacheinander Spannung bzw. Frequenz verändert werden. Die Anzahl der Aktionen wäre in diesem
Fall 17 Stück (11 Frequenz und 6 Spannung). Bei Multi-Step-Experimenten muÿ aber
das Reinforcement-Programm das
eop Flag setzen, damit signalisiert es, dass die Aufgabe
erfüllt wurde. Genau dies ist aber nicht möglich, da das Reinforcement-Programm nie
entscheiden kann, ob das Optimum erreicht wurde. Das bedeutet, der Reward muÿ immer
nach einer festgelegten Anzahl an Schritten zurückgeliefert werden. Ein weiteres Problem
bei Multi-Step-Experimenten ist, dass kein direkter Zusammenhang zwischen der eingestellen Frequenz und der vorliegenden Spannung hergestellt werden kann. Eine höhere
Spannung kann durchaus die richtige Wahl in einer gegebenen Situation sein. Allerdings
Kapitel 5 Evaluierung des XCS
53
Abbildung 5.1: Ablauf der Lernphase
wenn daraufhin die falsche Frequenz gewählt wird, dann wird durch den erzwungenen
Reward, die prinzipiell gute Wahl der höheren Spannung, mit einem niedrigen Reward
belohnt. Dies führt dazu, dass der XCS aussagelose Classier erstellt, da eine Aktion
teilweise hoch belohnt wird, aber teilweise auch wieder niedrigere Belohnungen erhält.
5.3 Generierung von Classiern
Als erstes werden die Classier mit Hilfe des XCS erstellt, dabei ist das Ziel alle möglichen
Temperatur-, Frequenz- und Spannungskombinationen zu testen. Im ersten Schritt wird
eine zufällige Frequenz/Spannung eingestellt und zwei Sekunden gewartet. Nach diesen
zwei Sekunden bekommt der XCS von der Umgebung die Situation geliefert. Er wählt
daraufhin eine neue Aktion aus. Diese Aktion wird dann auf dem Core eingestellt und
zwei Sekunden gewartet. Danach wird die Aktion bewertet und der Reward berechnet.
Als nächstes wird erneut die Frequenz/Spannung zufällig eingestellt und zwei Sekunden
gewartet. Dann ist wieder der XCS an der Reihe, eine neue Einstellung zu testen. Dieser
Vorgang wird in Abbildung 5.1 verdeutlicht.
Der Vorgang muÿ dann genügend oft wiederholt werden. In diesem Anwendungsbeispiel
wurden 50000 solcher Schritte durchgeführt. Die Temperatur steigt bei einer Spannungs/Frequenzänderung in den ersten zwei Sekunden sehr stark an. Deshalb muÿ mindestens
solange gewartet werden, damit die verschiedenen Aktionen verglichen werden können.
Der schnelle Anstieg in den ersten zwei Sekunden wird in Abbildung 5.2 dargestellt. Dabei liefen die anderen Cores im IDLE-Modus und hatten eine Frequenz von 2000MHz
und eine Spannung 1,2V. Die Classier werden auf einem Core erstellt. Dabei ist die
Signalaktivität konstant bei 0,05. Zu Cachezugrien kommt es in dieser Zeit nicht. Dadurch kann eine deutlich höhere Simulationszeit erreicht werden, als wenn die Traces aus
Abschnitt 4.2.4 ausgeführt werden. Die wichtigsten Parameter für diese Lernphase sind
Kapitel 5 Evaluierung des XCS
54
Abbildung 5.2: Temperaturschwankung von 500MHz, 0.8V nach 3000MHz, 1.3V
in Tabelle 5.1 aufgeführt. Auÿerdem wird die Temperatur zufällig um
5, 10, 20 und 30◦ C
erhöht, um äuÿere Temperatureinüsse zu modellieren. Die zufällige Erhöhung darf erst
wieder zurückgenommen werden, wenn die Aktion des XCS evaluiert wurde.
Don't Care Prob.
Explore Prob.
θGA
θDel
θSub
Lernphase
1.0
1.0
25
20
20
Verikation
1.0
0.0
∞
∞
∞
Tabelle 5.1: Parameterwerte des XCS
5.3.1 Beschreibung der Rewardfunktion
Der XCS soll lernen, den Energieaufwand bei einer gewünschten Leistung auf den Cores
zu minimieren. Zusätzlich dürfen aber keinerlei Fehler mit diesen Einstellungen auftreten.
Kapitel 5 Evaluierung des XCS
55
Abbildung 5.3: Timing-Error bei einer Frequenz von 2000 MHz (1 ist ein Fehler
Diese Bedingungen führen zu folgendem Ansatz für die Rewardfunktion:
R(f, p, t, v) =
f
fmax
∗ w1 + 1 −
mit
p
pmax
∗ w2 + rel(t, v, f ) ∗ w3

0
rel(t, v, f ) =
1
(5.2)
falls Timing-Error,
sonst
Da der XCS nur auf den Cores aktiv ist, können nur Timing-Errors berücksichtigt werden.
Soft-Errors sind nur für Caches modellierbar. In Abbildung 5.3 ist zu sehen, wann das
Timing-Error Modell bei einer Frequenz von 2000MHz Fehler injiziert. Die Gewichte
wurden auf
w1 = 200, w2 = 35
und
w3 = 200
festgelegt. Dadurch soll das System
bei einer möglichst niedrigen Verlustleistung eine möglichst hohe Frequenz erreichen.
Abbildung 5.3 zeigt auÿerdem, dass die Frequenz von 2000MHz und 1,2V, in normalen
Temperaturbereichen eine sichere und performante Einstellung darstellt. Weshalb sie
immer einen hohen Reward bekommen wird.
Kapitel 5 Evaluierung des XCS
Abbildung 5.4: Reaktion
des
56
XCS
nach
zufälligen
Parametereinstellungen
(LR-
Zerlegung)
5.4 Steuerung der Cores durch den XCS
Das Experiment wurde mit den Parametern aus 5.3 durchgeführt. Danach wurden diese
Classier getestet, indem die Parameter aus Tabelle 5.1 (Verikation) geändert wurden.
Die Explore-Wahrscheinlichkeit wird auf 0 gesetzt, so dass nur die Aktionen gewählt
werden, die den höchsten Reward versprechen. Die Änderungen der Parameter
und
θSub
θGA , θDel
führen dazu, dass der GA nicht mehr aktiv ist und keine Classier gelöscht
oder vereinigt werden. Die einzige Möglichkeit dass neue Classier entstehen ist durch
Covering. Auf den Cores werden in dieser Phase verschiedene Trace-Files ausgeführt, die
Anwendungen laufen dabei in einer Endlosschleife.
Als erstes wird die LR-Zerlegung ausgeführt und jeweils alle 5 sek zufällig eine neue
Frequenz und Spannung eingestellt wurde. Der XCS reagierte auf diese Änderung immer
mit Rücksetzung des Systems auf 2000MHz und 1.2V, was in diesen Temperaturbereichen
zu keinen Fehler führt und die beste Einstellung ist. In Abbildung 5.4 wird dieser Test
veranschaulicht.
In einem zweiten Test wurde untersucht, ob diese Classier auch auf die Matrix-Multiplikation
anwendbar sind. Hierzu wurde die Matrix-Multiplikation auf Core1 ausgeführt. In Abbildung 5.5 ist zu sehen, dass der XCS das System auch hier wieder in einen sicheren
Kapitel 5 Evaluierung des XCS
Abbildung 5.5: Reaktion
des
XCS
57
nach
zufälligen
Parametereinstellungen
(Matrix-
Multiplikation)
Zustand überführt.
Der nächste Test untersucht wie sich der XCS verhält, wenn auf allen vier Cores eine
Anwendung ausgeführt wird. Dabei läuft auf Core1 die Matrix-Multiplikation, auf Core2
der Video-Stream und auf Core3/Core4 die LR-Zerlegung. Jeder Core hat dabei sein
eigener XCS. Dabei starten die vier Cores mit unterschiedlichen Frequenzen/Spannungen,
wobei jeder XCS nach 10 sek gestartet wird. Wie in Abbildung 5.6 zu sehen ist, ändert
jeder XCS sofort wieder die Spannung/Frequenz auf 2000MHz und 1,2V ab.
Durch den XCS ist es daher möglich, optimale Betriebspunkte innerhalb eines spezizierten Bereiches zu nden.
5.5 Reaktion auf äuÿere Temperatureinüsse
In diesem Abschnitt wird gezeigt, wie der XCS auf äuÿere Einüsse reagiert. Dies wird am
Beispiel einer Erhöhung der Chiptemperatur durchgeführt. Die Ursache könnte sein, dass
die Auÿentemperatur ansteigt oder das Kühlsystem nicht richtig funktioniert. Durch die
erhöhte Temperatur kann es zu Timing-Errors kommen, so dass eine bestimmte Frequenz
Kapitel 5 Evaluierung des XCS
58
Abbildung 5.6: Frequenzänderung und Spannungänderung bei allen vier Cores
nicht mehr eingehalten werden kann. Auÿerdem wird gezeigt wie Hard-Errors vermieden
werden können. Hierzu wird die Rewardfunktion 5.2 erweitert:
R(f, p, t, v) =
f
fmax
mit
∗ w1 + 1 −
p
∗ w2 + rel(t, v, f ) ∗ w3
pmax



0
falls Timing-Error,

 70 2
rel(t, v, f ) =
für t > 70

 t

1
sonst
Die Gewichte wurden für eine Temperatur unterhalb von
35
und
w3 = 200
festgelegt. Oberhalb von
70◦ C
ist
(5.3)
70◦ C wieder auf w1 = 200, w2 =
w1 = 100, w2 = 100
Durch die Erweiterung der Reward-Funktion wird eine Art
und
w3 = 200.
Notfallverhalten beschrieben,
welches sich dadurch auszeichnet, dass der Chip durch den XCS bei über
70◦ C
auf eine
weniger performante Einstellung reguliert werden soll. Durch die hohe Gewichtung der
Verlustleistung kann zudem erreicht werden, dass die Temperatur absinkt. Ziel ist es,
das System möglichst wieder in die Nähe von
70◦ C
zu bringen. Die Reduzierung der
Temperatur vermindert gleichzeitig die Hard-Error-Rate. Die Classier wurden mit der
gleichen Methode erstellt wie in Abschnitt 5.4.
Die Verikation verläuft folgendermaÿen: Die Temperatur wird für 20 sek um
15◦ C
er-
höht. Ein Evaluator ist nur auf Core1 aktiv, auf dem die LR-Zerlegung läuft. Die anderen
Cores sind im IDLE-Modus. Der Evaluator ruft alle vier Sekunden den Monitor ab. In
Abbildung 5.7 sieht man die Reaktion des XCS auf die Veränderung der Umgebung. Der
Kapitel 5 Evaluierung des XCS
59
Abbildung 5.7: Reaktion des XCS auf einen Temperaturanstieg von
15◦ C
XCS schaltet sofort die Frequenz auf 1500MHz und 0,9V herunter. Dadurch sinkt die
Temperatur und wieder auf unter
70◦ C.
In diesem Bereich liefert wieder die Frequenz
2000MHz und 1,2V den besten Reward, weshalb der XCS diese Einstellung wählt. Dadurch steigt die Temperatur an und der Vorgang wiederholt sich. Einmal stellt der XCS
allerdings 1,3V anstatt 1,2V ein. Solche kleine Fehler liegen wohl daran, dass eine andere
Anwendung als die gelernte läuft. Zum anderen ist es sehr unwahrscheinlich, dass der
XCS Classier erstellt, die den Problemraum zu hundertprozentig abdecken.
Die Temperatur sank nach einer Erhöhung um
und 0,8V, nicht mehr unter
20◦ C , trotz einer Umstellung auf 1250MHz
70◦ C . Wie Abbildung 5.8 zeigt, behält der XCS deshalb diese
Einstellung bei. Durch die beide Einstellungen konnten Timing-Errors vermieden werden
und das System blieb in einem stabilen Zustand. Nachdem in den Tests der Temperaturanstieg zurückgenommen wurde, reguliert der XCS das System wieder auf 2000MHz
und 1,2V. Dieser Test zeigt, dass die Erweiterung der Rewardfunktion den gewünschten
Eekt hatte und der XCS dadurch auf äuÿere Temperatureinüÿe sehr gut reagieren
kann.
5.6 Lernen mit initialen Classiern
In diesem Abschnitt wird das Verhalten untersucht, ob der XCS eine neue RewardFunktion mit Classiern einer anderen Reward-Funktion lernen kann. Dabei dienen die
bereits in Abschnitt 5.5 verwendeten Classier als initiale Classier. Da diese Classier
den Problemraum schon gut abdecken, wird der GA deaktiviert. Bei der neuen Reward-
Kapitel 5 Evaluierung des XCS
60
Abbildung 5.8: Reaktion des XCS auf einen Temperaturanstieg von
Funktion werden die Gewichte auf
w1 = 100, w2 = 100
und
w3 = 200
20◦ C
gesetzt. Dadurch
haben Verlustleistung und Performanz die gleiche Priorität. Die Gewichte über
70◦ C
bleiben allerdings gleich. Damit die Lernzeit niedrig gehalten wird, muÿ der Lernvorgang aus Abbildung 5.1 abgeändert werden. Daher wird eine Strategie angewendet, die
versucht, möglichst nur in einer Nische die neue Reward-Funtkion zu lernen. Die veränderte Lernphase beschreibt Abbildung 5.9. Darin sieht man, dass immer die selbe
Frequenz-/Spannungskombination gewählt wird, bis der XCS eine bessere ndet. Sobald
das Reinforcement-Programm einen höheren Reward (rew) als der bisherig beste Reward
(o_rew) liefert, dann wird, ab diesem Zeitpunkt, die zugehörige Frequenz/Spannung eingestellt. Damit wird der Problemraum eingeschränkt, indem nur an lohnenden Bereichen
die neue Reward-Funktion gelernt wird. Auÿerdem wurde die Lernrate von 0,2 auf 1,0
erhöht, um die Lernzeit weiter zu minimieren. Die hohe Lernrate ist auch notwendig da
die alte Reward-Funktion erst wieder verlernt werden muÿ. Das Experiment wird auf
einem Core durchgeführt, die anderen drei sind im IDLE-Modus.
In Abbildung 5.10 ist der Verlauf der Lernphase beschrieben. Darin ist zu sehen, dass
das System relativ lange benötigt, trotz der hohen Lernrate, bis es sich einigermaÿen
stabilisiert hat. Die Abbildung zeigt aber auch deutlich das Lernprinzip des XCS. In der
Lernphase müssen ständig zufällige Parametereinstellungen getestet werden, damit der
XCS überhaupt lernen kann. Der XCS benötigt unbedingt den Explore-Schritt um den
Problemraum zu erkunden. Umso höher die Explore-Wahrscheinlichkeit
P]
(Standard ist
1,0) ist, desto schneller wird der XCS lernen.
Nach 1000 Schritten (2000 sek) wird diese Lernphase wieder beendet. Der XCS wählt
Kapitel 5 Evaluierung des XCS
Abbildung 5.9: Ablauf der Lernphase zur Laufzeit
Abbildung 5.10: Frequenz-/Spannungänderungen zur Laufzeit
61
Kapitel 5 Evaluierung des XCS
62
Abbildung 5.11: Verhalten des XCS nach Neulernen einer Reward-Funktion und simulierter Temperaturanstieg von
20◦ C
nun als beste Einstellung 1250MHz und 0,8V.
Nun wird die Temperatur um
20◦ C
erhöht. Wie in Abbildung 5.11 zu sehen ist, hat sich
das Notfallverhalten nicht geändert. Der XCS behält die Frequenz und Spannung bei. Dieses Verhalten ist aber nicht immer der Fall. Denn Classier die sehr allgemein sind, hätten
normalerweise einen hohen Vorhersagefehler. Da aber nicht der ganze Problemraum neu
gelernt werden kann, geht dieser Vorhersagefehler verloren. Dadurch haben allgemeine
Classier eine höhere Gewichtung im Match-Set, somit werden andere Einstellungen als
ursprünglich vorgenommen. Es ist klar, dass durch die vorgeschlagene Lernstrategie erst
nach und nach alle wichtigen Classier ihre Parameter ändern. Das gute Funktionieren der initialen Classiern hängt wohl damit zusammen, dass durch die Wahl der ersten
Reward-Funktion relativ spezielle und sehr allgemeine Classier enstanden. Dadurch sind
sie auch für andere Reward-Funktionen sehr gut geeignet.
5.7 Optimierung eines Kernes bei einer
DualCore-Anwendung
Die gewonnenen Ergebnisse aus den vorangegangenen Abschnitten können nun dazu benutzt werden, zwei Cores bzgl. einer DualCore-Anwendung zu optimieren. Dabei werden
die Trace-Files aus Listing 4.7 und 4.8 auf Core1 und Core2 ausgeführt. Da der Prozess
1 die längere Rechenzeit hat, wird Core1 mit maximaler Frequenz getaktet: 2000MHz
bei 1,2V. Der andere Core soll nun so eingestellt werden, dass seine Wartezeit minimiert
Kapitel 5 Evaluierung des XCS
63
wird. Dazu wird die Rewardfunktion leicht angepaÿt.
p
R(f, p, t, v, wt) = time (wt) ∗ w1 + 1 −
∗ w2 + rel(t, v, f ) ∗ w3
pmax



0
falls Timingfehler,

 70 2
mit rel(t, v, f ) =
für t > 70
t



1
sonst

1 − wt
falls Wartezeit Core1 = 0,
wtmax
mit time(wt) =
0
sonst
(5.4)
Bei der neuen Reward-Funktion ist zu sehen, dass nicht mehr die Frequenz bewertet wird,
sondern die Wartezeit von Core2 auf Core1 (wt). Ist Core2 zu langsam, dann ist die Wartezeit von Core1 > 0. Deshalb wird dieser Fall mit einem Reward von 0 bewertet, da sich
sonst die Laufzeit insgesamt verlängern würde. Im Code müssen zwei Messpunkte festgelegt werden. In Listing 5.1 sind diese zwei Messpunkte durch START_EVALUATE und
END_EVALUATE vertreten. Auÿerdem ist noch eine dritte Trace-Primitive hinzugefügt
worden, die den Evaluator veranlaÿt eine neue Aktion auszuführen (START_ACTION).
PARA:
START_ACTION
LOAD CACHE MEM 0 . 0 2
ACT 2 0 0 0 0 0 0 0 0 0
0.5
STORE CACHE L3
0.02
ACT 0 . 0
1
512
0.0
START_EVALUATE
WAIT_ON c o r e 1
END_EVALUATE
LOOP PARA 2 0 0 0 0 0 0
Listing 5.1: DualCore-Anwendung mit Messpunkten: Prozess 2
Die Classier stammen aus den Experimenten aus Abschnitt 5.4, der Lernvorgang wurde
aus Abschnitt 5.6 übernommen. Das heiÿt nach 1000 Schritten endet die Lernphase und
das System wählt die beste Einstellung aus. In Abbildung 5.12 ist zu sehen, dass der XCS
Core2 auf 1000 MHz und 0.8V einstellt. Diese Einstellung ist optimal, da die Wartezeit
von Core2 auf Core1 minimal wird, aber Core1 nicht auf Core2 warten muÿ. Es ist klar
dass bei dieser Einstellung es zu keinem Timing-Error kommt.
Kapitel 5 Evaluierung des XCS
64
Abbildung 5.12: Frequenz-/Spannungänderungen Optimierung Core2
5.8 Steuerung der Speicher
Die Steuermöglichkeiten durch den XCS lassen sich auch auf den Speicher ausweiten.
In diesem Beispiel besitzt die Umgebungsbeschreibung keine Temperaturkomponente.
Daher wird angeommen, dass sich die Temperatur bei ca.
60◦ C
hält. Der Grund hierfür
ist, dass die Temperatur der Speicher während den Simulationen fast konstant war. Eine
Situation beschreibt sich durch Frequenz, Spannung und Fehlerbit. Ein entscheidender
Unterschied sind die Aktionen. Da hier Cache-Speicher modelliert wird, macht es wenig
Sinn, diese anders als mit dem Prozessortakt zu betreiben. Das heiÿt der XCS kann nur die
Spannung ändern. Die Frequenz bekommt er von seinem jeweiligen Core vorgeschrieben.
Eine Aktion ist also:
(s) mit s ∈ {0..5}
(5.5)
Auÿerdem werden in diesem Beispiel nur Soft-Errors berücksichtigt, wobei eine sehr aggressive SER von 100000 FITS angeommen. Das verwendete Modell ist in Abschnitt 3.19
beschrieben, dem Parameter
d
wird der Wert
6
zugewiesen. Da Soft-Errors sehr selten
vorkommen, wird die Wartezeit von bisher 2 sek auf 10 sek erhöht. Für Timing-Errors
bei Speicherelementen stand kein Modell zu Verfügung.
Auÿerdem wurde die Reward-Funktion vereinfacht. Da die Frequenz immer vom jeweiligen Core vorgeben wird, braucht diese nicht mehr berücksichtigt werden. Ein Notfallverhalten ist, wie bei einem unerwarteten Temperaturanstieg, bei Soft-Errors nur schwer
zu formulieren, da hierfür der Neutronenuÿ gemessen werden müsste. Allerdings ist ein
plötzlicher Anstieg des Neutronenusses nicht sehr realistisch. Auf diesen Fall kann nur
Kapitel 5 Evaluierung des XCS
65
Abbildung 5.13: Spannungsänderung durch den XCS bei einem Cache
mit Neulernen reagiert werden. Die Reward-Funktion beschreibt sich deshalb mit:
R(f, p, v) =
mit
1−
p
∗ w2 + rel(v, f ) ∗ w3

0 falls Soft-Error
rel(f, v) =
1 sonst
pmax
(5.6)
In Abbildung 5.13 ist das Ergebnis nach dem Lernen zu sehen. In der Abbildung wird alle 20 Sekunden eine neue Frequenz-/Spannungskombination ausgewählt. Danach soll der
XCS die Spannung entsprechend anpassen. Die vom XCS gewählte Spannung bleibt 20
sek. eingestellt. Dieser Vorgang wird dann dreimal wiederholt. Die zufällig gewählten Frequenzen/Spannungen sind: 500MHz/0,8V, 750MHz/1,2V, 1750MHz/1,1V und 2000MHz/1,3V. Der XCS stellt immer die Spannung auf 1V ein. Ab einer Spannung von 1V sind
Soft-Errors sehr unwahrscheinlich. In der Realität könnte dann der Ablauf folgendermaÿen aussehen. Die AEs der Cores teilen den AEs der Caches die ausgewählte Frequenz
mit. Daraufhin stellen die AEs die entsprechende Spannung auf den Caches ein.
Kapitel 5 Evaluierung des XCS
66
5.9 Zusammenfassung
Die hier beschriebenen Tests konnten auch für andere Situationen reproduziert werden.
In der Regel entscheidet sich der XCS immer für die optimale Einstellung. Falls der XCS
nicht die optimale Einstellung ndet, dann ist zumindest die vorgenommene Einstellung
immer eine sehr gute. Diese Fälle kommen allerdings sehr selten vor. Für ein erfolgreiches Lernen ist es zwingend notwendig, alle möglichen Kombinationen von Spannung,
Frequenz und Temperatur dem XCS als Situation zu liefern. Kann dies nicht realisiert
werden, dann wird der XCS sehr schlechte Ergebnisse produzieren.
Die Versuche zeigen, dass der XCS in der Lage ist ein SoC zu steuern. Abschnitt 5.4 und
5.6 zeigt, dass durch die Skalierung der Reward-Funktion mit den Gewichten verschiedene
optimale Betriebspunkte gefunden werden können. Durch erweitern der Reward-Funktion
in Abschnitt 5.5 war es auch möglich den XCS ein Verhalten lernen zu lassen, falls die
Temperatur plötzlich ansteigt. Mit kleinen Änderungen in der Reward-Funktion können
auch verschiedene Optimierungsziele erreicht werden. In Abschnitt 5.7 war dies an der
Minimierung der Wartezeit eines Prozesses zu sehen. Genauso konnte der XCS auch
Speicher unter Einwirkung von Soft-Errors optimieren. Diese ganzen Tests zeigten, dass
der XCS ein sehr exibles Werkzeug zum Lösen solcher Probleme ist. Das Hauptproblem
ist allerdings die lange Lernzeit. Gerade dann wenn mit einer leeren Population gestartet
wird.
Kapitel 6
Zusammenfassung und Diskussion
6.1 Zusammenfassung
In dieser Arbeit wurden die Einsatzmöglichkeiten des Learning-Classier-System XCS
zur Kontrollierung eines SoCs gezeigt. Die Steuerungsmöglichkeiten des XCS waren dabei die Parameter Spannung und Frequenz. Damit die Evaluierung durchgeführt werden
konnte, ist eine Simulationumgebung zur Modellierung eines SoC entwickelt worden. Die
Simulationsumgebung umfaÿt die Modellierung von Temperatur, elektrische Leistung,
Timing-Errors und Soft-Errors. Für die Temperaturberechnung ist der Temperatursimulator HotSpot zum Einsatz gekommen. Für die Leistungsaufnahme wurden jeweils
ein statisches und ein dynamisches Verlustleistungsmodell vorgestellt und implementiert.
Die vier Gröÿen Spannung, Frequenz, Leistung und Temperatur sind hauptverantwortlich dafür, ob ein Chip fehlerfrei arbeitet. Sie bilden die Ursachen für die drei vorgestellen
Fehlertypen. Dabei handelt es sich um
1. Timing-Errors,
2. Soft-Errors,
3. Hard-Errors.
Die Ursachen dieser Fehler beschrieben worden. Die Modelle wurden mithilfe der Simulationsbibliothek asoc-sim implementiert. Mit diesen Modellen konnte ein Testsystem
konguriert werden, um die Evaluierung des XCS durchzuführen. Bei dem System handelt es sich um den Quad-Core Prozessor Opteron (Barcelona). Mithilfe von vier kleinen
Trace-Files konnten Beispielprogramme simuliert werden, dabei handelt es sich um eine
LR-Zerlegung, Matrix-Multiplikation, DualCore-Anwendung und einen Video-Stream.
Kapitel 6 Zusammenfassung und Diskussion
68
In Folge der Evaluierung wurde sowohl eine mögliche Umgebungsbeschreibung für den
XCS vorgestellt, als auch ein mögliches Reinforcement-Programm. Weiter konnte gezeigt
werden, dass der XCS damit optimale Betriebspunkte nden kann. Der XCS ist ebenfalls
in der Lage äuÿere Einüÿe wie das Ansteigen der Temperatur zu lernen. Falls die initialen
Classier zu der Umgebung passen, dann kann der XCS auch ohne Einsatz des GAs gute
Ergebnisse liefern. Bei der Steuerung von Speicherelementen unter Einuÿ von SoftErrors zeigte der XCS gute Ergebnisse.
6.2 Diskussion und Ausblick
Wie gezeigt wurde, kann der XCS einen SoC optimal einstellen. Allerdings sind die Lernzeiten recht lange. Dies liegt vorallem daran, dass die Temperatur auf Veränderungen
sehr träge reagiert. Damit aber zwei Einstellungen miteinander verglichen werden können, muÿ solange gewartet werden, bis sie einen gewissen Sättigungspunkt erreicht. Neben
der Temperatur sollte auch die Leistungsaufnahme nicht zu stark schwanken. Diese Wartezeit führt zu einer enorm langen Lernzeit. Ein anderer Punkt ist, dass das System in
der Lernphase in möglichst alle Zustände gebracht werden muÿ. Wenn dies nicht ermöglicht werden kann, wird der XCS keine guten Ergebnisse liefern. Die Arbeit mit dem
XCS hat auÿerdem gezeigt, dass es sehr schwierig ist, überhaupt eine funktionierende
Problembeschreibung zu nden. Um die Komplexität zu reduzieren, sollte jede FE ihre
Classier selber verwalten. Ingesamt gesehen konnte der XCS die gestellten Aufgaben
gut bewältigen. Damit die Lernzeit beschleunigt werden kann, ist vorallem eine kompaktere Umgebungsbeschreibung wichtig. Das bedeutet kurze Bedingungen mit wenigen
Aktionen. Dadurch sollte sich die Lernzeit sehr verkürzen.
Die Simulation selber sollte weiter verbessert werden. Gerade die Schätzung der Verlustleistung und Modellierung von Timing-Errors ist äuÿerst komplex und schwierig. Die
Simulation von Soft-Errors in kombinatorischer Logik stellt eine weitere Herausforderung
dar.
Anhang A
Wichtige Herleitungen
A.1 Dynamische Verlustleistung
Zur Herleitung (aus [27]) der dynamischen Verlustleistung in einem Inverter wird folgende Annahme gemacht: die auf- und absteigende Schaltzeit ist sehr viel kleiner als die
Taktperiode und das Eingangssignal ist quadratisch mit der Taktfrequenz
fp =
1
.
tp
Die durchschnittliche Verlustleistung errechnet sich dann durch
1
Pd =
tp
tZp /2
0
dabei ist
in
Ztp
1
in (t)Vout dt +
tp
ip (t) (VDD − Vout ) dt,
tp /2
der transiente Strom des n-Mos Elements und
einen Takt und mit
IDsat (t) = CL fVo ut /dt
CL
Pd =
tp
=
VZDD
CL
Vout dVout +
tp
0
2
CL VDD
tp
2
= CL VDD
fp
(A.1)
ip
des p-Mos Elements. Für
ergibt sich:
Z0
(VDD − Vout ) d (VDD − Vout )
(A.2)
VDD
(A.3)
(A.4)
Anhang A Wichtige Herleitungen
70
Abbildung A.1: Zeiten bei Schaltvorgang in einem Transitor nach [27]
A.2 Schaltzeit eines Inverters
In [27] wird ein analytisches Modell vorgestellt mit dessen Hilfe sich die Verzögerungszeit
in Abhängigkeit von der Spannung berechnen läÿt. Das Modell beschreibt die Verzögerungszeit eines Inverters. Die Schaltgeschwindigkeit eines CMOS-Gates wird dabei von
der Lade- und Entladezeit der Kapazität abhänig gemacht, wobei in drei Zeiten unterschieden wird:
1.
tr
beschreibt die Zeit, die das Ausgangssignal eines Transistors benötigt, um von
10%
2.
tf
auf
90%
seines stationären Wertes anzusteigen.
beschreibt die Zeit, die das Ausgangssignal eines Transistors benötigt, um von
90%
auf
10%
seines stationären Wertes abzufallen.
In Abbildung A.1 wird der Schaltvorgang eines Inverters verdeutlicht. Sobald sich das
Ausgangssignal verändert, fängt die nachfolgende Kapzität an sich zu laden. Der Verlauf
des ieÿenden Entladestroms am NMOS-Transistor wird in Abbildung A.2 dargestellt.
Anhang A Wichtige Herleitungen
71
Abbildung A.2: Stromstärke in Abhängigkeit der Ausgangsspannung nach [27]
Berechnung der Zeit für einen Signalabfall bei einem Inverter
Aus dem oben beschriebenen Schaltverhalten lassen sich zwei Annahmen bzgl. der Beschreibung der Fallzeit des Ausgangssignals ableiten:
1.
tf 1
ist die Zeit das die Ausgangsspannung von
0.9VDD
2.
tf 2
ist die Zeit das die Ausgangsspannung von
VDD − Vtn
Vtn
Dabei ist
auf
VDD − Vtn
abfällt.
0.1VDD
abfällt.
auf
die Schwellwertspannung des NMOS-Transitors. Solange
Vout > VDD − Vtn
ist, verhält sich der Entladestrom konstant, da er im Sättigungsbereich arbeitet. Dies
führt zu folgendem Ansatz:
Dabei ist
β
tf 1
(A.5)
t = t1
für den Zeitpunkt an dem
der Steilheitskoezient. Setzt man nun
Vout = 0.9VDD
läÿt sich
CL dVout βn
+
(VDD − Vtn )2 = 0.
dt
2
ist, und
t = t2
als den Zeitpunkt an dem
Vout = VDD − Vtn
erreicht, dann
beschreiben mit:
tf 1
Z 0.9VDD
2CL
=
dVout
βn (VDD − Vtn )2 VDD −Vtn
2CL (Vtn − 0.9VDD )
=
βn (VDD − Vtn )2
(A.6)
(A.7)
Anhang A Wichtige Herleitungen
72
Wenn der NMOS-Transitor des Inverters in seinem linearen Bereich arbeitet, ist der
Entladestrom nicht länger konstant. Daher läÿt sich die Entladezeit tf 2 von
nach
0.1VDD
beschreiben mit:
tf 2
2CL
=
βn (VDD − Vtn )2
=
mit
n=
(VDD − V tn)
Z
VDD −V tn
0.1VDD
dVout
2
Vout
2(VDD −Vtn ) −
(A.8)
Vout
CL
ln (19 − 20n)
βn VDD (1 − n)
(A.9)
Vtn
VDD .
Zusammen ergibt sich die gesamte Fallzeit durch
tf = tf 1 + tf 2
Die Herleitung von
tr
2CL
=
βn VDD (1 − n)
ist analog zu
tf .
(n − 0.1) 1
+ ln (19 − 20n) .
(1 − n)
2
(A.10)
Anhang B
Parameter XCS
B.1 Die Parameter des XCS im Überblick
Der XCS kann über eine ganze Reihe von Parametern gesteuert werden, um Einuÿ auf
den Lernprozess nehmen zu können. Diese Parameter können in der Orgrinalimplementierung von Butz durch eine Kongurationsdatei eingestellt werden. Durch die Vielzahl
der Parameter werden im folgenden alle diese Parameter einmal aufgeführt. Diese Liste
stammt aus [4] und wurde durch zusätzliche Erklärungen erweitert.
1.
N
2.
β
3.
α, 0
4.
γ
beschreibt die maximale Gröÿe einer Population.
ist die Lernrate für
und
v
ρ, , F
as.
werden für die Berechnungen der Fitness eines Classiers benutzt.
wird bei Multistep Problemen verwendet, um diesen Faktor wird die Belohnungs-
vorhersage der Classier in
5.
und
θGA
χ
7.
θsub
vermindert.
beschränkt den GA. Falls die durschnittliche Zeit, seit der letzten Benutzung
des GA, gröÿer ist als
6.
[A]−1
θGA ,
dann wird der GA erneut ausgeführt.
ist Wahrscheinlickeit, dass ein Crossover im GA stattndet.
die Vereinigungsschranke: die Erfahrung eines Classiers muÿ mindestens diese
Schranke überschreiten, damit er mit einem anderen Classier vereinigt werden
kann.
8.
P] :
mit dieser Wahrscheinlichkeit wird an jeder Stelle der Bedingung des neuen
Classiers ein Don't-Care-Symbol gesetzt, falls
9.
pI , I
und
FI
θmna
nicht erfüllt ist
sind die initialen Werte eines neu erstellten Classiers.
Anhang B Parameter XCS
10.
pexp
11.
θmna
74
ist die Wahrscheinlichkeit, dass eine zufällige Aktion ausgewählt wird.
ist die minimale Anzahl von Aktionen, die im Match-Set vorhanden sein
müssen. Ansonsten wird ein neuer Classier (der die aktuelle Situation überdeckt)
erstellt, der sich aber von allen anderen in der Population unterscheiden muÿ.
12.
doGASubsumption
gibt an, ob Kinder eines Classiers mit ihren Eltern vereinigt
werden können.
13.
doActionSetSubsumption gibt an, mit dessen Vereinigung der Classier im ActionSet aktiviert werden kann.
Literaturverzeichnis
[1] AMD
White-Paper:
Power
Consumption,
www.amd.com/us-
en/assets/content_type/DownloadableAssets/43761A_ACP_WPv7.pdf,
Stand:
13 Januar 2008
[2] A. Bernauer et al.:
Architecture and Design Methodology for Autonomic Systems
on Chip (ASoC) http://www-ti.informatik.uni-tuebingen.de/~bernauer/asoc/, 28.
Dezember 2007
[3] R. Blish, N. Durrant:
Semiconductor Conductor Device Reliability Failure Models,
International Sematech, Mai,2000.
[4] M. Butz, S.W. Wilson:
An Algorithmic Description of XCS, Advances in Learning
Classifer Systems: Proc. 3rd Int Workshop, P. L. Lanzi, W. Stolzmann, S. W.
Wilson, editors, Springer-Verlag Berlin, 253-272, 2001.
[5] M. Butz, T. Kovacs, P.L. Lanzi:
in XCS,
Toward a Theory of Generalization and Learning
IEEE Transactions on Evolutionary Computation, Vol. 8, No.1, Februar
2004.
[6] J. A. Butts, G. S. Sohi:
A Static Power Model for Architects,
Proceedings of the
33rd Annual International Symposium on Microarchitecture (Micro-33), Dezember
2000.
[7] F. Delattre:
AMD K10 architecture, http://www.behardware.com/art/imprimer/682/,
13. September, 2007.
Intel Pentium M Processor Power Estimation, Budgeting, Optimization and Validation, Intel Technology Journal, 7(2), Mai 2003.
[8] D. Genossar et al.:
[9] H-O. Georggii:
Stochastik - Einführung in die Wahrscheinlichkeitstheorie und Sta-
tistik, Walter de Gruyter GmbH & Co, Berlin, 2004.
[10] A. Gold, A. Kos:
Temperature Inuence on Power Consumption and Time Delay,
Department of Electronics, Cracow, Poland, 2003.
Literaturverzeichnis
76
Neutron soft error rate measurements in a 90-nm CMOS process and scaling trends in SRAM from 0.25-um to 90-nm generation, Intel Corp.,
[11] P. Hazucha et al. :
Hillsboro, OR, USA, 2003.
[12] P. Hazucha , C. Svensson:
Impact of CMOS Technology Scaling on the Atmospheric
Neutron Soft Error Rate, IEEE Transactions on Nuclear Science, 47(6), Dezember
2000.
[13] J.H. Holland: Adaptation. In R. Rosen & F.M. Snell (eds), Progress in Theoretical
Biology, 4. Plenum, 1976.
[14] W. Huang, M. R. Stan, K. Skadron, K. Sankaranarayanan, S. Ghosh, and S. Velusamy:
Compact Thermal Modeling for Temperature-Aware Design, Proceedings of
the 41st Design Automation Conference, Juni 2004.
[15]
Failure Mechanisms and Models or Semiconductor Devices,
JEDEC Publication,
JEP122C, März, 2006.
[16] T. Juhnke:
Die Soft-Error-Rate von Submikrometer-CMOS-Logikschaltungen, Dis-
seration, TU Berlin, 2003.
[17] S. Lee, S. Song, V. Au, and K. Moran:
Constricting/spreading resistance model for
electronics packaging, Proc. AJTEC, März 1995, 199-206.
[18] G. Lipsa, A. Herkersdorf, W. Rosenstiel, O. Bringmann and W. Stechele:
Towards a
Frame- work and a Design Methodology for Autonomic SoC, in: 2nd ICAC (2005).
[19] R. Mastipuram, E.C. Wee:
Soft errors' impact on system reliability, Cypress Semi-
conductor, 2004.
Delphi: The development of libraries of physical models of
electronic components for an integrated design environment, Proc. Conf. Int. Elec.
[20] H. Rosten, C. Lasance:
Pack. Soc., 1994.
[21] B.
Sander:
Barcelona: AMD's Next-Generation Quad-Core Microprocessor,
developer.amd.com/assets/CART2007-Barcelona.pdf, 11.01.08.
Historical trend in alphaparticle induced soft error rates of the alpha micro-processor. In Proc. of the Annual
[22] N. Seifert, D. Moyer, N. Leland, and R. Hokinson:
International Reliability Physics Symposium, 2001.
Literaturverzeichnis
77
[23] K. Skadron, K. Sankaranarayanan, S. Velusamy, D. Tarjan, M. R. Stan, and W.
Huang:
Temperature-aware microarchitecture: Modeling and implementation, ACM
Transactions on Architecture and Code Optimization, 1(1), 94-125, März 2004.
Modeling the Eect of Technology Trends on the Soft Error Rate of Combinational Logic, Proceedings of the International Conference on
[24] P. Shivakumar et al.:
Dependable Systems and Networks, Universität Texas und IBM Austin Research
Laboratory, Austin, 2002.
[25] J. Srinivasan, S. V. Adve, P. Bose, J. Rivers, C-K. Hu:
RAMP: A Model for
Reliability Aware MicroProcessor Design, IBM Research Report, Universität Illinois
und IBM T.J. Watson Research Center, 2003.
[26] http://www.tecchannel.de/server/prozessoren/450380/, Stand: 11.01.08
Principles of CMOS VLSI Design: A Systems Perspective (VLSI
Systems Series), Addison-Wesley, 2. Auage, 1993.
[27] N.H.E. Weste:
[28] S.W. Wilson:
Classier Systems and the Animat Problem, Machine Learning, 2(3),
199-228, 1987.
[29] S.W. Wilson:
Classier tness based on accuracy, Evolutionary Computation, 3(2),
149-175, 1995.
[30] S.W. Wilson:
Generalization in the XCS Classier System, Genetic Programming
1998: Proceedings of the Third Annual Conference, J. Koza et.al., (eds), San Francisco, Kalifornien, 1998.
[31] D. Zastrow:
Elektronik, Vieweg & Sohn Verlag, Wiesbaden, 2007.
[32] H. Yserentant:
Numerik 1, Skriptum, Tübingen, 2003