TECHNISCHE UNIVERSITAT¨ DORTMUND …ls12-€¦ · 2.6 Struktur einer ARM7-basierten MPARM ... 2.10...

TECHNISCHE UNIVERSITATDORTMUNDFAKULTAT FUR INFORMATIK

Diplomarbeit

Speicherhierarchie

Design-Space-Exploration fur

den MPARM System-on-Chip

Simulator

Alexander Katriniok

18. Juni 2008

I N T E R N E B E R I C H T EI N T E R N A L R E P O R T S

Lehrstuhl Informatik XIITechnische Informatik und Eingebettete SystemeFakultat fur InformatikTechnische Universitat DortmundGutachter:Prof. Dr. Peter MarwedelDipl.-Inf. Robert Pyka

GERMANY · D-44221 DORTMUND

Inhaltsverzeichnis

1 Einleitung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Ziele der Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Aufbau der Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Grundlagen 52.1 Speichertechnologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 SRAM-Speicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 DRAM-Speicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Flash-Speicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.4 Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 ARM7-Prozessorfamilie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1 Interpretive Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2 Compiled Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 MEMSIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.1 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.2 Komponentenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.3 Simulationssemantik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.4 Konfigurierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.5 Simulationsstatistik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.6 Energiemodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 MPARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5.1 Struktur der Simulationsplattform . . . . . . . . . . . . . . . . . . . . . . 172.5.2 AMBA AHB Bussystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5.3 SWARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5.4 Physikalischer und logischer Adressraum . . . . . . . . . . . . . . . . . . . 232.5.5 Konfigurierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.6 Simulationsstatistik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.5.7 Energiemodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.6 Optimierungsverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.6.1 Lineare Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.6.2 Nichtlineare Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.6.3 Evolutionare Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.6.4 SPEA2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3 MEMSIM-Integration 373.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.2 AMBA AHB Master-Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.1 MEMSIM-Master-Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 38

i

ii INHALTSVERZEICHNIS

3.2.2 Erweiterung des Zustandsautomaten . . . . . . . . . . . . . . . . . . . . . 393.2.3 Wurzelkomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.4 AMBA AHB-Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3 AMBA AHB Slave-Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3.1 MEMSIM-Slave-Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3.2 Wurzelkomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4 MEMSIM-Komponenten in MPARM . . . . . . . . . . . . . . . . . . . . . . . . . 443.4.1 Grundlegendes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.4.2 Wurzelkomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.4.3 Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.4.4 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.4.5 Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.4.6 AMBA AHB-Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.5 Energiemodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.6 Statistikerfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.7 Simulationsstatistik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.8 MPARM/MEMSIM-Adresstabelle . . . . . . . . . . . . . . . . . . . . . . . . . . 493.9 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.9.1 Konfiguration der Simulationskomponenten . . . . . . . . . . . . . . . . . 503.9.2 Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.9.3 Beispiel einer Konfiguration unter Verwendung der API . . . . . . . . . . 523.9.4 Schnittstelle zur Visual MEMSIM-Systemkonfiguration . . . . . . . . . . 53

3.10 Korrektheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.11 Aufruf von der Kommandozeile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4 Design Space Exploration 574.1 Explorationsziele und Annahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.2 Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.3 Generelle Umsetzung und globale Kriterien . . . . . . . . . . . . . . . . . . . . . 59

4.3.1 Evolutionarer Ansatz unter Verwendung von SPEA2 . . . . . . . . . . . . 594.3.2 TEA Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.3.3 Grundkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.3.4 Konvergenzkriterium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.3.5 Auswahl einer Losung aus der Pareto-Front . . . . . . . . . . . . . . . . . 624.3.6 Ausgabe des Optimierungsverfahrens . . . . . . . . . . . . . . . . . . . . . 63

4.4 Optimierung der Speicherhierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . 634.4.1 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.4.2 Grundkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.4.3 Reprasentation des Problems . . . . . . . . . . . . . . . . . . . . . . . . . 654.4.4 Nebenbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.4.5 Evaluation der Individuen durch MPARM/MEMSIM . . . . . . . . . . . 674.4.6 Initialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.4.7 Rekombination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.4.8 Mutation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.4.9 Reparatur unzulassiger Losungen . . . . . . . . . . . . . . . . . . . . . . . 72

4.5 Optimierung der Scratchpad-Allokation . . . . . . . . . . . . . . . . . . . . . . . 734.5.1 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.5.2 Grundkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.5.3 Reprasentation des Problems . . . . . . . . . . . . . . . . . . . . . . . . . 754.5.4 Nebenbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.5.5 Evaluation der Individuen durch ICD-C und MPARM/MEMSIM . . . . . 76

INHALTSVERZEICHNIS iii

4.5.6 Initialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.5.7 Rekombination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.5.8 Mutation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.5.9 Bestrafung unzulassiger Losungen . . . . . . . . . . . . . . . . . . . . . . 77

4.6 Gekoppelte Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5 Ergebnisse und Validierung 795.1 Verwendete Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.2 Vergleich der MPARM-Erweiterung mit MPARM . . . . . . . . . . . . . . . . . . 79

5.2.1 Grundlegendes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.2.2 Matrixmultiplikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.2.3 JPEG Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.2.4 Abschließende Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.3 Design Space Exploration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.3.1 Optimierung der Speicherhierarchie . . . . . . . . . . . . . . . . . . . . . . 875.3.2 Optimierung der Scratchpad-Allokation . . . . . . . . . . . . . . . . . . . 97

6 Zusammenfassung und Ausblick 103

Literaturverzeichnis 108

iv INHALTSVERZEICHNIS

Abbildungsverzeichnis

2.1 SRAM-Zelle [WM06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 DRAM-Zelle [WM06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Direct Mapped Cache [WM06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Beispiel einer MEMSIM-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . 132.5 MEMSIM-Simulationssemantik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.6 Struktur einer ARM7-basierten MPARM-Simulationsplattform . . . . . . . . . . 172.7 Multiplexer-basierter AMBA AHB Bus . . . . . . . . . . . . . . . . . . . . . . . . 192.8 Transaktion am AMBA AHB Bus . . . . . . . . . . . . . . . . . . . . . . . . . . 192.9 Struktur der SWARM/MPARM-Synchronisation . . . . . . . . . . . . . . . . . . 202.10 SWARM-Zustandsautomat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.11 Physikalischer und logischer Adressraum . . . . . . . . . . . . . . . . . . . . . . . 232.12 Evolutionarer Algorithmus [Rud06] . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1 Resultierende SWARM-Struktur mit MEMSIM-Master-Interface . . . . . . . . . 383.2 Erweiterter SWARM-Zustandsautomat . . . . . . . . . . . . . . . . . . . . . . . . 393.3 Resultierende AMBA AHB Slave-Struktur mit MEMSIM-Slave Interface . . . . . 423.4 Innere Struktur der Memory-Komponente . . . . . . . . . . . . . . . . . . . . . . 463.5 Visual MEMSIM-Beispielkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . 53

4.1 Workflow zur Optimierung der Speicherhierarchie . . . . . . . . . . . . . . . . . . 644.2 Hierarchisch ganzzahlige Vektorreprasentation . . . . . . . . . . . . . . . . . . . . 664.3 Beispiel einer Rekombination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.4 Dichtefunktion ϕ0;1 der Standard-Normalverteilung . . . . . . . . . . . . . . . . . 714.5 Workflow zur Optimierung der Scratchpad-Allokation . . . . . . . . . . . . . . . 744.6 Hierarchisch binare Vektorreprasentation . . . . . . . . . . . . . . . . . . . . . . . 76

5.1 Matrixmultiplikation: Energiebilanz im Vergleich . . . . . . . . . . . . . . . . . . 825.2 JPEG Encode: Energiebilanz im Vergleich . . . . . . . . . . . . . . . . . . . . . . 855.3 Matrixmultiplikation: Optimierungsergebnis . . . . . . . . . . . . . . . . . . . . . 895.4 GSM Decode: Optimierungsergebnis . . . . . . . . . . . . . . . . . . . . . . . . . 925.5 JPEG Encode: Optimierungsergebnis . . . . . . . . . . . . . . . . . . . . . . . . . 945.6 JPEG Encode: Ergebnispopulation unter Vernachlassigung der Chipflache . . . . 965.7 GSM Decode: Optimierungsergebnis . . . . . . . . . . . . . . . . . . . . . . . . . 100

v

vi ABBILDUNGSVERZEICHNIS

Tabellenverzeichnis

2.1 Zugriffsenergien der Memory-Komponente . . . . . . . . . . . . . . . . . . . . . . 16

5.1 Matrixmultiplikation: CPU-Konfiguration . . . . . . . . . . . . . . . . . . . . . . 815.2 Matrixmultiplikation: Slave-Konfiguration . . . . . . . . . . . . . . . . . . . . . . 815.3 Matrixmultiplikation: Simulationsergebnisse im Vergleich . . . . . . . . . . . . . . 825.4 Matrixmultiplikation: CACTI 4.2 Zugriffsenergien . . . . . . . . . . . . . . . . . . 835.5 JPEG Encode: CPU-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . 845.6 JPEG Encode: Slave-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . 845.7 JPEG Encode: Simulationsergebnisse im Vergleich . . . . . . . . . . . . . . . . . 855.8 JPEG Encode: CACTI 4.2 Zugriffsenergien . . . . . . . . . . . . . . . . . . . . . 865.9 Grundkonfiguration des EA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.10 Allgemeine Grundkonfiguration des SoC . . . . . . . . . . . . . . . . . . . . . . . 885.11 Matrixmultiplikation: Grundkonfiguration des SoC . . . . . . . . . . . . . . . . . 885.12 Matrixmultiplikation: Ergebnisindividuum . . . . . . . . . . . . . . . . . . . . . . 905.13 Matrixmultiplikation: Optimierungsgroßen des Ergebnisindividuums . . . . . . . 905.14 GSM Decode: Grundkonfiguration des SoC . . . . . . . . . . . . . . . . . . . . . 915.15 GSM Decode: Ergebnisindividuum . . . . . . . . . . . . . . . . . . . . . . . . . . 935.16 GSM Decode: Optimierungsgroßen des Ergebnisindividuums . . . . . . . . . . . . 935.17 JPEG Encode: Grundkonfiguration des SoC . . . . . . . . . . . . . . . . . . . . . 935.18 JPEG Encode: Ergebnisindividuum . . . . . . . . . . . . . . . . . . . . . . . . . . 955.19 JPEG Encode: Optimierungsgroßen des Ergebnisindividuums . . . . . . . . . . . 955.20 JPEG Encode: Ergebnisindividuum unter Vernachlassigung der Chipflache . . . . 965.21 JPEG Encode: Optimierungsgroßen des Ergebnisindividuums unter Vernachlassigung

der Chipflache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.22 Grundkonfiguration des GA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.23 Allgemeine Grundkonfiguration des SoC . . . . . . . . . . . . . . . . . . . . . . . 985.24 GSM Decode: Optimierungsgroßen des Ergebnisindividuums . . . . . . . . . . . . 985.25 GSM Decode: Ergebnisindividuum . . . . . . . . . . . . . . . . . . . . . . . . . . 101

vii

Kapitel 1

Einleitung

Wurden Rechensysteme bis in die spaten 80er Jahre mit großen Mainframes und in den 90erJahren mit Personal Computers, kurz PCs, assoziiert, so nimmt heutzutage im Trend der Minia-turisierung der Anteil sog. eingebetteter Systeme stark zu. Unter eingebetteten Systemen sinddabei informationsverarbeitende Systeme zu verstehen, die in ein großeres Produkt eingebettetsind [Mar03].

Die Einsatzdomanen solcher eingebetteten Systeme sind außerst vielfaltig. So kommen ein-gebettete Systeme z.B. in Kraftfahrzeugen, Flugzeugen, Handys, PDAs, Haushaltsgeraten oderin medizinischem Equipment zum Einsatz. Im Rahmen von steuerungs- und regelungstechni-schen Aufgaben sind sie haufig in sog. mechatronische Systeme eingebettet, in denen sie uberSensoren Informationen uber die physikalische Umwelt erhalten und uber Aktoren Einfluss aufdie physikalische Umwelt nehmen.

Aufgrund des vielfaltigen, haufig sicherheitskritischen Einsatzes dieser Systeme, z.B. in Air-bagsteuerungen oder in der Avionik, sind auch die Anforderungen dementsprechend hoch. Sosollen sie eine hohe Verfugbarkeit, Echtzeitfahigkeit, geringe Leistungsaufnahme, ein geringesGewicht und geringe Entwicklungskosten fur Hard- und Software aufweisen [Mar03]. All dieseAnforderungen sind wahrend des Designs eines eingebetteten Systems zu berucksichtigen.

1.1 Motivation

Da sowohl die Anforderungen als auch der gewunschte Funktionsumfang eingebetteter Sys-teme weitgehend zur Entwicklungszeit bekannt ist, ermoglicht dies vielfaltige Optimierungs-moglichkeiten. So konnen sowohl Hardware- als auch Softwarekomponenten speziell auf die An-wendungsdomane angepasst werden. Aufgrund hoher Komplexitat, kurzer Entwicklungszyklenund dem Wunsch nach geringen Entwicklungskosten wird meist ein Plattform-basierter Ansatzim Design mikroelektronischer Systeme verfolgt. Dabei wird ausgehend von einer vorgefertig-ten, parametrisierten Hardwarearchitektur eine Anpassung an die jeweilige Anwendungsdomanedurchgefuhrt. Insbesondere die Speicherhierarchie stellt eine der wichtigsten Architekturparame-ter dar. So kann diese sowohl horizontal, z.B. durch die Verwendung von Scratchpadspeichern, alsauch vertikal durch den Aufbau von Cache-Hierarchien modifiziert werden. Beispiele fur Variati-onsmoglichkeiten liefert u.a. [WM06]. Die Optimierung der Speicherhierachie wird insbesonderedurch die bisher wesentlich hoheren Leistungssteigerungen im Bereich der Prozessoren als imBereich der Speicher motiviert [WM95]. Dabei verdoppelt sich nach Moore’s Law sich die Anzahlder Transistoren auf einem Prozessorchip alle 18 bis 24 Monate [Int08]. In Folge dieser Verdopp-lung, die meist mit einer Verkleinerung der Strukturgroße der Transistoren einhergeht, ergibt sicheine hohere Prozessorperformance durch hohere Taktfrequenzen oder Parallelisierung. Da diesePerformancesteigerungen jedoch nicht auf Speicher ubertragbar sind, ist eine gute Auslegungder Speicherhierarchie entscheidend fur den effizienten Einsatz eines eingebetteten Systems.

1

2 1 Einleitung

Eine sehr energieeffiziente Plattform-basierte Architektur im Bereich eingebetteter Systemestellt die AMBA Architektur (Advanced Microcontroller Bus Architecture) dar. Dabei werdenin einer integrierten Schaltung ein oder mehrere ARM-Prozessoren, On-Chip Speicher und Teileder Speicherhierarchie zu einem sog. System-on-Chip (SoC) integriert [ARM99]. Wahrend derEntwicklung eines neuen Systems hat sich ein iteratives Vorgehen etabliert, bei dem Architek-turparameter festgelegt, die Software diesbezuglich optimiert und ubersetzt und anschließenddie Qualitat der Hardware-/Software-Kombination durch eine Simulation evaluiert wird. DiesesVorgehen wird solange wiederholt, bis ein bzgl. des Designziels hinreichend optimales Ergebniserzielt worden ist. Beispiele fur eine architekturspezifische Ubersetzung bzgl. der Speicherhier-archie finden sich in [SWLM02] und [VWM04].

Der Einsatz von Simulationen ermoglicht somit zur Designzeit eine ausfuhrliche Analyseder Hardware-/Software-Kombination des zu entwickelnden Systems und erlaubt, Optimierun-gen basierend auf Simulationsergebnissen durchzufuhren. Ebenso ist die Automatisierung desDesignprozesses und damit die Verkurzung der Entwicklungszeit durch die Verwendung einesgeeigneten Optimierungsverfahren denkbar, wobei die geeignete Parametrisierung des zu opti-mierenden Systems eine uberaus schwierige und komplexe Aufgabe darstellt.

1.2 Ziele der Diplomarbeit

Wie bereits dargestellt, findet die Ermittlung eines bzgl. der Designziele hinreichend opti-malen eingebetteten Systems in einem iterativen Prozess unter Verwendung von Simulatio-nen der Hardware-/Software-Kombinationen statt. Fur die Simulation von Harwareplattfor-men ist beispielsweise der MPARM System-on-Chip Simulator geeignet [BBB+05], wobei diesergroße Einschrankungen in der Konfigurierbarkeit der Speicherhierarchie aufweist. Neben derEinschrankung auf einen Cache-Level sind die Großen des Hauptspeichers und des Scratch-pads unveranderlich. Dem gegenuber existiert MEMSIM [WM06], ein reiner Speicherhierarchie-Simulator, der am Lehrstuhl entwickelt wurde.

Ziel dieser Diplomarbeit ist es daher, beide Simulatoren zu einem flexiblen System-on-ChipSimulator zu integrieren. Die besondere Herausforderung besteht dabei in der konsistenten,praxisgerechten und wohldefinierten Kombination der unterschiedlichen Simulationskonzepte,die MEMSIM und MPARM zugrunde liegen. Dabei soll die resultierende Simulationsplatt-form moglichst genau die Eigenschaften der simulierten Hardwareplattform bzgl. des Energie-verbrauchs und der benotigten Taktzyklen (der Ausfuhrungszeit) widerspiegeln. Zusatzlich zurIntegration soll eine wohldefinierte Schnittstelle (API) zur Konfiguration und Parametervariati-on entwickelt werden, um unter anderem eine einfache Anbindung des resultierenden Simulatorsan das am Lehrstuhl entwickelte MaCCv2 Compiler Framework [MAH] zu ermoglichen.

Neben der Integration soll des Weiteren im Rahmen einer Design Space Exploration einauf Evolutionaren Algorithmen (EA) basierendes Optimierungsverfahren zur Optimierung derSpeicherhierarchie eines SoC auf Basis einer Grundkonfiguration des Systems und ausgewahlterZielanwendungen, die den Funktionsumfang des zu optimierenden Systems hinreichend beschrei-ben, implementiert werden. Evolutionare Algorithmen eigenen sich insbesondere fur Optimie-rungsprobleme hoher Dimensionalitat, fur die uber konventionelle Verfahren keine oder nur untersehr großem Berechnungsaufwand eine Losung ermittelt werden kann. Dabei wird der Evolu-tionare Algorithmus den Energieverbrauch des Gesamtsystems, die benotigten Taktzyklen (dieAusfuhrungszeit) und den durch Speicher induzierten Chipflachenbedarf als Optimierungsgroßenberucksichtigen. Die Berechnung einer Losung korrespondiert damit mit der Bestimmung bzw.Approximation der Pareto-optimalen Menge von Losungen, aus der bzgl. der Designziele dieOptimalste auszuwahlen ist. Da sich in eingebetteten Systemen durch den Einsatz kleiner, ener-gieeffizienter Scratchpadspeicher ebenso ein großes Optimierungspotential ergibt, wird in dieserDiplomarbeit zusatzlich ein Ansatz zur Approximation der optimalen statischen Scratchpad-

1.3 Aufbau der Diplomarbeit 3

Allokation auf Basis eines Referenzsystems des SoC und ausgewahlter Zielanwendungen unterVerwendung Evolutionarer/Genetischer Algorithmen untersucht.

Abschließend soll diese Diplomarbeit eine Uberprufung der Genauigkeit der entwickeltenSimulationsplattform und der EA-basierten Design Space Exploration enthalten. Dazu wirddie Qualitat der Integration anhand einiger ausgewahlter Benchmarks im Vergleich zur ur-sprunglichen Version des MPARM-Simulators untersucht. Ebenso erfolgt eine Bewertung desOptimierungsverhaltens der EA-basierten Ansatze anhand ausgewahlter Optimierungsinstan-zen.

1.3 Aufbau der Diplomarbeit

Kapitel 2 vermittelt die notwendigen Grundlagen dieser Diplomarbeit. Da sich diese inharent mitder Analyse und Optimierung von Speicherhierarchien auseinandersetzt, werden zunachst Spei-chertechnologien vorgestellt, die in eingebetteten Systemen zum Einsatz kommen. Des Weiterenerfolgt eine kurze Einfuhrung in die ARM7-Prozessorfamilie, da alle Simulationen dieser Diplom-arbeit auf Basis eines ARM7-Instruktionssatzsimulators ausgefuhrt werden. Die zugehorigenKonzepte der Instruktionssatzsimulation werden anschließend vorgestellt. Im Folgenden wer-den die grundlegenden Konzepte des MEMSIM Speicherhierarchie-Simulators und des MPARMSystem-on-Chip Simulators erlautert, die fur die in Kapitel 3 beschriebene Integration von MEM-SIM in MPARM von entscheidender Bedeutung sind. Abschließend erfolgt eine Einfuhrung inOptimierungsverfahren, wobei insbesondere Evolutionare Algorithmen, die fur nichtlineare oderfunktional nicht hinreichend spezifizierte Probleme zum Einsatz kommen, betrachtet werden.Ein besonderer Fokus liegt dabei auf mehrkriteriellen Evolutionaren Algorithmen.

Kapitel 3 erlautert die konsistente, praxisgerechte und wohldefinierte Integration von MEM-SIM in MPARM. Des Weiteren wird ein Uberblick uber die API des resultierenden Simulators,d.h. dessen Konfigurierbarkeit, und den Umfang der aus einer Simulation resultierenden Simu-lationsergebnisse gewahrt.

Die auf Evolutionaren Algorithmen basierende Design Space Exploration wird in Kapitel 4erlautert. Dabei wird zum einen ein Ansatz zur Optimierung der Speicherhierarchie des SoCauf Basis einer Grundkonfiguration des Systems und ausgewahlter Zielanwendungen, die dengewunschten Funktionsumfang des System widerspiegeln, zum anderen ein Ansatz zur Opti-mierung der statischen Scratchpad-Allokation auf Basis eines Referenzsystems des SoC undausgewahlter Zielanwendungen vorgestellt.

Kapitel 5 uberpruft die Validitat der MPARM-Erweiterung um MEMSIM anhand aus-gewahlter Benchmarks auf Basis von Simulationsergebnissen. Des Weiteren werden drei Op-timierungen der Speicherhierarchie und eine Optimierung der statischen Scratchpad-Allokationdurchgefuhrt und die resultierenden Losungen diskutiert.

Abschließend liefert Kapitel 6 eine Zusammenfassung der Ergebnisse dieser Diplomarbeitund gibt einen Ausblick, wie die entwickelten Ansatze zukunftig fortgefuhrt werden konnen.

4 1 Einleitung

Kapitel 2

Grundlagen

Dieses Kapitel vermittelt die elementaren Grundlagen dieser Diplomarbeit. Da sich diese inharentmit der Analyse und Optimierung von Speicherhierarchien auseinandersetzt, werden zunachstSpeichertechnologien vorgestellt, die in eingebetteten Systemen zum Einsatz kommen. Da in die-ser Diplomarbeit alle Simulationen unter Verwendung eines ARM7-Softcore-Prozessors durch-gefuhrt werden, erfolgt ebenso eine kurze Erlauterung der ARM7-Prozessorfamilie. Des Weiterenwerden zwei verschiedene Konzepte der Instruktionssatzsimulation vorgestellt. Darauf erfolgt ei-ne Einfuhrung in den Aufbau und die Funktionsweise der Simulatoren MEMSIM und MPARM,die im Rahmen dieser Diplomarbeit miteinander kombiniert werden. Abschließend werden Op-timierungsverfahren, insbesondere mehrkriterielle Evolutionare Algorithmen vorgestellt, die indieser Diplomarbeit zur Optimierung der Speicherhierarchie und der statischen Scratchpad-Allokation in Kapitel 4 eingesetzt werden.

2.1 Speichertechnologien

Die Analyse und Optimierung von Speicherhierarchien ist integraler Bestandteil dieser Diplom-arbeit. In diesem Abschnitt werden daher die Grundlagen der in eingebetteten Systemen ein-gesetzten Speicherarchitekturen SRAM (Static Random Access Memory), DRAM (DynamicRandom Access Memory) und Flash, wie sie in [WM06] beschrieben werden, vorgestellt.

2.1.1 SRAM-Speicher

Das grundlegende Prinzip einer einzelnen SRAM-Speicherzelle, das in Abb. 2.1 dargestellt wird,kann mit einem Flip-Flop verglichen werden, wobei jede 1-Bit Speicherzelle aus 6 Transisto-ren besteht. Bedingt durch diesen Aufbau, handelt es sich bei SRAM-Speichern um fluchtigeSpeicher, die mit Verlust der Betriebsspannung ihren Inhalt verlieren. Der Zugriff auf eine Zelleerfolgt uber die Adressleitung. Im lesenden Fall kann das gespeicherte Bit uber Data und Data(invertiertes Bit) ausgelesen werden. Soll hingegen ein Bit, z.B. eine ’0’, in die Zelle geschrie-ben werden, so sind Data und Data mit ’0’ bzw. ’1’ anzusteuern. Aufgrund des asynchronenZugriffsverhaltens von Standard-SRAM-Speicherbausteinen erfolgt das Auslesen bzw. Schreibeneines Datums nach einer festen zeitlichen Verzogerung. Dieses Zugriffsverhalten ermoglicht je-doch eine einfache Modellierung des zeitlichen Verhaltens und des Energieverbrauchs, sodass furjeden Zugriff dieselbe Verzogerung und Zugriffsenergie angenommen werden kann. Der Nachteilvon SRAM-Speichern besteht, bedingt durch die aus 6 Transistoren bestehende Speicherzellen-struktur, im großen Chipflachenbedarf pro Bit. Jedoch kann dieser Speichertyp direkt auf demProzessor-Die als On-Chip Speicher integriert werden, da der Halbleiter-Produktionsprozess, derfur Transistoren verwendet wird, auch fur SRAM-Speicher genutzt werden kann. Des Weiterenzeichnet sich SRAM durch eine hohe Zugriffsgeschwindigkeit aus, sodass im Fall eines On-Chip

5

6 2 Grundlagen

Speichers der Zugriff innerhalb eines Taktes erfolgen kann.

Address

VDD

Data Data

'0'

'0'

'0'

'1'

'1'

'1'

Abbildung 2.1: SRAM-Zelle [WM06]

SRAM-Speicher kommen in eingebetteten Systemen als Caches (siehe 2.1.4), Hauptspei-cher oder Scratchpads vor, wobei letztere kleine, energieeffiziente Speicher darstellen und imGegensatz zu Caches uber keine Hardware-Kontrolllogik verfugen. Der effiziente Einsatz vonScratchpads muss dabei uber den Programmierer oder Compiler erfolgen.

Die Gesamtkapazitat eines SRAM-Speichers kann entweder auf einer Speicherbank realisiertoder auf mehrere Speicherbanke aufgeteilt werden. Die Aufteilung in kleinere Speichereinheitenhat bei großen Speichern den Vorteil, dass ein Zugriff immer nur auf einen entsprechend klei-neren Bereich des Speichers zu erfolgen hat, sodass sowohl der Energieverbrauch als auch dieZugriffszeit verringert werden kann. Jede Speicherbank besteht des Weiteren aus L Zeilen, diewiederum uber eine Kapazitat von B Byte verfugen.

Die neusten Entwicklungen im Bereich der SRAM-Speicher tendieren zu synchronen SRAMs(SSRAMs), die aufgrund eines internen Pipelinings einen großeren Datendurchsatz aufweisen.Des Weiteren bieten SSRAMs einen Burst-Mode, sodass die Adresse automatisch inkremen-tiert wird und nicht uber den Adressbus ubertragen werden muss. Durch neue Halbleiter-Fertigungstechnologien kann inzwischen der große Chipflachenbedarf durch Einsatz von Thin-Film Transistoren (TFT) um bis zu 50 Prozent reduziert werden. Weitergehende Informationenzu SRAMs und ihren Zeit- und Energiemodellen konnen [WM06] entnommen werden.

2.1.2 DRAM-Speicher

DRAM Speicherzellen sind von ihrem Aufbau wesentlich einfacher als SRAM-Zellen. So bestehendiese nur aus einem Transistor und einem Kondensator pro Bit, woraus ein auf 1/6 reduzierterChipflachenbedarf pro Bit im Gegensatz zu SRAM-Zellen resultiert. Da somit große Speicherzu geringen Kosten produziert werden konnen, wird die DRAM-Technologie primar fur großeHauptspeicher eingesetzt. Ebenso, wie SRAMs, sind DRAMs fluchtige Speicher. Ein Nachteil derDRAM-Speicher ist jedoch das komplexere Zugriffsprotokoll. Durch die Verwendung von Kon-densatoren kleiner Kapazitat und unerwunschte Leckstrome wird in periodischen Zeitintervallendas Erneuern des Speicherinhalts, ein sog. Refresh, notwendig.

Zur Steigerung der Performance von DRAM-Speichern werden synchrone DRAMs (SDRAMs)oder double data rate SDRAMs (DDR-SDRAMs) eingesetzt. Letztere ermoglichen das Lesenvon Daten bei einer steigenden und fallenden Taktflanke. Im Folgenden werden SDRAMs alsBasis fur die Charakterisierung von DRAM-Speichern verwendet. Bei einem lesenden Zugriff

2.1 Speichertechnologien 7

Word Select

Data

Abbildung 2.2: DRAM-Zelle [WM06]

wird die zugehorige Zeile des SDRAMs vollstandig gelesen und in einem I/O-Puffer gespeichert.Erst anschließend wird uber die Zugriffsadresse die zugehorige Spalte selektiert und das an-geforderte Datum im Datenregister des SDRAMs abgelegt. Beim Lesen der Zeile verlieren dieKondensatoren jedoch ihre Ladung, sodass die komplette Zeile vom I/O-Puffer in den Speicherzuruckgeschrieben werden muss. Dieser Vorgang nennt sich Precharge. Ahnlich verhalt es sichim schreibenden Fall. Die der Zugriffsadresse zugehorige Zeile wird dabei vollstandig in denI/O-Puffer geladen und daraufhin das zu schreibende Datum in den Puffer geschrieben. Ab-schließend wird die Zeile vollstandig aus dem Puffer in den Speicher zuruckgeschrieben. Auchdieser Vorgang nennt sich Precharge. Das Auslesen einer vollstandigen Zeile kann jedoch da-zu genutzt werden, den Datendurchsatz eines DRAM-Speichers zu erhohen. Bei nachfolgendenlesenden Zugriffen auf Daten derselben Zeile kann das gewunschte Datum aus dem I/O-Puffergelesen werden. Der sequenzielle Zugriff auf Speicherinhalte wird auch Burst-Zugriff genannt.

2.1.3 Flash-Speicher

Im Gegensatz zu SRAM- und DRAM-Speichern sind Flash-Speicher nicht fluchtig, sodass sieauch bei Verlust der Versorgungsspannung ihren Inhalt nicht verlieren. Diese Speicher werden ineingebetteten Systemen haufig fur die Speicherung des Boot-Loaders oder des Betriebssystemsverwendet und losen zunehmend Read-Only Speicher wie ROMs, EPROMs und EEPROMs,die nur unter großem Aufwand uberschrieben werden konnen, ab. Flash-Speicher zeichnet zu-dem eine vernachlassigbar kleine Standby-Leistungsaufnahme bei gleichzeitig geringem Energie-verbrauch bei einem lesenden Zugriff aus, sodass sich diese Speicher ausgezeichnet als Read-Only Speicher eignen. Da Flash-Speicher uber eine wesentlich hohe Zugriffszeit als SRAMs oderDRAMs verfugen, wird auszufuhrender Code zunachst in einen schnelleren SRAM oder DRAMkopiert und von dort aus ausgefuhrt. Ebenso ist die Anzahl der Schreibzyklen fur einen Flash-Speicher auf 105 bis 106 beschrankt, wobei aus einem schreibenden Zugriff stets das Schreibeneines ganzen Blocks und damit ein hoher Energieverbrauch resultiert.

Flashs konnen grundsatzlich in 2 Typen untergliedert werden, NAND- und NOR-Flashs.NAND-Flashs, die im Gegensatz zu NOR-Flashs gunstiger sind, sind intern seriell organisiert.Aufgrund dieser Organisation konnen NAND-Flashs nicht als Random Access Speicher einge-setzt werden und werden daher meist als reiner Datenspeicher in Form von USB-Sticks eingesetzt.NOR-Flashs hingegen bieten aufgrund ihrer internen parallelen Organisation wahlfreien Zugriffauf die gespeicherten Daten und eignen sich daher als Speicherform, aus der Code direkt aus-gefuhrt werden kann (execute in place (XIP) Speicher). NOR-Speicher zeigen jedoch ein außerstschlechtes Verhalten im schreibenden Fall, in dem stets nur sehr große Blocke geschrieben werdenkonnen.

8 2 Grundlagen

2.1.4 Caches

Caches sind kleine, energieeffiziente Speicher auf Basis der SRAM-Technologie, die einem be-deutend großeren Speicher mit i.d.R. wesentlich großerer Latenz und Zugriffsenergie vorgelagertsind und dabei haufig verwendete Daten und Instruktionen enthalten. Eine Besonderheit vonCaches ist, dass sie vor dem Benutzer und Compiler verborgen sind. So erfolgt die Nutzungdieser kleinen Speicher implizit und erfordert im Gegensatz zu Scratchpads keine zusatzlichenAnderungen am Quellcode. Besonders die wesentlich hoheren Leistungssteigerungen im Bereichder Prozessoren im Vergleich zu DRAM-Speichern macht den Einsatz kleiner energieeffizienterSpeicher unabdingbar.

Caches berucksichtigen dabei die in Programmen nachweislich inharent vorhandene tempo-rale und ortliche Lokalitat. Der temporalen Lokalitat liegt die Annahme zugrunde, dass die ineinem Zeitintervall referenzierten Daten bzw. Instruktionen auch in naher Zukunft verwendetwerden (z.B. Schleifen), der ortlichen Lokalitat hingegen, dass Daten bzw. Instruktionen, diein naher Zukunft referenziert werden, sich bzgl. ihrer Adresse nahe bei bereits referenziertenbefinden (z.B. Arrays) [Fin06].

Tag Index Offset

Data

== ?

Access Address

Tag Array Data Array

Abbildung 2.3: Direct Mapped Cache [WM06]

Der Aufbau von Caches ist aufgrund der funktionalen Komplexitat deutlich komplexer alsder eines gewohnlichen SRAM-Speichers. Die Große CS eines Caches in Byte gibt dabei dieMenge an Daten bzw. Instruktionen an, die ein Cache aufnehmen kann. Die Organisation einesCaches erfolgt stets in Form einer Matrix von CL Cache-Zeilen mit einer Zeilen-/Blockgroßevon je BS Worten der Wortlange WL. Damit besteht ein Cache stets aus CS/(WL ·BS) Cache-Zeilen. Einer Cache-Zeile ist dabei ein sog. Tag zugeordnet, uber den in Verbindung mit einemValid-Bit, das definiert, ob eine Cache-Zeile valide im Cache vorliegt, festgestellt werden kann, obsich das zu einer Adresse gehorige Datum im Cache befindet. Dabei kann ein Valid-Bit pro Wortoder Cache-Zeile verwendet werden. Je nach Schreibstrategie wird zusatzlich ein Dirty-Bit proWort oder Cache-Zeile benotigt, das die Modifikation eines Worts oder der Zeile dokumentiert.Unter Vernachlassigung der Valid- und Dirty-Bits kann demzufolge ein Cache als Kombinationeiner Daten- und Tag-Matrix betrachtet werden. Des Weiteren kann uber die Assoziativitat ASeines Caches die Anzahl der Zeilen festgelegt werden, in denen ein Datum bzgl. der zugehorigenAdresse im Cache gespeichert werden kann. Im Fall eines Direct Mapped Cache (AS = 1) istdies genau eine Zeile, fur einen n-Weg assoziativen Cache existieren n potentielle Moglichkeitenund beim vollassoziativen Cache kommt jede Cache-Zeile in Frage. Organisatorisch wird dazuder Cache in sog. Cache Sets aufgeteilt, die jeweils AS Cache-Zeilen enthalten. Die Gesamtzahl

2.1 Speichertechnologien 9

der Cache Sets ergibt sich uber den Zusammenhang CS/(WL · BS · AS). Die Funktionsweiseeines Caches und die Verwendung der Tags wird im Folgenden anhand eines Beispiels verdeut-licht. Bei einem lesenden Zugriff wird zunachst uberpruft, ob das angeforderte Datum im Cachevorliegt. Im positiven Fall liegt ein Cache-Hit vor und das Datum wird an den Prozessor oderden vorgelagerten Cache-Level delegiert, im negativen Fall ergibt sich ein Cache-Miss und dasDatum muss vom nachsten Level der Speicherhierarchie geladen werden. Die Ermittlung einesCache-Hits oder Cache-Misses erfolgt dabei uber die Zugriffsadresse, die sich in einen Tag-,Index- und Offset-Abschnitt gliedert. Der Index-Teil der Adresse wird fur den Zugriff auf daszugehorige Cache Set verwendet, der Tag-Teil der Adresse wird mit dem Tag jeder Zeile desselektierten Cache Sets gleichzeitig verglichen. Bei Ubereinstimmung des Tags einer Zeile mitdem Tag-Teil der Adresse und gleichzeitig gesetztem Valid-Bit liegt ein Cache-Hit vor, ansonstenein Cache-Miss. Bei einem Cache-Hit kann uber den Offset-Teil der Adresse das angeforderteDatum ausgelesen werden. Abb. 2.3 zeigt diesen Sachverhalt am Beispiel eines Direct MappedCaches.

Nachdem der generelle Aufbau und die grundlegende Funktionalitat von Caches erlautertwurde, wird im Folgenden ein zusammenfassender Uberblick uber die vielfaltigen Designpara-meter gewahrt [WM06]:

• Split- oder Unified-Caches: Split-Caches enthalten entweder Daten oder Instruktionenund werden im Folgenden Instruktions- bzw. Daten-Caches oder I-/D-Caches genannt.Unified-Caches hingegen enthalten sowohl Daten als auch Instruktionen. Split-Caches zei-gen im Allgemeinen eine bessere Performance, da sowohl Daten als auch Instruktionen eineinharente Lokalitat zugrunde liegt. Jedoch steigt durch die Verwendung von Split-Cachesauch der Bedarf an Chipflache und damit verbunden die Produktionskosten.

• Cache-Große: Die Große des Caches in Byte gibt stets die Menge an Daten- bzw. Instruk-tionen an, die ein Cache aufnehmen an. Diese Großenangabe vernachlassigt dabei dendurch Tag-Speicher und zusatzliche Bits induzierten Speicherbedarf.

• Block-/Zeilengroße: Die Block-/Zeilengroße in Worten einer Wortlange von WL Byte legtden Umfang der berucksichtigten ortlichen Lokalitat des Caches fest.

• Assoziativitat : Die Assoziativitat legt fest, in wie vielen Cache-Zeilen ein Datum bzgl.seiner Adresse gespeichert werden kann. Direct Mapped Caches werden hauptsachlich furInstruktions-Caches verwendet, da Instruktionen haufiger sequentiell referenziert werdenals Daten. Ansonsten kommen haufig 2-Weg assoziative Caches zum Einsatz.

• Schreibstrategie: Wird ein Wort unter der Annahme eines Cache-Hits in den Cache ge-schrieben, so existieren zwei Strategien. Zum einen kann das Wort in den Cache geschriebenund das zugehorige Dirty-Bit gesetzt werden, sodass kein Zugriff auf einen nachfolgendeCache-Level oder den Hauptspeicher erforderlich wird. Erst wenn die zugehorige Cache-Zeile entfernt wird, ist diese in die nachste Stufe der Speicherhierarchie zuruckzuschreiben.Diese Strategie nennt sich Write Back. Zum anderen besteht die Moglichkeit, ein Datumsimultan in den Cache und die nachste Stufe der Speicherhierarchie zu schreiben. Darausresultieren zwar mehr schreibende Zugriffe auf nachfolgende Caches oder den Hauptspei-cher, es kann jedoch auf das Dirty-Bit verzichtet werden. Diese Strategie nennt sich WriteThrough.

• Strategie bei einem Write Miss: Bei einem Write Miss kann entweder die zu der Zugriffs-adresse gehorige Zeile geladen (allocate on write miss) oder das Datum in die nachsteStufe der Speicherhierarchie geschrieben werden (no allocate on write miss). Das Ladender entsprechenden Zeile bringt dann Vorteile, wenn aufgrund der inharenten Lokalitat innaher Zukunft auf das Datum oder dessen Umgebung zugegriffen wird.

10 2 Grundlagen

• Ersetzungsstrategie: Wird bei einem Cache-Miss die zur Zugriffsadresse gehorige Zeile odernur das entsprechende Wort aus einer nachfolgenden Stufe der Speicherhierarchie geladenund sind die potentiellen Positionen im Cache bereits belegt, so ist eine Cache-Zeile zuersetzen. Es existieren viele verschiedene Ersetzungsalgorithmen. LRU (Least RecentlyUsed) ersetzt dabei die am langsten nicht referenzierte Zeile eines Cache Sets, RoundRobin wechselt reihum. Ebenso ist eine zufallsbasierte Strategie einsetzbar.

• Strategie beim Laden einer Cache-Zeile: Beim Laden einer Cache-Zeile besteht die Moglich-keit, zuerst das angeforderte Datum und dann den Rest der Zeile zu laden, um die Anzahlan Prozessorstalls zu minimieren. Im Fall, dass nicht nur ein Valid-Bit pro Zeile, sondernauch pro Wort existiert, besteht ebenso die Moglichkeit, die Cache-Zeile unvollstandig zuladen.

Die richtige Kombination der Design-Parameter zum Entwurf eines fur die Anwendungs-domane optimalen Caches bzw. einer optimalen Cache-Hierarchie stellt eine außerst diffizileAufgabe dar, da alle Parameter einen gegenseitigen Einfluss aufeinander ausuben. Dieser Her-ausforderung widmet sich Kapitel 4 ausfuhrlich und stellt einen Ansatz vor, mit dem das Problemnaherungsweise losbar ist.

2.2 ARM7-Prozessorfamilie

ARM7-Prozessoren gehoren zur Familie der 32-Bit Embedded-RISC-Mikroprozessoren. Diesezeichnen sich insbesondere durch eine geringe Leistungsaufnahme, geringen Chipflachenbedarfund hohe Performance im Bereich eingebetteter Applikationen aus und finden so haufigen Ein-satz in Mobiltelefonen (z.B. in Apples iPhone), PDAs, MP3-Playern oder im Automotive Bereich[ARM] [ARM01a]. Der ARM7TDMI stellt den in der Industrie am weitesten verbreiteten 32-BitEmbedded-RISC-Mikroprozessor dar, fur den ebenso ein synthetisierbares VHDL- und Verilog-Modell existiert. Neben diesem gehort der ARM720T, der einen ARM7TDMI-Prozessorkern,einen 8 kB Unified-Cache und eine Memory Management Unit (MMU) verwendet und somit zuBetriebssystemen wie Windows CE, Linux, Palm OS und Symbian OS kompatibel ist, zur Fa-milie der ARM7-Prozessoren. Des Weiteren existiert mit dem ARM7EJ-S ein synthetisierbaresProzessormodell, das sich grundlegend vom ARM7TDMI-Prozessor durch eine Java Bytecode-Ausfuhrungseinheit, einen DSP-Befehlssatz und eine 5-stufige Pipeline unterscheidet. Unter Ver-nachlassigung des ARM7EJ-S Prozessors sind allen ARM7-Prozessoren folgende Eigenschaftengemeinsam [ARM01a]:

• 32-Bit RISC Load/Store Von-Neumann-Architektur

• 3-stufige Pipeline (Fetch, Decode, Execute)

• 32-Bit Adressraum (4 GB)

• 37 32-Bit Register: 31 General Purpose-Register, 6 Statusregister

• 8-Bit (Byte), 16-Bit (Halbwort) und 32-Bit (Wort) Datentypen

• Unterstutzte Befehlssatze: 32-Bit ARM-Befehlssatz, 16-Bit Thumb-Befehlssatz

• Unterstutzung von Little-Endian und Big-Endian Word Order

Der 16-Bit Thumb-Befehlssatz ist dabei eine Untermenge des 32-Bit ARM-Befehlssatzes, wo-bei jeder Thumb-Befehl einem korrespondierenden ARM-Befehl zugeordnet ist, der denselbenEffekt auf den Prozessorzustand hat. Des Weiteren operiert der Thumb-Befehlssatz auf dem

2.3 Simulation 11

ARM7-Registersatz. Bei der Ausfuhrung von Thumb-Instruktionen werden diese in Echtzeitund ohne Performanceverlust in 32-Bit ARM-Instruktionen umgewandelt. Thumb-Instruktionenkonnen dabei alle Vorzuge eines 32-Bit Prozessorkerns, wie den 32-Bit Adressraum, 32-Bit Regis-ter, 32-Bit Shifter, 32-Bit ALU (Arithmetic Logical Unit) und 32-Bit Speichertransfers nutzen[ARM01a]. Weitere Informationen zum Thumb-Befehlssatz konnen [ARM01a] und [ARM01b]entnommen werden.

2.3 Simulation

Unter Simulation wird die modellhafte Darstellung oder Nachbildung bestimmter Aspekte einesvorhandenen oder zu entwickelnden Systems, insbesondere auch seines Zeitverhaltens verstan-den [Bro07]. Wahrend eines Hardware-Designprozesses erlaubt die Simulation eines Programmsauf einer Hardwarearchitektur somit die detailierte Analyse verschiedener Anforderungen wieEchtzeitfahigkeit oder Energieverbrauch und die Moglichkeit der Optimierung. [WL02] erlautertzwei verschiedene Ansatze fur die sog. Instruktionssatzsimulation eines Prozessors. Diese werdenim Folgenden vorgestellt.

2.3.1 Interpretive Simulation

Beim interpretativen Ansatz, einer klassischen Vorgehensweise bei der Simulation von Prozessor-Instruktionen, dient das zu simulierende Programm in binarer Form dem Simulator als Einga-be. So wird jede zu simulierende Instruktion durch den Simulator dekodiert und anschließenddurch eine Routine interpretiert, wodurch sich schlussendlich ein neuer Zustand des Simulatorseinstellt. Der Nachteil dieses Verfahrens ist die geringe Performance. So mussen beispielsweiseInstruktionen in Schleifen in jeder Iteration neu dekodiert werden, was zu einem großen Over-head und somit zu Performanceeinbußen in der Simulation fuhrt. Besonders bei rechenintensivenSimulationen wird dieser Nachteil deutlich.

2.3.2 Compiled Simulation

Die Compiled Simulation verfolgt einen anderen Ansatz. So wird das zu simulierende Programm,das in Form von Assembler- oder Binarcode vorliegt, zunachst in kompilierbaren C++ - Codetransformiert und dann zusammen mit dem Simulator ubersetzt. Die Dekodierung der Instruktio-nen erfolgt so nur bei der Ubersetzung der Simulation, wodurch der Overhead des interpretativenAnsatzes entfallt. Damit lasst sich durch den Ansatz der Compiled Simulation eine wesentlichhohere Performance erzielen.

2.4 MEMSIM

MEMSIM wurde am Lehrstuhl mit der Funktion eines reinen Speicherhierarchie-Simulators ent-wickelt, um gegenuber existierenden, bzgl. der Konfigurierbarkeit der Speicherhierarchie sehrrestriktiven Simulatoren Abhilfe zu schaffen [WM06]. So ermoglicht MEMSIM als zyklengenau-er Simulator mit einer flexiblen Konfigurierbarkeit die Evaluation verschiedenster Speicherhier-archien in einem Ein-Prozessor-System, wobei mehrstufige Cache-Hierarchien und Scratchpad-speicher unterstutzt werden. Die Entwicklung von MEMSIM erfolgte ebenso unter der Pramisseeiner einfachen Anpassbarkeit an verschiedene Prozessorarchitekturen.

2.4.1 Workflow

Eingesetzt wird MEMSIM in Verbindung mit encc (Energy Aware C Compiler) [WM06] undARMulator [ARM03b]. Encc wurde am Lehrstuhl entwickelt und erzeugt Code fur den 16-

12 2 Grundlagen

Bit Thumb-Befehlssatz eines ARM7-Prozessors. Neben der Performance kann encc auch denEnergieverbrauch der Hardwarearchitektur optimieren, wozu zusatzliche Informationen uber dieverfugbaren Speicher (z.B. ein Scratchpad) als Eingabe bereitgestellt werden mussen. Der re-sultierende ausfuhrbare Binarcode wird mit Hilfe von ARMulator, einem von ARM Ltd. ent-wickelten Simulator, der ARM-Prozessormodelle von ARM2 bis ARM7 und sowohl Thumb- alsauch ARM-Befehlssatze unterstutzt, simuliert. Die Simulation erfolgt dabei unter Verwendungeiner flachen Speicherhierarchie ohne Caches und einer Speicherzugriffszeit von einem Zyklusohne zusatzliche Wait States, sodass alle zeitlichen Verzogerungen durch die CPU hervorgeru-fen werden. ARMulator stellt als Ergebnis ein Tracefile bereit, das alle ausgefuhrten Instruk-tionen und Speicherzugriffe beinhaltet und MEMSIM als Eingabe dient. In einer MEMSIM-Simulation werden alle ausgefuhrten Instruktionen und Speicherzugriffe simuliert, wobei sichggf. zusatzliche Latenzen durch die konfigurierte Speicherhierarchie bzw. die eingesetzten Spei-cher einstellen. Damit verwendet MEMSIM den in 2.3.1 beschriebenen Ansatz der interpreta-tiven Simulation. Detaillierte Statistiken zu Speicherzugriffen, zum Energieverbrauch und zurAnzahl benotigter Taktzyklen werden lokal in den MEMSIM-Komponenten, deren Konzept imFolgenden naher erlautert wird, gespeichert und nach der Simulation komponentenspezifischausgegeben. Da MEMSIM den Fokus auf die Simulation einer Speicherhierarchie legt, existiertkein Energiemodell fur die CPU. Bei Bedarf kann jedoch der Energieverbrauch des Prozessorsaus den ARMulator Simulationsergebnissen zeitlich interpoliert werden.

2.4.2 Komponentenmodell

Zur Modellierung paralleler Hardware und komplexer Speicherhierarchien verwendet MEMSIMein Komponentenmodell, das alle Elemente der Hardwarearchitektur als eigenstandige Kom-ponenten abbildet, die jeweils ausschließlich mit ihren direkten Vorgangern und Nachfolgernohne Inanspruchnahme einer zentralen Simulationsinstanz kommunizieren. Jede in MEMSIMexistierende Komponente leitet sich dabei von der Klasse Component ab, die die elementars-ten Kommunikationskonstrukte bereitstellt. Die Kommunikation mit einem Nachfolger, also diePropagierung eines Speicherzugriffs, erfolgt uber den Aufruf der Funktion AddressIn(). DenAbschluss eines Speicherzugriffs meldet die Nachfolgekomponente uber die Funktion ReadyIn().Diesen Funktionen wird stets die den Speicherzugriff spezifizierende Datenstruktur MemoryTaceubergeben, die folgende Informationen enthalt:

• Zugriffsadresse

• Lesender/schreibender Zugriff

• Bitbreite des Zugriffs (Byte (8 Bit), Halbwort (16 Bit), Wort (32 Bit))

• Opcode Fetch-Flag (true beim Laden einer Instruktion)

Des Weiteren verfugt jede Komponente uber einen internen Zustandsautomaten, der das Ver-halten der Komponente definiert. Ein Beispiel einer MEMSIM-Konfiguration wird in Abb. 2.4dargestellt.

MEMSIM verfugt uber folgende Komponenten zur Modellierung einer Hardwarearchitektur:

• CPU: Jede MEMSIM-Konfiguration enthalt genau eine CPU, da MEMSIM nur Ein-Prozessor-Systeme unterstutzt. Die CPU-Komponente verarbeitet wahrend der Simulationdie Instruktionen und Speicherzugriffe des ARMulator-Tracefiles. Im Fall eines Speicher-zugriffs wird dieser an den direkten Nachfolger delegiert, woraufhin die CPU solange imIdle-Zustand verbleibt, bis der Zugriff abgeschlossen ist. Erst daraufhin erfolgt die Verar-beitung der nachsten Instruktion bzw. des nachsten Speicherzugriffs. Da MEMSIM primarals Speicherhierarchie-Simulator entwickelt wurde, werden keine Daten zum Energiever-brauch des Prozessors erhoben.

2.4 MEMSIM 13

CPU

Hub

L1 D-Cache

Hub

L2 D-Cache

Hub

MainMemory

Hub

Scratch-pad

Memory

Abbildung 2.4: Beispiel einer MEMSIM-Konfiguration

• Cache: Die Implementierung der Caches gliedert sich in die Cache-Interface-Komponente,den Cache, die Cache Sets und die zugehorigen Cache-Zeilen. In den letzten 3 Teilkompo-nenten wird das Cache-Verhalten und die Speicherung der Tag-Bits implementiert, wohin-gegen das Cache-Interface die Anbindung an die Speicherhierarchie ubernimmt. So wirdz.B. im Fall eines Cache-Misses das Laden der Cache-Zeile vom Cache-Interface durch-gefuhrt. Wahrend der Simulation werden keine realen Daten, sondern nur die jeweiligenTags in den Caches gespeichert. Caches sind in MEMSIM grundsatzlich latenzlos, sodassein Zugriff innerhalb eines Taktes abgeschlossen werden kann.

• Memory: Zur Modellierung des Hauptspeichers oder anderer Speicher, wie z.B. Scratch-pads, existiert die Memory-Komponente. Da Zugriffszeiten und Zugriffsenergien inharentvom Typ des Zugriffs abhangen, ermoglicht diese Komponente die Spezifikation von La-tenzen in Abhangigkeit von einem lesenden/schreibenden Zugriff und der Bitbreite desZugriffs. Auch in dieser Komponente werden wahrend der Simulation keine realen Datengespeichert.

• Hubs: Hub-Komponenten werden in MEMSIM zur Modellierung von Bussen, als Adress-Dekoder bzw. Router und zur Komplexitatsreduktion der Komponentenschnittstellen ein-gesetzt. Im 1. Fall, der Modellierung von Bussen, konnen z.B. lange physikalische Leitungenvom Prozessor zu einem Off-Chip-Speicher abgebildet werden. Der Hub als Adress-Dekoderbzw. Router dient z.B. bei einem Zugriff auf einen Scratchpadspeicher als Router und leitetso, abhangig von der Adresse, den Zugriff an die entsprechende Komponente weiter. DerEinsatz von Hubs vereinfacht aber auch die Komponentenschnittstellen, da ein Routingnur in den Hub-Komponenten erfolgt und alle anderen Komponenten ausschließlich miteinem direkten Nachfolger bzw. Vorganger kommunizieren. Es existieren 2 Hub-Typen.Der einfachste Hub-Typ verbindet einen Vorganger mit einem Nachfolger und modelliertsomit eine physikalische Leitung, der Hub12 dient als Adress-Dekoder bzw. Router. In deraktuellen MEMSIM-Version existiert jedoch keine Moglichkeit, die ohmschen Verluste derphysikalischen Leitungen und damit den Energieverbrauch eines Hubs zu parametrisieren.

14 2 Grundlagen

Daher bringt der Einsatz eines gewohnlichen Hubs, der Eingang und Ausgang miteinanderverbindet, nur symbolische Vorteile mit sich.

2.4.3 Simulationssemantik

Zur Simulation paralleler Hardware verwendet MEMSIM eine globale Uhr, die mit jedem Taktdiesen an alle Komponenten der Simulation propagiert. Die Ausfuhrung der Simulation erfolgt,wie in Abb. 2.5 dargestellt, in jedem Takt in 2 Schritten:

1. Alle aktiven Komponenten werden identifiziert. Aktive Komponenten sind diejenigen, diezum Zeitpunkt t der Auswertung eine Aktion durchfuhren, z.B. einen internen Speicher-zugriff oder eine Anfrage an eine Nachfolgekomponente, und damit ggf. ihren Zustandandern.

2. Alle aktiven Komponenten werden aktiviert, d.h. alle vorgesehenen Aktionen bzw. Zu-standsanderungen werden durchgefuhrt.

Diese 2 Schritte werden solange wiederholt, bis die Menge der aktiven Komponenten leerist und somit keine Aktion oder Zustandsanderung zum Zeitpunkt t + ∆t (mit infinitesimalkleinem ∆t) mehr stattfindet. Anschließend wird der nachste Takt der Globaluhr propagiert.Diese Simulationssemantik erlaubt somit mehrere zeitlich versetzte Operationen innerhalb einesTaktzyklus, ahnlich dem δ-Zyklen-Konzept in VHDL [HPH+00] oder SystemC [Ins06].

Die Simulation gilt als beendet, wenn die CPU auf keinen Speicherzugriff wartet und alleInstruktionen des ARMulator-Tracefiles ausgefuhrt wurden.

Start der Simulation

Nächster Taktt = t+1

1.: Identifikation aktiver

Komponenten

2.: Aktivierung aktiver

Komponenten

Ende der Simulation

Test auf aktiveKomponenten zum

Zeitpunkt t+∆t

Keine aktivenKomponenten

Programmendeerreicht

Abbildung 2.5: MEMSIM-Simulationssemantik

2.4.4 Konfigurierbarkeit

Nach der Vorstellung der MEMSIM-Komponenten wird im Folgenden ein Uberblick uber derenvariable und unveranderliche Konfigurationsparameter gegeben:

2.4 MEMSIM 15

Cache

• Split- oder Unified-Cache: Instruktions-, Daten- oder Unified-Cache

• Cache-Große in Byte

• Blockgroße in Worten (mit Wortgroße von 4 Byte)

• Assoziativitat

• Load Entire Line: Diese Option legt fest, ob beim Laden einer Cache-Zeile zunachst dievollstandige Zeile geladen und anschließend das angeforderte Datum zuruckgegeben wirdoder ob zuerst das geforderte Datum geladen und zuruckgegeben und anschließend derRest der Zeile geladen wird.

• Strategie bei einem Write Miss: allocate on write miss oder no allocate on write miss

• Ersetzungsstrategie: LRU, Round Robin und zufallsbasierte Ersetzungsstrategie; keine imFall eines Direct Mapped Cache

• Schreibstrategie: Write Through wird als fixe Schreibstrategie angenommen, jedoch nichtdurch das Cache-Interface aktiv umgesetzt. D.h. in der nachsten Stufe der Speicherhierar-chie erfolgen diesbezuglich keine messbaren Zugriffe.

• Latenz/Wait States: Es wird stets eine Latenz von 0 angenommen.

• Zugriffsenergie: Die Energie pro Zugriff wird einer Konfigurationsdatei entnommen (siehe2.4.6).

Memory

• Latenz/Wait States: In Abhangigkeit eines lesenden/schreibenden Zugriffs und der Bit-breite des Zugriffs konnen Latenzen konfiguriert werden.

• Zugriffsenergie: Die Energie pro Zugriff ist abhangig vom Zugriffstyp (lesend/schreibend)und der Bitbreite des Zugriffs fix festgelegt und entstammt einer Messung an einem realenSRAM-Baustein eines ARM7 Evalutation Boards (siehe 2.4.6).

Hub12

• Speicherbereiche: Fur jeden der 2 Ausgange sind Speicherbereiche definierbar, fur die derHub eine eingehende Speicheranfrage weiterleitet. Diese Speicherbereiche setzen sich auseiner Anfangs- und Endadresse zusammen.

Zur Konfiguration einer MEMSIM-Speicherhierarchie existiert das grafisches Konfigurations-progamm Visual MEMSIM, das am Lehrstuhl entwickelt wurde. Das konfigurierte System wirddabei in einer XML-Datei gespeichert und dient MEMSIM als Eingabe.

2.4.5 Simulationsstatistik

Als Ausgabe erzeugt MEMSIM sowohl komponentenspezifische als auch globale Statistiken,deren Inhalt der folgenden Ubersicht entnommen werden kann.

Globale Statistik

• Taktzyklen (Ausfuhrungszeit)

16 2 Grundlagen

Cache (aufgeschlusselt nach lesendem/schreibendem Zugriff)

• Gesamtzahl der Zugriffe

• Anzahl der Cache-Hits und Cache-Misses

• Cache-Performance (Relativer Anteil der Hits an allen Zugriffen)

• Energieverbrauch [µJ]

Memory (aufgeschlusselt nach lesendem/schreibendem Zugriff und Bitbreite des Zugriffs)

• Anzahl der Zugriffe

• Energieverbrauch fur einen Zugriff [nJ] bzw. alle ausgefuhrten Zugriffe [µJ]

• Gesamtenergieverbrauch [µJ]

2.4.6 Energiemodell

Die Messung des Energieverbrauchs der Speicherhierarchie erfolgt lokal in den MEMSIM-Kom-ponenten. Fur die Caches existiert genau ein Energiewert, der bei einem Zugriff auf den Cache aufden lokalen Energiezahler addiert wird. Dieser Energiewert entstammt einer Konfigurationsdatei,die mit Hilfe von CACTI [TTJ06], einem Programm, das unter Verwendung eines analytischenModells fur SRAM-Speicherbausteine Zeit- und Energieparameter fur eine SRAM-Konfigurationberechnet, generiert wurde.

Die Memory-Komponenten verwenden Energiewerte, aufgeschlusselt nach lesendem/schrei-bendem Zugriff und der zugehorigen Bitbreite, die im Fall eines Speicherzugriffs auf den ent-sprechenden Energiezahler addiert werden. Diese Energiewerte entstammen einer Messung aneinem realen SRAM-Baustein eines ARM7 Evalutation Boards:

Bitbreite Energie [nJ]

Lesender ZugriffByte 15,48Halbwort 24,00Wort 49,32

Schreibender ZugriffByte 149,8Halbwort 29,88Wort 41,10

Tabelle 2.1: Zugriffsenergien der Memory-Komponente

Fur CPUs und Hubs existieren aufgrund der Fokussierung auf die Analyse der Speicherhier-archie keine Energiemodelle.

2.5 MPARM

MPARM (Multiprozessor ARM) wurde am Micrel Lab der Universitat Bologna aufgrund dessteigenden Einsatzes von sog. Multi-Prozessor Systems-on-Chip (MP-SoC), die Prozessoren,Speicher, I/O-Gerate und weitere funktionale Einheiten auf einem Die integrieren und großenEinsatz z.B. in Multimedia-Anwendungen mit einem hohen Anteil an parallelen Berechnun-gen finden, als zyklengenauer Multi-Prozessor Simulator entwickelt [LPB04] [BBB+05]. Dabeistellt MPARM verschiedene Prozessor-, Speicher- und Busmodelle auf Basis von SystemC 2.0.1

2.5 MPARM 17

[Ins06] bereit und ermoglicht so, abhangig von der Anwendungsdomane, verschiedene Hardware-/Software-Kombinationen bzgl. des Energieverbrauchs, der Ausfuhrungszeit und weiterer Kenn-großen des System zu evaluieren. Bei der Verwendung von ARM7-Prozessoren konnen Bench-marks, geschrieben in C oder Assembler, nachdem sie mit Hilfe des arm-gcc Cross-Compilers(Version 3.2.2+) kompiliert wurden, mit oder ohne Betriebssystemumgebung in einem Ein- oderMehrprozessorsystem auf Grundlage der interpretativen Simulation ausgefuhrt werden. RTEMS[RTH] (Real-Time Executive for Multiprocessor Systems), ein flexibles Betriebssystem fur einge-bettete Systeme mit Unterstutzung von homogenen und heterogenen Multiprozessor-Systemen,und eine reduzierte Version von uCLinux [UCH] wurden dazu auf MPARM portiert. DieserDiplomarbeit liegt eine aktuelle Version des Simulators von Marz 2008 zugrunde.

2.5.1 Struktur der Simulationsplattform

Die grundlegende Struktur der MPARM-Simulationsplattform besteht aus einem oder mehrerenProzessoren, privaten, d.h. den Prozessoren exklusiv zugeordneten, und gemeinsamen Speichern,einem Interruptcontroller, einem Semaphorencontroller und einem Bussystem, das alle Kompo-nenten miteinander verbindet. Eine schematische Darstellung der haufig verwendeten, auf ARM7Prozessoren basierenden, Plattform wird in Abb. 2.6 dargestellt.

. . . GemeinsamerSpeicher

Semaphoren-controller

PrivaterSpeicher

PrivaterSpeicher

PrivaterSpeicher

ARM7Prozessor

ARM7Prozessor

ARM7Prozessor. . . Interrupt-

controller

Bussystem (AMBA AHB / AXI oder ST-Bus)

Abbildung 2.6: Struktur einer ARM7-basierten MPARM-Simulationsplattform

Es stehen Instruktionssatzsimulatoren fur die Prozessoren ARM7TDMI, StrongARM, Po-werPC 750 und MIPS R3000 und eine Unterstutzung fur LISATek-Modelle zur Verfugung, sodassMPARM sowohl homogene als auch heterogene Multiprozessor-Systeme ermoglicht [MPH]. AlsVerbindungsmedium konnen sowohl die von ARM Ltd. spezifizierten Bussysteme AMBA AHB(Advanced High Performance Bus) [ARM99] und AMBA AXI (Advanced eXtensible Interface)[ARM03a] als auch der von ST Microelectronics entwickelte proprietare ST-Bus verwendet wer-den. Sowohl der Semaphoren- als auch der Interruptcontroller dient der Synchronisierung derProzessoren, wobei der Semaphorencontroller eine test-and-set Operation bereitstellt und derInterruptcontroller das Senden von Interrupts an andere Prozessoren ermoglicht. Die Registerdieser beiden Controller werden in den globalen Adressraum des SoC abgebildet.

Der Fokus soll im Folgenden auf dem ARM7TDMI-Prozessor, der in Form des in C++geschriebenen Instruktionssatzsimulators SWARM (Software ARM) [Dal00] vorliegt und furden Einsatz in MPARM geringfugig modifiziert wurde, und dem AMBA AHB Bussystem unterVerwendung der AMBA AHB-Interface-Implementierung liegen, da diese im Rahmen dieserDiplomarbeit zum Einsatz kommen. In den folgenden Abschnitten werden diese Komponentennaher erlautert, da das Verstandnis der Funktionsweise relevant fur die in Kapitel 3 beschriebeneIntegration von MEMSIM ist.

18 2 Grundlagen

2.5.2 AMBA AHB Bussystem

Das AMBA AHB Bussystem wurde von ARM Ltd. mit dem Ziel entwickelt, den Designprozesseingebetteter Mikrocontroller unter Verwendung einer oder mehrerer RISC- oder Signalprozes-soren (DSPs) in einem Plattform-basierten Ansatz zu vereinfachen. Des Weiteren wird durchdie Ermoglichung eines modularen System-Designs die Wiederverwendbarkeit von IP-Cores (In-tellectual Property), d.h. Komponenten, die der AMBA AHB-Spezifikation genugen und einespezielle Funktionalitat bereitstellen, angestrebt. Ebenso soll mit dieser Vorgehensweise die Mi-nimierung der benotigten Chipflache einhergehen, was wiederum Kosten in der spateren Pro-duktion des mikroelektonischen Systems einspart [ARM99].

MPARM stellt mehrere SystemC-Implementierungsvarianten des in [ARM99] spezifizier-ten AMBA AHB Bussystems bereit. In dieser Diplomarbeit wird die AMBA AHB Interface-Implementierung verwendet, da sie im Gegensatz zu anderen Implementierungen ein Energie-modell des Busses beinhaltet und somit einen großen Vorteil bei der Analyse des Gesamtsystemsbietet. Um die wichtigsten Eigenschaften und Funktionsweisen dieses Bussystems zu verstehen,werden diese im Folgenden kurz erlautert. Ein typisches AMBA AHB-System enthalt folgendeKomponenten:

• AHB Master: Nur ein Bus-Master kann eine Lese- oder Schreiboperation auf dem Businitiieren und damit aktiv den Bus ansteuern. Die AMBA AHB-Spezifikation sieht einemaximale Anzahl von 16 Bus-Mastern vor.

• AHB Slave: Ein Bus-Slave antwortet auf eine Lese- oder Schreibanfrage eines Bus-Masters innerhalb seines am Bus spezifizierten Adressbereichs.

• AHB Arbiter: Der Arbiter gewahrleistet, dass zum Zeitpunkt t nur ein Bus-Master denBus aktiv fur eine Ubertragung verwendet. Die Arbitrierungsstrategie ist nicht festgelegtund kann je nach Anwendungsdomane implementiert werden. Die vorliegende Version vonMPARM verwendet Round Robin als Arbitrierungsstrategie (den Mastern wird der Reihenach der Buszugriff gewahrt).

• AHB Decoder: Der AHB Decoder dekodiert auf Basis der durch den Master angelegtenAdresse den selektierten Slave und treibt so das Select-Signal des ausgewahlten Slaves. Eineinzelner zentralisierter Decoder ist in allen AMBA AHB-Implementierungen erforderlich.

Nach der Definition der AMBA AHB-Komponenten kann nun eine Zuordnung der grund-legenden Struktur der MPARM-Simulationsplattform zur speziellen Form des AMBA AHB-Systems erfolgen. Dabei werden die ARM7-Prozessoren als einzige Bus-Master verwendet. DerVollstandigkeit halber sei erwahnt, dass ein weiterer Typ eines Bus-Masters, der DMA-Master,der eine Anbindung an Off-Chip-Speicher ermoglicht, existiert, dieser aber im Folgenden nichtweiter betrachtet werden soll. Die in Abb. 2.6 dargestellten privaten und gemeinsamen Speicher,Semaphoren- und Interruptcontroller werden im AMBA AHB-System als Slave integriert, wobeijedem Prozessor genau ein privater Slave zugeordnet ist. Neben diesen existiert zusatzlich einProzessor-assoziierter Slave, der Zugriff auf den Scratchpad des Prozessors hat, und ein Slave, dersich aus einem Scratchpad und einer DMA-Einheit zusammensetzt. Diese werden im Folgendenebenso von der Betrachtung ausgeschlossen.

Das AMBA AHB Bussystem, siehe Abb. 2.7, ist eine Multiplexer-basierte Schaltung, inder die Auswertung der Signale stets mit einer steigenden Taktflanke erfolgt. Ein Taktzy-klus definiert sich somit uber den zeitlichen Abstand zweier steigender Taktflanken. Bei ei-nem Ubertragungswunsch legt jeder AMBA AHB Master die Adresse und weitere Kontrollsi-gnale (Lese-/Schreibzugriff, Bitbreite der Ubertragung, Burst) am Bus an, woraufhin der Ar-biter auf Basis der Arbitrierungsstrategie einem Master den Bus zuweist. Jede Ubertragung

2.5 MPARM 19

Abbildung 2.7: Multiplexer-basierter AMBA AHB Bus

besteht dabei aus (a) einem Adress- und Kontrollzyklus und (b) einem oder mehreren Da-tenubertragungszyklen (siehe Abb. 2.8). Die Besonderheit des AMBA AHB Busses liegt in sei-nem Pipelineverhalten. Dabei uberlagern sich die Adressphase der aktuellen und die Datenphaseder letzten Ubertragung, wodurch die Performance deutlich gesteigert werden kann.

Abbildung 2.8: Transaktion am AMBA AHB Bus

In Phase (a), die eine Dauer von einem Zyklus hat, ubertragt der Master, wie bereits erlauert,die Adresse und weitere Kontrollinformationen an den Slave. Dieser schließt in Phase (b), dieeine Dauer von einem Zyklus zuzuglich der Latenz des Slaves hat, die Transaktion mit dem

20 2 Grundlagen

gesetzten HREADY-Signal (’1’) ab. Im Fall eines lesenden Zugriffs wird mit der positivenTaktflanke zusatzlich das gelesene Datum HRDATA an den Master ubertragen. Liegt hin-gegen ein schreibender Zugriff vor, so kann das zu schreibende Datum HWDATA mit dersteigenden Taktflanke vom Slave als valide betrachtet und somit verarbeitet werden. Insgesamtdauert eine Ubertragung uber den AMBA AHB Bus, unter Annahme eines latenzlosen Slaves,3 Taktzyklen, wobei jeweils ein Taktzyklus auf die Arbitrierung, die Adress- und Kontrollpha-se (a) und die Datenubertragungsphase (b) entfallt. Weitergehende Informationen zur AMBAAHB-Spezifikation konnen [ARM99] entnommen werden.

Die SystemC-Implementierung des AMBA AHB Busses unterstutzt nicht alle, aber den-noch einige der wichtigsten Funktionen, die fur dieses Bussystem spezifiziert wurden. Zumeinen werden inkrementierende Burst-Ubertragungen (Ubertragung mehrerer Datenpakete ei-ner festen Bitbreite uber mehrere Zyklen und fortlaufende Adressen) der Lange 1 (normaleDatenubertragung), 4, 8 und 16, zum anderen aber auch Split-Transaktionen, in denen Slavesmit großer Latenz das HSPLIT-Signal setzen konnen, um den Bus fur wartende Master frei-zugeben, ermoglicht. Ebenso kann die Ubergabe des Busses an einen anderen Master innerhalbeines Zyklus durchgefuhrt werden.

2.5.3 SWARM

SWARM (Software ARM) [Dal00] stellt den in dieser Diplomarbeit eingesetzten Instruktions-satzsimulator fur einen ARM7TDMI- Prozessor, implementiert in C++, dar. Dieser ermoglichtdie Simulation von ARM-Instruktionen, der Thumb-Befehlssatz wird nicht unterstutzt. Zur Ver-wendung in MPARM wurde SWARM leicht modifiziert und ein SystemC-Wrapper hinzugefugt,der SWARM mit der SystemC-Umgebung verbindet und synchronisiert. Durch die Erweite-rung von MPARM um MEMSIM (siehe Kapitel 3), wird auch die Integration von MEMSIM inSWARM erforderlich. Daher werden im Folgenden die wichtigsten Grundlagen, d.h. die interneStruktur und der Zustandsautomat des SWARM-Instruktionssatzsimulators vorgestellt.

ARM7-Prozessor

(CArmCore)

Lokaler Bus

Interrupt-controller

Timer

UART- Controller

SystemC - Wrapper

CArmProc

I/D/U-Caches

SPMs

AMBA AHBMaster AMBA AHB Bus

MMU

PINOUT

Abbildung 2.9: Struktur der SWARM/MPARM-Synchronisation

Die wesentliche Struktur des Instruktionssatzsimulators gliedert sich in folgende C++ - Klas-sen:

• CArmProc: Diese Klasse bildet die Schnittstelle zwischen SystemC-Wrapper und dem Pro-zessorkern CArmCore. Die Synchronisation von SystemC-Wrapper und CArmProc erfolgtuber den Aufruf der Cycle()-Funktion, die einen weiteren Simulationszyklus des CArmProcveranlasst. CArmProc und CArmCore werden durch das gleiche Prinzip synchronisiert, wo-bei durch CArmProc ein weiterer Simulationszyklus des CArmCore ausgelost wird. Des

2.5 MPARM 21

Weiteren werden Caches, Scratchpads und weitere funktionale Einheiten wie ein UART-,LCD- oder Interrupt-Controller und ein Timer in dieser Klasse zusammengefuhrt. Dabeiermoglicht CArmProc die Nutzung zweier verschiedener Scratchpads, eines sog. Instrukti-onsscratchpads und eines gewohnlichen Scratchpads, in unterschiedlichen Adressbereichen.Die Kommunikation des Prozessorkerns mit den einzelnen Komponenten erfolgt uber denProzessor-lokalen Bus, der Zugriff auf den AMBA AHB Bus und damit die Kommuni-kation mit dem SystemC-Simulationssystem uber den SystemC-Wrapper, dem bei einemZugriff alle relevanten Steuerdaten uber die gemeinsame Datenstruktur PINOUT ubergebenwerden. Uber diese Datenstruktur konnen im Wesentlichen die Adresse, der Zugriffstyp(lesend/schreibend), die zu schreibenden Daten (bei einem schreibenden Zugriff), die Bit-breite des Zugriffs und die Burstlange (ein Burst der Lange 1 ist dabei eine normaleUbertragung, Bursts der Lange 4, 8 und 16 sind moglich) spezifiziert werden. Bei einemZugriff auf den AMBA AHB Bus wird die Cycle()-Funktion des CArmProc solange durchden Wrapper nicht aufgerufen, bis die Transaktion abgeschlossen ist. Durch diesen Mecha-nismus wird die funktionale Synchronisation der einzelnen Komponenten sichergestellt. Dajeder Prozessor, wie in 2.5.4 naher erlautert wird, uber eine eigene logische Sicht auf denAdressraum verfugt, findet bei jedem Speicherzugriff eine Umrechnung einer logischen aufeine physikalische Adresse des Gesamtsystems statt. Dieser Sachverhalt wird durch diedem Prozessorkern angeschlossene MMU ausgedruckt.

• CArmCore: Diese Klasse stellt den eigentlichen Prozessorkern dar und bildet die Pipelineund den Datenpfad eines ARM7TDMI-Prozessors so exakt wie moglich ab. Ein weitererAusfuhrungszyklus wird durch den Aufruf der Cycle()-Funktion initiiert. Des Weiterenermoglicht CArmCore uber einen Software Interrupt-Mechanismus (SWI) die Ausfuhrungzusatzlicher Funktionen, wie z.B. das Starten oder Stoppen der Statistikerhebung fureinen ausgefuhrten Benchmark oder die Ausgabe von Debug-Informationen. Uber dashochstwertigste Bit des 24 Bit SWI-Aufrufs wird dabei determiniert, ob es sich um einengewohnlichen ARM7 oder einen speziellen SWI handelt. Ist dieses Bit 0, so wird der SWIwie bei einem realen ARM7-Prozessor behandelt, im Fall einer 1 wird der SWI als no-opinterpretiert und zur selben Zeit eine SWARM-Funktion ausgefuhrt.

Die komplette Struktur der MPARM/SWARM-Synchronisation wird in Abb. 2.9 dargestellt.Die Abbildung zeigt, wie der Signalfluss vom C++ - Prozessorkern uber den SystemC-Wrapperbis hin zum AMBA AHB Bus verlauft. Zur Anbindung an den Bus kommt ein weiteres SystemC-Modul, der AMBA AHB Master, zum Einsatz der mit dem SystemC-Wrapper uber SystemC-Signale kommuniziert.

Der interne Zustandsautomat des CArmProc (siehe Abb. 2.10), der mit jedem Aufruf derCycle()-Funktion aktiviert wird, definiert 6 Zustande zur Realisierung der Kommunikation mitden Prozessor-lokalen Komponenten und dem SystemC-Wrapper und damit auch dem AMBAAHB Bus:

• P NORMAL: In diesem Zustand finden nur lesende Zugriffe statt. Wird die durch CArmCoreangeforderte Adresse durch Caches abgedeckt und liegt ein Cache-Hit vor, oder findet einZugriff auf ein Scratchpad statt, so wird das angeforderte Datum gelesen und im selbenZyklus durch CArmCore verarbeitet. Der Folgezustand ergibt sich aus der nachsten Anfragedes CArmCore. Liegt ein lesender Zugriff auf ein Scratchpad oder einen durch Caches ab-gedeckten Adressbereich vor, so wird im aktuellen Zustand verblieben. Bei einem Zugriffauf den UART-, LCD-, Interrupt-Controller oder den Timer findet ein Zustandswechselnach P INTWRITE statt. Im Fall eines Zugriffs auf einen anderen Adressbereich wirdim lesenden Fall in den Zustand P READING1, im schreibenden Fall in den ZustandP WRITING1 gewechselt. Liegt ein Cache-Miss vor, so findet ein Zugriff auf den Bus

22 2 Grundlagen

P_NORMAL

P_READING

P_READING1 P_WRITING1

P_INTWRITE

P_WRINTING_DIRTY_LINE

Laden derder Cache-Zeile

Write Back

SchreibenderZugriff auf

UART-, LCD-,Interrupt-Controller,

Timer

Schreibender Speicherzugriff

Read Miss /Lesender Speicherzugriffauf nicht Prozessor-lokale

Speicher

Abbildung 2.10: SWARM-Zustandsautomat

unter Zuhilfenahme des Wrappers statt. Je nach Schreibstrategie des Caches wird bei ei-ner Write Back-Strategie im Fall eines gesetzten Dirty-Bits die zugehorige Cache-Zeile imZustand P WRITE DIRTY LINE zuruckgeschrieben, im Fall eines nicht gesetzten Dirty-Bits oder einer Write Through-Strategie wird der Zustand P READING1 angenommen,in dem das Laden der Cache-Zeile initiiert wird.

• P READING1 : In diesem Zustand wird bei einem lesenden Zugriff auf eine Adresse, diedurch Caches abgedeckt wird, das Laden der Cache-Zeile durch die Anforderung des erstenWortes auf dem Bus initiiert und anschließend in den Zustand P READING gewechselt.Andernfalls wird der vorliegende Speicherzugriff an den Bus delegiert und ein Zustands-wechsel nach P NORMAL vollzogen.

• P READING : Die verbleibenden Worter der Cache-Zeile werden in diesem Zustand ge-laden. Ist dieser Vorgang abgeschlossen, so wird der Zustand P NORMAL angenommenund das ursprunglich angeforderte Datum aus dem Cache ausgelesen. Dieser Zugriff wirdin MPARM falschlicher Weise als Read Hit registriert.

• P WRITING1 : In diesem Zustand finden nur schreibende Zugriffe statt. Erfolgt ein schrei-bender Zugriff auf ein Scratchpad oder den Cache (mit einem Write Hit), so wird dieseOperation unmittelbar ausgefuhrt. Bei einem Write Miss oder einer nicht durch Cachesabgedeckten Zugriffsadresse findet ein Zugriff auf den Bus statt. Ist der nachste Speicher-zugriff des Prozessorkerns ein schreibender Zugriff, so wird in diesem Zustand verblieben,andernfalls wird ein Zustandswechsel nach P NORMAL vollzogen.

• P WRITING DIRTY LINE : Im Fall eines Cache-Misses mit Schreibstrategie Write Backund gesetzten Dirty-Bit wird in diesem Zustand die zugehorige Cache-Zeile uber den Buszuruckgeschrieben. Nach Abschluss der Transaktion stellt sich der Zustand P NORMALein, in dem das Laden der Cache-Zeile ausgelost wird. Dabei wird durch erneuten Zugriffauf den Cache falschlicher Weise ein erneuter Read Miss registriert.

• P INTWRITE : Ein interner Schreibzugriff auf den UART-, LCD-, Interrupt-Controlleroder den Timer findet in diesem Zustand statt und wird mit einem Zustandswechsel nachP NORMAL abgeschlossen.

2.5 MPARM 23

2.5.4 Physikalischer und logischer Adressraum

Jeder Teilnehmer des AMBA AHB Busses wird in den globalen Adressraum des SoC abgebildetund erhalt somit eine eindeutige physikalische Adresse. Da jedem ARM-Prozessor des Systemsprivate Slaves zugeordnet werden und ebenso der Einsatz von Scratchpads innerhalb des Prozes-sorkerns moglich ist, verfugt jeder Prozessor, d.h. AHB Master, uber eine eigene logische Sichtauf den Adressraum des SoC. Dieser Sachverhalt erfordert auf Prozessorseite die Umrechnungeiner logischen in eine globale, physikalische Adresse. Der Zusammenhang zwischen logischenund physikalischen Adressen wird in Abb. 2.11 verdeutlicht. In Zuge der Integration von MEM-SIM wird es moglich sein, die starre Struktur des Adressraums aufzulosen und so z.B. jedemprivaten Speicher eine individuelle Große zuzuweisen.

Privater SpeicherARM 0

0x00000000

Privater SpeicherARM i

. . .

Globaler Adressraum

0x01000000*i

GemeinsamerSpeicher 0

GemeinsamerSpeicher j

0x19000000 +0x0010000*j

0x19000000

Semaphoren-speicher

Interrupt-Slave

Logischer Adressraum ARM 0

0x00000000

Privater Speicher

IScratchpad0x00c00000

12 MB

4 MB

GemeinsamerSpeicher 0

GemeinsamerSpeicher j

0x19000000+ 0x0010000*j

0x19000000

0x20000000

1 MB

0x21000000

16 kB

336 B

Semaphoren-speicher

Interrupt-Slave

0x20000000

0x21000000

Scratchpad0x22000000

Interne Devices0x90000000

128 kB

. . . . . .

Abbildung 2.11: Physikalischer und logischer Adressraum

2.5.5 Konfigurierbarkeit

In der vorliegenden Version des MPARM System-on-Chip Simulators ergeben sich unter Ver-wendung des AMBA AHB Busses, des SWARM-Instruktionssatzsimulators und unter den be-reits genannten Einschrankungen auf spezielle Bus-Master und -Slaves folgende Konfigurati-onsmoglichkeiten:

• Anzahl verwendeter Prozessoren

• Anzahl gemeinsamer Slaves

24 2 Grundlagen

• Verwendung von Scratchpads und die zugehorige Große

• Cache-Parameter: Split- oder Unified-Caches (Instruktions-, Daten- oder Unified-Cache),Assoziativitat (Direct Mapped, Vollassoziativ, n-Weg assoziativ (2 ≤ n ≤ 32), Cache-Große bei einer fixen Zeilen-Große von 4 Worten (maximal 16 kB), Schreibstrategie (WriteBack, Write Through); Strategie bei einem Write Miss: no allocate on write miss (un-veranderlich)

• Latenz/Wait States der privaten und gemeinsamen Speicher

Es muss jedoch beachtet werden, dass die Konfiguration eines Prozessors bzgl. seiner Cachesund Scratchpads fur alle Prozessoren bzw. die Konfiguration eines Slaves fur alle Slaves gleichenTyps ubernommen werden. Ebenso existiert keine Moglichkeit, mehr als einen Cache-Level zudefinieren. Dies stellt insgesamt eine starke Einschrankung der Konfigurierbarkeit des SoC imAllgemeinen und der Speicherhierarchie im Besonderen dar und motiviert somit die Integrationvon MEMSIM, das eine flexible Konfiguration der Speicherhierarchie ermoglicht.

2.5.6 Simulationsstatistik

Die aus der Simulation resultierende Statistik enthalt unter Verwendung der optional aktivier-baren Energiemessungen im Wesentlichen folgende Daten:

Globale Statistik

• Energieverbrauch des Gesamtsystems [pJ]


CPU

• Buszugriffsstatistiken

• Statistik lokaler Caches

• Energieverbrauch ohne lokale Speicher [pJ]

Cache

• Anzahl der Cache-Hits und Cache-Misses im lesenden und schreibenden Fall

• Anzahl der lesenden und schreibenden Daten-Zugriffe

• Anzahl der lesenden und schreibenden Tag-Zugriffe

• Miss-Rate (Anzahl der Cache-Misses an allen Zugriffen)

• Energieverbrauch [pJ]

Scratchpad


Privater/gemeinsamer Slave

• Anzahl der lesenden und schreibenden Zugriffe


2.6 Optimierungsverfahren 25

AMBA AHB Bus

• Gesamtzahl der Zugriffe

• Zugriffs-/Ubertragungszeiten aufgeschlusselt nach Zugriff (lesend/schreibend, Burst/ein-zelner Zugriff)

• Typischer, minimaler und maximaler Energieverbrauch [pJ]

2.5.7 Energiemodell

Die Erfassung des Energieverbrauchs erfolgt in MPARM fur jede Systemkomponente mit Aus-nahme des Semaphoren- und Interrupt-Slaves.

Fur die ARM7-Prozessoren wird ein zustandsbasiertes Modell verwendet, in dem zwischenden Zustanden POWER IDLE, RUNNING und STALLED unterschieden wird. Ein ARM7-Prozessor kann uber einen Software Interrupt in den Zustand POWER IDLE versetzt werden,in dem dieser eine sehr geringe Leistungsaufnahme aufweist. Wird die interne Pipeline auf-grund einer Instruktions- oder Datenabhangigkeit blockiert oder werden Daten uber den Busubertragen, so befindet sich der Prozessor im Zustand STALLED. In allen anderen Fallen fin-det die Erfassung des Energieverbrauchs auf Basis des Zustands RUNNING statt, fur den einEnergieverbrauch von 55 nJ pro Taktzyklus veranschlagt wird. Fur die Zustande POWER IDLEund STALLED wird ein Energieverbrauch von 5,5 nJ und 36,3 nJ pro Taktzyklus erfasst. DiesesEnergiemodell wurde einer von ST Microelectronics entwickelten Implementierung eines ARM7-Prozessors auf Basis einer 0,13 µm Technologie entnommen.

Fur die Slave-Speicher und Caches wird ein empirisches Modell eingesetzt, das Zugriffs-energien, die mit Hilfe eines von ST Microelectronics entwickelten Programms auf Basis einerWortgroße von 32 Bit und einer Technologiegroße von 0,13 µm ermittelt wurden, interpoliert. DieInterpolation findet dabei auf Energiewerten statt, die auf Basis verschiedener Speichergroßenberechnet wurden. Dabei wird zwischen einem lesenden und schreibenden Zugriff unterschieden[LPB04].

Fur die Caches wird zusatzlich zwischen dem Lesen/Schreiben einer ganzen Cache-Zeile, demLesen/Schreiben eines Tags und dem Schreiben eines Wortes unterschieden, um eine moglichstgenauer Erfassung des Energieverbrauchs zu erreichen.

Das Energiemodell des AMBA AHB Busses basiert auf den Energiewerten aus [BCZZ04] undskaliert proportional mit der Anzahl der an den Bus angeschlossen Master und Slaves [SAR+05].

2.6 Optimierungsverfahren

In diesem Abschnitt werden zunachst lineare und nichtlineare Optimierungsverfahren vorge-stellt. Aus der Nichtlosbarkeit einiger nichtlinearer Probleme wird im Folgenden die VerwendungEvolutionarer Algorithmen, die im Rahmen dieser Diplomarbeit zur Losung komplexer Optimie-rungsprobleme genutzt werden, motiviert. Des Weiteren folgt eine Einfuhrung in die Grundlagenund Grundbegriffe der Evolutionaren Algorithmen, wobei auch Evolutionare Algorithmen zurmehrkriteriellen Optimierung, insbesondere SPEA2 [ZLT01], naher erlautert werden.

2.6.1 Lineare Optimierung

Die lineare Optimierung oder lineare Prorammierung, kurz LP, stellt ein Optimierungsverfahrendar, bei dem eine oder mehrere lineare Zielfunktionen unter gegebenen linearen Nebenbedingun-gen zu maximieren oder zu minimieren sind. Dabei werden meist (nichtnegative) reellwertigeVariablen verwendet. Im Folgenden wird o.B.d.A. nur der Fall einer zu minimierenden Ziel-funktion betrachtet. Die Betrachtung der Minimierung stellt jedoch keine Einschrankung dar,

26 2 Grundlagen

da diese in die duale Form der Maximierung leicht uberfuhrt werden kann. Jedes LP lasst sichdabei wie folgt formulieren:

Minimierung der Zielfunktion

F (x) =n∑

i=1

cixi → min

unter den Nebenbedingungen

n∑i=1

aijxi ≤ bj , 1 ≤ j ≤ m

und zumeist unter Berucksichtigung der Nichtnegativitatsbedingungen:

xi ≥ 0, 1 ≤ i ≤ n

mit ci, bj , aij ∈ R, xi ∈ {R+,Z+,B}

Eine Losung des LPs kann unter Verwendung des Simplex Algorithmus berechnet werden.Im Fall ganzzahliger linearer Optimierungsprobleme ergibt sich xi ∈ Z bzw. bei binaren Ent-scheidungsvariablen sogar xi ∈ {0, 1}. LPs werden in vielen Bereichen, so z.B. im Operations Re-search zur Fertigungsplanung (z.B. Produktionsprogramm- oder Mischungsoptimierung) [DD05]oder im Bereich der technischen Informatik zur Berechnung von Scratchpad-Allokationen zurEnergieoptimierung, siehe z.B. [VWM04], eingesetzt.

2.6.2 Nichtlineare Optimierung

Im Gegensatz zu linearen Optimierungsproblemen ist ein nichtlineares Optimierungsproblemdurch eine nichtlineare Zielfunktion und/oder mindestens eine nichtlineare Nebenbedingung ge-geben, wobei in der Regel (nichtnegative) reellwertige Variablen zum Einsatz kommen. Genauwie bei der linearen Optimierung erfolgt die mathematische Beschreibung unter Annahme ei-nes Minimierungsproblems, das in das duale Maximierungsproblem uberfuhrt werden kann. Einnichtlineares Optimierungsproblem lasst sich wie folgt formulieren:

Minimierung der Zielfunktion

F (x)→ min

unter den Nebenbedingungen

gj(x) ≤ 0, 1 ≤ j ≤ m

und zumeist unter Berucksichtigung der Nichtnegativitatsbedingungen:

xi ≥ 0, 1 ≤ i ≤ n

mit xi ∈ {R+,Z+,B}

wobei die Nebenbedingungen gj die in der linearen Optimierung explizit ausgewiesenen Kon-stanten bj zur Vereinfachung enthalten [DD05].

Nichtlineare Optimierungsprobleme lassen sich in verschiedene Klassen nichtlinearer Proble-me untergliedern, wobei sich einige dieser Problemklassen uber spezielle Losungsverfahren losenlassen, andere wiederum unlosbar sind. [DD05] definiert folgende nichtlineare Problemklassen:


• Unrestringierte Optimierungsprobleme: Optimierungsprobleme ohne Nebenbedin-gungen konnen bei zweimal stetig differenzierbaren Zielfunktionen zum einen analytischgelost werden, zum anderen lassen sich auch numerische Losungsverfahren wie z.B. dieMethode des goldenen Schnitts oder das Gradientenverfahren anwenden.

• Allgemeine restringierte Optimierungsprobleme: In realen Optimierungsproblementreten haufig zu berucksichtigende Nebenbedingungen auf. Eine Losung kann dabei gra-fisch, unter Verwendung der Karush-Kuhn-Tucker-Bedingungen, uber Methoden der zu-lassigen Richtungen oder uber Hilfsfunktionsverfahren ermittelt werden.

• Quadratische Optimierung: Quadratische Optimierungsprobleme unterscheiden sichvon linearen Optimierungsproblemen nur in der Zielfunktion F (x). Diese enthalt nebenlinearen Termen cjxj auch quadratische Terme der Form ciix

2i und/oder cijxixj fur einige

oder alle i 6= j. Maximierungsprobleme mit konkaver bzw. Minimierungsprobleme mitkonvexer Zielfunktion lassen sich z.B. mit dem Algorithmus von Wolfe losen.

• Allgemeine konvexe Optimierungsprobleme: Fur diese Klasse von Optimierungs-problemen kann eine Naherungslosung bei linearen Restriktionen uber die Methode derzulassigen Richtungen bzw. des steilsten Anstiegs und fur nichtlineare Restriktionen uberHilfsfunktionsverfahren bestimmt werden.

• Separable konvexe Optimierung: Bei dieser Form eines nichtlinearen Optimierungs-problems wird neben linearen Nebenbedingungen vorausgesetzt, dass die Zielfunktion keinegemischten Terme hi ·hj mit i 6= j enthalt und somit als Summe von Funktionen fi(xi) mitje einer Variablen xi darstellbar ist. Des Weiteren wird fur die Funktionen fi vorausgesetzt,dass sie im Fall eines Minimierungsproblems konvex und im Fall eines Maximierungspro-blems konkav sind. Durch stuckweise lineare Approximation der Funktionen fi(xi) wirddas nichtlineare Problem in ein Problem mit linearer Zielfunktion uberfuhrt und kann somit Hilfe des Simplex Algorithmus gelost werden.

Eine detaillierte Erlauterung der genannten numerischen Losungsverfahren findet sich in[DD05].

2.6.3 Evolutionare Algorithmen

Ist das zugrunde liegende Optimierungsproblem nichtlinear und kann aufgrund der Form derZielfunktion oder der Nebenbedingungen uber keine der Problemklassen eine Losung gefundenwerden oder liegt die Zielfunktion nicht einmal in geschlossener Form vor, wie es zum Beispielim Fall einer Simulations-gestutzten Optimierung der Fall ist, so ist das Optimierungsproblemmeist nicht uber konventionelle Verfahren losbar [Rud06]. Besonders Evolutionare Algorithmen(EA) bieten in diesem Fall ein adaquates Werkzug zur Losung dieser Probleme.

Dabei basiert das Grundprinzip der Evolutionaren Algorithmen auf dem scheinbar einfachenund leicht nachvollziehbaren Prinzip des Darwinistischen Evolutionsparadigmas. Nach dem Mus-ter der Natur werden dabei durch die Anwendung von Variation (Rekombination, Mutation) undSelektion auf eine Population von Losungsalternativen schrittweise bessere Losungen gefundenund auf diese Weise Optima bestimmt oder zumindest approximiert [BBJ+01]. EvolutionareAlgorithmen stellen damit ein heuristisches, nicht-deterministisches Losungsverfahren mit meisthoher Berechnungseffizienz dar. Bereits in den 50er und 60er Jahren wurde das Potential diesesOptimierungsansatzes fur unterschiedliche Aufgaben erforscht. So entwickelten unabhangig von-einander Holland [Hol62] [Hol75] die Genetischen Algorithmen (GA) als Modell fur Adaptions-und Klassifikationsprozesse und Fogel [Fog62] [FOW66] die Evolutionare Programmierung (EP)zur Zeitreihenvorhersage mittels endlicher Automaten. Rechenberg [Rec65] [Rec71] und Schwefel

28 2 Grundlagen

[Sch68] [Sch75] entwarfen nahezu zeitgleich die Evolutionsstrategien (ES) als Heuristiken fur dieexperimentelle Optimierung [HB98]. In der jungeren Vergangenheit, den 90er Jahren, wurde dieVariante des Genetischen Programmierens (GP) durch Koza [Koz92] erforscht. Reprasentiertendie Genetischen Algorithmen, die Evolutionsstrategien und die Evolutionare Programmierungin den Anfangen der EA-Geschichte zunachst noch disjunkte EA-Klassen, so findet heutzuta-ge zunehmend einer Vermischung dieser Ansatze statt. Daher wurde 1991 der Oberbegriff derEvolutionaren Algorithmen eingefuhrt, wobei dieser neben der allgemeinen Verwendung immerdann eingesetzt werden sollte, wenn die speziellen EA-Varianten nicht zutreffen [BBJ+01].

2.6.3.1 Grundbegriffe

Ein Optimierungsproblem stellt ein Suchproblem auf dem Suchraum X der Parameter des rea-len, zu optimierenden Systems mit dem Ziel der Optimierung einer gegebenen Zielfunktion F (x)mit x ∈ X , die auch mehrkriteriell sein kann, dar. Dieser Suchraum wird auch Phanotypraumgenannt. Evolutionare Algorithmen operieren jedoch auf abstrakten mathematischen Objek-ten wie Zeichenketten oder reellwertigen Vektoren, dem Genotypraum bzw. der ReprasentationR. Daher wird haufig die Definition einer geeigneten Kodierungsfunktion Γ : X → R bzw.einer Dekodierungsfunktion Γ : R → X erforderlich. In vielen Fallen, wie z.B. einer reinenParameteroptimierung, sind X und R identisch, wohingegen dies bei einer kombinatorischenOptimierung nicht der Fall ist. Auf Basis dieser Reprasentation werden die Variationsopera-toren Rekombination und Mutation definiert, die Wahl der Selektion ist dagegen unabhangigvon der Reprasentation formulierbar. Fur jedes Individuum wird auf Basis des FunktionswertesF (x) die Fitness, also die Qualitat des Individuums bestimmt, die wahrend der Evolution zurSelektion verwendet wird. Des Weiteren wird die genetische Information eines Individuums I alsGenotyp von I und der Trager dieser Information auf der Menge R als Chromosom bezeichnet.Eine Menge von Individuen wird als Population P , die Anzahl durchgefuhrter Evolutionszy-klen als Generation g deklariert [HB98]. Nachdem nun die grundlegenden Begriffe EvolutionarerAlgorithmen eingefuhrt und der grundlegende Zusammenhang erlautert wurden, wird im Fol-genden genauer auf die Aspekte der Reprasentation, Mutation, Rekombination und Selektioneingegangen.

2.6.3.2 Reprasentation

[HB98] liefert einen Uberblick uber mogliche Varianten der Reprasentation, wobei zu beruck-sichtigen ist, dass eine Reprasentationsform stets Problem-spezifisch zu wahlen ist.

• Binar-Strings: Genetische Algorithmen verwenden in ihrer ursprunglichen Form binareStrings der Lange l, sodass RB = Rl gilt und jeder Wert (x1, ..., xn) ∈ X durch denString (b1, ..., bl) ∈ RB reprasentiert wird. Diese Reprasentation wurde ursprunglich inGenetischen Algorithmen aufgrund des Schematheorems [Hol75] bevorzugt.

• Reellwertige Reprasentation: Im Fall X ⊆ Rn bietet es sich an, die Elemente ausX als reellwertige Vektoren mit RR ⊆ Rn zu reprasentieren. Dies geschieht im Fall derEvolutionsstrategien und Evolutionaren Programmierung, inzwischen aber auch im FallGenetischer Algorithmen.

• Ganzzahlige Reprasentationen: Fur den Fall X ⊆ Zn konnen die Konstruktionsprin-zipien aus RR auf RZ ⊆ Zn ubertragen werden. Haufig treten auch gemischt-ganzzahligeProbleme auf, sodass eine gemischte Reprasentationen RR ×RZ eingesetzt wird.

• Permutationen: Permutationen werden haufig uber der Menge Z abgebildet. Anwen-dungsfalle sind z.B. Scheduling-Probleme oder die Routenplanung.


• Andere Reprasentationen: Fur strukturbeschreibende Variablen oder geometrische Ob-jekte werden haufig komplexere Reprasentationen, wie Graphen oder Parse-Trees, verwen-det, da ansonsten strukturelle oder raumliche Beziehungen verloren gehen.

Generell existiert kein Rezept fur den Entwurf einer Reprasentation, [HB98] nennt jedocheinige wichtige Punkte, die zu beachten sind:

• Die Dekodierfunktion sollte uber eine moglichst starke Kausalitat verfugen, d.h. kleineAnderungen des Genotyps bewirken kleine Anderungen des Phanotyps.

• Gleich große Regionen des Suchraums X sollten uber gleich viele Reprasentanten in Rverfugen.

• Durch eine geschickte Wahl der Reprasentation lasst sich die Erzeugung ungultiger Indi-viduen (Individuen, fur die sich r ∈ R nicht im Definitionsbereich von Γ befindet, d.h.es existiert zur Reprasentation eines Individuums kein gultiges Element im Suchraum)vermeiden.

• Problemnahe Reprasentationen, die moglichst viel Informationen aus X enthalten, fuhrenin der Regel zu effizienteren Algorithmen und lassen sich leichter erweitern.

2.6.3.3 Rekombination/Crossover

Die Rekombination stellt eine N -stellige richtungslose Operation dar, wobei ein neues Individu-um I ′ = (I ′1, .., I

′l) durch Kombination der genetischen Information von N Eltern I1, ..., IN mit

Ii = (Ii1, ..., I

il ) generiert wird. Meist wird dabei N = 2 gewahlt. Die gebrauchlichsten Varianten

sind laut [HB98]:

• z-Point-Crossover: Aus dem Intervall [1, l − 1] werden z Positionen j1 < j2 < ... < jzgleichverteilt bestimmt, sodass sich I ′ als I1

1 , ..., I1j1, I2

j1+1, ..., I2j2, I1

j2+1, ..., I1jz, I2

jz+1, ..., I2l

darstellt. Das One-Point-Crossover (z = 1) und das Two-Point-Crossover (z=2) sind dabeidie am haufigsten verwendeten Varianten. Bei der Verwendung von Genetischen Algorith-men entstehen bei N = 2 und z = 1 meist 2 neue Individuen I1′ und I2′, wobei die hinterenGen-Teilstrings der Eltern zur Rekombination paarweise vertauscht werden, sodass sich furI1′ die Form I1

1 , ..., I1j1, I2

j1+1, ..., I2l und fur I2′ die Form I2

1 , ..., I2j1, I1

j1+1, ..., I1l ergibt.

• Uniform-Crossover: Unter Verwendung von z = l − 1 werden fur jedes i die I ′i gleich-verteilt aus der Menge der Elternelemente gezogen.

2.6.3.4 Mutation

Die Mutation sorgt fur eine zufallige und richtungslose Modifikation einzelner Gene des Chro-mosoms. Ein Gen stellt dabei eine Untereinheit eines Chromosoms, z.B. ein Objektparameter inder Parameteroptimierung, dar. Bei binarer Reprasentation des Problems wird jedes Ii mit derWahrscheinlichkeit pm mutiert. Fur pm werden dabei in der Regel Werte von pm ∈ [0, 001; 0, 01]verwendet. Empirische Befunde und die Analyse einfacher Beispiele haben jedoch gezeigt, dasspm = 1/l umgekehrt proportional zur Lange l des Binar-Strings oder zeitlich variabel gewahltwerden sollte. Im Falle reellwertiger Reprasentationen wird die Mutation meist als additiv nor-malverteilter Prozess modelliert: I ′i = Ii + N(0, σi) mit Standardabweichung σi (Schrittweite).Die Wahl der Schrittweiten σi hangt sowohl von der Zielfunktion als auch vom Fortschritt derSuche ab und stellt somit ebenso ein Optimierungsproblem dar. Dies wird meist durch die An-passung der Strategievariablen σi wahrend des Evolutionsprozesses realisiert [HB98].

30 2 Grundlagen

2.6.3.5 Selektion

Wahrend die richtungslosen Operatoren Mutation und Rekombination die Entstehung neuergenetischer Informationen bewirken, wird die evolutionare Suche erst durch die Selektion zu ei-nem zielgerichteten Prozess. Dabei wird jedem Individuum Ii ∈ P (g) mit uberdurchschnittlicherGute F (Γ(Ii)) eine uberdurchschnittliche Selektionswahrscheinlichkeit zugewiesen [HB98]. DieSelektion kommt sowohl fur die Bestimmung der Rekombinationspartner als auch fur die Aus-wahl von Individuen zur Bildung einer neuen Generation zum Einsatz. Selektionsverfahren, diestets die besten gefunden Losungen in der Population bewahren, werden elitar genannt. [HB98]erlautert folgende haufig eingesetzte Selektionsverfahren:

• Proportionale Selektion: Jedes Individuum Ii ∈ P (g) wird mit einer der relativenFitness von Ii proportionalen Wahrscheinlichkeit selektiert:

psi =S(F (Γ(Ii)))∑|P (g)|

j=1 S(F (Γ(Ij)))

• (µ,λ)-Selektion: Aus den µ besten der λ Individuen in P (g) wird gleichverteilt gezogen:

psi =

{1/µ, 1 ≤ i ≤ µ0, µ < i ≤ λ

Aus empirischen Befunden und der Analyse einfacher Zielfunktionen wird ein Verhaltnisµ/λ = 1/7 empfohlen.

• Turnier-Selektion: q Individuen werden gleichverteilt zufallig aus der Population P (g)gezogen, wobei das Beste der q Individuen selektiert wird. Dieser Vorgang wird λ-fachwiederholt. Es ergibt sich als Selektionswahrscheinlichkeit:

psi = 1/λq · ((λ− i+ 1)q − (λ− i)q)

2.6.3.6 Restriktionsbehaftete Optimierungsprobleme

Ein restriktionsbehaftetes Optimierungsproblem mit den Restriktionen gi kann unter Annahmeder Minimierung der Zielfunktion F (x) fur X ⊆ R wie folgt allgemein beschrieben werden:

F (x)→ min , x = (x1, ..., xn) ∈ Xgi(x) ≤ 0, i = 1, ..., p

Um die Einhaltung der Restriktionen gi sicherzustellen, wurden fur Evolutionare Algorith-men eine Reihe von Modifikationen vorgeschlagen [HB98]:

• Straffunktion: Die Zielfunktion wird mit einem von der Starke der Restriktionsverletzungabhangigem Strafterm beaufschlagt.

• Dekoder: Durch geschickte Wahl der Reprasentation R und der Dekodierfunktion Γ kannunter Umstanden die Einhaltung der Restriktionen erzwungen werden.

• Restriktionserhaltende Operatoren: Diese Ansatz entspricht dem vorhergehenden,nur werden die Variationsoperatoren so konstruiert, dass aus zulassigen keine unzulassigenLosungen generiert werden konnen.

• Reparaturmechanismen: Auf Genotyp-Ebene werden zusatzliche Operatoren definiert,die unzulassige in zulassige Losungen uberfuhren.


• Co-Evolution: Dieser Ansatz ist durch biologische Vorbilder co-evolvierender Populatio-nen (z.B. Parasiten und Wirte) motiviert. Die erste Population enthalt Individuen aus dergesamten Reprasentation R. Deren Fitness wird gemaß einer Straffunktion ermittelt. Diezweite Population besteht aus den Restriktionen. Deren Fitness wird aus der Anzahl derIndividuen der ersten Population bestimmt, die diese Restriktionen verletzen. Restriktio-nen, die haufiger verletzt werden, erhalten so eine starkere Gewichtung.

2.6.3.7 Evolutionarer Algorithmus

Evolutionare Algorithmen, die auf dem Prinzip der biologischen Evolution grunden, orientierensich an folgendem algorithmischen Iterationsschema, das auch in Abb. 2.12 dargestellt wird:

1. Erzeugen einer initialen Population mit N Individuen

2. Berechnung der Fitness der Individuen

3. Selektion zur Reproduktion

4. Durchfuhren einer Variation (Rekombination, Mutation) zur Erzeugung von Nachkommen

5. Berechnung der Fitness der Individuen

6. Selektion von N Individuen bester Fitness, die die nachste Generation bilden

7. Wenn Konvergenz-/Abbruchkriterium erfullt, dann STOP, sonst fahre mit 3. fort

Initialisierung

Auswertung der Population

Selektion zurReproduktion

Erzeuge Nachkommendurch Variation

(Rekombination, Mutation)

Auswertung der Nachkommen

Selektion der Folgepopulation

EVOLUTION

STOPPAbbruchkriterium erfüllt ?

Abbildung 2.12: Evolutionarer Algorithmus [Rud06]

2.6.3.8 Varianten Evolutionarer Algorithmen

Wie schon in der Einfuhrung dieses Abschitts erwahnt, existieren verschiedene Klassen von Evo-lutionaren Algorithmen, die heutzutage nicht als disjunkt angenommen werden konnen. [Wei99]beschreibt die folgenden Auspragungen Evolutionarer Algorithmen:

• Genetische Algorithmen: Genetische Algorithmen verwenden in der klassischen Formeine binare Reprasentation des Problems, wobei inzwischen viele Genetische Algorithmen

32 2 Grundlagen

auch uber ganzzahlige oder reellwertige Reprasentationen verfugen. Dem Rekombinations-operator wird durch das Schematheorem, welches die starke Verbreitung und Kombinationvorteilhafter Informationen in der Population durch die Rekombination postuliert, beson-ders viel Bedeutung beigemessen, wohingegen dem Mutationsoperator eine eher geringeBedeutung zukommt. Eine Unterklasse der Genetischen Algorithmen stellen die ClassifierSysteme dar, welche unter Verwendung der binaren Reprasentation Regeln zur Klassifika-tion oder Steuerung eines Systems erlernen.

• Evolutionsstrategien: Evolutionsstrategien arbeiten in der Regel auf einer reellwertigenReprasentation des Problems. Die klassische Evolutionsstrategie verwendet lediglich dieMutation, der bzgl. des Fortschritts der Evolution die großte Bedeutung zukommt. DieMutation der Gene erfolgt dabei additiv gemaß einer Normalverteilung, wobei sehr haufigauch selbstadaptive Strategievariablen σi zum Einsatz kommen. Der Rekombination wirdhingegen nur eine geringe Bedeutung beigemessen, wobei diese inzwischen auch in vielenEvolutionsstrategien verwendet wird.

• Evolutionares Programmieren: Die Variante des Evolutionaren Programmierens ar-beitet auf der naturlichen Darstellung des Problems und beschrankt sich nicht auf einebestimmte Reprasentation. Eingesetzt wird diese Variante fur die Entwicklung endlicherAutomaten zur Zeitreihenvorhersage. Charakteristisch fur dieses Verfahren ist das Nicht-vorhandensein des Rekombinationsoperators und die Verwendung einer speziellen Turnier-Selektion zur Erzeugung der nachsten Generation. Ahnlich den Evolutionsstrategien, wur-den auch im Bereich des evolutionaren Programmierens selbstadaptive Streuungen derMutationsparameter entwickelt.

• Genetisches Programmieren: Diese Variante der Evolutionaren Algorithmen wird meistfur die evolutionare Entwicklung von Computerprogrammen eingesetzt und arbeitet daherauf einer dynamischen Reprasentation, wie z.B. auf Baumstrukturen.

2.6.3.9 Mehrkriterielle Optimierung

In praktischen Optimierungsaufgaben werden haufig mehrere Großen Fi(x), x ∈ X mit un-terschiedlicher Zielsetzung optimiert (z.B. minimaler Energieverbrauch bei maximaler Reisege-schwindigkeit). Eine mogliche Losung ist eine Zielfunktion, die sich als gewichtete Summe derTeilziele Fi(x) ergibt, wobei die Gewichtung a-priori subjektiv festgelegt werden muss. Dabeigehen jedoch Informationen uber die Teilziele durch die Summenbildung verloren, sodass derSuchprozess im Fall einer Gewichtungsveranderung neu gestartet werden muss.

Daher wird bei der mehrkriteriellen Optimierung, also einer Optimierung, die verschiedeneTeilziele verfolgt, meist versucht, die sog. Pareto-Menge P zu approximieren. [HB98]. Im Folgen-den wird stets von einer Minimierung aller Teilziele Fi(x) als Ziel der Optimierung ausgegangen.Dies stellt keine Einschrankung dar, da bei einer Maximierung eines Teilziels Fi(x) durch −Fi(x)ersetzt werden kann. Die Pareto-Menge stellt die Menge nicht-dominierter Individuen bzgl. derPareto-Dominanz-Relation ≺p dar.

Dabei dominiert ein Individuum I1 ein Individuum I2 (I1 ≺p I2), wenn fur die zugehorigenElemente x1 ∈ X und x2 ∈ X des Phanotypraums bezuglich der Fitnessfunktion F(x) gilt, dassalle Optimierungsgroßen Fi(x1) kleiner oder gleich Fi(x2) sind und mindestens ein Fj(x1) echtkleiner als Fj(x2) ist:

I1 ≺p I2 ⇐⇒ x1 ≺p x2 ⇐⇒ ∀i : Fi(x1) ≤ Fi(x2) ∧ ∃j : Fj(x1) < Fj(x2)

Damit definiert sich die Pareto-Menge, die Menge nicht-dominierter Individuen, wie folgt:

P = {Ii | @Ij : xj ≺p xi}

Die Elemente der Pareto-Menge werden als Pareto-Front bezeichnet.


2.6.4 SPEA2

SPEA2 (Strength Pareto Evolutionary Algorithm 2) [ZLT01], eine Verbesserung des ursprung-lichen SPEA Algorithmus [ZT98], stellt ein Optimierungsverfahren zur Berechnung bzw. Appro-ximation der Pareto-Menge fur mehrkriterielle Optimierungsprobleme dar und wird im Rahmendieser Diplomarbeit zur Optimierung der Speicherhierarchie des SoC und zur Berechnung einerApproximation der optimalen statischen Scratchpad-Allokation (siehe Kapitel 4) eingesetzt.

2.6.4.1 SPEA2-Algorithmus

Zunachst sei erwahnt, dass SPEA2 zusatzlich zur Population ein Archiv verwendet, das dieMenge der besten bisher gefundenen Losungen zu jedem Zeitpunkt der Evolution reprasentiert.Dabei enthalt das Archiv neben nicht-dominierten Individuen auch ggf. dominierte, wenn dieAnzahl nicht-dominierter Individuen kleiner als die Archivgroße ist. Der SPEA2-Algorithmusoperiert wie folgt [ZLT01]:

Input: N (Große der Population)N (Große des Archivs)T (Maximale Anzahl von Generationen)

Output: A (Menge nicht-dominierter Individuen)

1. Initialisierung: Erzeuge eine initiale Population P0 und ein leeres Archiv P0 = ∅. Setzeden Generationenzahler auf t = 0.

2. Berechnung der Fitness: Berechne die Fitness der Individuen aus Pt und Pt.

3. Umweltselektion (environmental selection): Kopiere alle nicht-dominierten Indivi-duen aus Pt und Pt nach Pt+1. Wenn die Große von Pt+1 N uberschreitet, reduziere Pt+1

unter Verwendung des Truncation-Operators. Wenn jedoch die Große von Pt+1 kleiner alsN ist, erganze Pt+1 durch dominierte Individuen aus Pt und Pt

4. Terminierung: Wenn t ≥ T oder ein anderes Abbruchkriterium erfullt ist, fuge allenicht-domierten Individuen aus Pt+1 in A ein. A stellt dann die gesuchte Pareto-Mengenicht-dominierter Individuen dar.

5. Selektion zur Erzeugung neuer Individuen (mating selection): Fuhre die binareTournier-Selektion (q = 2) (binary tournament selection with replacement) auf Pt+1 ausund fulle so den Mating-Pool.

6. Variation: Wende den Rekombinations- und Mutationsoperator auf die Individuen desMating-Pools an. Die resultierende Population sei Pt+1. Inkrementiere den Generatio-nenzahler (t = t+ 1) und gehe zu Schritt 2.

Im Folgenden werden die Berechnung der Fitness (Schritt 2.) und die Umweltselektion(Schritt 3.) naher erlautert. Der Mutations- und Rekombinationsoperator und das Abbruch-kriterium sind abhangig vom Optimierungsproblem zu wahlen.

2.6.4.2 Berechnung der Fitness

Die Fitness eines Individuum setzt sich aus mehreren additiven Komponenten zusammen. Dabeiwird zunachst jedem Individuum Ii der Population Pt und des Archivs Pt eine Starke S(Ii)

34 2 Grundlagen

(strength value) zugewiesen, die die Anzahl der Individuen aus Pt und Pt angibt, die das In-dividuum Ii dominiert, wobei ≺p die Pareto-Dominanz-Relation bzgl. der Minimierung allerTeilziele Fi(x) aus 2.6.3.9 und + die Vereinigung zweier Multimengen bezeichnet:

S(Ii) =∣∣{Ij | Ij ∈ Pt + Pt ∧ Ii ≺p Ij}

∣∣Des Weiteren wird auf Basis von S(Ii) die rohe Fitness R(Ii) eines Individuums Ii berechnet:

R(Ii) =∑

Ij∈Pt+Pt,Ij≺pIi

S(Ij)

Die rohe Fitness R(Ii) (raw fitness) eines Individuums Ii wird dabei durch die Starke S(Ij)der Individuen, die das Individuum Ii dominieren, bestimmt. Eine rohe Fitness von R(Ii) = 0korrespondiert so mit einem nicht-dominierten Individuum. Diese Definition der Fitness ver-hindert, dass zwei Individuen, die von einem anderen Individuum dominiert werden, denselbenFitnesswert erhalten. Jedoch weist die Definition der Fitness uber R(Ii) einige Schwachen auf,wenn die meisten Individuen nicht-dominiert sind, da R(Ii) fur diese Individuen 0 ist und so Clus-ter des Losungsraums nicht mehr differenzierbar sind. Aus diesem Grund wird eine zusatzlicheadditive Dichte-Komponente verwendet, um Individuen mit identischer Fitness unterscheidenzu konnen. Die Bestimmung dieser additiven Komponente erfolgt uber eine Adaption des k-thNearest-Neighbor-Algorithmus (Silverman 1986). Dabei wird fur jedes Individuum Ii die Distanzzu jedem Individuum Ij aus der Population Pt und dem Archiv Pt berechnet und in einer Listegespeichert, die anschließend aufsteigend sortiert wird. Das k-te Element gibt dann die gesuchteDistanz σi

k an. k wird dabei stets wie folgt gewahlt: k =√N +N . Insgesamt ergibts sich die

additive Dichte-Komponente D(Ii) als:

D(Ii) =1

σik + 2

Die Addition von 2 im Nenner von D(Ii) stellt sicher, dass stets 0 < D(Ii) < 1 gilt. DieFitness eines Individuum Ii ergibt sich schließlich aus der Summe von R(Ii) und D(Ii):

F (Ii) = R(Ii) +D(Ii)

Aus der Definition der Fitness resultiert so fur ein nicht-domiertes Individuum Ii der Fitness-wert F (Ii) < 1. Die Laufzeit dieser Prozedur zur Fitness-Berechnung wird durch die Berechnungder additiven Dichte-Komponente dominiert (O(M2 logM)), wahrend die Berechnung von S undR eine Komplexitat von O(M2), mit M = N +N , hat [ZLT01].

2.6.4.3 Umweltselektion (environmental selection)

Die Umweltselektion (environmental selection) erzeugt aus einer Population Pt der Große Nund einem Archiv Pt der Große N ein Archiv Pt+1 der Große N . Dabei werden in einem erstenSchritt alle nicht-domierten Individuen (Individuen Ii mit F (Ii) < 1) aus der Population Pt

und dem Archiv Pt in das Archiv Pt+1 der nachsten Generation kopiert:

Pt+1 = {Ii | Ii ∈ Pt + Pt ∧ F (Ii) < 1}

Entspricht die Große∣∣Pt+1

∣∣ des resultierenden Archivs der nachsten Generation genau N ,so ist die Umweltselektion abgeschlossen. Andernfalls existieren zwei Situationen:

•∣∣Pt+1

∣∣ < N : In diesem Fall werden die besten N −∣∣Pt+1

∣∣ dominierten Individuen ausPt und Pt nach Pt+1 kopiert. Dies kann durch Sortieren der Menge Pt + Pt nach derFitness der Individuen und anschließendem Kopieren der ersten N −

∣∣Pt+1

∣∣ Individuenmit F (Ii) ≥ 1 nach Pt+1 umgesetzt werden.


•∣∣Pt+1

∣∣ > N : In diesem Fall wird die Große des Archivs iterativ unter Anwendung desTruncation-Operators auf N reduziert. In jedem Iterationsschritt wird dabei ein Individu-um Ii entfernt, fur das Ii ≤d Ij fur alle j ∈ Pt+1 gilt:

Ii ≤d Ij :⇐⇒ ∀0 < k <∣∣Pt+1

∣∣ : σik = σj

k ∨∃0 < k <

∣∣Pt+1

∣∣ : [(∀0 < l < k : σil = σj

l) ∧ σik < σj

k]

Dabei bezeichnet σik die Distanz von Ii zum k-nachsten Nachbarn. Mit anderen Worten

bedeutet dies, dass das Individuum mit geringster Distanz zu einem anderen Individuumin jedem Iterationsschritt entfernt wird.

Im Worst-Case betragt die Komplexitat des Truncation-Operators O(M3) (M = N + N),im Average-Case jedoch nur O(M2 logM), da sich Individuen meist fur k = 2 oder k = 3unterscheiden und so die Sortierung der Distanzen die Komplexitat dominiert.

36 2 Grundlagen

Kapitel 3

MEMSIM-Integration

In diesem Kapitel wird die Integration von MEMSIM (siehe 2.4), einem reinen Speicherhierarchie-Simulator, in MPARM (siehe 2.5), einem Mulit-Prozessor System-on-Chip Simulator, erlautert.Diese Integration wird einerseits durch die Fahigkeit des MPARM-Simulators, ARM7-Binarcodeauf einer parametrisierbaren AMBA AHB-Plattform zyklengenau zu simulieren, andererseitsdurch die hohe Flexibiltat in der Konfigurierbarkeit der Speicherhierarchie des MEMSIM-Simu-lators motiviert. Wie in 2.5.5 dargelegt, ist die Konfigurierbarkeit der Speicherhierarchie inMPARM sehr stark eingeschrankt, sodass nur ein Cache-Level und eine feste Große fur al-le Speicher gleichen Typs (private bzw. gemeinsame Speicher) festgelegt werden kann. DieseRestriktionen sollen mit der Integration einer modifizierten und erweiterten Version des amLehrstuhl entwickelten Speicherhierarchie-Simulators MEMSIM behoben werden.

3.1 Anforderungen

Die Integration von MEMSIM in MPARM (kurz MPARM/MEMSIM) bringt viele Anforderun-gen mit sich, die eine große Herausforderung darstellen. So muss stets die Synchronitat der beidenSimulationssysteme gewahrleistet sein, um die zyklengenaue Simulation des Gesamtsystems, diesowohl MPARM als auch MEMSIM zugrunde liegt, zu erhalten. Ahnlich der Integration desSWARM-Simulators in die SystemC-Umgebung von MPARM (siehe 2.5.3) werden Konzepte zuerarbeiten sein, die dies sicherstellen. Dies wird jedoch einen tiefen Eingriff in die Strukturen vonMPARM und eine Anpassung von MEMSIM notwendig machen. Fur die verwendeten MEMSIM-Komponenten ist die Entwicklung praziser Energiemodelle fur den Einsatz in MPARM erfor-derlich, um moglichst aussagekraftige Simulationsergebnisse zu erhalten. MPARM ermoglichtdes Weiteren einem Benchmark, der auf der Simulationsplattform ausgefuhrt wird, uber dieFunktionen start metric() und stop metric() die Statistikerhebung zu einem frei wahlbarenZeitpunkt zu starten. Um diese Funktionalitat ebenso in MPARM/MEMSIM zu gewahrleisten,ist auch hierfur ein Konzept zu erarbeiten. Da in MPARM/MEMSIM fur alle Speicher dieKonfiguration einer individuellen Große erlaubt werden soll, ist das MPARM-Adressmodell aus2.5.4 dementsprechend anzupassen. Ebenso muss die Kombination der beiden Simulatoren dieErhaltung der Simulationeffizienz, d.h. praktikabler Simulationszeiten, gewahrleisten. Im Zugeder Integration wird des Weiteren eine einfache, wohldefinierte Konfigurationsschnittstelle (API)entwickelt, die die Parametrisierung des zu simulierenden Systems vereinfacht. Dies wird insbe-sondere durch die vielfaltigen Konfigurationsparameter der MEMSIM-Komponenten notwendig.Die entwickelte API soll eine einfache Anbindung des MPARM/MEMSIM-Simulators an das amLehrstuhl entwickelte MaCCv2 Compiler Framework [MAH] ermoglichen.

37

38 3 MEMSIM-Integration

3.2 AMBA AHB Master-Integration

Die Integration von MEMSIM in den ARM7-Prozessor, d.h. in die SWARM-Struktur, stellt diegroßte Herausforderung dar, da sich diese als außerst komplex darstellt. In einem ersten Schrittwurde dazu eine Schnittstelle zwischen CArmProc (siehe 2.5.3) und MEMSIM entwickelt, ineinem zweiten Schritt der Zustandsautomat des CArmProc erweitert, um MEMSIM und SWARMfunktional zu verbinden.

3.2.1 MEMSIM-Master-Interface

Um MEMSIM in SWARM zu integrieren, wurde eine C++ - Schnittstelle in Form der KlasseMemsimMstIf (MEMSIM-Master-Interface) entwickelt, die das MEMSIM-Simulationssystem mitdem ARM7-Instruktionssatzsimulator verbindet. Da MEMSIM als Speicherhierarchie-Simulatoruber eigene Speicherkomponenten verfugt, findet eine Verlagerung der Caches und Scratchpadsin das MEMSIM-Simulationssystem statt, wobei die MPARM-Cache-Implementierung durchdie in 3.4.3 beschriebene MPARM/MEMSIM-Cache-Implementierung ersetzt wird. Eine Cache-Hierarchie kann dabei aus beliebig vielen Cache-Levels mit jeweils einem Instruktions- und/oderDaten-Cache oder einem Unified-Cache bestehen. Durch dieses Vorgehen ist die Konfigurationdes MEMSIM-Simulationssystems vollig transparent fur MPARM und ermoglicht so eine ein-fache Umsetzung komplexer Speicherhierarchien. Ein Uberblick uber die daraus resultierendeSWARM-Struktur zeigt Abb. 3.1.

SystemC - Wrapper

CArmProc

MemsimMstIf

Wurzel-komponente

SPMCache-

Hierarchie

AMBA AHB Interface

AMBA AHB Bus

ARM7-Prozessor

(CArmCore)

Lokaler Bus

Interrupt-controller

Timer

UART Controller

MMU

AMBA AHBMasterPINOUT

Abbildung 3.1: Resultierende SWARM-Struktur mit MEMSIM-Master-Interface

Wie in der resultierenden Struktur dargestellt, erfolgt durch die Verlagerung der Cachesin das MEMSIM-Simulationssystem die Kommunikation mit dem AMBA AHB Bus nun auchdurch das MEMSIM-Master-Interface unter Zuhilfenahme des AMBA AHB-Interface, das in3.2.4 naher erlautert wird. Dieser Fall tritt z.B. ein, wenn eine Cache-Zeile aus dem Hauptspei-cher geladen wird. Des Weiteren wird eine Wurzelkomponente (MasterComponentRoot) verwen-det, die im Wesentlichen als Decoder bei einem Speicherzugriff und als dezentrale MEMSIM-Simulationsinstanz zur Umsetzung der in 2.4.3 beschriebenen Simulationssemantik dient. Einegenauere Beschreibung dieser Wurzelkomponente liefert 3.2.3.

Die Kommunikation und Synchronisation von CArmProc und MemsimMstIf erfolgt uber fol-gende Funktionen:

• void clock(): Jeder Takt, der an CArmProc delegiert wird, wird durch den Aufruf dieser

3.2 AMBA AHB Master-Integration 39

Funktion an das MEMSIM-Master-Interface weitergeleitet. Dieser Takt wird wiederumvom MEMSIM-Master-Interface unmittelbar an die Wurzelkomponente delegiert.

• void read(uint32 addr, bool opcodeFetch, AccessWidth accessWidth): Ein lesen-der Speicherzugriff wird durch den Aufruf dieser Funktion an das MEMSIM-Simulations-system delegiert. Dazu werden die Zugriffsadresse, ein Flag, das festlegt, ob der aktuelleZugriff ein Opcode Fetch ist, und die Bitbreite des Zugriffs spezifiziert.

• void write(uint32 addr, uint32 data, AccessWidth accessWidth): Ein schreiben-der Speicherzugriff wird durch den Aufruf dieser Funktion an das MEMSIM-Simulations-system delegiert. Dazu werden die Zugriffsadresse, das zu schreibende Datum und dieBitbreite des Zugriffs spezifiziert.

• bool hasOperationCompleted(): Uber diese Funktion wird ermittelt, ob der zuletzt in-itiierte Speicherzugriff durch das MEMSIM-Simulationssystem abgeschlossen wurde.

• uint32 getOperationData(): Diese Funktion liefert bei einem lesenden Speicherzugriff,sofern dieser abgeschlossen ist, das angeforderte Datum zuruck.

3.2.2 Erweiterung des Zustandsautomaten

Um das MEMSIM-Master-Interface funktional in CArmProc zu integrieren, wird eine Anpassungdes in 2.5.3 beschriebenen Zustandsautomaten erforderlich. Der resultierende Zustandsautomatwird in Abb. 3.2 dargestellt.

P_NORMALP_READING1 P_WRITING1

P_INTWRITEP_MEMSIM_WAIT_WRITE



Timer


Lesender Speicherzugriffauf nicht Prozessor-lokale

Speicher

P_MEMSIM_WAIT_READLesender Speicherzugriff

auf nicht Prozessor-lokaleSpeicher


Speicherzugriffmit zusätzlichen

Wait States

Speicherzugriffmit zusätzlichen

Wait States



Timer

Abbildung 3.2: Erweiterter SWARM-Zustandsautomat

So findet im Zustand P NORMAL, im Fall eines lesenden Scratchpad- oder Cache-Zugriffsein Zugriff auf das MEMSIM-Master-Interface uber die read()-Funktion statt. Wird der lesendeZugriff unmittelbar, z.B. durch einen Cache-Hit, abgeschlossen, so entspricht das Folgeverhaltendem des ursprunglichen Zustandsautomaten. Im Fall einer Latenz l > 0, z.B. bei einer Konfigu-ration ohne Caches, wird der Zustand P MEMSIM WAIT READ angenommen, in dem solange


verblieben wird, bis der Speicherzugriff abgeschlossen ist. Wahrend dieser Zeit findet kein weite-rer Simulationszyklus des CArmCore statt. Der Folgezustand ergibt sich aus dem nachsten Spei-cherzugriff. Bei einem schreibenden Zugriff, der nicht auf den UART-, LCD-, Interrupt-Controlleroder den Timer erfolgt, wird ein ein Zustandswechsel nach P WRITING1 vollzogen, im Fall eineslesenden Zugriffs auf nicht Prozessor-lokale Speicher wird der Zustand P READING1 angenom-men, bei einem schreibenden Zugriff auf den UART-, LCD-, Interrupt-Controller oder den Timerwird in den Zustand P INTWRITE und in allen anderen Fallen in den Zustand P NORMAL ge-wechselt. Resultierend aus dieser Anderung kann der Zustand P READING entfallen, in dem dasLesen einer Cache-Zeile aus dem Hauptspeicher initialisiert wurde. Der Zustand P READING1dient damit nur noch dem Lesen eines Wortes, dessen Adresse nicht durch Caches oder Prozessor-lokale Speicher abgedeckt wird. Da alle Write Backs innerhalb des MEMSIM-Simulationssystemserfolgen, wird ebenso der Zustand P WRITING DIRTY LINE nicht weiter benotigt. Im Falleines schreibenden Zugriffs, der nicht auf den UART-, LCD-, Interrupt-Controller oder denTimer erfolgt, befindet sich der Zustandsautomat des CArmProc im Zustand P WRITING1.Bei einem Zugriff auf Adressbereiche, die mit Caches oder Scratchpads assoziiert sind, wirddieser an das MEMSIM-Master-Interface unter Verwendung der write()-Funktion delegiert.Wird dieser Zugriff unmittelbar abgeschlossen, d.h. liegt keine Latenz vor, so entspricht dasVerhalten dem des ursprunglichen Zustandsautomaten. Im Falle einer Latenz l > 0 wird imFolgezustand P MEMSIM WAIT WRITE bis zum Abschluss des Speicherzugriffs verweilt. DerFolgezustand ergibt sich wiederum aus dem nachsten Speicherzugriff. Im Fall eines schreiben-den Zugriffs wird der Zustand P WRITING1, ansonsten der Zustand P NORMAL angenommen.Ob ein Speicherzugriff abgeschlossen ist, wird uber die Funktion hasOperationCompleted() desMEMSIM-Master-Interface ermittelt. Liegt keine durch Speicher induzierte Latenz vor, so liefertdiese Funktion unmittelbar nach Aufruf von read() bzw. write() true, um die Verarbeitungdes Ergebnisses eines Speicherzugriffs im nachsten Taktzyklus des CArmCore zu ermoglichen.Diese Anderung des Zustandsautomaten ermoglicht die zyklengenaue Integration des MEMSIM-Simulationssystems in die SWARM-Struktur und damit in MPARM.

3.2.3 Wurzelkomponente

Wie in Abb. 3.1 dargestellt, ist bei einem Zugriff auf das MEMSIM-Master-Interface und damitdas MEMSIM-Simulationssystem zuerst die Wurzelkomponente involviert. Die Konzeption die-ser Komponente entspricht dem in 2.4.2 vorgestellten Komponentenmodell, jedoch stellt sie keineklassische MEMSIM-Simulationskomponente dar. Bei einem lesenden oder schreibenden Zugriffauf das MEMSIM-Master-Interface uber read() bzw. write() leitet diese Komponente, je nachZugriffsadresse und Status des Opcode Fetch-Flags, den Zugriff an die MEMSIM-Komponentenweiter. Im Fall eines gesetzten Opcode Fetch-Flags wird der Zugriff an einen Instruktions-Cacheoder, falls nicht vorhanden, an einen Unified-Cache weitergeleitet. Damit dient die Wurzelkom-ponente in erster Funktion als Decoder. In einer weiteren Funktion stellt die Wurzelkomponenteeine dezentralisierte Umsetzung einer MEMSIM-Simulationsinstanz dar. So wird zum einen jederTakt, der vom MEMSIM-Master-Interface uber die clock()-Funktion an die Wurzelkomponen-te delegiert wird, an alle MEMSIM-Komponenten weitergeleitet, zum anderen die Aktivierungaller aktiven MEMSIM-Komponenten (siehe 2.4.3) durchgefuhrt. Wird durch den Aufruf vonread() bzw. write() ein Speicherzugriff am MEMSIM-Master-Interface initiiert, so werdenMEMSIM-Komponenten im aktuellen Taktzyklus aktiv. Um im selben Taktzyklus die initiierteOperation durchfuhren zu konnen, wird ebenso durch den Aufruf von read() bzw. write() dieAktivierung aktiver Komponenten veranlasst.

Die Synchronisierung von MemsimMstIf und MasterComponentRoot erfolgt uber folgendeFunktionen:

• void clock(): Jeder Takt, der an das MEMSIM-Master-Interface delegiert wird, wird

3.3 AMBA AHB Slave-Integration 41

unmittelbar durch den Aufruf dieser Funktion an die Wurzelkomponente weitergeleitet.

• void addressIn(Component* comp, MemoryAccess* memaccess): Jeder lesende bzw.schreibende Speicherzugriff auf das MEMSIM-Master-Interface wird uber diese Funktionan die Wurzelkomponente weitergeleitet. Die Parameter des Speicherzugriffs werden dabeiuber die Klasse MemoryAccess (siehe 3.4.1) spezifiziert.

• bool isActive(): Uber diese Funktion kann festgestellt werden, ob sich die Wurzelkom-ponente in einem aktiven Zustand befindet, d.h. ob auf den Abschluss eines Speicherzu-griffs gewartet wird. Liefert diese Funktion false, so liefert hasOperationCompleted()des MEMSIM-Master-Interface true.


3.2.4 AMBA AHB-Interface

Eine weitere MEMSIM-Komponente, die neben MasterComponentRoot nur in AMBA AHB Mas-tern zum Einsatz kommt, ist das AMBA AHB-Interface (AMBAInterface). Diese Komponentestellt die Schnittstelle zwischen dem MEMSIM-Simulationssystem und dem AMBA AHB Busdar. Ein Speicherzugriff innerhalb des MEMSIM-Simulationssystems wird durch diese Kompo-nente an den SystemC-Wrapper unter Verwendung der PINOUT-Datenstruktur delegiert. JedeWeiterleitung eines Speicherzugriffs bzw. des zugehorigen Ergebnisses erfolgt ohne Verzogerungan den AMBA AHB Bus bzw. die Vorgangerkomponente, da das AMBA AHB-Interface nurals Schnittstellenkomponente fungiert und damit keine Latenzen induziert. Auch Bursts wer-den durch das AMBA AHB-Interface unterstutzt. Da die SystemC-Implementierung des AMBAAHB Busses nur inkrementierende Bursts der Lange 1 (normale Datenubertragung), 4, 8 und16 unterstutzt, werden Bursts mit eine Lange großer 16 in moglichst wenige Bursts maximalerGroße unterteilt, um die Gesamtlatenz einer Bustransaktion zu minimieren. Ein Burst der Lange48 wurde so z.B. in 3 Bursts der Lange 16 unterteilt.

3.3 AMBA AHB Slave-Integration

Die Integration des MEMSIM-Simulationssystems in die AMBA AHB Slaves wird nur fur privateund gemeinsame Slaves durchgefuhrt, da nur diese fur die MPARM-Speicherhierarchie relevantsind. Im Fall anderer Slaves, z.B. eines Semaphoren-Slaves, wird auf die Integration von MEM-SIM verzichtet.

3.3.1 MEMSIM-Slave-Interface

Fur die Integration von MEMSIM in die AMBA AHB Slaves wurde eine C++ - Schnittstellein Form der Klasse MemsimSlaveIf (MEMSIM-Slave-Interface) entwickelt. Alle Zugriffe auf denSlave-Speicher erfolgen nach der Integration ausschließlich uber das MEMSIM-Slave-Interface.Einen Uberblick uber die resultierende interne Struktur eines AMBA AHB Slaves liefert Abb. 3.3.Durch die MEMSIM-Integration ist es moglich, eine Slave-lokale Cache-Hierarchie zu etablieren,um so eine ggf. vorhandene Latenz des Slave-Speichers zu kompensieren. Eine Cache-Hierarchieinnerhalb eines Slaves kann dabei aus beliebig vielen Cache-Levels von Unified-Caches bestehen.Instruktions- und Daten-Caches sind nicht einsetzbar, da am AMBA AHB Bus nicht zwischeneinem Daten- und Instruktionszugriff unterschieden wird. Wie im Fall des AMBA AHB Masterswird eine Wurzelkomponente (SlaveComponentRoot) verwendet, die zum einen einen Speicher-zugriff bzw. dessen Ergebnis an die MEMSIM-Komponenten bzw. das MEMSIM-Slave-Interface


delegiert und zum anderen eine dezentrale Simulationsinstanz implementiert. Eine detaillierteBeschreibung der Wurzelkomponente liefert 3.3.2.

AMBA AHB Slave

MemsimSlaveIf

Wurzel-komponente

Cache-Hierarchie(optional)

MEMSIM-Speicherkomponente

AMBA AHB Bus

MPARM Slave-Speicher

Abbildung 3.3: Resultierende AMBA AHB Slave-Struktur mit MEMSIM-Slave Interface

Wie in Abb. 3.3 zu dargestellt, werden die ursprunglichen MPARM-Speicherklassen in einerMEMSIM-Speicherkomponente eingebettet. Dieses Vorgehen ermoglicht, einem Slave-SpeicherMEMSIM-Konfigurationen, z.B. eine individuelle Große oder Latenz, aufzupragen. Wie in 3.4.4naher erlautert wird, ist es somit moglich, einen SRAM-, DRAM- oder Flash-Speicher zu simu-lieren.

Die Kommunikation und Synchronisation des AMBA AHB Slave und des MEMSIM-Slave-Interface erfolgt uber die folgenden Funktionen:

• void clock(): Jeder Takt, der an den AMBA AHB Slave delegiert wird, wird durch denAufruf dieser Funktion an das MEMSIM-Slave-Interface weitergeleitet. Dieser Takt wirdwiederum vom MEMSIM-Slave-Interface unmittelbar an die Wurzelkomponente delegiert.

• void read(int coreId, uint32 addr, AccessWidth accessWidth, bool burst,unsigned int burstLength): Ein lesender Speicherzugriff wird durch den Aufruf dieserFunktion an das MEMSIM-Simulationssystem delegiert. Dazu werden die Id des Masters,der diesen Zugriff initialisiert hat, die Zugriffsadresse, die Bitbreite des Zugriffs, ein Burst-Flag und, im Fall eines Bursts, die Burstlange spezifiziert.

• void write(int coreId, uint32 addr, uint32 data, AccessWidth accessWidth,bool burst, unsigned int burstLength): Ein schreibender Speicherzugriff wird durchden Aufruf dieser Funktion an das MEMSIM-Simulationssystem delegiert. Dazu werden dieId des Masters, der diesen Zugriff initialisiert hat, die Zugriffsadresse, das zu schreibendeDatum, die Bitbreite des Zugriffs, ein Burst-Flag und, im Fall eines Bursts, die Burstlangespezifiziert.

• bool hasOperationCompleted(): Uber diese Funktion wird ermittelt, ob der zuletzt in-itiierte Speicherzugriff durch das MEMSIM-Simulationssystem abgeschlossen wurde.


Ein lesender Zugriff auf einen AMBA AHB Slave wird unmittelbar uber die read()-Funktionan das MEMSIM-Slave-Interface delegiert, im Fall eines schreibenden Zugriffs erfolgt dies erst

3.3 AMBA AHB Slave-Integration 43

einen Takt spater durch Aufruf der write()-Funktion, da erst zu diesem Zeitpunkt die zuschreibenden Daten valide am Bus vorliegen (siehe 2.5.2). Wie im Fall des MEMSIM-Master-Interface, wird uber die Funktion hasOperationCompleted() ermittelt, ob ein Speicherzugriffabgeschlossen wurde. Liegt keine Latenz vor, so liefert diese Funktion unmittelbar nach Aufrufvon read() bzw. write() true, um im Folgezyklus den Abschluss der Transaktion am AMBAAHB Bus zu ermoglichen. Im Fall einer Latenz l > 0 wird erst dann die Transaktion am AMBAAHB Bus abgeschlossen, wenn hasOperationCompleted() true liefert.

Wie in 2.5.2 beschrieben, ermoglicht die SystemC-Implementierung des AMBA AHB Bus-ses Split-Transaktionen, sodass Slaves mit großer Latenz den Bus fur wartende AHB Masterfreigeben konnen. Da in der ursprunglichen Implementierung der Slaves auf die Umsetzung vonSplit-Transaktionen verzichtet wird und kein Anhaltspunkt besteht, wann solch eine Transak-tion durchzufuhren ist, wird auch bei der Integration von MEMSIM in MPARM von dieserUmsetzung abgesehen.


Abb. 3.3 zeigt, dass auch bei einem Zugriff auf das MEMSIM-Slave-Interface und damit dasMEMSIM-Simulationssystem zunachst die Wurzelkomponente (SlaveComponentRoot) involviertist. Da sich die Struktur der Speicherhierarchie innerhalb eines Slaves linear und ohne Verzwei-gungen darstellt, delegiert diese einen Speicherzugriff ausschließlich an den direkten Nachfolgerbzw. stellt das Ergebnis des Speicherzugriff dem MEMSIM-Slave-Interface zur Verfugung. Diekomplexe Funktionalitat eines Decoders, wie im Fall der Wurzelkomponente des MEMSIM-Master-Interface, entfallt. Eine weitere Funktionalitat der Wurzelkomponente besteht in derUmsetzung einer dezentralen MEMSIM-Simulationsinstanz. Dabei wird zum einen jeder Takt,der vom MEMSIM-Slave-Interface an die Wurzelkomponente propagiert wird, an alle MEMSIM-Komponenten delegiert, zum anderen werden alle aktiven Komponenten aktiviert (siehe 2.4.3).Findet ein Speicherzugriff auf das MEMSIM-Slave-Interface durch den Aufruf von read() bzw.write() statt, so werden MEMSIM-Komponenten im aktuellen Taktzyklus aktiv. Um die Akti-vierung dieser Komponenten im selben Taktzyklus sicherzustellen, wird ebenso durch den Aufrufvon read() bzw. write() die Aktivierung aktiver Komponenten veranlasst.

Die Synchronisierung von MemsimSlaveIf und SlaveComponentRoot erfolgt uber folgendeFunktionen:

• void clock(): Jeder Takt, der an das MEMSIM-Slave-Interface delegiert wird, wird un-mittelbar durch den Aufruf dieser Funktion an die Wurzelkomponente weitergeleitet.

• void addressIn(Component* comp, MemoryAccess* memaccess): Jeder lesende bzw.schreibende Speicherzugriff auf das MEMSIM-Slave-Interface wird uber diese Funktion andie Wurzelkomponente weitergeleitet. Die Parameter des Speicherzugriffs werden dabeiuber die Klasse MemoryAccess (siehe 3.4.1) spezifiziert.

• bool isActive(): Uber diese Funktion kann festgestellt werden, ob sich die Wurzelkom-ponente in einem aktiven Zustand befindet, d.h. ob auf den Abschluss eines Speicherzu-griffs gewartet wird. Liefert diese Funktion false, so liefert hasOperationCompleted()des MEMSIM-Slave-Interface true.



3.4 MEMSIM-Komponenten in MPARM

3.4.1 Grundlegendes

Nachdem zuvor die Schnittstellen zwischen MPARM und MEMSIM und deren Integration vor-gestellt wurden, werden im Folgenden alle Komponenten des fur die Integration modifiziertenMEMSIM-Simulationssystems naher erlautert. Das Komponentenmodell entspricht im Wesent-lichen dem ursprunglichen Modell aus 2.4.2, jedoch wurde dem abstrakten KomponententypComponent die Funktion isPrecedessorRoot() hinzugefugt, uber welche festgestellt werdenkann, ob es sich bei der Vorgangerkomponente um die Wurzelkomponente handelt. Ist dies beider Auslieferung des Ergebnisses eines Speicherzugriffs der Fall, so ist das Ergebnis im gleichenZyklus an die Wurzelkomponente zu delegieren, um im nachsten Taktzyklus durch CArmCore imFall eines AMBA AHB Masters bzw. den AMBA AHB Bus im Fall eines AMBA AHB Slavesverarbeitet werden zu konnen. Ohne diesen Mechanismus wurde eine zusatzliche Latenz voneinem Taktzyklus pro Speicherzugriff induziert werden. Dieser Sachverhalt wird auch in 3.2.2und 3.3.1 erlautert. Im Fall einer MEMSIM-Komponente erfolgt die Ubergabe des Ergebnis-ses eines Speicherzugriffs einen Takt spater, da durch die MEMSIM-Simulationssemantik eineVerarbeitung im selben Takt ermoglicht wird.

Die Kommunikation der MEMSIM-Komponenten mit dem direkten Nachfolger bzw. Vorgan-ger erfolgt uber die Funktionen addressIn(Component* comp, MemoryAccess* memaccess)bzw. readyIn(Component* comp, MemoryAccess* memaccess). Die Spezifikation eines Spei-cherzugriffs bzw. des zugehorigen Ergebnisses erfolgt dabei uber die Klasse MemoryAccess, diefolgende Informationen bereitstellt:

• Zugriffsadresse

• Lesender/schreibender Zugriff

• Bitbreite des Zugriffs (Byte (8 Bit), Halbwort (16 Bit), Wort (32 Bit))

• Opcode Fetch-Flag (true beim Laden einer Instruktion)

• Gelesenes/zu schreibendes Datum

• Burst-Flag (true im Fall eines Bursts)

• Burstlange in Worten (falls Burst vorliegt)

• Id des Masters, der Speicherzugriff initiiert hat (dient der Statistikerfassung (siehe 3.6)

Des Weiteren kann in MPARM/MEMSIM jeder Speicherkomponente der Chipflachenbedarfin mm2 zugewiesen werden, um den durch Speicher induzierten Chipflachengesamtbedarf zuerfassen. Dieser Chipflachenbedarf kann entweder manuell oder unter Verwendung von CACTI4.2 konfiguriert werden.

Komponenten, die speziell einem AMBA AHB Master oder AMBA AHB Slave zugeordnetsind und somit schon Erwahnung fanden, werden der Vollstandigkeit halber im Folgenden nurkurz erwahnt.


Die Wurzelkomponente ist sowohl als MasterComponentRoot im AMBA AHB Master, als auchals SlaveComponentRoot im AMBA AHB Slave vorzufinden. Diese delegiert bei einem Spei-cherzugriff auf das MEMSIM-Master- bzw. MEMSIM-Slave-Interface diesen an die MEMSIM-Simulationskomponenten und stellt das Ergebnis eines Speicherzugriffs dem MEMSIM-Master-bzw. MEMSIM-Slave-Interface zur Verfugung. Eine weitere wichtige Funktionalitat stellt die

3.4 MEMSIM-Komponenten in MPARM 45

Implementierung einer dezentralen MEMSIM-Simulationsinstanz zur Umsetzung der in 2.4.3beschriebenen MEMSIM-Simulationssemantik dar. Damit entspricht diese Komponente von derSchnittstelle zwar dem klassischen MEMSIM-Komponentenmodell, von der Funktionalitat un-terscheidet sie sich jedoch von diesem deutlich. Details zur MasterComponentRoot finden sichin 3.2.3, detaillierte Informationen zur SlaveComponentRoot in 3.3.2.

3.4.3 Cache

Die Caches wurden fur die Integration in MPARM von Grund auf neu entwickelt. Die Strukturder Caches gliedert sich weiterhin in das MEMSIM-Cache-Interface (Cacheinterface), das dieAnbindung an die MEMSIM-Speicherhierarchie ubernimmt, und die zugrunde liegende Cache-Implementierung, die sich aus den Klassen Cache, CacheSet und CacheLine zusammensetzt. Ei-ne Cache-Zeile enthalt den zugehorigen Tag, die Daten der Cache-Zeile und ein Valid- und Dirty-Bit pro Wort. Die Ersetzungsstrategie wird durch CacheSet umgesetzt und unterstutzt, wie dieursprungliche Implementierung, LRU, Round Robin und eine zufallsbasierte Ersetzungsstrate-gie. Ferner werden in dieser Cache-Implementierung die Schreibstrategien Write Back und WriteThrough durch das Cache-Interface unterstutzt und uber das MEMSIM-Simulationssystem aktivumgesetzt, d.h. jedes Write Through bzw. Write Back geht mit mindestens einem Speicherzugriffin der Nachfolgekomponente einher. Fur die Schreibstrategie Write Back kann uber den Parame-ter Full Line Write Back festgelegt werden, ob im Fall eines Write Backs die ganze Cache-Zeileoder nur die Worter, deren Dirty-Bit gesetzt sind, zuruckgeschrieben werden. Zur Umsetzungdieses Parameters wurde insbesondere der SystemC-Wrapper und die Klasse amb ahb master an-gepasst, da in der ursprunglichen MPARM-Version keine schreibenden Burst-Zugriffe unterstutztwerden. Des Weiteren verfugt diese Cache-Implementierung, im Gegensatz zu MEMSIM, uberdie Moglichkeit, Latenzen/Wait States fur den lesenden und schreibenden Fall zu definieren.

Wie in der ursprunglichen MPARM- und MEMSIM-Implementierung, haben alle Zugriffeauf einen Cache in MPARM/MEMSIM einen blockierenden Charakter. Dadurch im Fall einesARM7-Prozessors die Pipeline bis zum Abschluss der Transaktion blockiert, im Fall eines AMBAAHB Slaves erfolgt der Abschluss der Bustransaktion erst nach Abschluss des Cache-Zugriffs.Daher sind auch alle Write Backs und Write Throughs blockierend. Eine nicht-blockierende Um-setzung innerhalb des MEMSIM-Simulationssystems ware zwar moglich gewesen, jedoch nichtkonsistent mit der Tatsache, dass jeder Zugriff auf den AMBA AHB Bus als Stall auf den Pro-zessor wirkt, vereinbar gewesen. Daraus resultierend wurde auf die Verwendung des Konfigura-tionsparameters Load Entire Line verzichtet, der zuerst das Laden des angeforderten Datumsund dann des Rests der Cache-Zeile veranlasst, um einen Cache-Zugriff im Fall eines Cache-Misszu beschleunigen.

Das Energiemodell wurde in dieser Cache-Implementierung ebenso angepasst. Existierte vor-her nur 1 Energiewert fur einen lesenden und schreibenden Zugriff, so wird nun uber 4 Ener-giewerte zwischen einem lesenden bzw. schreibenden Tag- bzw. Daten-Zugriff differenziert, umeine moglichst genaue Erfassung des Energieverbrauchs zu ermoglichen. In dieser neuen Variantekonnen der Statistik zusatzlich die Gesamtanzahl der Write Backs und die Anzahl der lesendenbzw. schreibenden Tag- bzw. Daten-Zugriffe entnommen werden.

3.4.4 Memory

Uber die Memory-Komponente werden sowohl die Speicher der privaten und gemeinsamen Slavesals auch die Prozessor-lokalen Scratchpads modelliert. Die Memory-Komponente gliedert sichdabei in die MEMSIM-Komponente Memory, eine Speicherlogik (MemoryLogic), die das Verhal-ten des Speichers bei einem Zugriff definiert, und eine MPARM-Speicherklasse, die die Datendes simulierten Speichers enthalt. Den schematischen Aufbau der Memory-Komponente zeigtAbb. 3.4. Durch dieses Vorgehen kann die Datenhaltung weiterhin in den MPARM-Klassen


realisiert und das Verhalten durch die Speicherlogik festgelegt werden. Uber verschiedenar-tige Auspragungen der Klasse MemoryLogic konnen so sowohl SRAM-, DRAM- oder Flash-Speicher simuliert werden. Im Zuge der MEMSIM-Integration wurde zunachst eine SRAM-Implementierung in Form der Klasse SRAMLogic umgesetzt. Daher sind alle Speicher, die indieser Diplomarbeit verwendet werden, ausschließlich SRAM-Speicher. Eine Erweiterung aufDRAMs wurde nur die Erweiterung der Klasse MemoryLogic und die Implementierung desDRAM-Zustandsautomaten erfordern. In der Konfiguration kann sowohl die Latenz als auchdie Zugriffsenergie des Speichers abhangig vom Zugriffstyp (lesend/schreibend) und der Bitbrei-te des Zugriffs spezifiziert werden. Ferner konnen neben der Speichergroße auch die Blockgroßeund Anzahl der Speicherbanke konfiguriert werden. Diese Daten konnen z.B. von einem DRAM-Speicher fur die Berechnung der Latenz bei einem Burstzugriff genutzt werden. Die Synchronisa-tion der Memory-Komponente und der Speicherlogik erfolgt durch die Propagierung des Taktesan die Speicherlogik durch Aufruf der clock()-Funktion. Die Memory-Komponente kann desWeiteren durch Aufruf der Funktionen hasOperationCompleted() und getOperationData()den Status des Zugriffs und, bei Abschluss eines lesenden Zugriffs, die gelesenen Daten ermitteln.

MPARM Speicherklasse

Memory

MemoryLogic (SRAM / DRAM / Flash)

Abbildung 3.4: Innere Struktur der Memory-Komponente

3.4.5 Hub

Ein Hub wird in MPARM/MEMSIM nur als Verbindungsglied zwischen einem Cache-Levelmit Instruktions- und/oder Daten-Cache und einer Nachfolgekomponente, einem Unified-Cacheoder dem AMBA AHB-Interface, eingesetzt und besitzt demzufolge einen Eingang und zweiAusgange. Sollte nur ein Instruktions- oder Daten-Cache vorliegen, so verbindet der Hub einenCache und die Wuzelkomponente mit der jeweiligen Nachfolgekomponente. Aufgrund der Funk-tionalitat eines reinen Verbindungsgliedes weist dieser Hub keine Latenz auf und leitet so je-den Speicherzugriff bzw. das Ergebnis eines Speicherzugriffs ohne Verzogerung an die jeweiligeNachfolge- bzw. Vorgangerkomponente weiter. Um dies zu bewerkstelligen, speichert der Hub beieinem eingehenden Speicherzugriff in einem internen Zustand, von welchem Eingang der Zugrifferfolgte, um so bei der Weiterleitung des Ergebnisses die entsprechende Vorgangerkomponentezu bestimmen. Wie in der ursprunglichen MEMSIM-Implementierung liegt dieser Komponenteweder ein Energiemodell zugrunde noch erfolgt eine Erhebung von Statistiken.

3.4.6 AMBA AHB-Interface

Das AMBA AHB-Interface, das ausschließlich innerhalb des MEMSIM-Master-Interface ein-gesetzt wird, verbindet das MEMSIM-Simulationssystem mit dem AMBA AHB Bus unterVerwendung der dem SystemC-Wrapper und dieser Komponente gemeinsamen Datenstruktur

3.5 Energiemodell 47

PINOUT. So setzt diese Komponente jeden Speicherzugriff, inklusive Bursts beliebiger Lange,in eine Anfrage an den AMBA AHB Bus um und delegiert eine Antwort von diesem in dasMEMSIM-Simulationssystem zuruck. Nahere Erlauterungen zum AMBA AHB-Interface findensich in 3.2.4.

3.5 Energiemodell

Die Erhebung des Energieverbrauchs erfolgt fur die ARM7-Prozessoren und den AMBA AHBBus weiterhin wie in 2.5.7 dargestellt.

Zur Erfassung des Energieverbrauchs der MPARM/MEMSIM-Caches wird zwischen einemTag- und einem Datenzugriff im lesenden und schreibenden Fall differenziert. Durch diese fein-granulare Unterscheidung entsteht ein besonders akkurates Energiemodell, ahnlich dem ur-sprunglichen MPARM-Cache-Energiemodell. Die 4 Zugriffsenergien konnen entweder manuelloder unter Verwendung von CACTI 4.2 [TTJ06] konfiguriert werden. Bei der Verwendung vonCACTI 4.2 werden diese auf Basis der MPARM/MEMSIM-Konfiguration, die voraussetzt, dassein Cache stets aus einer Speicherbank besteht, ermittelt. Dabei existieren jedoch einige Restrik-tionen seitens CACTI 4.2. Zum einen darf die Anzahl der Cache Sets 8 nicht unter- und 524288nicht uberschreiten, zum anderen wird eine Assoziativitat großer 16, mit Ausnahme eines vollas-soziativen Caches, nicht unterstutzt. Uberschreitet eine MPARM/MEMSIM-Konfiguration diesemaximale Assoziativitat, so werden uber CACTI 4.2 die Zugriffsenergien eines vollassoziativenCaches als grobe Naherung ermittelt. Wird hingegen die Anzahl der Cache Sets unter- oderuberschritten, so muss eine andere Konfiguration gewahlt werden.

Fur die Memory-Komponente, die sowohl die privaten und gemeinsamen Speicher als auchdie Prozessor-lokalen Scratchpads modelliert, kann abhangig von einem lesenden/schreibendenZugriff und der Bitbreite des Zugriffs eine Zugriffsenergie festgelegt werden. Die Festlegungdieser Zugriffsenergien kann entweder manuell oder unter Verwendung von CACTI 4.2 erfolgen.Unter Verwendung von CACTI 4.2 wird aus der Konfiguration der Komponente eine exakteZugriffsenergie fur den lesenden und schreibenden Fall fur einen reinen SRAM-Speicher ohneUnterscheidung der Bitbreite des Zugriffs ermittelt.

3.6 Statistikerfassung

Die Erfassung des Energieverbrauchs der ARM7-Prozessoren und des AMBA AHB Busses er-folgt nach wie vor wie in MPARM ohne MEMSIM-Erweiterung. Die MEMSIM-Komponenteninnerhalb der MEMSIM-Master- und MEMSIM-Slave-Interfaces erfassen alle relevanten Statisti-ken lokal. Ein Zugriff auf die durch MPARM/MEMSIM erhobenen Daten, die sowohl MPARM-als auch MEMSIM-Statistiken umfassen, ist uber die Klasse MemsimStatistics moglich. DieseKlasse ist nach ihrer Instanziierung als globales Objekt verfugbar, referenziert alle verwende-ten MEMSIM-Interfaces und extrahiert nach Abschluss einer Simulation den Energieverbrauchder ARM7-Prozessoren (ohne den Energieverbrauch der lokalen Speicher) und des AMBA AHBBusses aus den Datenstrukturen des MPARM-Simulators. Die Erfassung der benotigten Takt-zyklen einer Simulation erfolgt ebenso uber diese Klasse. Dazu wird jeder globale SystemC-Taktan MemsimStatistics uber die Funktion globalClock() propagiert.

Die Funktionen start metric() und stop metric() ermoglichen in MPARM einem Bench-mark, die Erhebung der Statistik zu einem frei wahlbaren Zeitpunkt zu starten. Durch den Aufrufvon start metric() wird im Falle eines Benchmarks ohne Betriebssystemumgebung ein SWI(Software Interrupt) ausgelost, der die Messung startet. Bei Vorhandensein einer Betriebssyste-mumgebung findet dies uber die Klasse Sim Support statt. Um dies auch in MPARM/MEMSIMzu ermoglichen, wurden der Klasse MemsimStatistics die Funktionen startMeasuring(int


id), stopMeasuring(int id) und isMeasuring(int id) hinzugefugt, um die Statistikerhe-bung fur einen Prozessor mit der Id id zu starten, zu stoppen oder festzustellen, ob diesegerade durchgefuhrt wird. In Folge dessen wurden die entsprechenden Mechanismen innerhalbvon MPARM um den Aufruf dieser Funktionen erganzt. Die Funktion isMeasuring(int id)wird ausschließlich von MEMSIM-Komponenten verwendet, um festzustellen, ob ein Zugriff inder lokalen Statistik erfasst werden soll. Dazu wird die Id der CPU, die den Speicherzugriff initi-iert hat, stets uber die Klasse MemoryAccess propagiert. Die Erfassung der globalen Taktzyklenbaut ebenso maßgeblich auf diesem Mechanismus auf, sodass der globale Zyklenzahler nur danninkrementiert wird, wenn fur mindestens einen Prozessor die Erhebung der Statistik gestartetwurde.

3.7 Simulationsstatistik

Die Simulationsstatistik des MPARM/MEMSIM-Simulators enthalt sowohl durch MEMSIM alsauch durch MPARM erfasste Messdaten, die das zu simulierende System beschreiben. Die Sta-tistik gliedert sich im Wesentlichen in eine globale, eine AMBA AHB Master-, eine AMBAAHB Slave- und eine AMBA AHB Bus-Statistik, wobei fur Master und Slaves zusatzlich dieStatistiken der lokalen Komponenten, d.h. der Caches und Speicher, aufgefuhrt werden.

Globale Statistik


• Energieverbrauch des Gesamtsystems [nJ]

• Durch Speicher induzierter Chipflachenbedarf des Gesamtsystems [mm2]

AMBA AHB Master

• Auflistung lokaler Caches, Scratchpads und derer Statistiken

• Energieverbrauch der CPU ohne den Energieverbrauch der lokalen Speicher [nJ]

• Gesamtenergieverbrauch der lokalen Caches und Scratchpads [nJ]

• Gesamtenergieverbrauch des Masters [nJ]

• Durch Speicher induzierter Chipflachenbedarf des Masters [mm2]

AMBA AHB Slave

• Auflistung lokaler Caches, des zugrunde liegenden Speichers und derer Statistiken

• Gesamtenergieverbrauch des Slaves [nJ]

• Durch Speicher induzierter Chipflachenbedarf des Slaves [mm2]

Cache

• Cache-Konfiguration

• Anzahl der Cache-Hits und Cache-Misses im lesenden und schreibenden Fall

• Anzahl lesender und schreibender Daten-Zugriffe

3.8 MPARM/MEMSIM-Adresstabelle 49

• Anzahl lesender und schreibender Tag-Zugriffe

• Cache-Performance (Relativer Anteil der Cache-Hits an allen Zugriffen)

• Anzahl der Write Backs

• Energieverbrauch [nJ]

• Chipflachenbedarf [mm2]

Memory (Slave-Speicher, Scratchpads)

• Speicherkonfiguration

• Anzahl der Zugriffe, gruppiert nach lesendem/schreibendem Zugriff und Bitbreite des Zu-griffs

• Energie fur einen Zugriff gruppiert nach lesendem/schreibendem Zugriff und Bitbreite desZugriffs [nJ]

• Energie fur alle Zugriffe gruppiert nach lesendem/schreibendem Zugriff und Bitbreite desZugriffs [nJ]

• Energieverbrauch [nJ]


AMBA AHB Bus

• Typischer Energieverbrauch [nJ]

3.8 MPARM/MEMSIM-Adresstabelle

Um die flexible und individuelle Konfigurierbarkeit der privaten und gemeinsamen Slaves undder Prozessor-lokalen Scratchpads bzgl. der Speichergroße umzusetzen, wurde die in Abb. 2.9dargestellte MMU, die durch die MPARM-Klasse Addresser funktional reprasentiert wird, mo-difiziert. Dazu wurde zunachst eine MPARM/MEMSIM-Adresstabelle zur Abbildung des fle-xiblen Adressraums in Form der Klasse AddressTable entwickelt, die der Klasse Addresserbei der Instanziierung zur Verfugung gestellt wird. Uber die Klasse AddressTable wird dazufur jede CPU, d.h. fur jeden AMBA AHB Master, und fur jeden privaten und gemeinsamenAMBA AHB Slave ein Adresstabelleneintrag in Form der Datenstruktur MasterAddressEntrybzw. SlaveAddressEntry gespeichert. Der Zugriff auf den entsprechenden Adresstabellenein-trag erfolgt uber die Id des jeweiligen Busteilnehmers. Ein MasterAddressEntry referenziertdie Adresstabelleneintrage der zugehorigen privaten Slaves und umfasst fur jedes Scratchpadein Flag, das definiert, ob dieses zum Einsatz kommt. Ist dies der Fall, so werden des Weiterendie Basisadresse und das Ende des zum Scratchpad gehorigen Adressbereichs gespeichert. EinSlaveAddressEntry beinhaltet im Wesentlichen die Basisadresse und das Ende des zum Slavegehorigen Adressbereichs. Uber die Funktionen getPhysicalAddress(uint32 addr, int id)und getLogicalAddress(uint32 addr, int id) konnen sowohl logische in physikalische alsauch physikalische in logische Adressen umgewandelt werden. Diese werden von Adresser an-statt der ursprunglichen Umrechnungsvorschrift verwendet. Insgesamt ermoglicht diese Erweite-rung die vollige Flexibilisierung der Konfigurierbarkeit der Slave-Speicher und Prozessor-lokalenScratchpads. Um jedoch die Struktur des ursprunglichen Adressraums aufrecht zu erhalten,werden die statischen Großen dieser Speicher als Obergrenzen verwendet, sodass zwar kleinere,jedoch keine großeren Speicher moglich sind (d.h. die maximale Große privater Speicher betragt12 MB, die maximale Große gemeinsamer Speicher 1 MB).


3.9 API

Zur Vereinfachung der Konfiguration der MPARM/MEMSIM-Simulationsplattform wurde eineeinfache und wohldefinierte Konfigurationsschnittstelle (API) entwickelt. Diese soll unter ande-rem eine einfache Anbindung des Simulationssystems an das am Lehrstuhl entwickelte MaCCv2Compiler Framework [MAH] ermoglichen. Uber die API kann dabei die Konfiguration einerSimulation auf Basis des AMBA AHB Busses und unter Verwendung von ARM7-Prozessorenerfolgen.

3.9.1 Konfiguration der Simulationskomponenten

Die zentrale Konfigurationsschnittstelle der API stellt die Klasse AmbaAHBSimulation dar. Uberdiese konnen der Simulation ARM7-Prozessoren und gemeinsame Slaves hinzugefugt werden.Ebenso bietet diese Klasse die Moglichkeit, eine Systemkonfiguration in eine XML-Datei zuschreiben oder diese aus einer XML-Datei zu lesen. Dies ist insbesondere deshalb sehr nutzlich,da SystemC das Starten einer Simulation nur ein einziges Mal in einem laufenden Prozessermoglicht. Durch das Schreiben der Konfiguration in eine XML-Datei kann MPARM/MEM-SIM unter Angabe dieser als Aufrufparameter in einem neuen Prozess gestartet werden. Dieglobalen Statistiken zum Energieverbrauch des Gesamtsystems, zur Anzahl benotigter Taktzy-klen und zum Chipflachenbedarf konnen ebenfalls in eine XML-Datei geschrieben werden. DieAusfuhrung einer uber die API konfigurierten Simulation erfolgt uber den Aufruf der FunktionstartSimulation().

Die Konfiguration eines ARM7-Prozessors erfolgt uber die API-Klasse CPU. Uber diese konnenunter Verwendung der Funktion addCache(const string& name, CacheType cacheType,unsigned int level) Caches hinzugefugt und so eine lokale Cache-Hierarchie konstruiert wer-den. Diese kann sich aus beliebig vielen Levels von Instruktions- und/oder Daten-Caches oderUnified-Caches unter Einhaltung der in 3.9.2 beschriebenden Nebenbedingungen zusammenset-zen. Die Prozessor-lokalen Scratchpads lassen sich uber setIScratchPadEnabled(bool enable)(Instruktionsscratchpad) bzw. setDScratchPadEnabled(bool enable) (gewohnliches Scratch-pad) aktivieren bzw. deaktivieren und uber die Memory-Klasse der API konfigurieren. PrivateSlaves konnen uber addPrivateSlave(const string& name, MemoryType memoryType) hin-zugefugt werden, wobei uber MemoryType die zu verwendende Speichertechnologie (SRAM,DRAM, Flash, etc.) festgelegt werden kann. In der aktuellen Version von MPARM/MEMSIMsind jedoch ausschließlich SRAM-Speicher verfugbar.

Private und gemeinsame Slaves werden uber die Klasse Slave parametrisiert. Dabei wirddie Konfiguration der Slave-lokalen Cache-Hierarchie und des zugrunde liegenden Speichersermoglicht. Uber addCache(const string& name) konnen der Slave-lokalen Cache-Hierarchiebeliebig viele Unified-Caches hinzufugt werden, Instruktions- und Daten-Caches sind hingegen,wie in 3.3.1 dargelegt, nicht moglich.

Die Parametrisierung eines Caches erfolgt uber die Klasse Cache. So konnen folgende Para-meter konfiguriert werden:

• Split- oder Unified-Cache: Instruktions-, Daten- oder Unified-Cache

• Cache-Level

• Cache-Große in Byte


• Assoziativitat

• Strategie bei einem Write Miss: allocate on write miss oder no allocate on write miss

3.9 API 51

• Schreibstrategie: Write Back oder Write Through

• Strategie beim Write Back : Zuruckschreiben der ganzen Zeile (Full Line Write Back) odernur der Worter mit gesetztem Dirty-Bit

• Ersetzungsstrategie: LRU, Round Robin und zufallsbasierte Ersetzungsstrategie; keine imFall eines Direct Mapped Caches

• Latenz/Wait States in Taktzyklen

• Tag-Zugriffsenergie fur lesenden/schreibenden Zugriff [nJ]

• Daten-Zugriffsenergie fur lesenden/schreibenden Zugriff [nJ]


Der Chipflachenbedarf und die Zugriffsenergien konnen manuell oder unter Verwendung vonCACTI 4.2 konfiguriert werden. Bei Verwendung von CACTI 4.2 konnen diese Daten uber dieAPI-Funktion computeAreaAndEnergy() berechnet und fur den Cache ubernommen werden. Beider Berechnung dieser Daten wird fur den Cache eine Implementierung der Gesamtkapazitat aufeiner Speicherbank angenommen.

Die Konfiguration der den privaten und gemeinsamen Slaves zugrunde liegen Speicher unddie Konfiguration der Scratchpads erfolgt uber die API-Klasse Memory. Uber diese kann folgendeParametrisierung vorgenommen werden:

• Speichertechnologie: momentan nur SRAM; erweiterbar auf zusatzliche Speichertechnolo-gien wie DRAM, Flash, etc.

• Speichergroße in Byte


• Anzahl der Speicherbanke

• Latenz/Wait States in Taktzyklen, konfigurierbar nach lesendem/schreibendem Zugriff undBitbreite des Zugriffs

• Zugriffsenergie konfigurierbar nach lesendem/schreibendem Zugriff und Bitbreite des Zu-griffs [nJ]


Der Chipflachenbedarf bzw. die Zugriffsenergien konnen auch hier manuell oder unter Verwen-dung von CACTI 4.2 uber die API-Funktion computeAreaAndEnergy() definiert werden. Beider Verwendung von CACTI 4.2 wird nur zwischen einem lesenden und schreibenden Zugriffunterschieden und somit die Zugriffsenergie fur alle Bitbreiten des Zugriffs gleich angenommen.

Neben der beschriebenen Funktionalitat ubernimmt die Klasse AmbaAHBSimulation des Wei-teren die Erzeugung des MPARM/MEMSIM-Simulationssystems. Zum einen werden, der Kon-figuration entsprechend, die MEMSIM-Master- bzw. MEMSIM-Slave-Interfaces und deren zu-gehorige MEMSIM-Simulationskomponenten erzeugt, zum anderen die MPARM-AMBA AHB-Plattform instanziiert. Die Instanziierung der AMBA AHB Master bzw. AMBA AHB Slaveserfolgt dabei unter Verwendung der zugehorigen MEMSIM-Interfaces. Des Weiteren werden ei-nige systemglobale Parameter gesetzt, wobei sich die Anzahl der Master und Slaves aus derKonfiguration ergibt. Die Anzahl der Semaphoren- und Interrupt-Slaves wird auf 1 festgesetzt,partitionierte Scratchpads werden deaktiviert.


3.9.2 Validierung

Vor dem Start einer Simulation erfolgt stets die Validierung der zugehorigen Konfiguration.Dabei wird zunachst gepruft, ob die durch die AMBA AHB-Spezifikation festgelegte maximaleAnzahl von 16 AMBA AHB Mastern (siehe 2.5.2) nicht uberschritten wird.

Fur jeden Prozessor des Systems erfolgt die Validierung der lokalen Cache-Hierarchie. Sogilt das Vorkommen eines Instruktions- oder Daten-Caches in einem Cache-Level großer 1 nurdann als valide, wenn ein Cache gleichen Typs auch im vorhergehenden Level existiert. Ebensoist das Vorkommen mehrerer Caches gleichen Typs oder eines Instruktions- und/oder Daten-Caches und eines Unified-Caches in einem Level nicht erlaubt. Neben diesen Hierarchie-globalenUberprufungen werden ebenso die Parameter eines Caches validiert (eine Erlauterung dazu er-folgt in diesem Abschnitt). Des Weiteren wird gepruft, ob die Beschrankung der Große desInstruktions-Scratchpads auf 4 MB und die Beschrankung der Große des gewohnlichen Scratch-pads auf 128 kB (CORESLAVE SPACING in MPARM) eingehalten wird. Ferner wird die Existenzmindestens eines privaten Slaves gefordert, wobei die Summe der Großen der privaten Slaves,d.h. der zugrunde liegenden Speicher, 12 MB (PRIVATE SIZE in MPARM) nicht uberschreitendarf.

Da die lokale Cache-Hierarchie eines Slaves nur Unified-Caches enthalt, stellt sich diesestets als gultig dar. Jedoch erfolgt fur jeden Slave die Validierung der Cache-Parameter (ei-ne Erlauterung dazu erfolgt in diesem Abschnitt). Im Fall eines gemeinsamen Slaves wird dieEinhaltung der Großenbeschrankung des zugrunde liegenden Speichers auf 1 MB (SHARED SIZEin MPARM) verifiziert.

Fur einen Cache wird sichergestellt, dass die Cache-Große, die Blockgroße, die Assoziativitatund die Zugriffsenergien durch wohldefinierte Werte großer 0 beschrieben werden. Des Weiterenmuss die Restriktion Blockgroße · Assoziativitat ·Wortgroße ≤ Cache-Große, die die Existenzmindestens eines Cache Sets fordert, stets erfullt sein, wobei sowohl die Blockgroße als auch dieAssoziativitat als 2er-Potenzen vorliegen mussen.

Der Zusammenhang Blockgroße ·Assoziativitat ·Wortgroße ≤ Cache-Große (min. ein CacheSet) muss ebenso stets erfullt sein, wobei sowohl die Blockgroße als auch die Assoziativitat2er-Potenzen sind.

Fur eine Memory-Komponente wird die Konfiguration der Speichergroße, der Blockgroße, derAnzahl der Speicherbanke, der Zugriffslatenzen und der Zugriffsenergien uberpruft. Zum einenist ein Parameterwert von 0 nicht erlaubt, zum anderen wird gefordert, dass sich Speichergroßeund Blockgroße, Blockgroße und Wortgroße, Speichergroße und Wortgroße und Speichergroßeund Anzahl der Banke stets ohne Rest dividieren lassen.

3.9.3 Beispiel einer Konfiguration unter Verwendung der API

Das folgende Beispiel zeigt die Verwendung der API zur Konfiguration eines Simulationssystems,das einen ARM7-Prozessor, der uber einen L1 Unified-Cache verfugt, und einen privaten Slaveohne lokale Caches verwendet:

// create simulation

AmbaAHBSimulation* sim = new AmbaAHBSimulation ();

// add CPU

CPU* cpu = sim ->addCPU("ARM_0",CPU::ARM7);

// create unified cache

Cache* ucache = cpu ->addCache("L1 U-Cache",UCache ,1);ucache ->setSize (8192);ucache ->setBlockSize (4);ucache ->setAssociativity (2);

3.9 API 53

ucache ->setAllocateOnWriteMiss(false);ucache ->setReplacementPolicy(LRU);ucache ->setWritePolicy(WRITE_BACK );ucache ->setFullLineWriteBack(false);ucache ->setWaitStates(READ ,0);ucache ->setWaitStates(WRITE ,0);ucache ->computeAreaAndEnergy ();

// add private slave to CPU

Slave* slave = cpu ->addPrivateSlave("Private Slave ARM_0",SRAM);slave ->getMemory()->setSize(PRIVATE_SIZE );Memory* mem = slave ->getMemory ();mem ->setBanks (4);mem ->setBlockSize (512);mem ->setWaitStates(READ ,BYTE ,10);mem ->setWaitStates(READ ,HALFWORD ,10);mem ->setWaitStates(READ ,WORD ,10);mem ->setWaitStates(WRITE ,BYTE ,10);mem ->setWaitStates(WRITE ,HALFWORD ,10);mem ->setWaitStates(WRITE ,WORD ,10);mem ->computeAreaAndEnergy ();

// start simulation

sim ->startSimulation ();

Listing 3.1: Beispiel einer Simulationskonfiguration unter Verwendung der API

3.9.4 Schnittstelle zur Visual MEMSIM-Systemkonfiguration

Neben der Konfiguration einer MPARM/MEMSIM-Simulation uber die API, kann ebenso ei-ne MEMSIM-Konfiguration, die uber die grafische, graphenbasierte KonfigurationsschnittstelleVisual MEMSIM konfiguriert und in einer XML-Datei gespeichert wurde, unter gewissen Ein-schrankungen eingelesen werden.

Abbildung 3.5: Visual MEMSIM-Beispielkonfiguration


Dabei wird zunachst jeder Prozessor als ARM7-Prozessor interpretiert. Alle einem Prozessornachfolgenden Caches werden diesem zugeordnet, wobei Cache-Hierarchien mit Instruktions-und/oder Daten-Caches oder Unified-Caches moglich sind. Im Fall von privaten oder gemeinsa-men Slaves ist die Verwendung von Caches nicht moglich. Jede Memory-Komponente der VisualMEMSIM-Konfiguration wird als privater oder gemeinsamer Slave interpretiert, wobei die Klas-sifikation in private oder gemeinsame Slaves uber die Anzahl der Prozessoren, die von einerMemory-Komponente erreichbar sind, erfolgt, wenn der Konfigurationsbaum von den Blatternzu den Wurzelknoten durchlaufen wird. Ist diese eins, so handelt es sich um einen privaten,ansonsten um einen gemeinsamen Slave. Abb. 3.5 zeigt ein Beispiel einer Visual MEMSIM-Konfiguration, in dem zwei CPUs mit lokalen Caches, ein privater Slave pro CPU und eingemeinsamer Slave verwendet werden.

3.10 Korrektheit

Die Korrektheit der Integration von MEMSIM in MPARM wurde auf vielfaltige Art und Weisegepruft. Bei der Integration in die SWARM-Struktur wurden dazu die Adressen und Daten, dievom Prozessorkern (CArmCore) zum Prozessor-lokalen Bus und vom Prozessor-lokalen Bus zumProzessorkern ubertragen werden, in eine Datei geschrieben. Dies geschah sowohl fur MPARMohne als auch fur MPARM mit MEMSIM-Erweiterung, wobei in einem ersten Validierungs-chritt MPARM/MEMSIM ohne Caches ausgefuhrt wurde, um den Einfluss moglicher Fehler inder Cache-Implementierung auszuschließen. Die Ausgabedateien wurden daraufhin solange ver-glichen, bis eine absolute Ubereinstimmung vorlag. Anschließend erfolgte dieselbe Prufung unterVerwendung der Caches, wobei auch dieser Schritt erfolgreich mit einer Ubereinstimmung abge-schlossen werden konnte, sodass zunachst induktiv die Korrektheit fur alle Konfigurationsfallegefolgert wurde. Im Fall der Slaves war keine solch aufwendige Validierung notwendig, da dieIntegration nicht mit der Anderung eines komplexen Zustandsautomaten, sondern nur mit einemFunktionsaufruf am MEMSIM-Slave-Interface verbunden ist.

Die Korrektheit der gesamten Integration wurde des Weiteren durch weit mehr als 400000Simulationen im Rahmen der automatisierten Design Space Exploration, auf die in Kapitel 4naher eingegangen wird, gepruft. Dies geschah sowohl fur Ein- als auch fur Multiprozessor-Systeme. Ein direkter Vergleich zwischen der ursprunglichen MPARM-Implementierung undMPARM/MEMSIM wird anhand ausgewahlter Benchmarks in 5.2 durchgefuhrt.

3.11 Aufruf von der Kommandozeile

MPARM/MEMSIM kann uber die Kommandozeile unter Verwendung verschiedener Parameteraufgerufen werden. Grundsatzlich wird dabei zwischen einer Simulation und der Durchfuhrungeiner Design Space Exploration (siehe Kapitel 4) unterschieden. Im Fall einer Simulation wirdsowohl die Verwendung der MPARM-Standard-Konfiguration, als auch das Einlesen einer sys-tembeschreibenden XML-Datei unterstutzt, die sowohl dem API-Standard als auch einer Vi-sual MEMSIM-Konfiguration entsprechen kann. Es ergeben sich folgende Aufrufparameter furMPARM/MEMSIM.

• --ms [m | d]: m: Simulation (measurment) - ohne Angabe einer XML-Datei wird dieStandard-Konfiguration verwendet; d: Durchfuhrung einer Design Space Exploration

• --ms xml <xmldatei>: Im Fall einer Simulation wird diese XML-Datei als Systembe-schreibung im API-Format interpretiert, auch Visual MEMSIM-Konfigurationen sind mog-lich (siehe --ms vm). Im Fall einer Design Space Exploration wird diese XML-Datei alsGrundkonfiguration (siehe 4.3.3) interpretiert.

3.11 Aufruf von der Kommandozeile 55

• --ms vm: Die XML-Datei wird als Visual MEMSIM-Konfiguration interpretiert.

• --ms ss: Gibt die Simulationsstatistik nach Abschluss der Simulation aus.

• --ms ws <xmldatei>: Schreibt die globale Simulationsstatistik (Energieverbrauch, An-zahl benotigter Taktzyklen, Chipflachenbedarf) in die angegebene XML-Datei.

Neben den genannten Aufrufparametern fur MPARM/MEMSIM besteht auch die Moglichkeit,den ursprunglichen MPARM-Simulator zu starten.

Kapitel 4

Design Space Exploration

In diesem Kapitel wird, aufbauend auf der Erweiterung des MPARM System-on-Chip Simula-tors, die Moglichkeit einer automatisierten Design Space Exploration unter Verwendung Evolu-tionarer Algorithmen zur mehrkriteriellen Optimierung untersucht. Unter Design Space Explo-ration wird dabei die Evaluation moglicher Design-Alternativen des SoC wahrend des Design-Prozesses verstanden. In dieser Diplomarbeit werden zwei Optimierungsansatze fur eingebetteteSysteme untersucht, die stets die Minimierung des Energieverbrauchs, der benotigten Taktzy-klen (Ausfuhrungszeit) und des Chipflachenbedarfs als Optimierungsziel verfolgen. Zum einenwird auf Basis einer Grundkonfiguration der MPARM/MEMSIM-Simulationplattform und aus-gewahlter Zielanwendungen, die die gewunschte Funktionalitat des zu optimierenden Systemshinreichend beschreiben, eine Optimierung der Cache-Hierarchie und Cache-Parameter vorge-nommen. Da die Verwendung kleiner, energieeffizienter Scratchpadspeicher ebenso ein großesOptimierungspotential im Bereich eingebetteter Systems aufweist, wird zum anderen fur einMPARM/MEMSIM-Referenzsystem auf Basis ausgewahlter Zielanwendungen die Approximati-on der optimalen statischen Scratchpad-Allokation untersucht.

4.1 Explorationsziele und Annahmen

Wie bereits im Vorwort dieses Kapitels erwahnt, werden zwei Optimierungsansatze aufbauendauf der um MEMSIM erweiterten Version des MPARM System-on-Chip Simulators verfolgt:

1. Optimierung der Speicherhierarchie (Cache-Hierarchie) auf Basis einer Grundkonfigurationdes SoC und ausgewahlter Zielanwendungen

2. Optimierung der statischen Scratchpad-Allokation auf Basis eines Referenzsystems desSoC und ausgewahlter Zielanwendungen

Das in dieser Diplomarbeit eingesetzte Optimierungsverfahren evaluiert eine mogliche Losung(Speicherhierarchie/Scratchpad-Allokation) stets nach folgenden drei Kriterien, die die zu mini-mierenden Optimierungsgroßen Fi(x) darstellen:

• Energieverbrauch des Gesamtsystems

• Anzahl benotigter Taktzyklen (Ausfuhrungszeit)

• Chipflachenbedarf (durch Speicher induziert)

Da eine Optimierung nur anwendungsspezifisch erfolgen kann, werden zur Optimierung stetsausgewahlte C-Applikationen (Zielanwendungen) herangezogen, die die gewunschte Funktiona-litat des zu optimierenden Systems widerspiegeln. Dieser Ansatz baut auf der Annahme auf, dass

57

58 4 Design Space Exploration

die Anforderungen und der Funktionsumfang eingebetteter Systems zur Entwicklungszeit weitge-hend bekannt sind. Diese Applikationen werden dabei unter Verwendung des arm-gcc Compilersfur die MPARM/MEMSIM-Simulationsplattform cross-kompiliert und wahrend des Optimie-rungsprozesses auf dieser zur Ausfuhrung gebracht. Im Fall der Speicherhierarchie-Optimierungbleibt der Binarcode einer Applikation unverandert, im Fall der Scratchpad-Allokation wirddieser durch die Auslagerung ausgewahlter globaler Funktionen und Variablen mit jeder Aus-wertung verandert. Der Workflow der Optimierungsansatze wird detailliert in 4.4.1 bzw. 4.5.1erlautert. Es ist des Weiteren zu beachten, dass insbesondere die Optimierung der Speicherhier-archie unter der Annahme statischer Eingabedaten aufgrund von vornherein festgelegter Zielan-wendungen erfolgt. Im allgemeinen Fall andern sich diese dynamisch und damit meist auch dieKomplexitat des zugrunde liegenden Problems. Es werden daher im Rahmen dieser Diplomar-beit Anwendungsfalle untersucht, die eine von der Eingabe relativ unabhangige Komplexitataufweisen. Ebenso wird im Rahmen der Speicherhierarchie-Optimierung grundsatzlich eine ein-zige Zielanwendung pro CPU zur Evaluation herangezogen, sodass verschiedenartige funktionaleAnforderungen nicht reprasentiert werden. Eine Erweiterung kann jedoch uber eine Verkettungmehrerer Anwendungen erfolgen. Aufgrund der ohnehin schon hohen Komplexitat der in dieserDiplomarbeit verwendeten Optimierungsansatze wird jedoch darauf verzichtet. Die genanntenPunkte stellen jedoch fur die Optimierung der Scratchpad-Allokation keine Einschrankung dar,da fur die Auslagerung von Daten und Instruktionen diese a-priori bekannt sein mussen.

Da die mehrkriteriellen Optimierungsprobleme dieser Diplomarbeit die Funktionswerte Fi(x)aus einer MPARM/MEMSIM-Simulation beziehen und somit inharent kein funktionaler Zusam-menhang zwischen der Parametrisierung und den zugehorigen Funktionswerten besteht, werdenzur Losung Evolutionare Algorithmen zur mehrkriteriellen Optimierung herangezogen. Es exis-tieren verschiedene Evolutionare Algorithmen zur mehrkriteriellen Optimierung, darunter PE-SA [CKO00], NGSA-II [DAPM00] und SPEA2 [ZLT01]. Im Allgemeinen zeigen NGSA-II undSPEA2 bessere Ergebnisse als PESA, wobei NGSA-II und SPEA2 meist eine vergleichbar hoheGute aufweisen. Da SPEA2 in [ACP04] bereits fur ein ahnliches Optimierungsproblem eingesetztwurde, wird dieses Optimierungsverfahren ebenso in dieser Diplomarbeit verwendet.

4.2 Verwandte Arbeiten

Im Wesentlichen existiert in der Literatur kein Ansatz, der die Optimierung einer Speicherhier-archie und der zugehorigen Parameter vornimmt. Ascia et al. liefert jedoch in [ACP04] einen An-satz, der in dieser Diplomarbeit fur die Losung des Problems der Speicherhierarchie-Optimierungadaptiert und erweitert wurde. [ACP04] untersucht im Rahmen der Design Space Explorati-on einer parametrisierbaren System-on-Chip Plattform, die in Form eines Simulators vorliegt,die Optimierung der Hardware-Architektur bzgl. der Optimierungsgroßen Ausfuhrungszeit undEnergieverbrauch auf Basis ausgewahlter Zielanwendungen, die die gewunschte Funktionalitatdes Systems widerspiegeln. Die Optimierung findet dabei unter Verwendung von SPEA2 und aufBasis eines genetischen Ansatzes statt, der zum einen die Simulationsplattform Platune [DAH],die auf einem RISC-Mikroprozessor basiert, und zum anderen eine auf einem VLIW (Very LongInstruction Word) Prozessor basierende Simulationsplattform verwendet. Beide Plattformen stel-len ein Framework zur Simulation und Abschatzung der Ausfuhrungszeit und des Energiever-brauchs einer in C geschriebenen Applikation bereit.

Der Optimierungsansatz, der auf Platune aufsetzt, verwendet als Basissystem einen R3000MIPS Prozessors, einen L1 Instruktions-, einen L1 Daten-Cache und einen Hauptspeicher. Dabeiwerden die Cache-Große (128 Byte bis 128 kB), die Assoziativitat (1 bis 16), die Blockgroße (4bis 64 Byte) und Adress- bzw. Datenbus-Parameter (Kodierung, Bitbreite der Busleitungen)als variable Großen (insgesamt 19) des Genetischen Algorithmus aufgefasst. Die Performanceund die Gute der ermittelten Losung wird uber die Anzahl der benotigten Simulationen und die

4.3 Generelle Umsetzung und globale Kriterien 59

mittlere prozentuale Distanz zur tatsachlichen Pareto-optimalen Menge (diese kann durch Pla-tune berechnet werden) ermittelt. Die verwendeten Zielanwendungen entstammen dem MotorolaPowerstone Benchmark, der eine Vielzahl eingebetteter Applikationen enthalt.

Unter Verwendung der parametrisierbaren VLIW-Plattform konnen 18 Parameter variiertwerden. Uber diese konnen der Registersatz, funktionale Einheiten (Integer Unit, Floating PointUnit, Branch Units und Memory Units), ein L1 Instruktions-, ein L1 Daten- und ein L2 Unified-Cache parametrisiert werden. Da sich die Berechnung der exakten Pareto-optimalen Menge indiesem Fall komplexer darstellt, werden die Konfiguration des Prozessors und des L2 Cachesals unveranderlich betrachtet und nur die Parameter der L1 Caches variiert. Die Bewertungder Performance und Gute der Losung erfolgt ebenso uber die Anzahl benotigter Simulatio-nen und die mittlere prozentuale Distanz zur tatsachlichen Pareto-optimalen Menge, wobei dieZielanwendungen ebenso dem Motorola Powerstone Benchmark entnommen wurden.

Zusatzlich zur Optimierung der Speicherhierarchie wird in dieser Diplomarbeit die Berech-nung einer naherungsweise optimalen Scratchpad-Allokation auf Basis eines Referenzsystems desSoC und ausgewahlter Zielanwendungen untersucht. Im Folgenden werden einige Ansatze zurBerechnung einer optimalen Scratchpad-Allokation auf Basis von ILPs vorgestellt.

[SWLM02] ermittelt eine optimale statische Allokation des Scratchpad fur Funktionen (In-struktionen) und globale Variablen (Daten) durch Losen des zugehorigen ILPs (ganzzahligelineare Optimierung, siehe 2.6.1). Fur Funktionen wird dabei die Auslagerung der zugehorigenBasisblocke untersucht. Insgesamt kann dieses Optimierungsproblem als Rucksackproblem mitder Scratchpadgroße als Rucksackgroße und der Energieeinsparung durch Auslagerung einer Va-riable oder eines Basisblocks als Nutzenfunktion formuliert werden. Die Ermittlung des Energie-verbrauchs erfolgt uber eine Simulation unter Verwendung von ARMulator (siehe 2.4.1), wobeidie Zugriffsenergien der Speicher CACTI entnommen werden. [VWM04] stellt eine dynamischeErweiterung des statischen Ansatzes aus [SWLM02] vor, in der Instruktionen und Daten zurLaufzeit zur Minimierung des Energieverbrauchs in den Scratchpad ausgelagert werden. Die-ses Problem lasst sich als Erweiterung des globalen Registerallokations-Problems uber ein ILPformulieren.

Im Gegensatz zu den vorgestellten ILP-basierten Optimierungsansatzen, wird in dieser Di-plomarbeit ein heuristischer Ansatz zur statischen Allokation globaler Funktionen und Variableneiner Zielanwendung unter Verwendung Genetischer Algorithmen verfolgt, wobei Funktionenstets als Ganzes ausgelagert werden. Eine Auslagerung von Basisblocken ist nicht moglich, da indiesem Fall zusatzlicher Code (sog. Spill Code) fur Sprunge aus dem Adressbereich des Scratch-pads in den des Hauptspeichers und umgekehrt eingefugt werden musste, der Genetische Algo-rithmus jedoch eine Optimierung ohne Kenntnis des zugrunde liegenden Problems vornimmt.Eine detaillierte Beschreibung dieser Optimierung liefert 4.5.

4.3 Generelle Umsetzung und globale Kriterien

In diesem Abschnitt werden die generelle Umsetzung der Optimierungsansatze und globale Op-timierungskriterien erlautert, bevor in den nachsten Abschnitten jeder der zwei Optimierungs-ansatze im Detail vorgestellt wird.

4.3.1 Evolutionarer Ansatz unter Verwendung von SPEA2

Unter der Verwendung von SPEA2 ergeben sich an vielen Stellen Freiheitsgrade. So sind z.B. dieMutations- und Rekombinationsoperatoren Problem-spezifisch zu wahlen. Auch der Evolutions-prozess an sich kann sich an Evolutionsstrategien oder Genetischen Algorithmen orientieren. ImFolgenden werden kurz die wichtigsten Prinzipien des Evolutionaren Ansatzes in SPEA2 unddamit die Ausnutzung der Freiheitsgrade beschrieben.


Der Evolutionare Ansatz dieser Diplomarbeit unter Verwendung von SPEA2 baut auf demKonzept der Genetischen Algorithmen auf und verwendet eine globale Mutationswahrschein-lichkeit pM und eine globale Rekombinationswahrscheinlichkeit pR. Wird keine Rekombinationdurchgefuhrt, so werden alle Individuen der aktuellen Population in die nachste ubernommen.Eine Mutation wird in diesem Fall auf der aktuellen Population ausgefuhrt. Findet eine Rekombi-nation statt, so werden stets aus zwei Individuen des Mating Pools zwei neue Individuen erzeugt.Findet eine Mutation statt, so wird diese auf der ganzen Population durchgefuhrt. Des Weiterenkann der Abbruch der Evolution durch eine vorher festgelegte Anzahl an Evolutionszyklen oderdurch das Konvergenzkriterium (siehe 4.3.4) bestimmt werden.

4.3.2 TEA Library

Zur Implementierung der beschriebenen Optimierungsansatze wird im Rahmen dieser Diplom-arbeit die C++ TEA Library (Toolbox for Evolutionary Algorithms) [EH] verwendet. Die Ver-wendung dieser Bibliothek vermindert den Implementierungsaufwand erheblich, da so auf einemvorhandenen Klassenkonstrukt, das die Struktur mono- und mehrkriterieller Evolutionarer Algo-rithmen sehr gut widerspiegelt und sich als sehr gut erweiterbar erweist, aufgebaut werden kann.Des Weiteren verfugt die TEA Library uber Funktionen zur Generierung gleich- und normal-verteilter Zufallswerte. Aufgrund einer existierenden Implementierung des SPEA2-Algorithmuskonnen ebenso viele Klassen, z.B. das SPEA2-Archiv, wiederverwendet werden. Jedoch wurdenfur die Umsetzung der Optimierungsansatze auf Basis von SPEA2 eigene Implementierungen derIndividuen, der Population und der zugehorigen Operatoren vorgenommen, um das gewunschteEvolutionsverhalten sicherzustellen. Diese werden im Folgenden jedoch nicht weiter erlautert,da sie nur die Grundstruktur zur Umsetzung des SPEA2-Algorithmus darstellen. Die entschei-denden Problem-spezifischen Reprasentationen und zugehorigen Operatoren werden in 4.4 und4.5 beschrieben.

4.3.3 Grundkonfiguration

Fur jede der beiden Optimierungen kann eine Grundkonfiguration festgelegt werden. In diesemAbschnitt werden jedoch nur die globalen Parameter erwahnt, Problem-spezifische Parameterfinden sich in den jeweiligen Abschnitten der Speicherhierarchie-Optimierung und Scratchpad-Allokations-Optimierung. Folgende globale Parameter sind dabei spezifizierbar:

• Optimierung der Speicherhierarchie/Scratchpad-Allokation (entweder oder)

• Populationsgroße N (die Archivgroße N entspricht stets der Populationsgroße)

• Anzahl auszuwertender Generationen/Evolutionszyklen: Bei einem Wert ≥ 0 wird dieserals Abbruchkriterium fur die Anzahl der auszufuhrenden Evolutionszyklen interpretiert,bei einem Wert < 0 wird das Konvergenzkriterium angewendet (siehe 4.3.4)

• Konvergenzparameter G, T , O (nur gultig bei einer Generationenzahl < 0; siehe 4.3.4)

• Reellwertige Gewichtungsparameter wenergy, wcycles, warea zur Auswahl des Ergebnis-Individuums (siehe 4.3.5)

• Rekombinationswahrscheinlichkeit pR ∈ [0, 1]

• Mutationswahrscheinlichkeit pM ∈ [0, 1]

Die vollstandige Grundkonfiguration (globale und Problem-spezifische Parameter) wird stetsin Form einer XML-Datei spezifiziert, die der Design Space Exploration als Eingabe dient. Dasfolgende Beispiel zeigt eine globale Grundkonfiguration, wobei <system opt def> (Optimierung

4.3 Generelle Umsetzung und globale Kriterien 61

der Speicherhierarchie) und <spm opt def> (Optimierung der statischen Scratchpad-Allokation)Problem-spezifische Konfigurationen andeuten, die in 4.4.2 und 4.5.2 naher erlautert werden:

<ga_base_def ><param name="system_opt" value="1"/><param name="spm_opt" value="0"/><param name="populationSize" value="50"/><param name="generations" value="-1"/><param name="t_T" value="0.1"/><param name="t_G" value="5"/><param name="t_O" value="3"/><param name="eval_weight_energy" value="1"/><param name="eval_weight_cycles" value="1"/><param name="eval_weight_area" value="1"/><param name="recombineProb" value="0.7"/><param name="mutationProb" value="0.6"/>

<system_opt_def >...</system_opt_def >

<spm_opt_def >...</spm_opt_def >

</ga_base_def >

Listing 4.1: Beispiel einer globalen Grundkonfiguration

4.3.4 Konvergenzkriterium

Das Konvergenzkriterium, das festlegt, ob der Evolutionsprozess des Evolutionaren Algorithmusabgebrochen werden kann, wurde [ACP04] entnommen. Die Grundidee ist dabei, die Evolutiongenau dann abzubrechen, wenn keine nennenswerte Verbesserung in der Menge nicht-dominierterIndividuen mehr erreicht werden kann.

Das Konvergenzkriterium verwendet dazu eine Funktion fcov (function of coverage), die dasrelative Maß an Uberdeckung bzw. Dominanz zwischen zwei Mengen nicht-dominierter Indivi-duen angibt. Seien C ′ und C ′′ zwei Mengen nicht-dominierter Individuen, dann ist fcov wie folgtdefiniert:

fcov(C ′, C ′′) =|{I ′′ ∈ C ′′ | ∃I ′ ∈ C ′ : I ′ � I ′′}|

|C ′′|

Dabei beschreibt I ′ � I ′′ die Uberdeckung von I ′′ durch I ′. Die Relation � ist als Erweiterungder Pareto-Dominanz-Relation ≺p um den Fall der Gleichheit anzusehen. Seien I ′ und I ′′ zweiIndividuen und x′ und x′′ die zugehorigen Elemente des Phanotypraums, dann gilt:

I ′ � I ′′ ⇐⇒ ∀i : Fi(x′) ≤ Fi(x′′)

Im Fall fcov(C ′, C ′′) = 1 werden alle Losungen aus C ′′ durch C ′ dominiert, in der umgekehrtenSituation fcov(C ′, C ′′) = 0 wird keine Losung aus C ′′ durch eine Losung aus C ′ dominiert. Sei imFolgenden nun Ci die Menge nicht-dominierter Individuen in der Generation i und G ≥ 0, G ∈ N.Dann ist der Konvergenzindex q(i, G) wie folgt definiert:

q(i, G) = fcov(Ci+G, Ci)− fcov(Ci, Ci+G) ≥ 0


Mit anderen Worten definiert der Konvergenzindex die Differenz der relativen Uberdeckungvon Ci durch Ci+G, d.h. die Uberdeckung der Menge nicht-dominierter Individuen einer alterenGeneration durch eine jungere Generation, und der relativen Uberdeckung von Ci+G durchCi, d.h. die Uberdeckung der Menge nicht-dominierter Individuen einer jungeren Generationdurch eine altere Generation. Da der Evolutionsprozess keine Verschlechterung der Menge nicht-dominierter Individuen herbeifuhrt, gilt stets:

fcov(Ci+G, Ci) ≥ fcov(Ci, Ci+G)⇒ q(i, G) ≥ 0

Schlussendlich wird der Evolutionsprozess abgebrochen, wenn keine nennenswerte Verbes-serung der Menge nicht-dominierter Individuen im Intervall von G Generationen beobachtetwerden konnte und dies auch fur weitere O Beobachtungen der Fall ist. Sei T ein benutzer-definierter Schwellwert und g die erste Generation, fur die q(g,G) ≤ T gilt, dann wird derEvolutionsprozess abgebrochen, wenn gilt:

q(g,G) ≤ T, q(g +G,G) ≤ T, ..., q(g +OG,G) ≤ T

Grundsatzlich ist zu beachten, dass ein kleiner Konvergenzindex q(i, G) auch durch die Tat-sache bedingt sein kann, dass die Populationsgroße a-priori zu klein gewahlt wurde und somitdie gegenseitige Uberdeckung der Mengen C ′ und C ′′ sehr groß ist. Wurde diese hingegen hinrei-chend groß gewahlt, so kann dem Konvergenzindex das Maß an Verbesserung im Abstand vonG Generationen entnommen werden.

4.3.5 Auswahl einer Losung aus der Pareto-Front

Da fur beide Optimierungsprobleme SPEA2 zur mehrkriteriellen Optimierung zum Einsatzkommt, stellt sich das Optimierungsergebnis als Menge nicht-dominierter Individuen bzgl. derPareto-Dominanz-Relation ≺p (siehe 2.6.3.9) dar. Aus dieser Pareto-Front ist bzgl. der Anforde-rungen an das zu optimierende System ein Ergebnisindividuum auszuwahlen, das diesbezuglichals optimal gilt. Der Ansatz dieser Diplomarbeit ermoglicht dem Designer dazu die Spezifikationvon Gewichtungsparametern, mit Hilfe derer die Relevanz der Optimierungsgroßen Energie-verbrauch, Anzahl benotigter Taktzyklen (Ausfuhrungszeit) und Chipflachenbedarf spezifiziertwerden kann. Die Gewichtung findet dabei auf den normierten Vektoren der Optimierungsgroßenstatt. Sei v ein Vektor der Optimierungsgroßen Fi(x), d.h. v = (venergy, vcycles, varea) zu einemIndividuum I. Dann lasst sich der Vektor v durch Normierung und Gewichtung wie folgt in denVektor v′ transformieren:

v′ = W N v

wobei N die Normierungsmatrix mit den Maximalwerten der Optimierunsgroßen (in derPareto-Front) auf der Hauptdiagonalen

N =

1/energymax 0 00 1/cyclesmax 00 0 1/areamax

und W die Gewichtungsmatrix mit den Gewichtungsparametern auf der Hauptdiagonalen

W =

wenergy 0 00 wcycles 00 0 warea

darstellt.

4.4 Optimierung der Speicherhierarchie 63

Die Normierung, ohne die eine Gewichtung nicht moglich ware, wird durch die unterschied-lich großen Wertebereiche der Fi(x) erforderlich. Die Gewichtung entspricht des Weiteren einerStreckung bzw. Stauchung des Losungsraums. Die Auswahl einer Losung erfolgt dann uber dieBerechnung des Vektors v′ mit minimalem quadratischen Abstand um Ursprung 0:

argminv′

v′2

Uber den Vektor v′ kann dann unmittelbar auf das zugehorige Individuum geschlossen wer-den.

4.3.6 Ausgabe des Optimierungsverfahrens

Die Ausgabe des implementierten Optimierungsverfahrens besteht aus verschiedenen Elementen.So wird zum einen die Grundkonfiguration, die initiale Population, die Menge nicht-dominierterIndividuen und das Ergebnisindividuum nach Erfullung des Konvergenzkriteriums in die Da-tei ga result.txt geschrieben. Zum anderen werden die Optimierungsgroßen Energieverbrauch,Anzahl benotigter Taktzyklen und Chipflachenbedarf der initialen Population und der appro-ximierten Pareto-Menge in den CSV Dateien ga initial.csv und ga result.csv gespeichert undsind so fur eine spatere Auswertung leicht zu verarbeiten. Durch die Ausgabe der approxi-mierten Pareto-Menge kann leicht eine andere Gewichtung der Optimierungsziele ohne erneuteAusfuhrung des Optimierungsalgorithmus durchgefuhrt werden. Auf der Kommandozeile erfolgtdie Ausgabe des Ergebnisindividuums, das bzgl. der Designziele (Spezifikation uber Gewich-tungsparameter) optimal ist. Zusatzlich wird zur Uberwachung des Evolutionsprozesses jedesevaluierte Individuum und der Konvergenzindex (nach jeweils G Generationen) in die Dateiga.log geschrieben.

4.4 Optimierung der Speicherhierarchie

In diesem Abschnitt wird die Optimierung der Speicherhierarchie eines SoC auf Basis einerGrundkonfiguration des Systems und ausgewahlter Zielanwendungen, die, so die Annahme, dieAnwendungsdomane des zu optimierenden Systems hinreichend beschreiben, erlautert. Im Ge-gensatz zur Arbeit von [ACP04], die neben den Parametern einer fixen Speicherhierarchie auchweitere Architekturparameter zur Optimierung des Systems mit den Zielgroßen Energiever-brauch und Ausfuhrungszeit evaluiert, fokussiert sich diese Diplomarbeit auf die Optimierung derCache-Hierarchie und der zugehorigen Cache-Parameter. Dabei werden nicht nur die Parametereiner fixen Cache-Hierarchie bzgl. der Zielgroßen optimiert, sondern auch die Hierarchie selbst.Die gleichzeitige Optimierung von Cache-Hierarchie und Cache-Parametern stellt einen, nacheingehender Recherche, bisher nicht existierenden Ansatz dar, der sich durch die ergebendenFreiheitsgrade als sehr komplex darstellt. Aufgrund der speziellen Form der Reprasentation undder daraus resultierenden Operatoren zur Mutation und Rekombination wird diese Optimierungkeinem klassischen Genetischen Ansatz entsprechen, sondern eine Variation dessen verwenden.Daher wird in diesem Abschnitt stets der Oberbegriff des Evolutionaren Algorithmus verwendet.Des Weiteren bezieht sich im Folgenden der Begriff der Speicherhierarchie-Optimierung stets aufdie Optimierung der Cache-Hierarchie und der zugehorigen Cache-Parameter unter Verwendungeiner statischen Grundkonfiguration des Systems.

4.4.1 Workflow

Bevor nun dieser Optimierungsansatz im Detail erlautert wird, wird zunachst der zugehorigeWorkflow erlautert, der in Abb. 4.1 dargestellt ist. Ausgewahlte C-Applikationen (Zielanwen-dungen) werden dabei zunachst mit Hilfe des arm-gcc Cross-Compilers kompiliert und dienen


dem MPARM/MEMSIM-Simulationssystem wahrend des Optimierungsprozesses unverandertals Eingabe. Der Evolutionare Algorithmus zur Optimierung der Speicherhierarchie operiert aufder in 4.3.3 und 4.4.2 erlauterten Grundkonfiguration (Basissystem, Wahrscheinlichkeiten, Po-pulationsgroße, etc.). Dabei erzeugt dieser zunachst zufallsbasiert eine initiale Population vonIndividuen (siehe 4.4.6), die jeweils eine Auspragung einer Speicherhierarchie reprasentieren (sie-he 4.4.3). Diese Population wird unter Verwendung des MPARM/MEMSIM-Simulationssystemsauf Basis der Grundkonfiguration des Systems und der ausgewahlten Zielanwendungen bzgl. derOptimierungsgroßen Energieverbrauch, Anzahl benotigter Taktzyklen (Ausfuhrungszeit) undChipflache evaluiert (siehe 4.4.5). Im Zuge der Evolution werden Selektion, Rekombination (sie-he 4.4.7) und Mutation (siehe 4.4.8) auf der Population bzw. dem Archiv durchgefuhrt und dieresultierende Population abermals unter Verwendung von MPARM/MEMSIM evaluiert. DieserProzess wird solange fortgefuhrt, bis das Konvergenzkriterium (siehe 4.3.4) erfullt ist. Schlus-sendlich erfolgt die Auswahl des Ergebnisindividuums aus der Pareto-Front (siehe 4.3.5).

Ziel-anwendungen

arm-gcc Cross-Compiler

MPARM / MEMSIM

Grund-konfiguration

Simulationsergebnisse

EvolutionärerAlgorithmus

Population /Archiv

Menge nicht-dominierter Individuen

Auswahl einer Lösung

Approx. optimales Individuum bzgl. des

Designziels

Gewichtung

Konvergenz

Ausführbare Dateien

Initialisierung

Selektion /Rekombination /

Mutation

Evaluation

CACTI 4.2(Energie,

Chipfläche)

Abbildung 4.1: Workflow zur Optimierung der Speicherhierarchie


Neben den Zielanwendungen konnen weitere Parameter des zu optimierenden Systems von vorn-herein festgelegt werden und bleiben wahrend des Optimierungsprozesses konstant. Dies sind furden speziellen Fall der Speicherhierarchie-Optimierung, neben den in 4.3.3 erwahnten Problem-unspezifischen Parametern, die folgenden:

• Minimal-/Maximalwerte der Cache-Parameter: Cache-Große (der Maximalwert wird stetsauf die Große des zu cachenden Speichers reduziert), Blockgroße, Assoziativitat (alle Wertewerden als Exponent einer Zweierpotenz notiert)

• Anzahl CPUs


• CPU: zugehorige private Slaves, Scratchpad aktiv/inaktiv

• Anzahl gemeinsamer Slaves

• Konfiguration der privaten/gemeinsamen Slaves (d.h. des zugrunde liegenden Speichers)und der Prozessor-lokalen Scratchpads: Latenz/Wait States, Große, Blockgroße, Anzahlder Speicherbanke

• Maximale Anzahl der lokalen Caches pro CPU, privatem und gemeinsamem Slave, diewahrend des Optimierungsprozesses verwendet werden konnen (auch 0 ist moglich)

Die Spezifikation dieser Parameter erfolgt zusammen mit den in 4.3.3 erwahnten Para-metern in Form einer XML-Datei. Als unveranderlich wird dagegen fur alle verwendeten Ca-ches eine Latenz von 0 angenommen. Das folgende Beispiel zeigt die Grundkonfiguration einerSpeicherhierarchie-Optimierung fur ein Ein-Prozessor-System mit einem privaten Slave, wobeisowohl im Fall der CPU als auch im Fall des Slaves die Anzahl lokaler Caches auf 5 beschranktist. Die Minimal- und Maximalwerte der Cache-Parameter werden als Exponenten einer Zwei-erpotenz notiert.

<system_opt_def ><param name="minCacheSize" value="6"/><param name="maxCacheSize" value="23"/><param name="minCacheBlockSize" value="1"/><param name="maxCacheBlockSize" value="7"/><param name="minCacheAssociativity" value="0"/><param name="maxCacheAssociativity" value="4"/><cpu>

<param name="maxCaches" value="5"/><slave>

<param name="type" value="PrivateSlave"/><param name="maxCaches" value="5"/><memory >

<param name="ws_readByte" value="10"/><param name="ws_readHalfword" value="10"/><param name="ws_readWord" value="10"/><param name="ws_writeByte" value="10"/><param name="ws_writeHalfword" value="10"/><param name="ws_writeWord" value="10"/><param name="size" value="12582912"/><param name="blockSize" value="512"/><param name="banks" value="4"/>

</memory ></slave>

</cpu></system_opt_def >

Listing 4.2: Beispiel einer Grundkonfiguration

4.4.3 Reprasentation des Problems

Fur die Reprasentation des Optimierungsproblems wurde eine hierarchisch ganzzahlige Vek-torreprasentation, wie sie in Abb. 4.2 dargestellt wird, gewahlt. Dabei wird im Wesentlichenzwischen 3 Hierarchiestufen unterschieden. Die System-Definition, d.h. die oberste Hierarchie-stufe, fasst alle Komponenten des zu optimierenden Systems, d.h. CPUs, zugehorige private undgemeinsame Slaves zusammen, fur die, nach Grundkonfiguration, die maximale Anzahl der Ca-ches mindestens eins ist. Dabei werden die Komponenten des Systems stets so geordnet, dass die


CPU 1 Pr. Slave 11

Cache 1 Cache 2 Cache 3 Cache m

m = max. #Caches pro CPU / Slave

. . .

System - Definition

Komponenten - Definition

LevelActive Type SizeBlockSize

Assoc.Alloc.on Wr.Miss

Write Policy

Full Line Wr.

Back

Repl.Policy

Cache - Definition

. . . CPU n Pr. Slave n1 . . . Sh. Slave 1 Sh. Slave k. . .

Abbildung 4.2: Hierarchisch ganzzahlige Vektorreprasentation

CPUs, gefolgt von den privaten Slaves, im vorderen Abschnitt des Vektors und die gemeinsamenSlaves im hinteren Abschnitt des Vektors reprasentiert werden. Die nachste Hierarchiestufe, dieKomponenten-Definition, umfasst die zugeordneten Caches, deren Anzahl durch die Grundkon-figuration aus 4.4.2 festgelegt ist. Die logische Auswertung einer Cache-Hierarchie erfolgt stetsbeginnend bei Cache 1 und endend bei Cache m, sodass z.B. fur einen L2 Cache mit Position iund einen L1 Cache mit Position j bzgl. der Komponenten-Definition stets gilt: i > j.Fur zweiCaches gleichen Levels (Instruktion- und Datencache) ist die Anordnung an den Positionen iund i+ 1 stets vertauschbar.

Auf der letzten Hierarchie-Stufe, der Cache-Definition, erfolgt die Parametrisierung der Ca-ches und damit auch der zugehorigen Cache-Hierarchie. Die folgende Auflistung erlautert dieBedeutung und den Wertebereich der Parameter innerhalb der Cache-Definition.

• Active: Cache aktiv/inaktiv → wenn inaktiv, wird dieser Cache wahrend der Evaluationals nicht vorhanden betrachtet

• Level : Cache-Level → beginnend bei 1, innerhalb der Komponenten-Definition nie abstei-gend

• Type: Cache-Typ → Instruktions- (Wert 0), Daten- (Wert 1) oder Unified Cache (Wert 2)

• Size: Cache-Große (in Byte)→ wird als Exponent einer Zweierpotenz notiert, Wertebereichwird uber die Grundkonfiguration bestimmt

• Block Size: Blockgroße (in Worten mit Wortgroße von 4 Byte) → wird als Exponent einerZweierpotenz notiert, Wertebereich wird uber die Grundkonfiguration bestimmt

• Associativity : Assoziativitat des Caches → wird als Exponent einer Zweierpotenz notiert,Wertebereich wird uber die Grundkonfiguration bestimmt

• Allocate On Write Miss: Allokation einer Cache-Zeile nach einem Write Miss → boolscheKodierung {0, 1}

• Write Policy : Schreibstrategie → Write Through (Wert 0), Write Back (Wert 1)

• Full Line Write Back : Zuruckschreiben der kompletten Zeile bei einem Write Back →boolsche Kodierung {0, 1}

• Replacement Policy : Ersetzungsstrategie → Keine (Wert 0), LRU (Wert 1), Round Robin(Wert 2), Random (Wert 3)


Durch die Einschrankung der Wertebereiche der Parameter Size, Block Size und Associa-tivity wird eine sinnvolle Einschrankung des Suchraums und die Vermeidung vieler ungultigerKonfigurationen erreicht. Jedoch ergeben sich innerhalb einer Komponenten-Definition sowohlzwischen den Parametern eines (lokale Abhangigkeit) als auch zwischen den Parametern verschie-dener Caches (Komponenten-globale Abhangigkeit) verschiedene Abhangigkeiten, die wiederumzu Nebenbedingungen des Optimerungsproblems fuhren.

4.4.4 Nebenbedingungen

Die in Abb. 4.2 dargestellte Reprasentation des Problems stellt nicht fur jede Auspragungr ∈ R des Vektors eine valide Cache-Hierarchie dar. Somit handelt es sich bei diesem Opti-mierungsproblem um ein restriktionsbehaftetes Problem, fur das sich die folgenden lokalen undKomponenten-globalen Restriktionen ergeben:

Lokale Restriktionen

• Fur die Anzahl der Cache Sets CS = Size/(Associativity · Block Size ·Word Size) mussstets gelten: 3 ≤ CS ≤ 19 (CACTI-Restriktion fur die Berechnung der Zugriffsenergienund des Chipflachenbedarfs)

• Associativity · Block Size ·Word Size ≤ Size (mindestens 1 Cache Set)

• Fur Associativity > 1 muss eine Ersetzungsstrategie aus {LRU,Round Robin,Random},fur Associativity = 1 Keine gewahlt werden

• Einhaltung des Wertebereichs fur jeden Parameter

Komponenten-globale Restriktionen

• Pro Cache-Level existiert genau ein Instruktions- und/oder Daten-Cache oder genau einUnified-Cache.

• Existiert in Level l ein Instruktions- oder Daten-Cache, so existiert ein Cache des selbenTyps auch in Level l − 1, wenn l > 1 gilt.

• Die Cache-Große wachst von Level zu Level (strenge Monotonie).

• Existieren Instruktions- und Daten-Caches gleicher Große in einem Level, so ist die Großedes Caches im nachsten Level mehr als doppelt so groß (aufgrund der Notation als Expo-nent einer Zweierpotenz verdoppelt sich die Cachesgroße bei einer Vergroßerung).

Zur Einhaltung dieser Restriktionen werden, wie in 2.6.3.6 vorgeschlagen, sowohl restrikti-onserhaltende Operatoren als auch Reparaturmechanismen (siehe 4.4.9) eingesetzt.

4.4.5 Evaluation der Individuen durch MPARM/MEMSIM

Die Evaluation eines Individuums, das eine Auspragung einer Speicherhierarchie reprasentiert,erfolgt bzgl. der Optimierungsgroßen unter Verwendung des MPARM/MEMSIM-Simulationssys-tems. Der Energieverbrauch und Chipflachenbedarf der Speicher wird dabei unter Verwendungvon CACTI 4.2 auf Basis einer Technologiegroße von 0,13 µm durch MPARM/MEMSIM (siehe3.5) ermittelt. Die Simulation einer Speicherhierarchie erfolgt jeweils in einem eigenen Prozess,wobei die zu simulierende Konfiguration in Form einer XML-Datei, die zuvor aus dem zu evaluie-renden Individuum und der Grundkonfiguration unter Verwendung der MPARM/MEMSIM-API


erzeugt wurde, dem Simulator als Eingabe dient. Die Ausfuhrung der Simulation in einem eige-nen Prozess wird durch die Einschrankung seitens SystemC erforderlich, dass nur eine Simulationpro Prozesslebenszeit ausgefuhrt werden kann. Die Optimierungsgroßen werden nach Abschlussder Simulation wiederum in einer XML-Datei gespeichert, anschließend vom Optimierungspro-zess eingelesen und im Zielgroßenvektor des zugehorigen Individuums gespeichert.

4.4.6 Initialisierung

Zur Erzeugung einer initialen Population von Individuen, die jeweils eine Auspragung einerSpeicherhierarchie reprasentieren, wurde ein Verfahren entwickelt, dass eine moglichst großezufallige Streuung im Suchraum des Optimierungsproblems herbeifuhrt, um so von vornhereinmoglichst global nach geeigneten Optima zu suchen.

In einem ersten Schritt wird die System- und Komponenten-Definition aus der Grundkon-figuration (siehe 4.3.3) erzeugt, wobei alle Caches als inaktiv (nicht vorhanden) initialisiertwerden. In einem zweiten Schritt erfolgt die Initialisierung der Cache-Parameter und damit derCache-Hierarchie. Dabei wird fur jede Komponente zunachst zufallig gleichverteilt aus dem In-tervall [0,max caches] ⊆ Z die Anzahl nCaches der zu verwendenden Caches bestimmt, wobeimax caches die maximale Anzahl an Caches aus der Grundkonfiguration (siehe 4.4.2) bezeich-net. Der nachste Schritt ist abhangig davon, ob die zu initialisierende Komponente eine CPUoder einen Slave reprasentiert. Bevor das jeweilige Vorgehen im Detail erlautert wird, wirdzunachst die zielgerichtete, aber dennoch auf einem Zufallsexperiment basierende Berechnungder initialen Cache-Große vorgestellt.

4.4.6.1 Berechnung der initialen Cache-Große

Da sich die Cache-Große von Level zu Level in realen Systemen nicht nur verdoppelt odervervierfacht, sondern ein exponentiell zunehmendes Wachstum aufweist (z.B. L1-Cache 4kB,L2 Cache 128kB L3-Cache 4 MB), wird in dieser Diplomarbeit ein Ansatz verfolgt, der uberdem Intervall der moglichen Cache-Große zufallsbasiert eine Cache-Hierarchie mit exponentiellzunehmender Cache-Große erzeugt. Da durch die Reprasentation des Problems die Cache-Großestets als Exponent einer Zweierpotenz notiert wird, wird im Folgenden ein Reihenansatz zurBerechnung der initialen Cache-Große herangezogen.

Um diesen Ansatz vereinfacht zu erlautern, wird im Folgenden nur die Verwendung vonUnified-Caches angenommen, das Vorgehen bei der Verwendung von Instruktions-, Daten- undUnified-Caches wird im nachsten Abschnitt erlautert. Die Idee dabei ist, dass sich die Schrittweite(Differenz der Großen zweier bzgl. des Levels aufeinander folgender Caches) fur die Cache-Große(notiert als Exponent einer Zweierpotenz) von Level zu Level zumindest um eins erhoht, z.B.L1 28, L2 210, L3 213, L4 217. Im genannten Beispiel ist die letzte Schrittweite beim Hinzufugendes L3-Caches 10 − 8 = 2. Die in diesem Abschnitt vorgestellte Berechnung verwendet alsEingangsparameter die verbleibende Intervallgroße rI bis zum Erreichen des Maximums derCache-Große (Maximum der Cache-Große − Cache-Große des zuletzt erzeugten Caches) unddie Anzahl verbleibender Cache-Level rL (bei Unified-Caches: Maximale Anzahl an Caches −Anzahl aktivierter Caches). Aus diesen Großen wird dann die maximale Schrittweite smax furdie Große eines neuen Caches errechnet. Gemaß der Idee dieses Ansatzes soll gelten:

smax+rL∑i=smax

= rI

Durch Verwenden von

n∑i=1

=n(n+ 1)

2


ergibt sich:

smax+rL∑i=smax

=smax+rL∑

i=1

−smax−1∑

i=1

= rI

⇒ (smax + rL)(smax + rL + 1)− smax(smax − 1)2

= rI

⇒ (2rL + 2)smax + rL2 + rL

2= rI

⇒ smax =2rI − rL2 − rL

2rL + 2

Die nachste Schrittweite, d.h. die Vergroßerung der Cache-Große des letzten Levels, wirdabschließend zufallig gleichverteilt aus dem Intervall [last step size + 1, smax] ⊆ Z gewahlt,wobei last step size die letzte Schrittweite angibt. Gilt last step size+ 1 > smax, so wird smax

verwendet, findet eine Verletzung der oberen Grenze des zulassigen Wertebereichs statt, so wirddies durch den in 4.4.9 dargestellten Reparaturmechanismus korrigiert.

4.4.6.2 Initialisierung einer CPU

Fur die Initialisierung der Cache-Hierarchie einer CPU wird ein Lotterie-Verfahren genutzt, uberdas solange Caches aktiviert werden, bis die Anzahl aktivierter Caches nCaches betragt. Dabeiwird fur jeden zu erzeugenden Cache-Level ein Lotterie-Topf verwendet, der alle moglichenCache-Kombinationen (Instruktions- und/oder Daten- oder Unified-Cache) unter Einhaltungder in 4.4.4 genannten Nebenbedingungen enthalt. Aus diesem wird dann zufallig gleichverteilteine Auspragung des Cache-Levels bestimmt. Fur die zu aktivierenden Caches werden die Pa-rameter Block Size, Associativity, Allocate on Write Miss, Write Policy, Full Line Write Backund Replacement Policy zufallig gleichverteilt uber ihrem Wertebereich initialisiert. In Level 1erfolgt die Initialisierung der Cache-Große zufallig gleichverteilt uber dem zulassigen Wertebe-reich, ab Level 2 wird die Berechnung der Cache-Große gemaß 4.4.6.1 durchgefuhrt, wobei sichdie Bestimmung der Parameter rL (verbleibende Cache-Level) und rI (verbleibendes Intervallder Cache-Große bis zur oberen Schranke) komplizierter darstellt. Werden nur Unified-Cachesverwendet, so werden rL und rI wie in 4.4.6.1 bestimmt. Existieren nur Instruktions- und/o-der Daten-Caches, so wird dasselbe Verfahren jeweils fur die Instruktions- bzw. Daten-Cachesangewendet, wobei beim Hinzufugen eines Instruktions- und Daten-Caches rL um eins kleinerist, da zwei Caches erzeugt werden. Wird einem Level mit Instruktions- und/oder Daten-Cachesein Unified-Cache nachgeordnet, so wird rI uber das Maximum der Cache-Großen (bei einemInstruktions- und Daten-Cache gleicher Große wird diese noch um 1 erhoht) des letzten Levelsund rL wie gewohnlich gewahlt. Die letzte Schrittweite bestimmt sich in diesem Fall ebenfallsaus dem Maximum der Schrittweiten des letzten Levels.

4.4.6.3 Initialisierung eines Slaves

Fur einen Slave ergibt sich ein wesentlich einfacheres Initialisierungsverfahren, da fur diesennur Unified-Caches zum Einsatz kommen. Sei i die Anzahl aktivierter Caches. Dann werdensolange Caches aktiviert und initialisiert, bis i = nCaches gilt. Dabei wird jedem aktiviertenCache der Level i zugewiesen. Die Parameter Block Size, Associativity, Allocate on Write Miss,Write Policy, Full Line Write Back und Replacement Policy werden zufallig gleichverteilt uberihrem Wertebereich initialisiert. Der Parameter Size wird in Level 1 zufallig gleichverteilt uberdem zulassigen Wertebereich ermittelt, ab Level 2, wie in 4.4.6.1 beschrieben, berechnet.


4.4.7 Rekombination

Der fur die Rekombination verwendete Operator stellt eine Variante des in 2.6.3.3 beschriebe-nen 1-Point-Crossovers dar, wobei aus zwei Elternindividuen stets zwei Nachkommen erzeugtwerden. Aufgrund der speziellen Form der Reprasentation kann die Rekombination zweier In-dividuen nicht an beliebiger Stelle des hierarchisch ganzzahligen Vektors stattfinden. Die Wahleiner Rekombinationsstelle z innerhalb einer Komponenten-Definition wurde meist zu einer in-validen Speicherhierarchie der jeweiligen Komponente fuhren, selbst dann, wenn genau an derGrenze zwischen zwei Cache-Definitionen rekombiniert wurde. So konnte z.B. eine lokale Cache-Hierarchie mit einem L1 Unified-Cache, einem L2 Instruktions- und einem L3 Daten-Cache resul-tieren. Aus diesem Grund findet die Rekombination nur an Komponentengrenzen statt, wobei dieWahl der Rekombinationsstelle z zufallig gleichverteilt uber dem Intervall [1,#Komponenten−1]erfolgt. Damit weist die Rekombination ein restriktionserhaltendes Verhalten auf. Abb. 4.3 zeigtein Beispiel einer Rekombination zwischen den Komponentengrenzen der Chromosome zwei-er Individuen an der Stelle z = 3. Dabei werden die hinteren zwei Chromosom-Komponentenpaarweise miteinander vertauscht.

CPU 1 Pr. Slave 11 CPU 2 Pr. Slave 21 Sh. Slave 1

CPU 1 Pr. Slave 11 CPU 2 Pr. Slave 21 Sh. Slave 1

Individuum 1

Individuum 2

z = 3

Abbildung 4.3: Beispiel einer Rekombination

Da die Rekombination nur an Komponenten-Grenzen stattfindet, stellt sich diese, im Ge-gensatz zu klassischen Genetischen Algorithmen, als außert schwach dar und tragt somit nichtmaßgeblich zur Evolution bei, sodass der Mutation eine entscheidende Bedeutung zukommt.Diese wird mit einer großen Wahrscheinlichkeit pM im Evolutionsprozess zu verwenden sein.

4.4.8 Mutation

Aufgrund der speziellen Reprasentation des Problems wurde ein Problem-spezifischer Muta-tionsoperator entwickelt, der eine Mutation sowohl in der Cache-Hierarchie als auch in denCache-Parametern vornimmt. Damit die Mutation nur kleine Anderungen an einem Individuumvornimmt und so den Suchraum moglichst kleinschrittig nach Optima durchsucht, werden beijeder Mutation entweder die Cache-Hierarchie oder die Cache-Parameter, die keine Anderungan der Hierarchie herbeifuhren, verandert. Dabei wird die Mutationsform anhand eines fairenMunzwurfs (p = 0, 5) ermittelt. Eine detaillierte Beschreibung der Hierarchie- bzw. Parameter-Mutation findet sich in den folgenden beiden Abschnitten.

4.4.8.1 Mutation der Cache-Parameter

Bei der Mutation der Cache-Parameter werden nur solche Parameter in der Cache-Definitionfur eine Modifikation in Betracht gezogen, die keine Anderung an der Cache-Hierarchie her-beifuhren. Dabei werden zunachst auf der Ebene der System-Definition die Komponenten aus-gewahlt, die einer Mutation unterzogen werden sollen, wobei fur die Mutationswahrscheinlich-keit einer Komponente pK = 1/#Komponenten gewahlt wird. Ist eine Komponente ausgewahltworden, so findet auf der Ebene der Komponenten-Definition eine Auswahl der zu mutieren-den Caches statt, wobei nur aktive Caches in Betracht gezogen werden. Damit ergibt sich fur


die Mutationswahrscheinlichkeit eines Caches pC = 1/#Aktive Caches. Wird ein Cache zurMutation vorgesehen, so erfolgt wiederum auf der Ebene der Cache-Definition die Auswahldes zu mutierenden Parameters, wobei fur die Mutationswahrscheinlichkeit eines ParameterspP = 1/#Parameter ohne Einfluss auf Cache-Hierarchie gewahlt wird und nur diejenigen Pa-rameter in Betracht gezogen werden, die keinen Einfluss auf die Struktur der Cache-Hierarchiehaben (bis auf Aktiv, Typ und Level sind dies alle Parameter). Wurde ein Parameter zur Muta-tion ausgewahlt, so gibt es zwei verschiedene Mutationsarten:

• Zufallige Mutation: Die zufallige Mutation wahlt fur einen Parameter zufallig gleich-verteilt aus dem zulassigen Wertebereich einen neuen Parameterwert aus. Dieses Vorgeheneignet sich nur fur Parameter, uber die ein Cache-Verhalten (z.B. eine Schreibstrategieoder eine Ersetzungsstrategie) kodiert wird und somit die Differenz zwischen zwei Para-meterwerten keinen echten geometrischen Abstand ausdruckt. Diese Mutationsart wird furalle Parameter außer Size, Block Size und Associativity verwendet.

• Standard-Normalverteilte Mutation: Diese Mutationsart wird fur die Parameter Si-ze, Block Size und Associativity verwendet, da diese echte geometrische Großen darstellen.Bei einer Mutation wird zunachst ein standard-normalverteilter (Erwartungswert µ = 0,Standardabweichung σ = 1) Zufallswert X ermittelt und aufgrund der ganzzahligen Re-prasentation gerundet, wobei im positiven Fall auf- und im negativen Fall abgrundet wird,damit nicht in den meisten Fallen eine Anderung um 0 (keine Anderung) vorgenommenwird. Durch die Rundung ergibt sich in den meisten Fallen eine Anderung des Parameter-betrags um 1:

X ′ =

{dXe, X ≥ 0bXc, X < 0

!! !" !# !$ !% & % $ # " !&

&'&!

&'%

&'%!

&'$

&'$!

&'#

&'#!

&'"

(

)*+,-e/012-*31

Abbildung 4.4: Dichtefunktion ϕ0;1 der Standard-Normalverteilung

Die Idee hinter dieser Vorgehensweise zeigt der in Abb. 4.4 dargestellte Graph der Dich-tefunktion ϕ0;1 der Standard-Normalverteilung. So wird eine kleine Anderung eines Pa-rameterwerts mit hoher Wahrscheinlichkeit und eine große Anderung mit kleiner Wahr-scheinlichkeit hervorgerufen. Schlussendlich wird X ′ dem zu mutierenden Parameterwertaufgeschlagen. Wird dabei eine Grenze des zulassigen Wertebereichs verletzt, wird fur denParameterwert der kleinste bzw. großte Wert gewahlt. Durch globale Abhangigkeiten der


Parameter kann jedoch durch die Anderung des Parameters Size eine Verletzung der Ne-benbedingungen (siehe 4.4.4) stattfinden, sodass die Mutation der Cache-Parameter keinenrestriktionserhaltenden Charakter aufweist.

4.4.8.2 Mutation der Cache-Hierarchie

Wird hingegen die Cache-Hierarchie mutiert, so wird mit einer Wahrscheinlichkeit von pK =1/#Komponenten eine Komponente modifiziert. Wurde eine Komponente zur Mutation aus-gewahlt, so wird ein standard-normalverteiler Zufallswert X ermittelt und, wie in 4.4.8.1 be-schrieben, ganzzahlig gerundet. Ist der resultierende Zufallswert X > 0, so werden Caches hin-zugefugt, im Fall X < 0 werden Caches entfernt. Ist im Fall X > 0 dieser Zufallswert großerals die Anzahl nicht aktivierter Caches oder im Fall X < 0 vom Betrag großer als die Anzahlaktivierter Caches, so wird X (vom Betrag) auf den entsprechenden Maximalwert gesetzt.

Werden n Caches entfernt, so werden diese innerhalb der Komponenten-Definition stetsvom großeren zum kleineren Cache-Level entfernt. Befinden sich in einem Level sowohl einInstruktions- als auch ein Daten-Cache, so wird uber einen fairen Munzwurf (p = 0, 5) der zuentfernende Cache determiniert.

Sollen n Caches hinzugefugt werden, so geschieht dies im Fall eines Slaves wie im Initia-lisierungsverfahren in 4.4.6.3 beschrieben. Im Fall einer CPU wird zunachst die vorliegendeCache-Hierarchie analysiert. Besteht der letzte Cache-Level aus einem Instruktions- oder Daten-Cache und ist, unter Einhaltung der Nebenbedingungen aus 4.4.4, ein zusatzlicher Daten- bzw.Instruktions-Cache im selben Level moglich, so wird uber einen fairen Munzwurf (p = 0, 5) er-mittelt, ob ein solcher Cache hinzugefugt wird. Daraufhin erfolgt das Hinzufugen der Caches,wie im Intialisierungsverfahren in 4.4.6.2 beschrieben.

Aus der Beschreibung der Mutation der Cache-Hierarchie ergibt sich insgesamt ein restrik-tionserhaltendes Verhalten bzgl. der Nebenbedingungen aus 4.4.4.

4.4.9 Reparatur unzulassiger Losungen

Werden Nebenbedingungen aus 4.4.4 durch die Initialisierung oder Mutation eines Individu-ums verletzt, so wird dieses uber Reparaturmechanismen korrigiert, wobei eine Reparatur stetsmoglichst kleine Anderungen an einem Individuum vornimmt. Da keine Abhangigkeiten zwischenKomponenten, sondern nur zwischen Caches einer Komponente bestehen, findet eine Korrekturnur auf der Ebene der Komponenten-Definition statt. Im Folgenden werden die Reparaturme-chanismen fur verletzte lokale und Komponenten-globale Nebenbedingungen naher erlautert.Ergibt sich nach 2 Reparaturdurchlaufen kein valides Individuum, so wird die Optimierung ab-gebrochen, da in diesem Fall die a-priori konfigurierbaren zulassigen Wertebereiche (siehe 4.4.2)vermutlich durch den Designer zu klein gewahlt wurden.

Lokale Nebenbedingungen Durch Initialisierung oder Mutation kann die CACTI Restrik-tion bzgl. der Anzahl der Cache Sets CS verletzt werden. Fur CS = Size / (Associativity ·Block Size ·Word Size) muss stets gelten: 3 ≤ CS ≤ 19.

• CS < 3: In diesem Fall wird zunachst die Assoziativitat soweit wie moglich reduziert. Istkeine Verringerung mehr moglich, so wird die Blockgroße verkleinert und in letzter Instanzdie Cache-Große vergroßert.

• CS > 19: Bei einer zu großen Anzahl an Sets wird zunachst die Blockgroße so weit wiemoglich erhoht. Ist keine Vergroßerung mehr moglich, so wird die Assoziativitat erhohtund zuletzt die Cache-Große verringert.

4.5 Optimierung der Scratchpad-Allokation 73

Des Weiteren wird bei einer Assoziativitat von 1 uberpruft, ob als Ersetzungsstrategie Keinegewahlt wurde. Bei einer Assoziativitat > 1 muss eine der Ersetzungsstrategien LRU, RoundRobin oder Random gewahlt werden. Wurde in diesem Fall Keine gewahlt, so wird zufalliggleichverteilt aus den gennanten Strategien eine ausgewahlt.

Komponenten-globale Nebenbedingungen Eine Verletzung Komponenten-globaler Ne-benbedingungen kann nur durch den Parameter Size erfolgen, sodass sich die Cache-Große vonLevel zu Level nicht streng monoton wachsend darstellt. In diesem Fall wird zunachst eine Analy-se der Cache-Hierarchie durchgefuhrt, wobei diese von Position 1 bis nCaches (Anzahl aktivierterCaches) und von nCaches bis 1 durchlaufen wird, um folgende Informationen zu ermitteln:

• Maximale Cache-Große incrmax bei Reparatur durch minimale Vergroßerung bei Ver-letzung der Monotonie-Eigenschaft. Dabei wird die Cache-Hierarchie von Position 1 bisnCaches durchlaufen und iterativ die strenge Monotonie gepruft.

• Minimale Cache-Große decrmin bei Reparatur durch minimale Verkleinerung bei Verlet-zung der Monotonie-Eigenschaft. Dabei wird die Cache-Hierarchie von Position nCaches

bis 1 durchlaufen und iterativ die strenge Monotonie gepruft.

Auf Basis dieser Information und dem a-priori definitierten Wertebereich [cmin, cmax] ⊆ Z derCache-Große wird entschieden, ob eine Reparatur durch minimale Vergroßerung (von Position1 bis nCaches) oder minimale Verkleinerung (von Position nCaches bis 1) der Cache-Große beiVerletzung der strengen Monotonie durchgefuhrt wird:

• incrmax > cmax ∧ decrmin ≥ cmin: Die Reparatur erfolgt durch minimale Verkleinerungder Cache-Große.

• incrmax ≤ cmax∧decrmin < cmin: Die Reparatur erfolgt durch minimale Vergroßerung derCache-Große.

• incrmax ≤ cmax ∧ decrmin ≥ cmin: Die Entscheidung fur eine minimale Vergroßerung bzw.Verkleinerung wird durch einen fairen Munzwurf (p = 0, 5) getroffen, da eine minima-le Veranderung die durchgefuhrte Mutation ruckgangig machen konnte. Da jedoch nichtbekannt ist, ob dies bei einer Vergroßerung oder Verkleinerung geschieht, wird dies ubereinen fairen Munzwurf entschieden.

• incrmax > cmax∧decrmin < cmin: In diesem Fall ist keine Reparatur moglich und daher er-folgt der Abbruch der Optimierung (Anpassung der Grenzen des Wertebereichs notwendig,da diese vermutlich zu klein gewahlt wurden)

4.5 Optimierung der Scratchpad-Allokation

Die Verwendung kleiner, energieeffizienter Scratchpadspeicher eroffnet im Bereich eingebetteterSysteme viele Optimierungsmoglichkeiten. So kann sowohl der Energieverbrauch, die benotigtenTaktzyklen (die Ausfuhrungszeit) einer auszufuhrenden Zielanwendung oder auch der Chip-flachenbedarf reduziert werden. Daher wird im Rahmen dieser Diplomarbeit zusatzlich zur Op-timierung des Speicherhierarchie des SoC, die die Hardware-Architektur variiert, ein Optimie-rungsansatz fur die statische Scratchpad-Allokation zur Compilezeit entwickelt, der im Wesentli-chen eine Variation in der Software vornimmt. Dabei wird auf Basis eines Referenzsystems (Ein-oder Mehr-Prozessorsystem) des SoC und ausgewahlter Zielanwendungen eine Approximationder optimalen, statischen Allokation von globalen Variablen und Funktionen zur Compilezeitunter Verwendung Evolutionarer/Genetischer Algorithmen untersucht. Die globalen Variablen


und Funktionen werden uber ihre zugehorigen Symbole, die unter Verwendung des ICD-C Com-piler Frameworks [ICD08] ermittelt werden, identifiziert. Im Gegensatz zur Optimierung derSpeicherhierarchie wird dieser Ansatz einem klassischen Genetischen Algorithmus nachempfun-den.

4.5.1 Workflow

Ziel-anwendungen

arm-gcc Cross-Compiler

MPARM / MEMSIM

Grund-konfiguration

Simulationsergebnisse

GenetischerAlgorithmus

Population /Archiv

Menge nicht-dominierter Individuen

Auswahl einer Lösung

Approx. optimales Individuum bzgl. des

Designziels

Gewichtung

Konvergenz

Ausführbare Dateien

Initialisierung über ICD-C

Selektion /Rekombination /

Mutation

Evaluation

CACTI 4.2(Energie,

Chipfläche)

ICD-C

Compilation Units für Hauptspeicher / SPM

Abbildung 4.5: Workflow zur Optimierung der Scratchpad-Allokation

Abb. 4.5 zeigt den Workflow dieses Optimierungsansatzes. Dabei dienen ausgewahlte C-Applikationen (Zielanwendungen) und eine Grundkonfiguration (siehe 4.5.2), die das zu verwen-dende Referenzsystem festlegt, dem Genetischen Algorithmus als Eingabe. Zur Erzeugung einerinitialen Population von Individuen (siehe 4.5.6) wird zunachst unter Verwendung des ICD-CCompiler Frameworks eine sog. Intermediate Representation (IR) der C-Applikationen erzeugt,aus der die Symbole aller globalen Funktionen und Variablen extrahiert werden. Dabei werdennur diejenigen Applikationen in Betracht gezogen, deren zugehorige CPU des Simulationssys-tems ein Scratchpad verwendet. Aus diesen IRs der Zielanwendungen wird so die hierarchischbinare Vektorreprasentation (siehe 4.5.3) generiert, die fur jedes Symbol einer globalen Funkti-on bzw. Variable einen Vektoreintrag enthalt. Durch eine zufallig gleichverteilte Belegung dieserVektoreintrage (1: Symbol in das Scratchpad auslagern, 0: Symbol verbleibt im Hauptspei-cher) wird so eine initiale Population von Individuen erzeugt. Diese Individuen werden unterVerwendung des ICD-C Compiler Frameworks und des MPARM/MEMSIM-Simulationssystemsevaluiert (siehe 4.5.5), wobei zunachst aus dem Chromosom eines Individuums fur jede Appli-kation jeweils eine Compilation Unit fur den Hauptspeicher und das Scratchpad generiert wird.Diese Compilation Units werden anschließend unter Verwendung des arm-gcc Cross-Compilerskompiliert und uber MPARM/MEMSIM unter Verwendung des Referenzsystems evaluiert. Aus

4.5 Optimierung der Scratchpad-Allokation 75

den Simulationsergebnissen werden die Optimierungsgroßen extrahiert und dem zu evaluieren-den Individuum zugewiesen. Im Zuge der Evolution werden auf der Population bzw. dem Archivdie evolutionaren Operatoren Selektion, Rekombination (siehe 4.5.7) und Mutation (siehe 4.5.8)durchgefuhrt. Die resultierende Population wird stets unter Verwendung des ICD-C CompilerFrameworks und des MPARM/MEMSIM-Simulationssystems evaluiert, bis das Konvergenzkri-terium (siehe 4.3.4) erfullt ist. Aus der Menge nicht-dominierter Individuen wird abschließendeine bzgl. der Gewichtungsparameter optimale Losung ausgewahlt (siehe 4.3.5).


Wie im Fall der Speicherhierarchie-Optimierung konnen einige Parameter des Optimierungspro-blems von vornherein festgelegt werden. Dies sind neben den Zielanwendungen folgende Problem-spezifische Parameter:

• Referenzsystem: Das Referenzsystem wird uber eine API-konforme XML-Datei festgelegt,die von der MPARM/MEMSIM-API (siehe 3.9.1) als Eingabe verwendet wird. Im Refe-renzsystem ist dabei nur ein privater Slave pro CPU erlaubt. Des Weiteren werden uber dasReferenzsystem auch die verwendeten Prozessor-lokalen Scratchpads aktiviert/deaktiviertund konfiguriert.

• Anpassen der Große des Scratchpads: Dieses Flag legt fest, ob das Scratchpad an dieGroße, die durch den Linker-Report spezifiziert wird, angepasst werden soll. Dabei dientdie Große der Scratchpads im Referenzsystem als obere Schranke. Bis zu einer benotigtenGroße von 2 kB wird die Große des Scratchpads, sofern diese keine Zweierpotenz ist, andie nachst großere Zweierpotenz angepasst, bei Großen uber 2 kB erfolgt die Anpassungin 2 kB Schritten bis zur oberen Schranke des Scratchpad-Große. So wurde fur eine nachLinker-Report benotigte Scratchpad-Große von 640 Byte 1 kB, fur 4 kB jedoch 6 kB alsresultierende Große gewahlt werden. Neben der Anpassung der Große des Scratchpadsfindet auch eine Anpassung der Blockgroße statt, die stets so bestimmt wird, dass dieAnzahl der Zeilen der Anzahl der Bytes pro Zeile entspricht (quadratische Form). DieBerechnung erfolgt nach folgender Vorschrift:

Neue Blockgroße = 2d(blog2(Cache-Große)c/2)e−2

Durch d(blog2(Cache-Große)c/2)e wird zunachst eine quadratische Aufteilung der Cache-Große vorgenommen. Da die Wortgroße 4 Byte (22) betragt und die Berechnung der neu-en Blockgroße auf Basis des Exponenten einer Zweierpotenz erfolgt, wird schlussendlich2 subtrahiert (Division durch Wortgroße) und durch Potenzierung die neue Blockgroßeberechnet.

Die Festlegung dieser Parameter erfolgt, zusammen mit der Grundkonfiguration aus 4.3.3und 4.4.2 in einer XML-Datei, die dem Optimierungsverfahren als Eingabe dient. Das folgendeBeispiel zeigt die Grundkonfiguration dieses Optimierungsansatzes:

<spm_opt_def ><param name="fitMemorySize" value="1"/><param name="referenceSystemFilename" value="refsystem.xml"/>

</spm_opt_def >

Listing 4.3: Beispiel einer Grundkonfiguration

4.5.3 Reprasentation des Problems

Fur die Optimierung der Scratchpad-Allokation wurde eine hierarchisch binare Vektorreprasen-tation gewahlt. Auf der ersten Ebene der Hierarchie werden dabei alle CPUs zusammengefasst,


Funktion 1 Funktion n

CPU nCPU 1 . . .

. . . Variable 1 Variable n. . . ! B = {0, 1}

Abbildung 4.6: Hierarchisch binare Vektorreprasentation

die nach Referenzsystem ein Scratchpad (an dieser Stelle ist wieder das gewohnliche Scratch-pad, nicht das Instruktions-Scratchpad gemeint) verwenden. In der zweiten Hierarchiestufe wirdfur die globalen Funktionen und Variablen der Zielanwendung einer CPU uber eine binare Ent-scheidungsvariable kodiert, ob die jeweilige Funktion bzw. Variable in das Scratchpad ausgelagertwird (Wert 1) oder im Hauptspeicher verbleibt (Wert 0). Da die Auslagerung der Main-Funktionin das Scratchpad nicht moglich ist, wird diese stets im Hauptspeicher platziert.

4.5.4 Nebenbedingungen

Die Reprasentation des Optimierungsproblems induziert zunachst keine Nebenbedingungen. Je-doch limitiert die Spezifikation des Referenzsystems durch die Große der Scratchpads, die ent-weder statisch oder im Fall der Anpassung der Scratchpad-Große als obere Schranke betrachtetwird, ggf. die mogliche Anzahl auszulagernder Symbole. Daher muss stets, vor Evaluation einesIndividuums, gepruft werden, ob durch die Auswahl auszulagernder Symbole die Kapazitat ei-nes Scratchpads nicht uberschritten wird. Ist dies dennoch der Fall, so wird eine Bestrafung derunzulassigen Losung vorgenommen (siehe 4.5.9).

4.5.5 Evaluation der Individuen durch ICD-C und MPARM/MEMSIM

Die Evaluation eines Individuums, das fur jeden verwendeten Prozessor, der ein lokales Scratch-pad verwendet, die Zuordnung globaler Funktionen und Variablen zum Hauptspeicher bzw.Scratchpad reprasentiert, erfolgt unter Verwendung des ICD-C Compiler Frameworks und desMPARM/MEMSIM-Simulators. Wird ein Individuum bzgl. der Optimierungsgroßen ausgewer-tet, so wird zunachst das Individuum in eine XML-Datei geschrieben und dient daraufhin demMPARM/MEMSIM-Simulator, der wie in 4.4.5 in einem neuen Prozess gestartet wird, als Ein-gabe. Zunachst liest dieser fur jede CPU des Individuums die gewahlte C-Applikation unterVerwendung des ICD-C Compiler Frameworks ein. Daraufhin werden die globalen Funktionenund Variablen gemaß der Auspragung des Individuums den zugehorigen Compilation Units desHauptspeichers bzw. des Scratchpads zugeordnet. Diese Compilation Units werden in zwei se-parate C-Dateien geschrieben und unter Verwendung des arm-gcc Cross-Compilers kompiliert.Wurde diese Prozedur fur alle CPUs des Individuums durchgefuhrt, so werden die Zielanwendun-gen anschließend unter Verwendung des Referenzsystems simuliert. Die Simulationsergebnisse,d.h. die Optimierungsgroßen Fi(x), werden nach Beendigung der Simulation in eine XML-Dateigeschrieben, anschließend vom Evolutionaren Algorithmus aus dieser extrahiert und dem zuevaluierenden Individuum zugewiesen.

4.5.6 Initialisierung

Die Initialisierung eines Individuums wurde auch fur diesen Optimierungsansatz so gewahlt, dasseine moglichst große initiale Streuung im Suchraum entsteht. Dabei wird fur jeden Vektoreintrag

4.6 Gekoppelte Optimierung 77

der zweiten Hierarchiestufe zufallig gleichverteilt uber B = {0, 1} ein initialer Parameterwertbestimmt.

4.5.7 Rekombination

Aufgrund der binaren Reprasentation des Problems und der Eigenschaft, dass eine beliebige Re-kombination keine Nebenbedingung verletzt, wurde der 1-Point-Crossover-Operator aus 2.6.3.3in einer Auspragung verwendet, in der aus zwei Elternindividuen stets zwei neue Individuenerzeugt werden. Dabei wird zufallig gleichverteilt uber dem Intervall [1, chromosome size − 1](chromosome size bezeichne die Gesamtlange des Chromosoms bei Einsetzen der zweiten Stufeder Hierarchie in die Erste) eine Rekombinationsstelle z bestimmt, hinter welcher die Gene derChromosome zur Erzeugung neuer Individuen paarweise vertauscht werden.

4.5.8 Mutation

Bezeichne chromosome size wieder die Gesamtlange des Chromosoms bei Einsetzen der zweitenStufe der Hierarchie in die Erste. Dann wird jede Position des binaren Vektors im Falle einerMutation mit der Wahrscheinlichkeit p = 1/chromosome size invertiert. Die Auslegung diesesOperators wurde dem vorgeschlagenen Vorgehen aus 2.6.3.4 nachempfunden.

4.5.9 Bestrafung unzulassiger Losungen

Vor der Evaluation eines Individuums ist zu prufen, ob durch die Auswahl auszulagernder Sym-bole nicht die Kapazitat eines Scratchpads des Referenzsystems uberschritten wird. Dazu wirdnach Kompilieren der Compilation Unit des Scratchpads uber den Linker-Report die benotigteScratchpad-Große determiniert und mit der im Referenzsystem spezifizierten Große verglichen.Uberschreitet die benotigte Große die im Referenzsystem spezifizierte, so liegt eine unzulassigeLosung vor. Da die Korrektur eines defekten Individuums nicht uber eine einfache Regel erfol-gen kann, wird den Optimierungsgroßen des defekten Individuums der Maximalwert zugewie-sen, sodass diese ungultigen Losungen bzgl. der Pareto-Dominanz ≺p stets durch andere gultigeLosungen dominiert und im Laufe der Evolution durch diese ersetzt werden.

4.6 Gekoppelte Optimierung

Im Rahmen dieser Diplomarbeit wird entweder die Optimierung der Speicherhierarchie, beider die Hardware-Architektur variiert wird, oder die Optimierung der statischen Scratchpad-Allokation, bei der im Wesentlichen die Software (zusatzlich kann die Große und die Blockgroßedes Scratchpads angepasst werden) variiert wird, verfolgt. Eine gleichzeitige Optimierung derHard- und Software in Form eines Multi-Chromosom-Individuums (Individuum, das beide Pro-blemreprasentationen enthalt) wird nicht vorgenommen. Dies hat den Grund, dass die Opti-mierung der Speicherhierarchie eine Variation eines genetischen Ansatzes und die Optimierungder statischen Scratchpad-Allokation einen klassischen genetischen Ansatz darstellt. Aus denverschiedenen Ansatzen resultiert des Weiteren eine unterschiedlich große Bedeutung der Va-riationsoperatoren (Mutation, Rekombination), die die Wahl der Variationswahrscheinlichkeitenfur einen Optimierungslauf bestimmt. Da globale Mutations- und Rekombinationswahrschein-lichkeiten zum Einsatz kommen, sind die speziellen Eigenschaften der Teilprobleme schwer zuberucksichtigen. Daher werden bei einer gekoppelten/gleichzeitigen Optimierung der Speicher-hierarchie und der statischen Scratchpad-Allokation die resultierenden Optimierungsergebnisseeinen vermutlich schwer nachvollziehbaren und schwer reproduzierbaren Charakter aufweisen.Aus diesem Grund wird im Rahmen dieser Diplomarbeit auf eine gekoppelte Optimierung ver-zichtet.

Kapitel 5

Ergebnisse und Validierung

In diesem Kapitel wird zum einen die Erweiterung des MPARM System-on-Chip Simulators umMEMSIM (siehe Kapitel 3) anhand ausgewahlter Benchmarks bzgl. der Simulationsergebnissevalidiert und mit dem ursprunglichen MPARM System-on-Chip Simulator verglichen. Zum an-deren wird die Optimierung der Speicherhierarchie des SoC und die Optimierung der statischenScratchpad-Allokation (siehe Kapitel 4) auf Basis ausgewahlter Benchmarks (Zielanwendungen)durchgefuhrt und die Gute der Losung analysiert.

5.1 Verwendete Benchmarks

Dieser Abschnitt stellt die fur den Vergleich von MPARM/MEMSIM und MPARM in 5.2 unddie Optimierungen in 5.3 verwendeten Benchmarks bzgl. ihrer Funktionalitat und Komplexitatkurz vor.

Matrixmultiplikation Der Matrixmultiplikations-Benchmark (asm-matrixind) entstammtder Benchmark-Suite des MPARM-Simulators und reprasentiert eine Applikation geringer Kom-plexitat, in der zwei quadratische 8 × 8 Matrizen miteinander multipliziert werden. Die Aus-fuhrung dieser Applikation erfolgt dabei ohne Verwendung der RTEMS Betriebssystemumge-bung.

GSM Decode Der GSM Decode-Benchmark, eine Applikation mittlerer Komplexitat, ent-stammt der Benchmark-Suite des ICD-C Compiler Frameworks und wurde im Rahmen dieserDiplomarbeit auf den MPARM System-on-Chip Simulator portiert. Dabei wird dieser Bench-mark ohne die RTEMS-Betriebssystemumgebung ausgefuhrt.

JPEG Encode Der JPEG Encoding-Benchmark wurde den frei verfugbaren JPEG-Quellender Independent JPEG Group [IJG] entnommen und im Rahmen dieser Diplomarbeit auf denMPARM System-on-Chip Simulator portiert, wobei die Ausfuhrung des Benchmarks stets in derRTEMS-Betriebssystemumgebung erfolgt. Als Eingabe dient eine 114 × 75 Bitmap, die in dasIMFS (In-Memory File System) des RTEMS-Betriebssystems geladen wird. Dieser Benchmarkstellt die rechenintensivste und komplexeste Applikation dar.

5.2 Vergleich der MPARM-Erweiterung mit MPARM

5.2.1 Grundlegendes

Zur Validierung und Bewertung der Erweiterung des MPARM System-on-Chip Simulators wer-den zwei Benchmarks, die sich in ihrer Komplexitat deutlich unterscheiden, unter unterschied-

79

80 5 Ergebnisse und Validierung

lichen Systemkonfigurationen durchgefuhrt. Dabei werden stets Ein-Prozessor Systeme unterVerwendung eines Cache-Levels und eines privaten Slaves ohne lokale Caches evaluiert. Para-meter, die ausschließlich in MPARM/MEMSIM variabel sind (Kennzeichnung uber * ), werdendabei so gewahlt, dass sie das Verhalten des MPARM-Simulators widerspiegeln. Die Berech-nung der Zugriffsenergien der Caches und Speicher erfolgt im Rahmen dieser Benchmarks furMPARM/MEMSIM unter Verwendung von CACTI 4.2 auf Basis einer Strukturgroße von 0,13µm. Die Gute der Integration wird im Folgenden durch den Vergleich der Simulationsergebnissebewertet, wobei sich aufgrund unterschiedlicher Energiemodelle im Bereich der Speicher un-terschiedliche Energiebilanzen ergeben werden. Des Weiteren sollte die Gesamtzahl benotigterTaktzyklen naherungsweise gleich sein, die Zugriffsstatistiken im Bereich der Caches und desHauptspeichers sollten eine vollstandige Ubereinstimmung ergeben. Die zur Validierung der In-tegration dargestellten Simulationsergebnisse basieren stets auf der Compiler-OptimierungsstufeO2 des arm-gcc Cross-Compilers.

Grundsatzlich sind fur den direkten Vergleich des ursprunglichen MPARM-Simulators mitder MEMSIM-Erweiterung einige wichtige Punkte zu berucksichtigen, um die Simulationser-gebnisse vergleichen zu konnen. Da MPARM in der Ausgangsversion an einigen Stellen einleicht abweichendes Verhalten zeigt und sogar im Bereich der Cache-Statistik Fehlzahlungenvornimmt, muss eine Bereinigung des MPARM-Simulationsergebnisses vorgenommen werden.Folgende Unterschiede von MPARM und MPARM/MEMSIM sind dabei zu berucksichtigen:

• Im Fall eines Read Miss erfolgt das Laden der Cache-Zeile aus der nachsten Stufe derSpeicherhierarchie (in MPARM aus dem Hauptspeicher). Jedoch wird nach dem Ladender Cache-Zeile in MPARM der erneute Zugriff auf das ursprunglich angeforderte Da-tum als Cache-Hit gezahlt. Dies entspricht nicht dem korrekten Zahlverhalten, da sofalschlicherweise auch interne Cache-Zugriffe als Cache-Hit registriert werden. MPARM/-MEMSIM implementiert das korrekte Zahlverhalten.

• Ein Cache-Miss wird im Fall eines Write Backs (dieser erfolgt nur im lesenden Fall, da dieStrategie no allocate on write miss angewendet wird) in MPARM doppelt gezahlt. Durchdie spezielle Form des Zustandsautomaten der CPU (siehe 2.5.3) wird dieser beim erstenZugriff und darauf nochmals nach dem Write Back registriert. MPARM/MEMSIM fuhrthingegen eine korrekte Zahlung der Cache-Misses durch.

• Nach dem Laden einer Cache-Zeile wird in MPARM/MEMSIM der Cache-Zugriff mit demnachsten Takt abgeschlossen, in MPARM geschieht dies erst einen Takt spater.

• In MPARM existiert nur ein Parameter fur die Wait States der Slaves. Dabei ist dietatsachliche Latenz im schreibenden Fall in MPARM um eins kleiner, da der erste Taktnach Zugriff auf einen Slave in die Latenz eingeht. Jedoch liegt bei einer schreibendenTransaktion am AMBA AHB Bus das zu schreibende Datum erst einen Takt spater validevor (siehe 2.5.2). Da dies in MPARM/MEMSIM berucksichtigt wurde, wird die Latenz imschreibenden Fall um eins kleiner gewahlt als in MPARM.

• Wird in MPARM eine Write Back-Strategie verwendet, so ist die Anzahl der Cache-Missesum das Produkt aus Blockgroße (stets 4 Worte) und Anzahl der Write Backs zu groß (dieFehlerquelle ist in diesem Fall unklar). MPARM/MEMSIM liefert die korrekte Anzahl.

Im Folgenden werden die Simulationsergebnisse des ursprunglichen MPARM- und des resul-tierenden MPARM/MEMSIM-Simulators im Vergleich diskutiert.

5.2 Vergleich der MPARM-Erweiterung mit MPARM 81

5.2.2 Matrixmultiplikation

Konfiguration Der Vergleich der ursprunglichen MPARM-Version mit der Erweiterung er-folgt im Fall der Matrixmultiplikation, die einen Benchmark geringer Komplexitat darstellt,unter Verwendung der MPARM-Standard-Konfiguration. Im Fall des privaten Slaves wird derSpeicher in 4 gleiche Banke zu je 3 MB mit einer Blockgroße von 2 kB unterteilt. Diese spe-zielle Parametrisierung wird realen Systemen nachempfunden. Insgesamt ergibt sich folgendeKonfiguration:

CPU Parameter Wert

L1 I-Cache

Große 8 kBBlockgroße in Worten* 4 (16 Byte)Assoziativitat 1Allocate On Write Miss* neinErsetzungsstrategie* keineWait States (lesend/schreibend) 0 / 0

L1 D-Cache

Große 4 kBBlockgroße in Worten* 4 (16 Byte)Assoziativitat 4Allocate On Write Miss* neinSchreibstrategie Write ThroughErsetzungsstrategie* Round RobinWait States (lesend/schreibend) 0 / 0

Tabelle 5.1: Matrixmultiplikation: CPU-Konfiguration

Slave Parameter Wert

Große 12 MBBlockgroße in Worten* 512 (2kB)Anzahl der Speicherbanke* 4Wait States (lesend/schreibend) 1 / 0

Tabelle 5.2: Matrixmultiplikation: Slave-Konfiguration


Auswertung Die um MPARM-Messfehler bereinigte Vergleichsstatistik des Matrixmultiplika-tions-Benchmarks wird in der folgenden Tabelle dargestellt, wobei zusatzlich die relative Abwei-chung der MPARM/MEMSIM-Simulationsergebnisse gegenuber MPARM angegeben wird:

Messwert MPARM/MEMSIM MPARM Abweichung

GlobalTaktzyklen 132828 132891 -0,05 %Energieverbrauch [nJ] 11056,05 20945,78 -47,22 %

CPUEnergieverbrauch CPU [nJ] 7028,08 6709,18 +4,75 %Energieverbrauch Caches [nJ] 1382,90 12454,30 -88,90 %Energieverbrauch Total [nJ] 8410,98 19163,48 -56,11 %

L1 I-Cache

Lesende Zugriffe 79038 79038 ±0,00 %Read Hits 79026 79026 ±0,00 %Read Misses 12 12 ±0,00 %Energieverbrauch [nJ] 904,44 10646,40 -91,50 %

L1 D-Cache

Lesende Zugriffe 15534 15534 ±0,00 %Read Hits 15483 15483 ±0,00 %Read Misses 51 51 ±0,00 %Schreibende Zugriffe 5861 5861 ±0,00 %Write Hits 5844 5844 ±0,00 %Write Misses 17 17 ±0,00 %Energieverbrauch [nJ] 478,46 1807,90 -73,54 %

AMBA AHB Energieverbrauch [nJ] 409,04 422,61 -3,21 %

Privater Slave

Zugriffe 6113 6113 ±0,00 %Lesende Zugriffe 252 252 ±0,00 %Schreibende Zugriffe 5861 5861 ±0,00 %Energieverbrauch [nJ] 2236,04 1359,68 +64,45 %

Tabelle 5.3: Matrixmultiplikation: Simulationsergebnisse im Vergleich

64% 8%

4%

4%

20%

CPUL1 I!CacheL1 D!CacheAMBA AHBPrivater Slave

(a) MPARM/MEMSIM

32%

51%

9%

2%6%

CPUL1 I!CacheL1 D!CacheAMBA AHBPrivater Slave

(b) MPARM

Abbildung 5.1: Matrixmultiplikation: Energiebilanz im Vergleich


Bewertung der Ergebnisse Die Simulationsergebnisse zeigen im Vergleich, mit Ausnahmedes Energieverbrauchs der Speicher, eine sehr gute Entsprechung. Dabei ergibt sich im Bereichder Zugriffsstatistiken die geforderte vollstandige Ubereinstimmung. Die Anzahl der Taktzy-klen zeigt eine leichte Abweichung, die durch die in 5.2.1 erlauterten Unterschiede begrundetist. So ergibt sich die Anzahl der Taktzyklen in MPARM aus der Anzahl der Taktzyklen inMPARM/MEMSIM, wenn die Summe der Read Misses hinzuaddiert wird. Dies resultiert ausder Tatsache, dass das Laden einer Cache-Zeile bei einem Read Miss in MPARM/MEMSIMeinen Takt schneller abgeschlossen werden kann als in MPARM. Die Abweichungen des Ener-gieverbrauchs der CPU (ohne den Energieverbrauch der Caches) und des AMBA AHB Bussesbefinden sich in einem tolerablen Bereich.

Ganzlich anders stellt sich im Vergleich die Energiebilanz des Gesamtsystems dar, die in Abb.5.1 dargestellt wird. In MPARM partizipieren allein die Caches zu 60 % am gesamten Energie-verbrauch, der Energieverbrauch des privaten Slaves wirkt sich lediglich mit einem Anteil von 6% aus, sodass die Caches um Faktor 10 mehr Energie verbrauchen. Die CPU (ohne den Energie-verbrauch der Caches) und der AMBA AHB Bus haben jeweils einen Anteil von 32 % bzw. 2 %am Energieverbrauch. Im Gegensatz dazu partizipieren die Caches in MPARM/MEMSIM mitAnteil von nur 12 %, der private Slave jedoch mit einen Anteil von 20 % am gesamten Energie-bedarf. Damit verbraucht der private Slave um ca. 67 % mehr Energie als die Caches. Die CPU(ohne den Energieverbrauch der Caches) stellt in MPARM/MEMSIM mit 64 % den großtenVerbraucher im System dar, der AMBA AHB Bus weist einen Anteil von 4 % am Energiebe-darf auf. Die großen Abweichungen ergeben sich dabei durch die Verwendung unterschiedlicherEnergiemodelle im Bereich der Speicher. Fur MPARM/MEMSIM werden die Zugriffsenergienunter Verwendung von CACTI 4.2 ermittelt, MPARM verwendet hingegen ein empirisches Mo-dell (siehe 2.5.7). Tabelle 5.4 zeigt die in MPARM/MEMSIM verwendeten Zugriffsenergien derSpeicher, die unter Verwendung von CACTI 4.2 berechneten wurden.

Zugriffsenergien Parameter Energie [nJ]

L1 I-Cache

Lesender Daten-Zugriff 0,0085Lesender Tag-Zugriff 0,0029Schreibender Tag-Zugriff 0,0022

L1 D-Cache

Lesender Daten-Zugriff 0,0236Lesender Tag-Zugriff 0,0064Schreibender Daten-Zugriff 0,0027Schreibender Tag-Zugriff 0,0023

Privater SlaveLesender Daten-Zugriff 2,6703Schreibender Daten-Zugriff 0,2667

Tabelle 5.4: Matrixmultiplikation: CACTI 4.2 Zugriffsenergien

Unter Vernachlassigung der schreibenden Tag-Zugriffe und unter Annahme einer Zugriff-senergie von 0,0114 nJ (Tag- + Daten-Zugriffsenergie) im lesenden Fall kann mit Hilfe einerUberschlagsrechnung ein Energieverbrauch von ca. 900 nJ auf Basis der Simulationsergebnissefur den L1 Instruktions-Cache ermittelt werden. Dies kann ebenso uberschlagsmaßig fur denL1 Daten-Cache durchgefuhrt werden. Unter der Annahme einer Zugriffsenergie von 0,03 nJim lesenden und 0,005 nJ im schreibenden Fall (Tag- + Daten-Zugriffsenergie) ergibt sich einEnergieverbrauch von ca. 495 nJ. Diese Energieverbrauche entsprechen dabei ungefahr denender Simulationsstatistik. Fur den privaten Slave ergibt sich die in der Simulationsstatistik an-gegebene Energie durch Multiplikation der Zugriffsenergien mit den Zugriffshaufigkeiten. Dergroße Unterschied in der Energiebilanz wird somit nachweislich durch das CACTI 4.2 Energie-


modell induziert. Da CACTI ein in der Industrie und der Wissenschaft sehr verbreitetes undangesehenes Programm zur Berechnung von Speicherparametern darstellt, wird die resultierendeEnergiebilanz in MPARM/MEMSIM als valide angenommen.

5.2.3 JPEG Encoding

Im Gegensatz zur Matrixmultiplikation stellt dieser Benchmark eine außerst rechenintensive undkomplexe Testapplikation dar, sodass auch fur sehr lange Berechnungszeiten die Validitat derMPARM-Erweiterung evaluiert wird. Des Weiteren wird durch die Verwendung eines Unified-Caches mit Write Back-Strategie und großerer Latenz des Hauptspeichers eine moglichst großeVariation in der Hardware-Architektur durchgefuhrt, um so die Gute der Integration auch furganzlich verschiedene Konfigurationen des Systems zu prufen.

Konfiguration Fur den privaten Slave wird bzgl. der Speicherstruktur die gleiche Konfigurati-on wie im ersten Benchmark gewahlt. Insgesamt ergibt sich folgende Konfiguration des Systems:

CPU Parameter Wert

L1 U-Cache

Große 16 kBBlockgroße in Worten* 4 (16 Byte)Assoziativitat 2Allocate On Write Miss* neinSchreibstrategie Write BackErsetzungsstrategie* Round RobinFull Line Write Back* jaWait States (lesend/schreibend) 0 / 0

Tabelle 5.5: JPEG Encode: CPU-Konfiguration

Slave Parameter Wert

Große 12 MBBlockgroße in Worten* 512 (2kB)Anzahl der Speicherbanke* 4Wait States (lesend/schreibend) 10 / 9

Tabelle 5.6: JPEG Encode: Slave-Konfiguration


Auswertung Aus der Simulation ergeben sich fur den JPEG Encoding-Benchmark folgendeMessdaten, die wiederum um die MPARM-Messfehler bereinigt wurden:

Messwert MPARM/MEMSIM MPARM Abweichung

GlobalTaktzyklen 5878512 5930488 -0,88 %Energieverbrauch [nJ] 706082,38 954497,45 -26,03 %

CPUEnergieverbrauch CPU [nJ] 287779,43 288302,40 -0,18 %Energieverbrauch Caches [nJ] 97707,38 619165,19 -84,22 %Energieverbrauch Total [nJ] 385486,82 907467,59 -57,52 %

L1 U-Cache

Lesende Zugriffe 3349789 3349789 ±0,00 %Read Hits 3322817 3322817 ±0,00 %Read Misses 26972 26972 ±0,00 %Schreibende Zugriffe 366750 366750 ±0,00 %Write Hits 331753 331753 ±0,00 %Write Misses 34997 34997 ±0,00 %Energieverbrauch [nJ] 97707,38 619165,19 -84,22 %

AMBA AHB Energieverbrauch [nJ] 18035,46 18790,24 -4,02 %

Privater Slave

Zugriffe 162121 162121 ±0,00 %Lesende Zugriffe 107888 107888 ±0,00 %Schreibende Zugriffe 54233 54233 ±0,00 %Energieverbrauch [nJ] 302560,10 28239,61 +971,40 %

Tabelle 5.7: JPEG Encode: Simulationsergebnisse im Vergleich

41%

14%3%

43%

CPUL1 U!CacheAMBA AHBPrivater Slave

(a) MPARM/MEMSIM

30%

65%

2%3%

CPUL1 U!CacheAMBA AHBPrivater Slave

(b) MPARM

Abbildung 5.2: JPEG Encode: Energiebilanz im Vergleich

Bewertung der Ergebnisse Auch fur diesen Benchmark stimmen die Zugriffsstatistiken desCaches und des privaten Slaves exakt uberein. Die Abweichung im Bereich der benotigten Takt-zyklen ist wiederum durch die in 5.2.1 erwahnten Punkte bedingt, und der Energieverbrauch der


CPU (ohne den Energieverbrauch der Caches) und des AMBA AHB Slaves weisen nur geringeAbweichungen auf.

Jedoch zeigen sich auch fur diesen Benchmark, wie in Abb. 5.2 dargestellt, große Unterschiedein der Energiebilanz des Gesamtsystems. Dabei stellt der L1 Unified-Cache in MPARM mit 65 %Anteil am Gesamtenergieverbrauch den großten Verbraucher dar. Der private Slave hat lediglicheinen Anteil von 3 %, sodass sich der Energieverbrauch des Caches ungefahr um den Faktor22 großer darstellt. Die CPU (ohne den Energieverbrauch der Caches) weist einen Anteil von30 % am Energiebedarf, der AMBA AHB Bus einen Anteil von 2 % auf. Im Gegensatz dazuhat der private Slave in MPARM/MEMSIM einen Anteil von 43 % am Energiebedarf, der L1Unified-Cache jedoch nur einen Anteil von 14 %, sodass in diesem Fall der private Slave einenungefahr um den Faktor 3 hoheren Energieverbrauch aufweist. Die ubrigen 41 % bzw. 3 %entfallen auf die CPU (ohne den Energieverbrauch der Caches) bzw. den AMBA AHB Bus.Dieses Ergebnis kann, wie im Fall des ersten Benchmarks, auf die Verwendung unterschiedlicherEnergiemodelle im Bereich der Speicher durch MPARM bzw. MPARM/MEMSIM zuruckgefuhrtwerden. Tabelle 5.4 zeigt die in MPARM/MEMSIM verwendeten Zugriffsenergien der Speicher,die unter Verwendung von CACTI 4.2 berechneten wurden.

Zugriffsenergien Parameter Energie [nJ]

L1 U-Cache

Lesender Daten-Zugriff 0,0218Lesender Tag-Zugriff 0,0060Schreibender Daten-Zugriff 0,0041Schreibender Tag-Zugriff 0,0051

Privater SlaveLesender Daten-Zugriff 2,6703Schreibender Daten-Zugriff 0,2667

Tabelle 5.8: JPEG Encode: CACTI 4.2 Zugriffsenergien

Wird fur den L1 Unified-Cache eine Zugriffsenergie von 0,0278 nJ im lesenden und 0,0092 nJim schreibenden Fall angenommen, so kann uberschlagsmaßig ein Energieverbrauch von 96500nJ bestimmt werden, der ungefahr den Simulationsergebnissen entspricht. Fur den Speicherdes privaten Slaves ergibt sich auf Basis der Zugriffsenergien und der Zugriffshaufigkeiten der inder Simulationsstatistik angegebene Energieverbrauch. Somit resultiert die große Abweichung inder Energiebilanz nachweislich aus der Verwendung unterschiedlicher Energiemodelle im Bereichder Speicher. Da jedoch CACTI, wie schon erwahnt, ein haufig verwendetes und angesehenesProgramm zur Berechnung von Speicherparametern darstellt, wird die in MPARM/MEMSIMermittelte Energiebilanz als valide angenommen.

5.2.4 Abschließende Bewertung

Nach der Auswertung zweier, bzgl. der Komplexitat vollig verschiedener Benchmarks unter derVerwendung vollig unterschiedlicher Systemkonfigurationen ist die Annahme der Korrektheitder Integration gerechtfertig. Es hat sich hat sich stets die geforderte Ubereinstimmung in denZugriffsstatistiken der Speicher gezeigt und auch die Anzahl benotigter Taktzyklen, der Ener-gieverbrauch der CPU (ohne den Energieverbrauch der Caches) und der Energieverbrauch desAMBA AHB Busses wiesen im Vergleich nur geringe Abweichungen auf, wobei Unterschiedein der Anzahl der benotigten Taktzyklen durch 5.2.1 begrundet werden konnten. Die großeDifferenz in der Energiebilanz des Gesamtsystems konnte nachweislich auf die Verwendung un-terschiedlicher Energiemodelle im Bereich der Speicher zuruckgefuhrt werden. Ebenso bleibtdie in Kapitel 3 geforderte Effizienz des MPARM-Simulators erhalten. So konnte fur keinenBenchmark ein signifikanter Unterschied in der benotigten Simulationszeit festgestellt werden.

5.3 Design Space Exploration 87

5.3 Design Space Exploration

Da die Optimierung der Speicherhierarchie des SoC auf Basis einer Grundkonfiguration des SoCund ausgewahlter Zielanwendungen (siehe 4.4) die komplexeste Optimierungsaufgabe darstellt,werden im Folgenden hierfur drei Optimierungen auf Basis von Zielanwendungen unterschied-licher Komplexitat vorgestellt und analysiert. Fur die Optimierung der statischen Scratchpad-Allokation (siehe 4.5) wird genau ein Anwendungsfall untersucht. Die Optimierungen werdendabei auf einem 2,4 GHz Intel Core2 Quad Prozessor ausgefuhrt.

5.3.1 Optimierung der Speicherhierarchie

Jede in diesem Abschnitt vorgestellte Optimierung der Speicherhierarchie erfolgt stets auf Ba-sis eines Ein-Prozessorsystems, da sich bereits fur Systeme, die eine CPU und einen privatenSlave enthalten, eine Vielzahl variabler Parameter in der Kodierung des Problems (siehe 4.4.3)ergibt. Des Weiteren soll diese Optimierung, die einen bisher nicht existierenden Ansatz dar-stellt, zunachst anhand kleinerer Problemgroßen getestet werden. Insgesamt werden 3 Optimie-rungen der Speicherhierarchie des SoC durchgefuhrt, wobei jeweils einer der in 5.1 vorgestell-ten Benchmarks als Zielanwendung eingesetzt wird. Dabei wird fur jeden Benchmark, der demMPARM/MEMSIM-Simulator zur Evaluation eines Individuums wahrend der Optimierung un-verandert als Eingabe dient, die Compiler-Optimierungsstufe O2 des arm-gcc Cross-Compilersgewahlt.

Grundkonfiguration Die Grundkonfiguration des Evolutionaren Algorithmus (siehe 4.3.3),die in Tabelle 5.9 dargestellt wird, wird fur alle durchgefuhrten Optimierungen verwendet. Dabeiwird die Mutationswahrscheinlichkeit hoch gewahlt, da der in 4.4.7 erlauterte Rekombinations-operator nur geringen Fortschritt im Evolutionsprozess erzielt und damit die Mutation maßgeb-lich zur Evolution beitragt. Da nur durch Rekombination Individuen des Archivs (Menge derbesten bisher gefundenen Losungen) in die aktuelle Population aufgenommen werden konnen,wird auch eine hohe Wahrscheinlichkeit fur die Rekombination verwendet. Die spezielle Wahl derParameterwerte ergibt sich aus vielen Optimierungslaufen und der anschließenden Auswahl derParameterkombination mit dem besten durchschnittlichen Ergebnis. Die Parameter des Kon-vergenzkriteriums (siehe 4.3.4) wurden ebenso auf diese Art und Weise ermittelt. Des Weiterenerfolgt die Gewichtung der Optimierungsgroßen Fi(x) ohne Bevorzugung eines Optimierungs-ziels. Dies kann nachtraglich durch die Auswertung der CSV-Ergebnisdatei (siehe 4.3.6) erfolgenund wird im Folgenden fur die JPEG Encoding-Zielanwendung, exemplarisch durchgefuhrt.

Parameter Wert

EAPopulationsgroße N = N 50Rekombinationswahrscheinlichkeit pR 0,6Mutationswahrscheinlichkeit pM 0,7

KonvergenzkriteriumT (Schwellwert) 0,1G (Beobachtungsabstand) 5O (Anzahl Beobachtungen) 3

GewichtungEnergie (wenergy) 1Zyklen (wcycles) 1Chipflache (warea) 1

Tabelle 5.9: Grundkonfiguration des EA

Die Grundkonfiguration des SoC (siehe 4.4.2) wird mit Ausnahme der Minimal- und Maxi-


malwerte der Cache-Parameter, die Problem-spezifisch festgelegt werden, in jeder Optimierunggleich gewahlt. Die Anzahl der Prozessor-lokalen Caches wird dabei auf 5 begrenzt, da in jedemFall eine Cache-Hierarchie der Tiefe 3 unter Verwendung zweier Cache-Levels, die aus jeweilseinem Instruktions- und einem Daten-Cache bestehen, und eines L3 Unified-Caches ermoglichtwerden soll. Eine großere Anzahl Prozessor-lokaler Caches wird als nicht sinnvoll erachtet. Hinterdem Bus werden zur Kompensation der Latenz des privaten Speichers 2 lokale Unified-Cachesermoglicht. Fur die Große des privaten Speichers wird der MPARM-Standardwert gewahlt. Furdiesen wird des Weiteren eine realen Speicherbausteinen entsprechende Anzahl von 4 Speicher-banken zu je 3 MB mit einer Blockgroße von 2 kB verwendet. Da der private Speicher in Formeines SRAM-Bausteins vorliegt, wird eine Latenz von 10 Taktzyklen gewahlt.

Parameter Wert

CPU Max. Anzahl lokaler Caches 5

Privater Slave

Max. Anzahl lokaler Caches 2Große 12 MBAnzahl Speicherbanke 4Blockgroße in Worten 512 (2 kB)Wait States - Byte-Zugriff (lesend/schreibend) 10 / 10Wait States - Halbwort-Zugriff (lesend/schreibend) 10 / 10Wait States - Wort-Zugriff (lesend/schreibend) 10 / 10

Tabelle 5.10: Allgemeine Grundkonfiguration des SoC

5.3.1.1 Matrixmultiplikation

Die Minimal- und Maximalwerte der Cache-Parameter werden fur diese Optimierung, die denMatrixmultiplikations-Benchmark als Zielanwendung nutzt, wie in Tabelle 5.11 dargestellt, ge-wahlt. Dabei wird die Cache-Große aufgrund der geringen Komplexitat und auf Basis der Analy-se bereits durchgefuhrter Optimierungen auf 128 kB beschrankt. Die Blockgroße wird so gewahlt,dass fur einen Cache der Große 128 kB zumindest eine quadratische Form mit einer Blockgroßevon 29 Byte (dies entspricht einer Anzahl von 27 Worten) und einer Anzahl von 29 Zeilenermoglicht wird. Die Assoziativitat wird aufgrund der CACTI 4.2 Beschrankung (siehe 3.5) aufmaximal 16 begrenzt.

Parameter Min. Max.

Cache-Große 64 Byte (26) 256 kB (218)Blockgroße in Worten 2 (21) 128 (27)Assoziativitat 1 (20) 16 (24)

Tabelle 5.11: Matrixmultiplikation: Grundkonfiguration des SoC

Abb. 5.3a zeigt die initiale Population bzgl. der zu minimierenden Optimierungsgroßen Fi(x).Dabei zeigt sich die gewunschte breite Streuung der Individuen im Losungsraum, sodass vonvornherein eine globale Suche nach geeigneten Optima sichergestellt wird. Diese breite Streuungresultiert dabei aus dem in 4.4.6 beschriebenen Ansatz, der sich an dieser Stelle diesbezuglichals besonders geeignet erweist.


01

23

4

x 105

0

0.5

1

1.5

2

x 106

600

650

700

750

800

850

Energieverbrauch [nJ]Taktzyklen

Chip

fläch

enbe

darf

[mm

2 ]

(a) Initiale Population

01

23

4

x 105

0

0.5

1

1.5

2

x 106

600

650

700

750

800

850


Chip

fläch

enbe

darf

[mm

2 ]

(b) Ergebnispopulation

0.60.8

11.2

1.4

x 104

1.261.28

1.31.32

1.341.36

x 105

644.5

645

645.5

646

646.5

647

647.5


Chip

fläch

enbe

darf

[mm

2 ]

(c) Ergebnispopulation in der Nahe des Ursprungs 0

5 10 15 20 25 30 35 40 45 50 550

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45

Generation

Konvergenzindex

(d) Konvergenzindex

Abbildung 5.3: Matrixmultiplikation: Optimierungsergebnis


Die Menge nicht-dominierter Individuen nach Erfullung des Konvergenzkriteriums wird inAbb. 5.3b bzgl. der zugehorigen Optimierungsgroßen Fi(x) dargestellt. Da eine Minimierungder benotigten Taktzyklen meist auch mit einer Minimierung des Energieverbrauchs einhergeht,ergibt sich aufgrund der Minimierung aller Teilziele eine Haufung nicht-domierter Individuenin der Umgebung des Ursprungs. Die Extremallosung einer Speicherhierarchie ohne Caches istals Punkt mit maximaler x- und y-Koordinate und minimaler z-Koordinate erkennbar. Abb.5.3c zeigt einen Ausschnitt des Losungsraums um den Ursprung, in dem sich die meisten nicht-dominierten Individuen befinden.

Der Evolutionsprozess benotigt insgesamt 55 Generationen bis zur Erfullung des Konver-genzkriteriums, was einer Berechnungszeit von 3 Stunden, 2 Minuten und 40 Sekunden ent-spricht. Den Verlauf des zugehorigen Konvergenzindex zeigt Abb. 5.3d, wobei die Horizontaley = 0.1 = T den Schwellwert des Konvergenzindex darstellt.

Die unter Gleichgewichtung aller Teilziele Fi(x) ermittelte Losung, die in Tabelle 5.12 darge-stellt wird, verwendet einen L1 Instruktions- und einen L1 Daten-Cache, wobei in beiden Fallenein Direct Mapped Cache zum Einsatz kommt. Dem Instruktions-Cache wird dabei eine Großevon 256 Byte, dem Daten-Cache eine Große von 2 kB zugewiesen. Bemerkenswert ist, dass derevolutionare Ansatz eine Write Back-Strategie fur den Daten-Cache bevorzugt und somit dieAnzahl der Bus-Transaktionen minimiert. Alle Parameter, die mit einem schreibenden Zugriffin Verbindung stehen, werden im Fall des Instruktions-Caches nicht aufgefuhrt. Die zugehorigenOptimierungsgroßen der ermittelten Losung finden sich in Tabelle 5.13.

Parameter Wert

L1 I-Cache

Große 256 ByteBlockgroße in Worten 8 (32 Byte)Assoziativitat 1Ersetzungsstrategie keine

L1 D-Cache

Große 2 kBBlockgroße in Worten 8 (32 Byte)Assoziativitat 1Allocate On Write Miss jaSchreibstrategie Write BackFull Line Write Back neinErsetzungsstrategie keine

Tabelle 5.12: Matrixmultiplikation: Ergebnisindividuum

Optimierungsgroße Wert

Energieverbrauch [nJ] 7954,05Taktzyklen 128100Chipflachenbedarf [mm2] 644,86

Tabelle 5.13: Matrixmultiplikation: Optimierungsgroßen des Ergebnisindividuums


5.3.1.2 GSM Decode

Im Vergleich zur ersten Optimierung, die den Matrixmultiplikations-Benchmark als Zielanwen-dung verwendet, werden die Maximalwerte der Cache-Parameter aufgrund der hoheren Komple-xitat des GSM Decode-Benchmarks großer gewahlt. So ergibt sich fur einen Cache eine maximaleKapazitat von 8 MB bei einer Blockgroße von 1 kB. Die Wahl dieser Blockgroße ermoglicht wie-der eine quadratische Form des Caches mit einer Blockgroße von 211 oder 212 Byte (29 oder 210

Worte) und 212 oder 211 Zeilen. Die minimale und maximale Assoziativitat bleibt unverandert.Diese Konfiguration wird in Tabelle 5.14 zusammenfassend dargestellt.

Parameter Min. Max.

Cache-Große 64 Byte (26) 8 MB (223)Blockgroße in Worten 2 (21) 1kB (210)Assoziativitat 1 (20) 16 (24)

Tabelle 5.14: GSM Decode: Grundkonfiguration des SoC

Abb. 5.4a stellt die initiale Population bzgl. der zu minimierenden Optimierungsgroßen Fi(x)dar. Dabei zeigt sich, wie im Anwendungsfall der Matrixmultiplikation, eine breite initiale Streu-ung im Losungsraum, die erneut die Gute des fur die Initialisierung gewahlten Ansatzes belegt.Da das Intervall erlaubter Cache- und Blockgroßen wesentlich großer gewahlt wurde als in derersten Optimierung, existieren ungunstige Konfigurationen einer Speicherhierarchie, die sichbzgl. des Energieverbrauchs und der Anzahl benotigter Taktzyklen schlechter darstellen alseine Speicherhierarchie ohne Caches (z.B. große Cache- und Blockgroße und Write Through-Strategie).

Abb. 5.4b zeigt die Ergebnispopulation nicht-dominierter Individuen bzgl. der Optimierungs-großen Fi(x) nach Erfullung des Konvergenzkriteriums. Auch fur diese Optimierung zeigt sichaufgrund der Minimierung aller Teilziele eine Haufung von Individuen in der Nahe des Ur-sprungs. Die Losung ohne Caches ist wieder als Losung mit maximaler x- und y- und minimalerz-Koordinate erkennbar. Abb. 5.4c zeigt die Umgebung des Ursprungs, in der sich eine Haufungnicht-dominierter Individuen ergibt. Die nicht-dominierte Losung mit großem Chipflachenbedarf,großem Energieverbrauch und geringer Anzahl an Taktzyklen ergibt sich durch die Verwendungeines großen Caches mit großer Blockgroße und der Strategie allocate on write miss.

Die benotige Anzahl an Generationen bis zur Erfullung des Konvergenzkriteriums betragt125, was einer Berechnungszeit von 54 Stunden, 11 Minuten und 55 Sekunden entspricht. DenVerlauf des zugehorigen Konvergenzindex zeigt Abb. 5.4d, wobei die Horizontale wieder denSchwellwert T des Konvergenzkriteriums darstellt. Die lange Berechnungszeit resultiert nebeneiner großeren Anzahl auszuwertender Generationen aus einer langeren Simulationszeit pro aus-zuwertendem Individuum aufgrund der hoheren Komplexitat dieses Benchmarks.


00.5

11.5

2

x 107

0

5

10

15

x 107

0

1000

2000

3000

4000

5000

6000

7000

8000


Chip

fläch

enbe

darf

[mm

2 ]


00.5

11.5

2

x 107

0

5

10

15

x 107

0

1000

2000

3000

4000

5000

6000

7000

8000


Chip

fläch

enbe

darf

[mm

2 ]


11.5

22.5

33.5

4

x 105

22.2

2.42.6

2.83

x 106

600

650

700

750

800

850

900

950

1000


Chip

fläch

enbe

darf

[mm

2 ]


20 40 60 80 100 1200

0.1

0.2

0.3

0.4

0.5

0.6

Generation

Konvergenzindex

(d) Konvergenzindex

Abbildung 5.4: GSM Decode: Optimierungsergebnis


Die ermittelte Approximation der optimalen Speicherhierarchie bei Gleichgewichtung al-ler Teilziele Fi(x) wird in Tabelle 5.15 dargestellt und verwendet einen 4-Weg assoziativen L1Unified-Cache mit einer Große von 32 kB und einer Blockgroße von 2 Worten (8 Byte). Andieser Stelle ist festzuhalten, dass sich aufgrund einer hoheren Berechnungskomplexitat undgroßerer Datenmengen (der Benchmark verwendet große Eingabedaten) eine großere Cache-Große einstellt. Bemerkenswert ist abermals die Verwendung einer Write Back-Strategie zurVermeidung von Buszugriffen. Ebenso werden bei einem Write Back nur modifizierte Worterzuruckgeschrieben. Aufgrund der ortlichen bzw. zeitlichen Lokalitat von Cache-Zugriffen scheintsich die Strategie allocate on write miss als optimal herausgestellt zu haben. Die zu dieser Losunggehorigen Optimierungsgroßen finden sich in Tabelle 5.16.

Parameter Wert

L1 U-Cache

Große 32 kBBlockgroße in Worten 2 (8 Byte)Assoziativitat 4Allocate On Write Miss jaSchreibstrategie Write BackFull Line Write Back neinErsetzungsstrategie Round Robin

Tabelle 5.15: GSM Decode: Ergebnisindividuum



Tabelle 5.16: GSM Decode: Optimierungsgroßen des Ergebnisindividuums

5.3.1.3 JPEG Encode

Die Minimal- und Maximalwerte der Cache-Parameter werden fur die Zielanwendung JPEGEncode unverandert von der Optimierung, die den GSM Decode-Benchmark verwendet, uber-nommen (siehe Tabelle 5.17). Die große Cache- und Blockgroße sind dabei wieder durch diehohe Berechnungskomplexitat des Benchmarks bedingt. Vorherige Optimierungslaufe haben desWeiteren gezeigt, dass sich in der Pareto-Menge nicht-dominierter Losungen Speicherhierarchienergeben, die Caches in der Großenordung von 1 oder 2 MB verwenden.

Parameter Min. Max.

Cache-Große 64 Byte (26) 8 MB (223)Blockgroße in Worten 2 (21) 1kB (210)Assoziativitat 1 (20) 16 (24)

Tabelle 5.17: JPEG Encode: Grundkonfiguration des SoC


00.5

11.5

2

x 109

0

5

10

15

x 107

0

0.5

1

1.5

2

2.5

x 104


Chip

fläch

enbe

darf

[mm

2 ]


00.5

11.5

2

x 109

0

5

10

15

x 107

0

0.5

1

1.5

2

2.5

x 104


Chip

fläch

enbe

darf

[mm

2 ]


00.5

11.5

2

x 106

4

6

8

10

12

x 106

600

650

700

750

800

850

900

950

1000


Chip

fläch

enbe

darf

[mm

2 ]


10 20 30 40 50 60 70 80 90 1000

0.1

0.2

0.3

0.4

0.5

0.6

Generation

Konvergenzindex

(d) Konvergenzindex

Abbildung 5.5: JPEG Encode: Optimierungsergebnis


Abb. 5.5a illustriert die initiale Population bzgl. der zu minimierenden OptimierungsgroßenFi(x). Dabei zeigt sich eine große Anzahl an Individuen mit scheinbar gleichem Energieverbrauchund unterschiedlicher Anzahl benotigter Taktzyklen. Dies ist jedoch durch die Skalierung derx-Achse (Energieverbrauch [nJ]) bedingt, die aufgrund einiger Ausreißer im Bereich des Ener-gieverbrauchs relativ groß skaliert wurde (109). Wie im Fall der Optimierung, die den GSMDecode-Benchmark als Zielanwendung verwendet, ergeben sich diese Ausreißer durch ungunstigeKonfiguration der Speicherhierarchie. Insgesamt zeigt sich aber in diesem Anwendungsfall einebreite Streuung in der initialen Population.

Die Ergebnispopulation bzgl. der Optimierungsgroßen Fi(x) nach Erfullung des Konvergenz-kriteriums, die in Abb. 5.5b dargestellt wird, zeigt auch fur diese Optimierung eine große Anzahlnicht-dominierter Individuen in der Nahe des Ursprungs, wobei durch die Skalierung der x-Achseeine Verzerrung der Darstellung hervorgerufen wird. Auch die Systemkonfiguration ohne Cachesist abermals als Losung mit maximaler x- und y- und minimaler z-Koordinate erkennbar. DesWeiteren zeigt Abb. 5.5c die Haufung nicht-dominierter Individuen in der Nahe des Ursprungsohne Verzerrung.

Dem in Abb. 5.5d dargestellten Konvergenzindex lasst sich eine benotigte Anzahl von 105Generationen bis zur Erfullung des Kovergenzkriteriums entnehmen, was einer Berechnungzeitvon 147 Stunden, 8 Minuten und 27 Sekunden entspricht. Diese lange Berechnungszeit wird vorallem durch die lange Auswertungs-/Simulationzeit pro Individuum hervorgerufen.

Das Ergebnisindividuum wurde abermals unter Gleichgewichtung aller Teilziele ermittelt.Die zugehorige Speicherhierarchie verwendet einen 4-Weg assoziativen L1 Unified-Cache miteiner Große von 32 kB und einer Blockgroße von 2 Worten (8 Byte). Auch in diesem Fall kommtvor dem Bus eine Write Back-Strategie zur Minimierung der Buszugriffe zum Einsatz, wobeinur modifizierte Worter der Cache-Zeile bei einem Write Back zuruckgeschrieben werden. AlsErsetzungsstrategie hat sich LRU als optimal erwiesen. Die zur Losung gehorigen Werte derOptimierungsgroßen konnen Tabelle 5.19 entnommen werden.

Parameter Wert

L1 U-Cache

Große 32 kBBlockgroße in Worten 2 (8 Byte)Assoziativitat 4Allocate On Write Miss neinSchreibstrategie Write BackFull Line Write Back neinErsetzungsstrategie LRU

Tabelle 5.18: JPEG Encode: Ergebnisindividuum



Tabelle 5.19: JPEG Encode: Optimierungsgroßen des Ergebnisindividuums


Neben der Gleichgewichtung aller Teilziele wird fur diese Optimierung zusatzlich die Ver-nachlassigung der benotigten Chipflache bei Gleichgewichtung der Anzahl benotigter Taktzy-klen und des Energieverbrauchs betrachtet. Die um eine Dimension reduzierte Ergebnispopu-lation (bzgl. der Optimierungsgroßen Fi(x)) zeigt Abb. 5.6, wobei eine naherungsweise lineareAbhangigkeit zwischen diesen Optimierungsgroßen erkennbar ist.

0 2 4 6 8 10 12x 106

0

1

2

3

4

5

6x 107

Energieverbrauch [nJ]

Takt

zykle

n

Abbildung 5.6: JPEG Encode: Ergebnispopulation unter Vernachlassigung der Chipflache

Die nach Normierung des zweidimensionalen Losungsraums ermittelte Losung zeigt Tabelle5.20. Dabei ergibt sich bei Vernachlassigung des Chipflachenbedarfs eine zweistufige Cache-Hierarchie, bestehend aus einem L1 Unified-Cache der Große 64 kB und einem L2 Unified-Cache der Große 128 kB. Im Gegensatz zur Minimierung aller Teilziele zeigt sich die Verwendunggroßerer Caches und großerer Cache-Hierarchien. Einen Uberblick uber die zur Losung gehorigenOptimierungsgroßen liefert Tabelle 5.21.

Parameter Wert

L1 U-Cache

Große 64 kBBlockgroße in Worten 8 (32 Byte)Assoziativitat 2Allocate On Write Miss jaSchreibstrategie Write BackFull Line Write Back neinErsetzungsstrategie Round Robin

L2 U-Cache

Große 128 kBBlockgroße in Worten 8 (32 Byte)Assoziativitat 16Allocate On Write Miss neinSchreibstrategie Write ThroughFull Line Write Back neinErsetzungsstrategie LRU

Tabelle 5.20: JPEG Encode: Ergebnisindividuum unter Vernachlassigung der Chipflache




Tabelle 5.21: JPEG Encode: Optimierungsgroßen des Ergebnisindividuums unter Ver-nachlassigung der Chipflache

5.3.2 Optimierung der Scratchpad-Allokation

Die in 4.5 erlauterte Optimierung der statischen Scratchpad-Allokation zur Compilezeit wirdim Folgenden anhand einer Zielanwendung durchgefuhrt, analysiert und validiert. Aufgrund desmodularen Aufbaus wird dazu der GSM Decode-Benchmark verwendet, dessen statische Funk-tionen und Variablen fur diese Optimierung in nicht-statische geandert wurden, da die Auslage-rung statischer Funktionen und Variablen aufgrund der lokalen Sichtbarkeit nicht moglich ist.Als Compiler-Optimierungsstufe des arm-gcc Cross-Compilers wird O2 gewahlt. Durch die Ver-wendung eines Genetischen Algorithmus fur die Optimierung der Scratchpad-Allokation (siehe4.5) ergeben sich im Vergleich zur Optimierung der Speicherhierarchie andere Mutations- undRekombinationswahrscheinlichkeiten, alle anderen Parameter bleiben unverandert. Die resultie-rende Grundkonfiguration (siehe 4.3.3) kann Tabelle 5.22 entnommen werden kann.

Parameter Wert

GAPopulationsgroße N = N 50Rekombinationswahrscheinlichkeit pR 0,7Mutationswahrscheinlichkeit pM 0,2

KonvergenzkriteriumT (Schwellwert) 0,1G (Beobachtungsabstand) 5O (Anzahl Beobachtungen) 3

GewichtungEnergie (wenergy) 1Zyklen (wcycles) 1Chipflache (warea) 1

Tabelle 5.22: Grundkonfiguration des GA

Um die resultierende Losung der Optimierung validieren zu konnen, wird ein Referenzsys-tem bestehend aus einer CPU und einem privaten Slave, jeweils ohne lokale Caches, verwen-det. Die Konfiguration des privaten Speichers (des Hauptspeichers) wird dabei wie im Fall derSpeicherhierarchie-Optimierung gewahlt. Fur das Prozessor-lokale Scratchpad wird eine maxi-male Große von 12 kB verwendet, wobei sowohl diese als auch die Blockgroße stets gemaß desuber den Linker-Report ermittelten Speicherbedarfs, angepasst wird. Bis zu einer benotigtenGroße von 2 kB wird diese, sofern keine Zweierpotenz vorliegt, an die nachst großere Zweierpo-tenz angepasst. Werden mehr als 2 kB benotigt, erfolgt eine Anpassung in 2 kB-Schritten biszu einer maximalen Große von 12 kB. Alle Losungen, die ein großeres Scratchpad benotigen,werden uber die Maximierung der Optimierungsgroßen bestraft (siehe 4.5.9). Die Blockgroßewird stets so gewahlt, dass die Anzahl der Bytes pro Zeile der Anzahl der Zeilen entspre-chen (quadratische Form). Die Anpassung der Große und der Blockgroße wird durchgefuhrt,da aus einer Verkleinerung des Scratchpads eine geringere Zugriffsenergie und ein geringererChipflachenbedarf resultiert. Ebenso wird die Degenerierung des Genetischen Algorithmus mitdrei Optimierungszielen (Energieverbrauch, Anzahl benotigter Taktzyklen, Chipflachenbedarf)


zu einem Algorithmus mit zwei Optimierungzielen (Energieverbrauch, Anzahl benotigter Takt-zyklen) bei gleichbleibendem Chipflachenbedarf vermieden. Des Weiteren verfugt das Scratchpaduber keine Latenz und verwendet aufgrund der geringen Große stets eine Speicherbank. EinenUberblick uber die Konfigurationsparameter des Referenzsystems liefert Tabelle 5.23.

Parameter Wert

Scratchpad

Max. Große 12 kBAnzahl Speicherbanke 1Wait States - Byte-Zugriff (lesend/schreibend) 0 / 0Wait States - Halbwort-Zugriff (lesend/schreibend) 0 / 0Wait States - Wort-Zugriff (lesend/schreibend) 0 / 0

Privater Slave

Große 12 MBAnzahl Speicherbanke 4Blockgroße in Worten 512 (2 kB)Wait States - Byte-Zugriff (lesend/schreibend) 10 / 10Wait States - Halbwort-Zugriff (lesend/schreibend) 10 / 10Wait States - Wort-Zugriff (lesend/schreibend) 10 / 10

Tabelle 5.23: Allgemeine Grundkonfiguration des SoC

Die initiale Population bzgl. der Optimierungsgroßen Fi(x), die in Abb. 5.7a illustriert wird,zeigt eine breite Streuung im Losungsraum, wobei diese durch den in 4.5.6 beschriebenen Initiali-sierungsansatz induziert wird. Dieser Ansatz, der sich somit fur den entwickelten Optimierungs-ansatz als geeignet erweist, ermoglicht daher von vornherein eine globale Suche nach geeignetenOptima.

Die Losungsmenge nicht-dominierter Individuen, die lediglich aus 4 Individuen besteht, zeigtAbb. 5.7b. Dabei wurde fur die Scratchpad-Großen 2, 4, 6 und 8 kB eine optimale Allokationberechnet, großere Scratchpad-Großen kommen aufgrund einiger nicht referenzierter Funktionenund Variablen (siehe Tabelle 5.25) nicht zum Einsatz.

Die Evolution erforderte die Auswertung von 80 Generationen, was einer Berechnungszeitvon 25 Stunden, 5 Minuten und 20 Sekunden entspricht. Der zugehorige Konvergenzindex kannAbb. 5.7c entnommen werden.

Die ermittelte Approximation der optimalen statischen Scratchpad-Allokation bei Gleich-gewichtung aller Teilziele wird in Tabelle 5.25 dargestellt. Dabei enthalt die erste Spalte dieSymbolnamen der globalen Funktionen und Variablen, der letzten Spalte kann entnommen wer-den, ob die zum Symbol gehorige Funktion bzw. Variable in das Scratchpad ausgelagert wird(X) oder nicht (×). Die zur Losung gehorige Scratchpad-Große betragt 8 kB (7192 Byte werdennach Linker-Report benotigt), die Blockgroße betragt 128 Byte (32 Worte). Die zugehorigenOptimierungsgroßen konnen Tabelle 5.24 entnommen werden.



Tabelle 5.24: GSM Decode: Optimierungsgroßen des Ergebnisindividuums

Zur Bewertung der Gute der ermittelten Losung wurde die Anzahl der Zugriffe Z auf denSpeicherbereich einer Funktion bzw. Variable (2. Spalte) und die jeweilige Große G einer Funk-tion bzw. Variable (3.Spalte) ermittelt. Die Große einer Funktion bzw. Variablen wurde der


Ausgabe des Linkers entnommen. Die Anzahl der Zugriffe auf den zugehorigen Speicherbereichwurden anhand eines Tracefiles des MPARM-Simulators, das alle lesenden und schreibendenZugriffe des Prozessors mit den zugehorigen Adressen enthalt, und der Ausgabe des Linkers, derdie Speicherbereiche der Funktionen bzw. Variablen entnommen werden konnen, ermittelt. Umdie im Tracefile dokumentierten Speicherzugriffe einer Funktion bzw. Variablen zuzuordnen unddie Gesamtzahl der Zugriffe zu ermitteln, wurde ein am Lehrstuhl entwickeltes Skript eingesetzt.Aus der Anzahl der Zugriffe Z und der Große G kann ein Nutzen N fur die Auslagerung einerFunktion bzw. einer Variablen berechnet werden. Da mit der Große einer Funktion bzw. Varia-blen der Nutzen sinkt und mit der Anzahl der Zugriffe steigt, wird der Nutzen einer Auslagerunguber den Quotienten Z/G (4. Spalte) definiert.

Die Bewertung der Gute der ermittelten Losung grundet sich im Folgenden auf der Annahme,dass alle Funktionen bzw. Variablen mit einem Nutzen N ≥ 4 (die Summe zugehorigen Großenist kleiner als die Obergrenze der Scratchpad-Große) auszulagern sind. Unter dieser Annahmekann Tabelle 5.25 entnommen werden, dass 16 von 20 auszulagernden Funktionen bzw. Varia-blen tatsachlich in das Scratchpad verschoben werden, was einem Anteil von 80 % entspricht.In Anbetracht einer moglichen Anzahl von 248 ≈ 2, 81 · 1014 Losungsalternativen (binare Ent-scheidungsvariablen fur 48 Symbole), ist die Gute der Losung sehr hoch einzustufen. Ebenso istbemerkenswert, dass eine solch gute Losung innerhalb von 80 Generationen, d.h. nach Auswer-tung von 4000 (aus 2, 81 · 1014; wobei nicht alle ausgewerteten Individuen paarweise verschiedensind) Individuen, ermittelt werden konnte. Eine Verbesserung dieser guten Losung kann ggf.durch eine Verkleinerung des Konvergenzschwellwerts T erreicht werden, was jedoch meist eineVerlangerung der Evolution zur Folge hat.


00.5

11.5

2

x 107

0.51

1.52

2.53

x 107

644.8

644.85

644.9

644.95

645

645.05

645.1


Chip

fläch

enbe

darf

[mm

2 ]


00.5

11.5

2

x 107

0.51

1.52

2.53

x 107

644.8

644.85

644.9

644.95

645

645.05

645.1


Chip

fläch

enbe

darf

[mm

2 ]


10 20 30 40 50 60 70 800

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Generation

Konvergenzindex

(c) Konvergenzindex

Abbildung 5.7: GSM Decode: Optimierungsergebnis


Symbolname Zugriffe Z Große G N = Z/G SPM

Funktionen

gsm add 0 60 0,00 ×gsm sub 0 60 0,00 ×gsm mult 0 52 0,00 ×gsm mult r 0 56 0,00 Xgsm abs 0 52 0,00 Xgsm L mult 0 28 0,00 ×gsm L add 0 88 0,00 ×gsm L sub 0 80 0,00 ×gsm norm 0 140 0,00 ×gsm L asl 0 96 0,00 ×gsm asl 0 120 0,00 ×gsm L asr 0 60 0,00 ×gsm div 0 80 0,00 ×gsm option 23 44 0,52 XDecoding of the coded Log Area Ratios 5862 1416 4,14 XCoefficients 0 12 4780 152 31,45 XLARp to rp 15306 248 61,72 Xdecode 506 160 3,16 ×gsm decode 14400 2868 5,02 XGsm Decoder 29180 264 110,53 XGsm Long Term Synthesis Filtering 146060 216 676,20 XGsm RPE Decoding 6560 132 49,70 XRPE grid positioning 12176 132 92,24 XAPCM inverse quantization 35767 348 102,78 Xgsm asr 0 76 0,00 XAPCM quantization xmaxc to exp mant 2662 120 22,18 ×Postprocessing 107731 184 585,49 XCoefficients 13 26 9840 112 87,86 XCoefficients 40 159 1140 24 47,50 XShort term synthesis filtering 1158892 284 4080,61 XGsm Short Term Synthesis Filter 2300 304 7,57 XCoefficients 27 39 4820 152 31,71 Xcreate 4220 64 65,94 X

Variablen

gsm FAC 80 16 5,00 ×f fast 0 4 0,00 Xf verbose 1 4 0,25 Xgsm A 0 16 0,00 ×gsm B 0 16 0,00 Xgsm MIC 0 16 0,00 ×gsm MAC 0 16 0,00 ×gsm INVA 0 16 0,00 Xgsm DLB 0 8 0,00 ×gsm QLB 80 8 10,00 ×gsm H 3 22 0,14 Xpcmdata 9479 6400 1,48 ×gsmdata 658 660 0,99 ×bitoff 0 256 0,00 ×gsmstate 109231 648 168,57 ×

Tabelle 5.25: GSM Decode: Ergebnisindividuum

Kapitel 6

Zusammenfassung und Ausblick

Eingebettete Systeme kommen in vielen Bereichen, wie z.B. in Kraftfahrzeugen, Flugzeugen,Haushaltsgeraten oder in medizinischem Equipment zum Einsatz. Dabei sind die Anforderun-gen an solche Systeme, je nach Einsatzdomane, sehr vielfaltig und hoch. So sollen eingebetteteSysteme meist energieeffizient, echtzeitfahig und kostengunstig sein. Die Simulation solcher Sys-teme ermoglicht bereits zur Enwicklungszeit eine Analyse und Optimierung des Systems, da dieAnforderungen und der gewunschte Funktionsumfang meist von vornherein bekannt sind. Si-mulatoren, die zu diesem Zweck genutzt werden, mussen jedoch eine flexible Konfigurierbarkeitdes Systems erlauben, um einen moglichst großen Suchraum fur Designalternativen zu bieten.Besonders im Bereich der Speicherhierarchie ist dies wunschenswert und notwendig, da dieseeinen entscheidenden Einfluss auf die Effizienz des zu entwickelnden Systems hat.

Durch die Erweiterung des MPARM System-on-Chip Simulators um MEMSIM wurde solchein Simulator entwickelt, der auch im Bereich der Speicherhierarchie eine moglichst flexible Eva-luation des Entwurfsraums ermoglicht. Der Vergleich dieses Simulators mit der ursprunglichenVersion des MPARM-Simulators lasst begrundet auf die Validitat dieser Entwicklung schließen.

Durch den Einsatz geeigneter Optimierungsverfahren auf Basis einer Simulation kann dieEntwicklungszeit eines eingebetteten Systems deutlich verkurzt werden. Diese elektronische Desi-gnautomatisierung stellt jedoch ein komplexes Optimierungsproblem dar. In dieser Diplomarbeitwurde unter Verwendung Evolutionarer Algorithmen zur mehrkriteriellen Optimierung ein Op-timierungsansatz entwickelt, der auf Basis einer Grundkonfiguration des SoC und ausgewahlterZielanwendungen, die die gewunschte Funktionalitat des Systems hinreichend beschreiben, eineApproximation der optimalen Speicherhierarchie (d.h. Cache-Hierarchie) ermittelt. Die Ergeb-nisse dieser Optimierung haben sich stets nachvollziehbar und gut dargestellt. Da auch derEinsatz kleiner, energieeffizienter Scratchpadspeicher viele Optimierungsmoglichkeiten im Be-reich eingebetteter Systeme bzgl. des Energieverbrauchs oder der Laufzeit einer Zielanwendungeroffnet, wurde zusatzlich eine Optimierung der statischen Scratchpad-Allokation auf Basis einesReferenzsystems des SoC und ausgewahlter Zielanwendungen unter Verwendung EvolutionarerAlgorithmen umgesetzt.

Aufbauend auf den Ergebnissen dieser Diplomarbeit ergeben sich zukunftig einige Erweite-rungsmoglichkeiten:

Unterstutzung zusatzlicher Speichertechnologien Die im Rahmen dieser Diplomarbeitentwickelte Version des MPARM/MEMSIM-Simulators beschrankt sich auf die Simulation vonSRAM-Speichern. In einer weiteren Entwicklungsstufe des Simulators ist ebenso eine Unterstutz-ung von DRAM- oder Flash-Speichern denkbar. Dazu ist lediglich die Implementierung einerzusatzlichen Speicherlogik als Derivat der Klasse MemoryLogic (siehe 3.4.4) notwendig. Im Falleines DRAMs ist z.B. der zugehorige DRAM-Zustandsautomat zu implementieren.

103

104 6 Zusammenfassung und Ausblick

Neue CACTI-Version MPARM/MEMSIM ermoglicht die Berechnung der Zugriffsenergienund des Chipflachenbedarfs der Speicher unter Verwendung von CACTI 4.2. Zukunftig ist derEinsatz der neueren CACTI-Versionen 5 oder 6 denkbar. Im Rahmen dieser Erweiterung mussjedoch genau uberpruft werden, welche Parameterkombinationen beim Aufruf von CACTI 5/6zu verwenden sind, da sich diese sehr viel umfangreicher darstellen als in CACTI 4.2. In dieserDiplomarbeit wurde CACTI 4.2 vor allem wegen der hohen Berechnungsgeschwindigkeit und dereinfachen Parametrisierbarkeit eingesetzt. Die Berechnungseffizienz hat in den neuen Versionenstark abgenommen, sodass eine Berechnung durchaus 15 Sekunden dauern kann. Die Parame-trisierung des Aufrufs von CACTI 5/6 ist somit entscheidend fur die Effizienz des gesamtenSimulators, vor allem im Bereich der Design Space Exploration, bei der durchaus zwischen 5000bis 6000 Simulationen durchgefuhrt werden.

Optimierung der Speicherhierarchie fur Systeme mit mehr als nur einer funktiona-len Anforderung Der Funktionsumfang eingebetteter Systeme beschrankt sich haufig nichtnur auf eine spezielle Funktionalitat. So sind z.B. die Einsatzdomanen heutiger Mobiltelefoneaußerst vielfaltig. Um auch diesen Anforderungen nachzukommen, kann die Optimierung derSpeicherhierarchie eines SoC unter Verkettung von Zielanwendungen, die die Vielfaltigkeit derfunktionalen Anforderungen widerspiegeln, untersucht werden.

Automatisiertes Hardware-/Software Codesign In dieser Diplomarbeit wurde entwederdie Optimierung der Speicherhierarchie, d.h. der Hardwarearchitektur, oder die Optimierung derstatischen Scratchpad-Allokation, d.h. der Software, betrachtet. Die gleichzeitige Optimierungwurde aus den in 4.6 genannten Grunden im Rahmen dieser Diplomarbeit nicht durchgefuhrt.In zukunftigen Forschungsarbeiten kann jedoch die Umsetzbarkeit und die Gute dieses Optimie-rungsansatzes naher untersucht werden.

Literaturverzeichnis

[ACP04] Ascia, G. ; Catania, V. ; Palesi, M.: A GA-Bases Design Space Exploration Fra-mework for Parameterized System-On-A-Chip Platforms. In: Evolutionary Compu-tation, IEEE Transactions on 8 (2004), August, Nr. 4, S. 329–346

[ARM] ARM Ltd. - ARM7 Family. http://www.arm.com/products/CPUs/families/ARM7Family.html

[ARM99] AMBA Specification (Rev 2.0). (1999), Nr. ARM IHI 0011A

[ARM01a] ARM7TDMI (Rev 3) Core Processor - Product Overview. (2001), Nr. ARM DVI0027B

[ARM01b] ARM7TDMI (Rev 4) - Technical Reference Manual. (2001), Nr. ARM DDI 0210B

[ARM03a] AMBA AXI Protocol v1.0 - Specification. (2003), Nr. AMBA IHI 0022B

[ARM03b] ARM Ltd. (Hrsg.): The ARMulator. ARM Ltd., September 2003. (Documentnumber: ARM DAI 0032F)

[BBB+05] Benini, L. ; Bertozzi, D. ; Bogliolo, A. ; Menichelli, F. ; Olivieri, M.:MPARM: Exploring the Multi-Processor SoC Design Space with SystemC. In: J.VLSI Signal Process. Syst. 41 (2005), Nr. 2, S. 169–182. – ISSN 0922–5773

[BBJ+01] Beyer, H.-G. ; Brucherseifer, E. ; Jakob, W. ; Pohlheim, H. ; Sendhoff, B.; To, T. B.: Evolutionare Algorithmen - Begriffe und Definitionen. In: VDI/VDE-Richtlinie- 3550, Blatt C3 (2001)

[BCZZ04] Bona, A. ; Caldari, M. ; Zaccaria, V. ; Zafalon, R.: High-level power charac-terization of the AMBA Bus interconnect. In: SNUG (2004)

[Bro07] Brockhaus - Die Enzyklopadie: in 30 Banden, Online Ausgabe. http://www.ub.tu-dortmund.de. Version: 2005-07

[CKO00] Corne, D. ; Knowles, J. D. ; Oates, M. J.: The Pareto Envelope-Based SelectionAlgorithm for Multi-objective Optimisation. In: PPSN VI: Proceedings of the 6thInternational Conference on Parallel Problem Solving from Nature. London, UK :Springer-Verlag, 2000. – ISBN 3–540–41056–2, S. 839–848

[DAH] The UCR Dalton Project IP-Based embedded system design.http://cs.ucr.edu/dalton,

[Dal00] Dales, M. ; Department of Computing Science, University of Glasgow(Hrsg.): SWARM 0.44 Documentation. Department of Computing Science, Univer-sity of Glasgow, November 2000

105

http://www.arm.com/products/CPUs/families/ARM7Family.html

http://www.arm.com/products/CPUs/families/ARM7Family.html

http://www.ub.tu-dortmund.de

http://www.ub.tu-dortmund.de

106 LITERATURVERZEICHNIS

[DAPM00] Deb, K. ; Agrawal, S. ; Pratap, A. ; Meyarivan, T.: A Fast Elitist Non-dominated Sorting Genetic Algorithm for Multi-objective Optimisation: NSGA-II.In: PPSN VI: Proceedings of the 6th International Conference on Parallel ProblemSolving from Nature. London, UK : Springer-Verlag, 2000. – ISBN 3–540–41056–2,S. 849–858

[DD05] Domschke, W. ; Drexl, A.: Einfuhrung in Operations Research. 6. Springer, 2005.– ISBN 978–3540709480

[EH] Emmerich, M. ; Hosenberg, R.: TEA - A C++ Library for the Design of Evolu-tionary Algorithms. In: DFG-SFB 531 CI

[Fin06] Fink, G. A.: Rechensysteme - Vorlesungsfolien. http://ls12-www.cs.tu-dortmund.de/~fink/lectures/SS06/rechensysteme/. Version: 2006

[Fog62] Fogel, L. J.: Autonomous Automata. In: Industrial Research (1962), S. 14–19

[FOW66] Fogel, L. J. ; Owens, A. J. ; Walsh, M. J.: Artificial Intelligence through Simu-lated Evolution. In: Wiley (1966)

[HB98] Hammel, U. ; Back, T.: Optimierung in der Simulation: Evolutionare Algorithmen.In: Interne Berichte / Universitat Dortmund, Sonderforschungsbereich 531 (1998)

[Hol62] Holland, J. H.: Outline for a Logical Theory of Adaptive Systems. In: Journal ofthe Association for Computing Machinery (1962), S. 297–314

[Hol75] Holland, J. H.: Adaptation in Natural and Artificial Systems. In: The Universityof Michigan Press (1975)

[HPH+00] Heinkel, U. ; Padeffke, M. ; Haas, W. ; Burner, T. ; Braisz, H. ; Gentner,T. ; Grassmann, A.: The VHDL Reference. Wiley & Sons, 2000. – ISBN 978–0471899723

[ICD08] ICD - Informatik Centrum Dortmund (Hrsg.): ICD-C Compiler Framework -Developer Manual. ICD - Informatik Centrum Dortmund, 2008

[IJG] Independent JPEG Group. http://www.ijg.org

[Ins06] The Institute of Electrical and Electronics Engineers, Inc. (Hrsg.):IEEE Standard SystemC Language - Reference Manual. The Institute of Electricaland Electronics Engineers, Inc., 2006

[Int08] 40 Jahre Mooresches Gesetz. http://www.intel.com. Version: April 2008, Abruf:25.04.2008

[Koz92] Koza, J. R.: The genetic programming paradigm: Genetically breeding populationsof computer programs to solve problems. Version: 1992. citeseer.ist.psu.edu/koza90genetic.html. In: Soucek, Branko (Hrsg.) ; IRIS Group the (Hrsg.):Dynamic, Genetic, and Chaotic Programming. New York : John Wiley, 1992, 203–321

[LPB04] Loghi, M. ; Poncino, M. ; Benini, L.: Cycle-accurate power analysis for multi-processor systems-on-a-chip. In: GLSVLSI ’04: Proceedings of the 14th ACM GreatLakes symposium on VLSI. New York, NY, USA : ACM, 2004. – ISBN 1–58113–853–9, S. 410–406

http://ls12-www.cs.tu-dortmund.de/~fink/lectures/SS06/rechensysteme/

http://ls12-www.cs.tu-dortmund.de/~fink/lectures/SS06/rechensysteme/

http://www.ijg.org

http://www.intel.com

citeseer.ist.psu.edu/koza90genetic.html

citeseer.ist.psu.edu/koza90genetic.html

LITERATURVERZEICHNIS 107

[MAH] MaCC - Memory aware C Compiler. http://ls12-www.cs.uni-dortmund.de/research/macc

[Mar03] Marwedel, P.: Embedded System Design. Kluwer Academic Publishers, 2003. –ISBN 978–0387292373

[MPH] MPARM - Multiprocessor ARM. http://www-micrel.deis.unibo.it/sitonew/research/mparm.html

[Rec65] Rechenberg, I.: Cybernetic Solution Path of an Experimental Problem. In: RoyalAircraft Establishment (1965)

[Rec71] Rechenberg, I.: Evolutionsstrategie: Optimierung technischer Systeme nach Prin-zipien der biologischen Evolution, Technische Universitat Berlin, Diss., 1971

[RTH] RTEMS - Real-Time Executive for Multiprocessor Systems. http://www.rtems.org

[Rud06] Rudolph, G.: Fundamente der Computational Intelligence - Vorlesungsfolien.http://ls11-www.cs.uni-dortmund.de/people/rudolph/teaching/lectures/FCI/WS2006-07/lecture.jsp. Version: 2006

[SAR+05] Srinivasan, S. ; Angiolini, F. ; Ruggiero, M. ; Benini, L. ; Narayanan, V.:Simultaneous Memory and Bus Partitioning for SoC Architectures. In: Proceedingsof SOCC 2005., 2005

[Sch68] Schwefel, H.-P.: Projekt MHD-Staustrahlrohr: Experimentelle Optimierung einerZweiphasenduse / Forschungsinstitut Berlin. AEG 1968. – Forschungsbericht

[Sch75] Schwefel, H.-P.: Evolutionsstrategie und numerische Optimierung, Technische Uni-versitat Berlin, Diss., 1975

[SWLM02] Steinke, S. ; Wehmeyer, L. ; Lee, B. ; Marwedel, P.: Assigning Program andData Objects to Scratchpad for Energy Reduction. In: DATE ’02: Proceedings ofthe conference on Design, automation and test in Europe. Washington, DC, USA :IEEE Computer Society, 2002, S. 409

[TTJ06] Tarjan, D. ; Thoziyoor, S. ; Jouppi, N. P.: CACTI 4.0, Juni 2006. (HPL-2006-86). http://www.hpl.hp.com/techreports/2006/HPL-2006-86.html

[UCH] uCLinux - Embedded Linux/Microcontroller Project. http://www.uclinux.org

[VWM04] Verma, M. ; Wehmeyer, L. ; Marwedel, P.: Dynamic overlay of scratchpadmemory for energy minimization. In: CODES+ISSS ’04: Proceedings of the 2nd IE-EE/ACM/IFIP international conference on Hardware/software codesign and systemsynthesis. New York, NY, USA : ACM, 2004. – ISBN 1–58113– 937–3, S. 104–109

[Wei99] Weicker, K.: Evolutionare Algorithmen. In: Weicker, Karsten (Hrsg.): Softcom-puting - Tagungsband zum ersten Softcomputing-Treffen. Stuttgart : Informatikver-bund Stuttgart, 1999, S. 27–39

[WL02] Wagner, J. ; Leupers, R.: A Fast Simulator and Debugger for a Network Processor.In: Embedded Systems/Embedded Intelligence. Nurnberg, Februar 2002

[WM95] Wulf, W. ; McKee, S.: Hitting the memory wall: implications of the obvious. In:SIGARCH Comput. Archit. News 23 (1995), Nr. 1, S. 20–24. – ISSN 0163–5964

http://ls12-www.cs.uni-dortmund.de/research/macc

http://ls12-www.cs.uni-dortmund.de/research/macc

http://www-micrel.deis.unibo.it/sitonew/research/mparm.html

http://www-micrel.deis.unibo.it/sitonew/research/mparm.html

http://www.rtems.org

http://ls11-www.cs.uni-dortmund.de/people/rudolph/teaching/lectures/FCI/WS2006-07/lecture.jsp

http://ls11-www.cs.uni-dortmund.de/people/rudolph/teaching/lectures/FCI/WS2006-07/lecture.jsp

http://www.hpl.hp.com/techreports/2006/HPL-2006-86.html

http://www.uclinux.org

108 LITERATURVERZEICHNIS

[WM06] Wehmeyer, L. ; Marwedel, P.: Fast, Efficient and Predictable Memory Accesses.Springer, 2006. – ISBN 978–1402048210

[ZLT01] Zitzler, E. ; Laumanns, M. ; Thiele, L.: SPEA2: Improving the Strength Pa-reto Evolutionary Algorithm. Version: 2001. citeseer.ist.psu.edu/article/zitzler01spea.html. Gloriastrasse 35, CH-8092 Zurich, Switzerland, 2001 (103).– Forschungsbericht

[ZT98] Zitzler, E. ; Thiele, L.: An Evolutionary Algorithm for Multiobjective Optimi-zation: The Strength Pareto Approach. Version: 1998. citeseer.ist.psu.edu/article/zitzler98evolutionary.html. Gloriastrasse 35, CH-8092 Zurich, Swit-zerland, 1998 (43). – Forschungsbericht

citeseer.ist.psu.edu/article/zitzler01spea.html

citeseer.ist.psu.edu/article/zitzler01spea.html

citeseer.ist.psu.edu/article/zitzler98evolutionary.html

citeseer.ist.psu.edu/article/zitzler98evolutionary.html

TECHNISCHE UNIVERSITAT¨ DORTMUND …ls12-€¦ · 2.6 Struktur einer ARM7-basierten MPARM ... 2.10...

Documents

Transcript of TECHNISCHE UNIVERSITAT¨ DORTMUND …ls12-€¦ · 2.6 Struktur einer ARM7-basierten MPARM ... 2.10...