Danksagung

Ganz besonders m¨ ochte ich mich bei meinem Doktorvater und Erstgutachter Herrn Prof. Dr. Hans Peter Großmann f¨ ur die hochschulseitige Betreuung bedanken.

Mein aufrichtiger Dank gilt ebenso Herrn PD Dr. G¨ unter St¨ ohr f¨ ur die freundliche ¨ Uber-

F¨ ur die studentische Unterst¨ utzung w¨ ahrend dieser Arbeit danke ich den Herren Frank Lex, Kai Hildebrandt und Yi Luo.

Meinen Vorgesetzten Frau Anke Kleinschmit und Herrn Hartmut Kolb danke ich f¨ ur die Bereitstellung einer angenehmen und einzigartigen Arbeitsatmosph¨ are.

Nicht zuletzt m¨ ochte ich mich bei meiner Frau Sarah und meiner Tochter Zoi Anastasia f¨ ur die Motivation und f¨ ur das Verst¨ andnis w¨ ahrend der Entstehung dieser Arbeit bedanken.

ii

Inhaltsverzeichnis

1  Einleitung  1

1.1  Motivation  1

1.2  Schwerpunkt der Arbeit  2

1.3  Gliederung der Arbeit  2

2  Stand der Technik  4

2.1  Vernetzungstopologie  4

2.2  Gatewayfunktionalit at  6

2.3  Gatewaydesign  7

2.4  Zusammenfassung und Trend  8

3  Gateway-Systemsynthese  9

3.1  FPGA-basiertes Gateway  9

3.1.1  Softwarel osung  10

3.1.2  Hardwarel osung  12

3.1.3  Heterogenes Design  15

3.2  Grundlagen der Entwurfsrepr asentation und Entwurfsmethodik  15

3.2.1  Entwurfsrepr asentation  15

3.2.2  Synthese und Analyse  17

3.2.3  Entwurfsmethodik  17

3.3  Modell zur Gateway-Systemsynthese  18

3.3.1  Einschr ankung der Abstraktionsebenen  18

3.3.2  Entwurf auf Systemebene  19

3.4  Der Gateway-Systemgraph  21

3.4.1  Definitionen  21

3.4.2  Gateway-Funktionsgraph  22

3.4.3  Gateway-Architekturgraph  22

3.4.4  Gateway-Systemgraph  23

3.5  Gewichtung der Mappingkanten  24

3.5.1  Gewichtung von Funktionsbl ocken  25

3.5.2  Gewichtung von Mikroprozessor IP-Cores  25

3.5.3  Softwaresynthese  25

iv

  INHALTSVERZEICHNIS INHALTSVERZEICHNIS  

3.6  Zusammenfassung  27

4  Optimales Gatewaydesign  28

4.1  Definitionen  28

4.2  Das Partitionierungsproblem  30

4.3  Partitionierungsalgorithmen  31

4.4  Mehrzieloptimierung  33

4.5  Optimierung des Gateway-Systemgraphen mit GA  35

4.5.1  EA-Struktur und Varianten  35

4.5.2  GA zur Systemoptimierung  37

4.5.3  Kodierung, Ablauf und Fitness  38

4.5.4  Parameter des GAs  40

4.5.5  Exploration des Entwurfsraums  42

4.5.6  Programmierung  43

4.6  Optimierung des Gateway-Systemgraphen mit ILP  47

4.6.1  Das Flussmodell  47

4.6.2  Aufstellung des Gleichungssystems  48

4.6.3  L osung des Gleichungssystems  51

4.6.4  Exploration des Entwurfsraums  51

4.6.5  Programmierung  55

4.7  Kombination GA und ILP  56

4.8  Performanceanalyse GA vs ILP  58

4.8.1  Vorbereitung der Messungen  58

4.8.2  Ergebnis und Diskussion der Messungen  59

4.9  Neue Verfahren  60

4.9.1  Multi-Level-Verfahren  60

4.9.2  Particle Swarm Optimization (PSO)  61

4.10  Zusammenfassung  61

5  CAN to CAN automotive Gateway  62

5.1  Aufgabenstellung  62

5.2  Design des Systemgraphen  64

5.2.1  Beschreiben des Systemverhaltens  64

5.2.2  Festlegung der Architektur  65

5.2.3  Abbilden des Systemverhaltens  66

5.3  Optimierung und Exploration mittels GA  68

5.3.1  Darstellung der Eingangsdaten  68

5.3.2  Ausgabe und Einschr ankung des Entwurfsraums  70

5.4  Optimierung und Exploration mittels ILP  72

5.4.1  Erstellen des Flussgraphen  72

5.4.2  Aufstellen des Gleichungssystems  74

5.4.3  L osung des Gleichungssystems und Exploration  79

v

  INHALTSVERZEICHNIS INHALTSVERZEICHNIS  

5.5  Interpretation der Ergebnisse  80

5.5.1  L osung GA  81

5.5.2  L osung ILP  82

5.6  Weitere Verfeinerung des Designs  82

5.7  Umsetzung  84

5.7.1  Versuchsaufbau  84

5.7.2  Umsetzung und Test des Designs  84

5.7.3  Die Gatewaykonfiguration  87

5.8  Zusammenfassung  88

6  Zusammenfassung und Ausblick  89

6.1  Zusammenfassung  89

6.2  Ausblick  90

A  Messungen zu Kapitel 4.8  93

  A.1 GA-Performance  96

  A.2 ILP-Performance  97

B  Ergebnisse GA Kapitel 5.3  98

C  Virtex-II Entwicklungsboard  101

D  FPGA-Floorplan  103

E  TOP-VHDL-Datei  104

  Ver offentlichungen und Patente  121

  Abbildungsverzeichnis  123

Tabellenverzeichnis 125   

  Literaturverzeichnis  127

vi

Kapitel 1

Einleitung

1.1 Motivation

Abbildung 1.1 zeigt eine Vernetzungstopologie mehrerer Bussysteme. Um Nachrichten zwischen den einzelnen Bussystemen austauschen zu k¨ onnen, m¨ ussen die Haupteinheiten E1- E3 eine Gatewayfunktionalit¨ at besitzen. Wie realisiert man eine Gatewayfunktionalit¨ at und wie sieht die Hard- und Software eines Gateways aus? Diese Frage stellt sich heutzutage jeder Steuerger¨ ateentwickler in der Automobilbranche, da aufgrund des immer gr¨ oßeren Botschaftsaufkommens die Prozessoren in den Steuerger¨ aten am Limit arbeiten.

Diese Arbeit entstand w¨ ahrend meiner T¨ atigkeit als Doktorand in dem Forschungsteam ’Steuerger¨ atekonzepte und Applikation’ der DAIMLERCHRYSLER AG mit dem Ziel, ein optimales automotive Gateway f¨ ur Motorsteuerger¨ ate zu entwickeln. Die Motivation hierbei liegt in dem Design der Gatewayarchitektur mit einer optimalen hardware- und softwareseitigen Verteilung der Funktionalit¨ at.

1

1.3 Gliederung der Arbeit

1.2 Schwerpunkt der Arbeit

Der Schwerpunkt dieser Arbeit liegt in dem optimalen Design eines Gateways f¨ ur FPGAs (engl. Field Programmable Gate Arrays). Dazu werden verschiedene Realisierungsalternativen aufgezeigt und eine neue, auf kombinatorischen Algorithmen basierende Methode vorgestellt. Durch Anwendung der entwickelten Methodik wird das Problem des Hardware/Software-CoDesigns gel¨ ost und eine optimale Gatewaystruktur f¨ ur das jeweilige System erstellt. Grundlage daf¨ ur bildet ein Modell zur Gatewaysynthese auf Systemebene, welches auf einem bipartiten Graphen beruht. Eine Kombination aus evolution¨ arem/genetischem Algorithmus (GA) und ganzzahliger linearer Programmierung (engl. integer linear programming, ILP) optimiert diesen Graphen. Diese Algorithmenkombination erm¨ oglicht die Bestimmung einer optimalen Gatewayarchitektur mit optimaler Hard-und Softwareverteilung. Die korrekte Anwendung des Verfahrens auf unterschiedliche Problemstellungen, Problemgr¨ oßen und Anzahl an Optimierungskriterien sowie eine Performanceanalyse der einzelnen Algorithmen und die Anwendung auf eine reale Problemstellung runden diese Dissertation ab. Wie anfangs erw¨ ahnt ist die Methodik auf den Einsatz von FPGAs ausgelegt. Sie l¨ asst sich jedoch auf Gateways jeglicher Bussysteme anwenden. Grundkenntnisse bei der Anwendung von FPGAs, beim Entwurf von eingebetteten Systemen, zur Graphentheorie und zu den Optimierungsverfahren werden hierbei vorausgesetzt.

1.3 Gliederung der Arbeit

Kapitel 2 ”Stand der Technik” geht auf aktuelle Vernetzungstopologien im Fahrzeug ein.

Die steigende Komplexit¨ at von automotive Vernetzungen und die Integration mehrerer unterschiedlicher Bussysteme ins Fahrzeug erfordern immer mehr den Einsatz von Gate- ways mit erweitertem Funktionsumfang. Dieser wird in Kapitel 2 f¨ ur ein Gateway eines Motorsteuerger¨ ates definiert. Eine kurze Exkursion in die Hardware von Motorsteuer- ger¨ aten und eine Trendanalyse beenden das Kapitel.

Die ”Gateway Systemsynthese” in Kapitel 3 befasst sich mit der Synthese auf Systemebene. F¨ ur dieses heutzutage wenig erforschte Gebiet wird eine graphenbasierte Methodik eingef¨ uhrt, welche es erm¨ oglicht, das Gatewayverhalten auf Systemebene in einem bipartiten Graphen darzustellen. Die Grundlagen f¨ ur diese Methodik werden anfangs erl¨ autert. Sie befassen sich mit den unterschiedlichen Designm¨ oglichkeiten f¨ ur Gateways in FPGAs sowie der Theorie der Entwurfsraumrepr¨ asentation und Entwurfsmethodik.

Kapitel 4 ”Optimales Gatewaydesign” widmet sich der Optimierung der graphenbasierten Darstellung des Systems. Die Komplexit¨ at des Optimierungsproblems ist NP-vollst¨ andig und daher nicht in deterministischer Zeit zu berechnen. Diese Problematik wird

2

1.3 Gliederung der Arbeit

anhand eines Partitionierungsproblems dargestellt, gefolgt von der Vorstellung zugeh¨ origer Partitionierungsalgorithmen. Zur L¨ osung des Partitionierungsproblems f¨ ur das Gateway wird eine neue Methodik bestehend aus der Kombination aus genetischem Algorithmus und ganzzahliger linearer Programmierung vorgestellt, sowie ein Verfahren zur mehrdimensionalen Entwurfsraumexploration mit klassischen Einzieloptimierungsverfahren. Die Algorithmen und deren Umsetzung sind im Detail erl¨ autert. Eine Performanceanaly-

se der einzelnen Verfahren und die Vorstellung neuer mathematischer Mehrzieloptimie- rungsverfahren schließen das Kapitel ab.

Die Anwendung des erarbeiteten Verfahrens wird in Kapitel 5 ”CAN to CAN automotive Gateway” anhand einer realen Problemstellung vorgestellt. Dabei soll ein FPGAbasiertes Gateway f¨ ur ein Motorsteuerger¨ at der Mercedes Benz S-Klasse entwickelt werden. Die in Kapitel 3 eingef¨ uhrte Methodik zum Erstellen des Systemgraphen und das in Kapitel 4 vorgestellte Verfahren zur Exploration des Entwurfsraums und Bestimmung der optimalen L¨ osung finden hierbei ihren Einsatz. Die Implementierung des optimalen Gateways erfolgt auf einer Entwicklungsplattform mit einem Xilinx Virtex-II FPGA.

3

Kapitel 2

Stand der Technik

2.1 Vernetzungstopologie

Der Trend zu mehr Elektronik im Fahrzeug h¨ alt nach wie vor ununterbrochen an. Die immer gr¨ oßer werdende Komplexit¨ at der Systeme tendiert zu einer Verteilung dieser Komplexit¨ at auf mehrere Steuerger¨ ate. Diese Entwicklung wird sich in Zukunft beschleunigt fortsetzen. Betrachtet man ein typisches Auto der Oberklasse mit seinen wesentlichen Steuerger¨ aten, erkennt man eine Busstruktur, welche in unterschiedliche Funktionsbereiche unterteilt ist. Jeder Bereich verf¨ ugt ¨ uber sein eigenes Netz mit der geeigneten Bustechnologie. Die Netze sind ¨ uber ein oder mehrere Gateways miteinander verbunden, sodass essentielle Daten in allen Bereichen zur Verf¨ ugung stehen. Heute werden teils ¨ uber 70

Steuerger¨ ate und bis zu sechs unterschiedliche Bussysteme in Premiumfahrzeugen verbaut. Bild 2.1 zeigt eine typische Steuerger¨ ate-Architektur eines Oberklassenfahrzeugs, wobei die Anordnung der einzelnen Gateways sowie die Art und Anzahl der Bussysteme je nach Automobilhersteller und Fahrzeugtyp variiert.

Das von Bosch und Intel 1981 entwickelte CAN (engl. Controller Area Network) hat sich mittlerweile als weltweites Standard-Bussystem im Antriebsstrang, Fahrwerk und Innenraum durchgesetzt, wobei das LIN (engl. Local Interconnect Network) immer mehr zur Kommunikation von intelligenten Sensoren und Aktoren eingesetzt wird. Das CAN-Datenbussytem ist bis zu einer Daten¨ ubertragungsrate von 1 Mbit/s spezifiziert, jedoch aufgrund fahrzeugtypischer Randbedingungen momentan auf 500 kbit/s begrenzt. Der LIN-Bus arbeitet mit einer maximalen Bandbreite von 19,6 kbit. F¨ ur hohe Bandbreiten in multimedialen Anwendungen (bis 25 Mbit/s) findet der 1998 von der MOST Cooperation entwickelte MOST-Bus (engl. Media Oriented System Transport-Bus) seinen Einsatz. Ebenfalls erw¨ ahnen sollte man das zukunftsorientierte echtzeitf¨ ahige Bussystem FlexRay (10 Mbit/s) f¨ ur X-by-Wire-Systeme. Es soll zuk¨ unftig die neuen Anforderungen im Kraftfahrzeug hinsichtlich Echtzeit, Fehlertoleranz, Flexibilit¨ at und Skalierbarkeit erf¨ ullen. Das Aufzeigen aller existierenden Bussysteme und Protokolle w¨ urde den Rahmen an dieser Stelle sprengen. F¨ ur eine detaillierte Beschreibung der genannten Bussysteme sei auf [1] bis [5] verwiesen.

4

2.1 Vernetzungstopologie

F¨ ur die Art der Vernetzung mit Gateways gibt es zwei grundlegende Einsatzvarianten. Die eine ist der Einsatz eines Gateways als sogenanntes zentrales Gateway. Hier werden die vorhanden Bussysteme im Fahrzeug ¨ uber ein einziges zentrales Gateway miteinander

verbunden. Dieser Ansatz wird aufgrund seiner vielen Nachteile hinsichtlich Hard- und Softwareanforderungen, Preis/Leistung sowie Fehlerausbreitung und Testbarkeit eher selten verwendet. Bei der zweiten Variante spricht man von einer Backbone-Architektur. Dabei ¨ ubernehmen einzelne lokale Gateways, welche ¨ uber einen Backbone-Bus miteinander

verbunden sind, die Protokollumsetzung. Dieser dezentrale Ansatz erm¨ oglicht eine modulare Vernetzung und bietet daher einen entscheidenden Kosten- und Konstruktionsvorteil bei der vorhandenen Variantenvielfalt. In heutigen Fahrzeugen der Oberklasse werden oft Hybrid-Vernetzungen beider Alternativen gebildet und komplette Gateways direkt in Steuerger¨ ate, wie zum Beispiel in das Motorsteuerger¨ at, integriert.

5

2.2 Gatewayfunktionalit¨ at

2.2 Gatewayfunktionalit¨ at

Die eher sp¨ arliche Literatur ¨ uber Gateways und ihre Funktionalit¨ at beschreibt sie meistens allgemein als Protokollwandler. Im Rahmen einer Neustrukturierung der Vernetzung in den neuen Fahrzeuggenerationen wird sich der Funktionalit¨ atsumfang der Gateways enorm erweitern. Dazu wird an dieser Stelle das Gateway eines aktuellen Motorsteuerger¨ ates betrachtet und dessen Aufgaben definiert. Es ¨ ubernimmt Funktionen wie

Botschafts- und Signalrouting, Signalextraktion, Protokollwandlung, Diagnose und Netzwerkmanagement.

Definition 2.1 (Botschaftsrouting) Unter Botschaftsrouting versteht man das direkte Umkopieren einer Botschaft zwischen zwei oder mehreren Bussystemen. Hierbei kann bei nachrichtenorientierten Bussystemen die Botschaftsidentifikation wahlweise beibehalten oder modifiziert werden.

Definition 2.2 (Signalrouting) Beim Signalrouting werden aus einer oder mehreren Nachrichten aus einem oder verschiedenen Bussystemen einzelne Signalinformationen extrahiert, in eine neue Nachricht verpackt und auf ein oder mehrere Bussysteme geroutet. Ein Signal kann dabei je nach abzubildendem Range aus einem oder mehreren Bits bestehen.

Definition 2.3 (Signalextraktion) Bei der Signalextraktion werden wie beim Signalrouting Signalinformationen aus einer oder mehreren Nachrichten aus einem oder verschiedenen Bussystemen extrahiert und in der Gatewayapplikation weiterverarbeitet bzw. dem Steuerger¨ at zugef¨ uhrt.

Definition 2.4 (Protokollwandlung) Die Protokollwandlung ist f¨ ur den Datenaustausch zwischen unterschiedlichen Bussystemen notwendig. Sie sorgt f¨ ur den reibungslosen Informationsaustausch zwischen unterschiedlichen Protokollen.

Definition 2.5 (Diagnose) Die Diagnose umfasst die vom Fahrzeughersteller definierte Diagnosefunktionalit¨ at. Sie erm¨ oglicht eine einfache Bestimmung fehlerhafter Aggregate und Sensoren im Fahrzeug.

Definition 2.6 (Netzwerkmanagement) Das fl¨ achendeckend eingef¨ uhrte OSEK-Netzwerkmanagement dient zur Verwaltung und Diagnose von Fahrzeugnetzen. Detaillierte Funktionalit¨ aten sind im OSEK-Netzwerkmanagement Standard [6] zu finden.

Diese Funktionalit¨ aten werden auf der Anwendungsebene des hierarchisch aufgebauten ISO-OSI-Schichtmodells realisiert. Das ISO-OSI-Modell (engl. International Standardization Organisation-Open System Interconnect-Model) ist eine international anerkannte Methode zur funktionalen Beschreibung komplexer Kommunikationssysteme [7]. Zur Realisierung eines automotive Gateways werden vereinfacht die Schichten eins, zwei und sieben verwendet. Die ersten beiden Schichten beschreiben die physikalischen Eigenschaften sowie den Zugriff auf das jeweilige Bussystem. Schicht sieben stellt die eigentliche Gatewayfunktionalit¨ at dar.

6

2.3 Gatewaydesign

2.3 Gatewaydesign

Seit der Serieneinf¨ uhrung des CAN-Protokolls 1989 mit drei Busteilnehmern ist die Anzahl heute - je nach Fahrzeugkategorie - auf ¨ uber 70 Steuerger¨ ate und mehrere Bussysteme angestiegen. Die Anforderungen an die Gateways und deren Elektronik steigt dazu ad¨ aquat. Begonnen mit 8 Bit Mikroprozessoren und externen Bustreibern bestehen heutzutage Steuerger¨ ate und Gateways aus 32 Bit Risk-Mikrocontrollern, Power-PCs (engl. power personal computer, PPC) oder digitalen Signalprozessoren (engl. digital signal processor, DSP).

F¨ ur die meisten Gatewayapplikationen werden Mikrocontroller mit integrierten Bustreibern eingesetzt. Dadurch kann die Anzahl an Bauelementen reduziert und somit Kosten eingespart werden. Durch die extrem steigende Botschaftsanzahl st¨ oßt man h¨ aufig bei Steuerger¨ aten mit integriertem Gateway oder Zentralgateways an die Grenzen der zur Verf¨ ugung stehenden Rechenleistung. Zur L¨ osung dieses Problems werden Kombinationen aus mehreren Prozessoren eingesetzt. Das Motorsteuerger¨ at der S-Klasse Baureihe 221 besteht z. B. aus zwei PPCs. Einer f¨ ur die Motor- und der andere f¨ ur die Gatewayapplikation. Die Aufgabe des Gateway-PPCs besteht in der Entlastung des Host-Prozessors von allen interruptlastigen Gatewayaufgaben, welche die Verarbeitung der eigentlichen Motorapplikation zu sehr verlangsamen w¨ urden. Weiterhin bietet er eine Schnittstellen- und Peripherieerweiterung f¨ ur das Steuerger¨ at. Es ist relativ schwer, nach einem Schaltungsentwurf f¨ ur ein Gateway den richtigen Prozessor/Mikrocontroller auf dem Markt zu finden. Entwickelt man z. B. ein CAN-Gateway mit zwei CAN-Bus Schnittstellen, wird man von der Variantenvielfalt regelrecht ¨ uberw¨ altigt. Entscheidet man

sich f¨ ur einen bestimmten Mikrocontroller, werden zu 99 Prozent nicht alle Peripheriekomponenten des Mikrocontrollers ben¨ otigt. Man bezahlt somit Geld f¨ ur nicht benutztes Silizium und muss die nicht ben¨ otigte Peripherie oft noch softwareseitig deaktivieren oder in einen sogenannten Safe-Mode versetzen, was wiederum einen Softwareoverhead zur Folge hat. Der Wunsch eines jeden Entwicklungsingenieurs ist es, ein individuell f¨ ur seine Applikation zugeschnittenes Gateway ohne Hardware-/Software-Overhead und erh¨ ohte Kosten zu designen.

Die Umsetzung dieses Wunsches wird in dieser Arbeit mittels der relativ jungen Technologie der FPGAs (engl. Field Programmable Gate Array) erfolgen. FPGAs sind Bausteine zum Aufbau digitaler Logikschaltungen und wurden in den fr¨ uhen Neunzigern eingef¨ uhrt. “Field Programmable“ bedeutet, dass die Funktionalit¨ at im Baustein durch den Anwender und nicht durch den Hersteller bestimmt wird. Sie vereinen die Vorteile von Mikroprozessoren und ASICs. Mikroprozessoren sind durch ihre programmierbare Funktionalit¨ at sehr flexibel, jedoch lassen sie aufgrund ihrer Struktur keine parallelen oder unverz¨ ogerten Operationen zu. ASICs hingegen sind f¨ ur solche Aufgaben zwar geeignet aber hinsichtlich Entwurfszeiten und Flexibilit¨ at von Nachteil. In Markus Wannemachers Werk “Das FPGA-Kochbuch“ [8] werden die wichtigsten Grundlagen, Entwurfsprinzipien, Bausteine und Werkzeuge in verst¨ andlicher und kompakter Weise dargestellt.

7

2.4 Zusammenfassung und Trend

2.4 Zusammenfassung und Trend

Wie dieses Kapitel zeigt, steigt die Funktionalit¨ at im Fahrzeug und somit der Anteil an Elektrik und Elektronik enorm an. Die komplexe Vernetzung verschiedenster Bussysteme setzt immer h¨ ohere Maßst¨ abe an das Design von Gateways. Aufgrund der hohen Systemkomplexit¨ at nahm die Verl¨ asslichkeit der Elektronik in den letzten Jahren rapide ab und die Fehlerh¨ aufigkeit aufgrund falsch ausgelegter oder nicht hinreichend getesteter Systeme stieg an. Im Jahr 2002 waren 50 Prozent aller Fahrzeugpannen auf Elektronikfehler zur¨ uckzuf¨ uhren. Daher geht der Trend in der n¨ achsten Automobildekade in Richtung Reduktion der Steuerger¨ ate bei zunehmender Funktionalit¨ at. Dies setzt eine bessere Nutzung von Systemressourcen, eine bessere Lastverteilung auf die verschiedenen Steuerger¨ ate und eine ¨ Uberarbeitung der Systemarchitektur voraus. Aufgrund der Aktualit¨ at dieser Thematik befassen sich viele Forschungseinrichtungen und Hochschulen mit dem Problem der optimalen Lastverteilung in verteilten Systemen. Des Weiteren erfordern die bevorstehenden Innovationen aus den Bereichen Multimedia, Telematik und Infotainment Hochleistungs-Gateways, welche die hohen Bandbreiten bew¨ altigen k¨ onnen. Daher bleiben die Anforderungen an immer leistungsf¨ ahigere Gateways erhalten. Wie man ein optimales Gateway designed, wird in den folgenden Kapiteln beschrieben.

8

Kapitel 3

Gateway-Systemsynthese

In diesem Kapitel wird ein graphenbasiertes Modell zur Gateway-Systemsynthese hergeleitet. Dazu bilden unterschiedliche FPGA-basierte Ans¨ atze sowie die Theorie der Entwurfsraumrepr¨ asentation und Entwurfsmethodik die Grundlage. Das Modell visualisiert eine Vorgehensweise beim FPGA-basierten Gatewaydesign von der Verhaltensbeschreibung bis hin zur strukturellen Beschreibung auf Systemebene.

3.1 FPGA-basiertes Gateway

Es gibt drei grunds¨ atzliche Methoden um ein Gateway in einem FPGA zu designen. Die erste und einfachste M¨ oglichkeit basiert auf einem Prozessor IP-Core (engl. Intellectual Property-Core) und den zugeh¨ origen Peripherie-Bibliotheken. Die IP-Core-Bezeichnung stammt aus der Halbleiterindustrie - speziell aus dem Gebiet des Chipentwurfs - und steht f¨ ur die wiederverwendbare Beschreibung eines Bauelements. Das Design des Gateways wird hier mittels einer Entwicklungsumgebung erstellt. Die einzelnen Peripheriemodule k¨ onnen wie bei den meisten Entwicklungsumgebungen komfortabel grafisch oder manuell in einer Hardware-Modellierungssprache miteinander verbunden werden. Da die gesamte Funktionalit¨ at des Gateways in einer Softwarehochsprache programmiert ist, wird diese Methode als ”Softwarel¨ osung” bezeichnet.

Die zweite Alternative ist die eigenst¨ andige Programmierung des kompletten Gateways in einer Hardware-Modellierungssprache wie z. B. VHDL (engl. Very High Speed Integrated Circuit Description Language) oder VERILOG. Hiermit kann der Anwender individuell f¨ ur seine Aufgabenstellung erforderliche Hardware kreieren. Dies reicht je nach Funktionalit¨ atsumfang und Geschick des Programmierers von einfachen kombinatorischen Logikfunktionen bis hin zum komplexen Prozessorentwurf. Dieses Design wird als ”Hardwarel¨ osung” bezeichnet.

Eine weitere Methode ist das ”heterogene Design”, bestehend aus einer Kombination der ersten beiden M¨ oglichkeiten. Hierbei wird die Gesamtfunktionalit¨ at einerseits in Softwa-

9

3.1 FPGA-basiertes Gateway

re auf einem Softprozessor IP-Core und andererseits in Hardware mit anwenderspezifischen Modulen realisiert. Die exakte Umsetzung sowie die Funktionsweise der einzelnen Methoden bilden die Basis des FPGA-basierten Gatewaydesigns. Sie werden im Detail vorgestellt und hinsichtlich ihrer Eigenschaften analysiert.

3.1.1 Softwarel¨ osung

Der Einsatz von IP-Cores beim Schaltungsdesign erm¨ oglicht dem Entwickler die Entwurfszeiten (engl. Time-To-Market) neuer FPGA-Designs drastisch zu reduzieren. IP-Cores sind oft verwendete, meist große und komplexe Funktionseinheiten. Bild 3.1 zeigt eine Gatewayl¨ osung mit einem Softprozessor und verschiedenen Peripheriemodulen.

Prozessor IP-Cores sind als PPCs, DSPs und als 8/16 Bit Mikroprozessoren erh¨ altlich. Peripheriemodule existieren f¨ ur alle g¨ angigen Bussysteme. Man unterscheidet zwischen harten und weichen IP-Cores. Harte Cores sind f¨ ur bestimmte FPGA-Familien ausgelegt und besitzen ein fest vorgegebenes Layout. Dadurch ist ihre Performance und Fl¨ achenausnutzung f¨ ur die jeweiligen Familien angepasst. Nachteilig hingegen ist die Unflexibilit¨ at gegen¨ uber neuen Produktreihen. Weiche IP-Cores (engl. Soft IPs) basieren auf einer synthetisierbaren Beschreibungsform wie z. B. VHDL oder VERILOG. Sie sind im Vergleich zu harten IPs f¨ ur den Einsatz auf unterschiedlichen FPGA-Typen konzipiert. Dementsprechend ist deren Performance und Adaptionsaufwand meistens gr¨ oßer als bei den harten IPs.

Die Softwarel¨ osung findet bevorzugt ihren Einsatz in den Entwicklungsphasen eines Projektes, um die prinzipielle Machbarkeit bestimmter Systemfunktionalit¨ aten in FPGAs nachzuweisen und zu testen. Aufgrund der immer k¨ urzeren Entwicklungszeiten und steigenden Funktionalit¨ atsumf¨ angen eines Produktes setzen Entwickler immer mehr auf den Einsatz von getesteten IP-Cores. Gerade das Erstellen von IPs f¨ ur Bussysteme ist sehr aufwendig und erfordert in der automotive Industrie das Erf¨ ullen von hohen Qualit¨ atsstandards. Die FPGA-internen Controller und Manager f¨ ur die an das Gateway angeschlosse-

10

3.1 FPGA-basiertes Gateway

nen Bussysteme werden daher meistens als fertige IP-Cores integriert. Bei der Auslegung eines FPGA-Systems spielen die beiden Faktoren Performance und Fl¨ achenausnutzung eines Designs die wichtigste Rolle. Sie sind f¨ ur die Architektur des Gateways und die Wahl des FPGA-Bausteins verantwortlich. Daher wird jede Realisierungsm¨ oglichkeit anhand dieser Faktoren bewertet.

Der Vorteil der Softwarel¨ osung liegt darin, dass der Entwickler nicht unbedingt fundierte Kenntnisse in den Hardware-Modellierungssprachen besitzen muss. Die komplette Funktionalit¨ at wird mit dem Prozessor IP in Form einer Programmierhochsprache, meistens ”C”, realisiert. Der Instruktionscode f¨ ur den Mikroprozessor wird hierbei in FPGA-internen Speicherzellen gespeichert. Dadurch ist die Fl¨ achennutzung des Designs unabh¨ angig von der Funktionalit¨ at und nur durch die Gr¨ oße und Anzahl dieser Speicherzellen beschr¨ ankt. Dies erleichtert die Wahl eines geeigneten FPGAs.

Schwieriger ist die Berechnung der Performance. Die Performance eines Systems beschreibt sein Echtzeitverhalten hinsichtlich der an das Gateway angeschlossenen Bussysteme. Die FPGA-interne Gateway-Designfrequenz f Design darf hierbei einen minimalen Wert, welcher die Funktionssicherheit des Gateways gew¨ ahrleistet, nicht unterschreiten:

f Design ≥ f io · N Design (3.1)

f io ist die maximale Eingangs-/Ausgangsfrequenz der Schnittstelle vom FPGA zum Physical Layer Treiber des Bussystems mit der h¨ ochsten ¨ Ubertragungsrate. Bei paralleler

Schnittstelle zum Physical Layer Treiber entspricht f io dem Quotienten aus maximaler Frequenz und Anzahl der Leitungen.

Die maximale Designfrequenz ist durch die maximale FPGA-Frequenz und durch das Design an sich beschr¨ ankt. Da bei der Softwarel¨ osung der komplette Funktionalit¨ atsumfang auf dem Prozessor IP realisiert wird, kann die Anzahl der ben¨ otigten Design-Taktzyklen nur durch Softwaresynthese des Funktionscodes bestimmt werden. Die Vorgehensweise bei der Softwaresynthese ist in Kapitel 3.5.3 beschrieben. Die ben¨ otigten Taktzyklen N Design der Softwarel¨ osung lassen sich aus der Summe der Anzahl an Takten der prozessorspezifischen Assemblerinstruktionen und der maximalen Anzahl an Takten des Bus IP-Cores berechnen. N Design muss f¨ ur den kritischen Softwarepfad und den Bus IP-Core mit der gr¨ oßten Anzahl an ben¨ otigten Takten kalkuliert werden.

na

n a ist die Anzahl der Assemblerinstruktionen und N ^AI i die Anzahl der Taktzyklen der individuellen Instruktion.

11

3.1 FPGA-basiertes Gateway

3.1.2 Hardwarel¨ osung

Bei der Hardwarel¨ osung besteht das Gateway Design nicht nur aus einem Mikroprozessor IP-Core und Peripherie, sondern es ist aus einzelnen Hardware-Funktionsbl¨ ocken zusammengestellt.

Definition 3.1 (Funktionsblock) Ein Funktionsblock ist ein anwenderspezifisches Objekt, welches eine oder mehrere Funktionen bereitstellt. Der Funktionsblock nimmt Daten-und Kontrollsignale ¨ uber eine fest definierte Schnittstelle entgegen bzw. leitet diese wei-

festlegen.

Jede Gatewayfunktionalit¨ at l¨ asst sich durch einen oder mehrere Funktionsbl¨ ocke beschreiben. Die Granularit¨ at ist hierbei dem Anwender ¨ uberlassen und abh¨ angig von der Abstraktionsebene der Beschreibungsform des jeweiligen Designs.

Definition 3.2 (Granularit¨ at) Die Granularit¨ at charakterisiert den Detaillierungsgrad einer Beschreibungsform. Sie ist abh¨ angig von der Abstraktionsebene und dem Verfeinerungsgrad der zu beschreibenden Funktionalit¨ at.

Erl¨ auterung: Bei der Darstellung eines Bus IP-Cores als ein einziger Funktionsblock handelt es sich um eine grob granulare Darstellungsform. Eine verfeinerte Darstellung eines Bus IP-Cores aus mehreren Funktionsbl¨ ocken mit jeweils einem geringeren Funktionsumfang pro Block, z. B. einem Nachrichten- oder Bitvergleich, entspricht einer fein granularen Beschreibung.

Funktionsbl¨ ocke erm¨ oglichen eine hierarchische Darstellungsform. Dies bedeutet, dass ein Funktionsblock durch Verfeinerung aus mehreren Bl¨ ocken dargestellt werden kann. Diese befinden sich dementsprechend auf einer niedrigeren Abstraktionsebene der Beschreibungsform. Abbildung 3.2 zeigt den Aufbau einer Bus-Basis-Konstellation. Zur Erl¨ auterung ihrer Funktionsweise wird eine grob granulare Darstellungsform gew¨ ahlt.

Eine Bus-Basis-Konstellation ist eine Kombination von Funktionsbl¨ ocken, welche notwendig sind, um ein beliebiges Bussystem in einem FPGA zu realisieren. Die grob granularen Bl¨ ocke sind dabei universell einsetzbar. In Referenz zum ISO-OSI-Schichtmodell wird die Bit¨ ubertragungsschicht durch den Physical Layer Treiber, die Sicherungsschicht durch den jeweiligen Bus IP-Core und die Anwendungsschicht durch die restlichen Funktionsbl¨ ocke realisiert. Der Physical Layer Treiber ist verantwortlich f¨ ur die physikalische Wandlung des Bussignals in ein serielles oder paralleles digitales TTL-Signal auf FPGA-Seite. Der Bus IP-Core ist der Controller eines Bussystems. Er sorgt f¨ ur die Initialisierung, Synchronisation und Steuerung des Bussystems. Das Verpacken, Zwischenspeichern und Weiterleiten von Informationen geh¨ ort dabei zu seinen Hauptaufgaben, außerdem das gesamte Nachrichtenhandling.

12

3.1 FPGA-basiertes Gateway

Die Schnittstelle vom Bus IP-Core zum konfigurierbaren Gateway-Manager (engl. Configurable Gateway-Manager, CGM) bildet der Receive/Transmit-Handler (Rx/Tx-Handler). Er ist f¨ ur die Initialisierung der Bus IPs zust¨ andig und steuert die Nachrichtenkommunikation zwischen dem Bus IP und einem oder mehreren CGMs. Der CGM ist die Steuerzentrale im Gateway. Er bestimmt die Funktionalit¨ at des Gateways anhand von den im ROM hinterlegten Informationen und entscheidet was mit einer eintreffenden Nachricht geschieht. Das Design des CGMs ist je nach Bussystem und Funktionsumfang unterschiedlich, jedoch immer modular strukturiert (siehe Bild 3.2). Abh¨ angig vom Bussystem k¨ onnen weitere Module integriert oder entfernt werden.

F¨ ur jedes im Gateway implementierte Bussystem bestimmen alleine die in den ROMs kodierten Informationen dessen Verhalten. Ein FPGA besitzt je nach Aufbau intern definierte RAM-Bereiche von bestimmter Anzahl und Gr¨ oße. Bei den FPGA-Familien des Herstellers Xilinx werden sie als Block-RAMs - oder kurz BRAMs (engl. Block Random Access Memory) bezeichnet und haben meist eine Gr¨ oße von 18 kbit je Block. Die Anzahl variiert bei kleinen FPGAs von vier bis zu ¨ uber 200 bei großen. Diese RAM-Zellen

k¨ onnen vom Anwender beliebig verwendet werden, wie in diesem Design beispielsweise als ROM-Zellen. Die ROM-Inhalte werden ¨ uber eine ASCII-Initialisierungsdatei beschrieben und direkt in den Bitstream des FPGAs integriert. Dabei ist die Kodierung der Gatewayfunktionalit¨ at in den ROMs dem Anwender selbst ¨ uberlassen. Die Schnittstelle

zwischen dem CGM bzw. den einzelnen Funktionalit¨ aten und den ROM-Zellen wirkt sich entscheidend auf die Performance des Systems aus.

Als Beispiel werde ein nachrichtenorientiertes Bussystem gew¨ ahlt, bei welchem jede Nachricht eine 11 Bit große Identifikationsnummer (ID) besitzt. Hier bietet es sich an, die IDs direkt als Adressleitungen des ROMs zu verwenden. Somit besitzt jede m¨ ogliche Nachricht ihre eigene Speicherzelle im ROM. Dadurch ist die Zugriffsgeschwindigkeit

13

3.1 FPGA-basiertes Gateway

enorm hoch, da man auf komplizierte Polling-Algorithmen verzichten kann. Die Speichertiefe ist abh¨ angig von der Gr¨ oße der BRAMs. Bei einem 18 kbit BRAM und einer 11 Bit ID stehen maximal 9 Bit zur Kodierung der Funktionalit¨ at zur Verf¨ ugung. Verwendet man davon f¨ unf zur Kodierung des Zielbussystems und 4 Bit zur Funktionalit¨ atsdekodierung, so lassen sich mit der empfangenen Nachricht 16 verschiedene Operationen ausf¨ uhren und 32 m¨ ogliche Bussysteme adressieren. Die Dekodierung des ROM-Inhaltes findet im CGM statt.

Mit der Bus-Basis-Konstellation kann jedes beliebige Gateway erstellt werden. Dabei unterscheidet man zwischen zwei Designalternativen. Einerseits gibt es das geschwindigkeitsoptimierte, zum anderen das fl¨ achen-/kostenoptimierte Design. Das geschwindigkeitsoptimierte Design ist geeignet f¨ ur Gateways mit sehr hohen Datenraten oder einer hohen Anzahl an angeschlossenen Bussystemen. Es ist eine parallele Implementierung, bei der f¨ ur jedes an das Gateway angeschlossene Bussystem eine Bus-Basis-Konstellation verwendet wird. Auch hier darf die FPGA-interne Systemfrequenz einen minimalen Wert, welcher die Funktionssicherheit des Gateways gew¨ ahrleistet, nicht unterschreiten (Formel 3.1). Die Anzahl der Taktzyklen N Design bei dieser parallelen Implementierung wird von demjenigen Funktionsblock bestimmt, der am meisten Taktzyklen zum Verarbeiten einer Nachricht ben¨ otigt. Hierbei wird angenommen, dass die Empfangs- und Senderoutinen der Bus IPs und der Rx/Tx-Handler identische Taktzyklen ben¨ otigen und in den Funktionsbl¨ ocken ebenfalls parallelisiert sind. Dann ergibt sich:

N Design = max( N BusIP , N RT H , N CGM , N ROM ) (3.3)

Durch diese parallele Implementierung erreicht man eine maximale Performance des Gateways, was jedoch einen enormen Fl¨ achenbedarf zur Folge hat. Da der Fl¨ achenverbrauch ¨ aquivalent zu den Kosten ist, werden f¨ ur Gateways mit geringen Datenraten und/oder geringer Anzahl an angeschlossenen Bussystemen bestimmte Vorg¨ ange durch sequenziell arbeitende Funktionsbl¨ ocke ersetzt. Das fl¨ achen-/kostenoptimierte Design besitzt nur einen Rx/Tx-Handler und einen CGM mit ROMs. Hierbei muss bei dem Design der einzelnen Funktionsbl¨ ocke ¨ außerste Vorsicht geboten werden, damit es nicht zu Datenkollisionen oder sogar zum Datenverlust kommt. F¨ ur jedes Bussystem ist weiterhin ein eigener Bus IP-Core vorhanden. Die internen Design-Taktzyklen werden folgendermaßen bestimmt:

N Design = max( N BusIP ) + 2N RT H + N CGM + N ROM (3.4)

Hierbei wird angenommen, dass die Empfangs- und Senderoutinen der Bus IPs identische Taktzyklen ben¨ otigen und in den Funktionsbl¨ ocken parallelisiert sind. Bei der Berechnung der Design-Taktzyklen sind parallele und sequenzielle Vorg¨ ange unterschiedlich betrachtet. Die exakte Kalkulation der Designfrequenz eines FPGA-Gateways muss individuell durchgef¨ uhrt werden, da jeder Entwickler seine Funktionsbl¨ ocke unterschiedlich konstruiert.

14

3.2 Grundlagen der Entwurfsrepr¨ asentation und Entwurfsmethodik

3.1.3 Heterogenes Design

Das Heterogene Design ist eine hybride L¨ osung aus der Softwarel¨ osung und der Hardwarel¨ osung. Sie kann die unterschiedlichsten Konstellationen annehmen. Der Prozessor erledigt hierbei Aufgaben des CGMs und/oder Aufgaben des Rx/TX-Handlers. Mittels dieser L¨ osung kann man jede Gatewayfunktion entweder in Hardware oder in Software realisieren. Die hybride L¨ osung ist das am schwersten zu entwickelnde Design aufgrund der Problematik beim Verteilen der einzelnen Aufgaben. Welche Funktionen sollen in Software mittels des Prozessors realisiert werden und welche als Hardware in Form von Funktionsbl¨ ocken? Dieses Problem ist auch unter dem Begriff Hardware/Software-CoDesign bekannt. Bei der exakten Verteilung der einzelnen Funktionen kann ein optimales Design erstellt werden. Um diese Problematik zu l¨ osen, muss ein Verfahren entwickelt werden, welches das gesamte Gateway beschreibt und eine optimale Architektur mit zugeh¨ origer Hardware/Software-Partitionierung liefert.

Die im n¨ achsten Kapitel vorgestellten Grundlagen der Entwurfsrepr¨ asentation und Entwurfsmethodik dienen als Basis zur Entwicklung eines solchen Verfahrens.

3.2 Grundlagen der Entwurfsrepr¨ asentation und Ent-

3.2.1 Entwurfsrepr¨ asentation

Es gibt viele Ans¨ atze, die verschiedenen Dimensionen des Entwurfs miteinander in systematischer Weise zu einem Entwurfsmodell zu verkn¨ upfen. Das am weitesten verbreitete ist das 1983 von Gajski und Kuhn entwickelte Y-Modell, das 1985 von Walker und Thomas weiter verfeinert wurde. Im Y-Modell (siehe Abbildung 3.3) ist der Grad der Verfeinerung eines Entwurfs in Abstraktionsebenen und die Repr¨ asentationen in Sichten dargestellt. Die in Form eines Ypsilons angeordneten Achsen repr¨ asentieren die Sichten. Dabei bilden die vom Ursprung ausgehenden konzentrische Kreise die Abstraktionsebenen.

Es sei an dieser Stelle darauf hingewiesen, dass die im Y-Diagramm verwendeten Bezeichnungen vom Original abweichen k¨ onnen. Das Modell zeigt die Aufteilung in funktionelle, strukturelle und physikalische Sichten. In der funktionellen Sicht wird das Verhalten des Entwurfs unabh¨ angig von dessen Implementierung beschrieben. Die strukturelle Sicht hingegen zeigt die logische Struktur bzw. abstrakte Implementierung des Entwurfsgegenstandes. Aufgabe der physikalischen Sicht ist die Darstellung der jeweiligen Abstraktionsebene in ihrer physikalischen Sichtweise. Dies entspricht der Form einer konkreten Implementierung mit realen Objekten. Es gibt viele Versionen des Y-Modells, da jeder Entwickler sich hinsichtlich seiner Problemstellung eigene erforderliche Sichten und Abstraktionsebenen zusammenstellt. Heute kommen mit steigender H¨ aufigkeit

15

3.2 Grundlagen der Entwurfsrepr¨ asentation und Entwurfsmethodik

heterogene Designs mit Hardware- und Softwarekomponenten zum Einsatz. Bild 3.4 visualisiert ein Modell zum Entwurf heterogener Systeme [15].

Das Wasserfallmodell zeigt, dass Abstraktionsebenen und Sichten in gewisser Weise orthogonal zueinander sind. Schon in der strukturellen Entwurfsrepr¨ asentation auf Systemebene erfolgt eine Aufteilung in Hardware- und Softwarekomponenten. Das Modell ist hierbei auf die funktionelle und strukturelle Sicht beschr¨ ankt. Die rechte Seite des Wasserfallmodells ist eine Ableitung aus dem Y-Modell, wobei die linke Seite eine Abstraktions¨ aquivalente f¨ ur den Softwareentwurf darstellt. Auf eine detaillierte Beschreibung der einzelnen Abstraktionsebenen beider Modelle sei auf [13] und [15] verwiesen. Die f¨ ur das Gatewaydesign relevanten Abstraktionsebenen und Sichten werden im Modell zur Gateway-Systemsynthese in Kapitel 3.3 beschrieben.

16

3.2 Grundlagen der Entwurfsrepr¨ asentation und Entwurfsmethodik

3.2.2 Synthese und Analyse

Der Begriff der Synthese und Analyse l¨ asst sich anhand der beschriebenen Modelle veranschaulichen. Ein Entwurfsschritt von einem festgelegten Punkt im Modell in Richtung des Entwurfziels bezeichnet man als Syntheseschritt. Die Vorgehensweise von der Verhaltensbeschreibung (funktionelle Sicht) hin zur strukturellen Sicht oder von der strukturellen hin zur physikalischen Sicht ist beispielsweise ein Syntheseschritt. ¨ Aquivalent dazu

ist der Entwurfsschritt von einer Abstraktionsebene einer Sicht zu einer Abstraktionsebene derselben Sicht mit h¨ oherem Detaillierungsgrad. Ein Syntheseschritt ist dadurch gekennzeichnet, dass der Detaillierungsgrad steigt und der Abstraktionsgrad sinkt. Die entgegengesetzten Vorgehensweisen bezeichnet man als Analyse.

3.2.3 Entwurfsmethodik

Eine traditionelle und heute noch vor allem im Hardwareentwurf verwendete Entwurfsmethodik ist das ”Erfassen und Simulieren”. Man beginnt mit einer formalen Beschreibung des Systems, welche in eine Blockstruktur, der Architektur, umgesetzt wird. Designer wandeln die einzelnen Bl¨ ocke in Logik um, die anschließend simuliert und verifiziert werden.

Seit einigen Jahren hat sich die Logiksynthese als integraler Bestandteil des Hardwareentwurfs etabliert und das System wird durch eine ausf¨ uhrbare Verhaltensbeschreibung spezifiziert. Diese Entwurfsmethodik wird als ”Beschreiben und Synthetisieren” bezeichnet und ist im Vergleich zum ”Erfassen und Simulieren (Entwurf per Hand)” eine wesentlich schnellere und qualitativ bessere Entwurfsart. Auf Logikebene werden dabei funktionale Einheiten wie z. B. Multiplizierer und Addierer automatisch und optimiert generiert. Das ”Beschreiben und Synthetisieren” findet ebenfalls seinen Einsatz bei der Architektursynthese. Sie wird auch als High-Level-Synthese bezeichnet, da sie sich in einer h¨ oheren Abstraktionsebene wie die Logiksynthese befindet (siehe Abbildung 3.4). Die funktionelle Beschreibung auf Architekturebene erfolgt durch synthetisierbare Daten- und Kontrollflussgraphen, welche durch die drei Syntheseaufgaben Allokation, Ablaufplanung und Bindung transformiert werden. Dabei ist die Aufgabe der Allokation die Festlegung der zur Implementierung ben¨ otigten funktionalen Komponenten. Der Detaillierungsgrad der Komponenten ist abh¨ angig von der jeweiligen Abstraktionsebene. Durch die Ablaufplanung wird die zeitliche Abfolge des spezifizierten Verhaltens auf den einzelnen Komponenten festgelegt, sodass zu jedem Zeitpunkt bekannt ist, welche Operation wann ausgef¨ uhrt wird. Die Bindung ordnet abschließend den Aufgaben die entsprechenden bei der Allokation festgelegten Komponenten zu. Das ”Beschreiben und Synthetisieren” wird ebenfalls beim Softwareentwurf eingesetzt. Dabei wird die Verhaltensbeschreibung des Systems durch eine ablauff¨ ahige Programmiersprache, z. B. C oder C++, dargestellt.

17

3.3 Modell zur Gateway-Systemsynthese

Bei der Synthese auf Systemebene gibt es momentan noch keine ausgereiften Methoden. Dennoch scheint sich hier ein Paradigma durchzusetzen, welches sich durch ”Spezifizie- ren,Explorieren und Verfeinern” beschreiben l¨ asst [12]. In der Spezifikationsphase wird die Spezifikation des Gesamtsystems erstellt. Sie beinhaltet in erster Linie die Beschreibung der Funktionalit¨ at, Verifikation kritischer Systemeigenschaften sowie die Untersuchung und Exploration verschiedener Realisierungsvarianten. Die Explorationsphase vergleicht die unterschiedlichen Realisierungsvarianten im Entwurfsraum. Hier werden die zu implementierenden Funktionalit¨ aten auf m¨ ogliche Komponenten eines heterogenen Systems gemapped. In der anschließenden Verfeinerungsphase erh¨ oht man den Detaillierungsgrad der Funktionalit¨ at und verteilt diese erneut auf die verschiedenen Hardware-und Softwarekomponenten. Die Exploration und Verfeinerung kann solange wiederholt werden, bis eine komplette strukturelle Beschreibung des Systems vorliegt, d. h. die Granularit¨ at wird st¨ andig erh¨ oht.

3.3 Modell zur Gateway-Systemsynthese

Ziel ist es, ein optimales FPGA-Gateway zu designen. Wie in Kapitel 3.1 beschrieben, kann ein Gateway aus einer reinen Hardwarel¨ osung, einer reinen Softwarel¨ osung oder aus einem heterogenen Design bestehen. Gesucht wird eine Beschreibungsform, die alle M¨ oglichkeiten in Betracht zieht und eine optimale L¨ osung liefert. Als Basismodell hierf¨ ur wird das Wasserfallmodell verwendet, da es heterogene Strukturen zul¨ asst.

3.3.1 Einschr¨ ankung der Abstraktionsebenen

Der erste Schritt beim Gateway-Modelldesign ist die Eingrenzung der zu behandelnden Abstraktionsebenen. Dies erreicht man durch die Definition der Grenzen zum vorhandenen automatisierten Entwicklungsfluss (engl. Designflow). Hardwareseitig wird die Verhaltensbeschreibung auf Architekturebene mittels einer Hardware-Modellierungssprache (VHDL oder VERILOG) programmiert und softwareseitig auf Modulebene mit einer Programmierhochsprache (C oder C++). Ein Automatismus von der Architektur/Modul-Verhaltensbeschreibung bis zur untersten Abstraktionsebene ist somit hardware- und softwareseitig durch Compiler und Synthesewerkzeuge in heutigen Entwicklungsumgebungen gegeben. Dieser Automatismus grenzt die Sichten und Abstraktionsebenen f¨ ur das Gateway-Synthesemodell auf die Systemebene ein. Die Grenzen sind in Bild 3.5 dargestellt. Folglich besitzt das Gateway-Synthesemodell als Eingangsparameter die Verhaltensbeschreibung des Gateways und liefert nach der Synthese ein optimales Design mit der entsprechenden Hardware-/Software-Partitionierung. Diese Partitionierung dient als Eingangsvektor f¨ ur den schon existierenden automatisierten Designflow.

18

3.3 Modell zur Gateway-Systemsynthese

3.3.2 Entwurf auf Systemebene

Auf Systemebene wird der Syntheseprozess als Systemsynthese bezeichnet. Das Gebiet der Systemsynthese ist derzeit noch wenig erforscht, daher existiert auch noch kein Konsens ¨ uber einheitliche Definitionen und ¨ uber das Aufgabenspektrum. Deshalb wird der Begriff der Gateway-Systemsynthese hier eingef¨ uhrt und definiert.

Definition 3.3 (Gateway-Systemsynthese) Unter Gateway-Systemsynthese wird das Problem verstanden, eine Gateway-Spezifikation auf Systemebene auf eine heterogene HW/SW-Struktur abzubilden. Dies verlangt folgende Vorgehensweise:

Die ersten drei Aufgaben der Gateway-Systemsynthese werden in den Unterkapiteln des Kapitels 3 behandelt, die Optimierung des Systems, Exploration des Entwurfsraums und das Finden einer optimalen L¨ osung im Folgekapitel 4. Durch Definition 3.3 ergibt sich das in Bild 3.6 dargestellte Modell zur Gateway-Systemsynthese.

19

3.3 Modell zur Gateway-Systemsynthese

F¨ ur das Beschreiben des Systemverhaltens eines Gateways w¨ urde sich eine datenflussorientierte Beschreibungsform anbieten. Sie besitzt jedoch den Nachteil, dass sie keine Kontrollstrukturen abbilden kann, welche aufgrund der Komplexit¨ at und Intelligenz heutiger Gateways erforderlich sind. Die L¨ osungen bieten hier sogenannte Kontroll-/Datenflussgraphen (engl. control data flow graph (CDFG)). CDFGs sind heterogene Modelle, die es erlauben, die Gatewayfunktionalit¨ at in Form von steuerungs- und datenflussorientierten Komponenten zu beschreiben. Die Festlegung m¨ oglicher Architekturen resultiert aus dem Hardwareaufbau des Gateways bzw. der zur Verf¨ ugung stehenden Komponenten. Diese Arbeit spezialisiert sich auf ein FPGA-basiertes Gateway, daher bestehen die m¨ oglichen Architekturen aus IP-Cores und/oder anwenderspezifischen Funktionsbl¨ ocken. F¨ ur die Darstellung der jeweiligen Architekturm¨ oglichkeiten bietet sich ebenfalls eine grafische Form an. Diese kann als Graph oder Schaltplan erfolgen. Das Abbilden des Systemverhaltens auf die festgelegten Architekturen wird mit Hilfe von Mappingkanten umgesetzt. Sie beschreiben m¨ ogliche hardwareseitige Implementierungsvarianten einer Funktion des Systemverhaltens.

F¨ ur die ersten drei Schritte der Gateway-Systemsynthese wird eine grafische Beschreibungsform gew¨ ahlt. Die in Teich’s ”Digitale Hardware/Software-Systeme” beschriebene Graphentheorie dient hierf¨ ur als Grundlage [15]. Das Beschreiben des Systemverhaltens und der m¨ oglichen Architekturen sowie das Abbilden der Funktionalit¨ at auf diese kann in Form eines Gateway-Systemgraphen dargestellt werden. Die folgenden Kapitel beschreiben die Transformation der Verhaltensbeschreibung in einen Systemgraphen.

20