Eingebettete Systeme

Materialien zur Vorlesung SS 2002

Ju ¨ rgen Teich, Lothar Thiele1 Institut TIK der ETHZ Fachgruppe Technische Informatik

1

c

bei den Autoren

Vorwort Begru ¨ndung Inhalt der Vorlesung sind Modelle und Methoden zum Entwurf komplexer Systeme. Die Komplexit¨at, so wie sie hier verstanden wird, entsteht nicht nur durch die Zahl der Einzelkomponenten, aus denen das System zusammengesetzt ist, sondern vor allem durch Heterogenit¨at. In Zukunft liegen die Anforderungen gerade bei der Beherrschung heterogener technischer Systeme, die sich durch verschiedenartige Komponenten und Interaktionen auszeichnen. Erfolgreiche Produkte in dieser Hinsicht sind in zahlreichen Bereichen zu finden, etwa der Verkehrstechnik mit ABS und Airbag. Hier zum Beispiel werden die wesentlichen Eigenschaften solcher Systeme deutlich: Heterogenit¨at (analog–digital, mechanisch–elektronisch, Hardware–Software, Sensorik, Aktorik, Mikrosystemtechnik), hohe Verf¨ ugbarkeit, Selbstdiagnose (Anzeige bei Ausfall des ABS), Fehlertoleranz. Selbstverst¨andlich k¨onnen im Rahmen der Vorlesung nicht beliebige komplexe technische Systeme betrachtet werden. Wir werden uns hier beschr¨anken auf Systeme, die aus miteinander verbundenen integrierten Schaltungen bestehen. Beispiele sind die sogenannten eingebetteten Systeme, siehe Bild 1. Sie sind dazu bestimmt, Funktionen als Antwort auf bestimmte Stimuli auszuf¨ uhren und fallen somit in die Klasse reaktiver Systeme. Es handelt sich dabei meist um zeitkritische Anwendungen, bei denen die Antwort innerhalb bestimmter Zeitschranken erforderlich ist (Echtzeitsysteme). Echtzeit–Steuerungssysteme m¨ ussen also kritische Informationen zwischen autonomen Teilsystemen unter Einhaltung von Zeitschranken zuverl¨assig austauschen. Diese Anforderungen werden zum Beispiel offensichtlich in Zusammenhang mit (¨offentlichen) Transportsystemen wie Flugzeug, Bahn oder auch Automobil. Man sollte sich zum Beispiel vorstellen, daß jeweils autonome Sensor–Elektronik–Aktor Systeme verantwortlich sind f¨ ur Bremsfunktion, Motorsteuerung, Federungssysteme, Kupplung, Getriebe und vieles andere mehr. Hier werden bereits analoge und digitale elektronische Hardware/Software–Systeme mit mechanischen Komponenten verbunden. Alle Teilsysteme stehen zus¨atzlich untereinander u ¨ber ein Kommunikationsnetzwerk miteinander in Verbindung. Andere Beispiele dieser Art finden sich in der Haustechnik, bei verteilten Produktionssystemen (verteilte Sensor–Aktor–Systeme, siehe oben) sowie im Telekommunikationsbereich (mobile Endger¨ate, Kommunikationsnetze). Das grosse Interesse am systematischen Entwurf von heterogenen Systemen, die mechanisch–elektronische, analog–digitale sowie Hardware–Software Komponenten enthalten ist massgeblich verursacht durch • die steigende Vielfalt und Komplexit¨at von Anwendungen f¨ ur eingebettete Systeme, • die Notwendigkeit, Entwurfs- und Testkosten zu senken sowie durch • Fortschritte in Schl¨ usseltechnologien (Mikroelektronik, formale Methoden). 1

2 Kopplung

Speicher

StandardKomponente

ASIC

Prozessor

Prozessor

eingebettetes System Systemumgebung

Abbildung 1: Schematische Darstellung eines eingebetteten Systems Um die Entwicklung in diesem Bereich genauer zu verstehen, ist es sinnvoll, sich die historische Entwicklung kurz vor Augen zu f¨ uhren. Als Beispiel eines Systems, das seine Komplexit¨at vor allem durch die riesige Anzahl seiner Komponenten erh¨alt, k¨onnen integrierte Schaltungen dienen: Eine integrierte Schaltung kann aus vielen Millionen Einzelelementen bestehen, die jedoch alle in ¨ahnlicher Weise arbeiten und in einem homogenen technologischen Prozess (aus Silizium) hergestellt werden. Die Forschritte in der Technologie h¨atten alleine jedoch nicht zu dem riesigen Erfolg in diesem Bereich gef¨ uhrt. Entscheidenden Einfluss hatte die Entwicklung rechnergest¨ utzter Entwurfsverfahren, mit deren Hilfe wesentliche Schritte automatisiert werden. Heutige integrierte Schaltungen k¨onnten nicht mehr ohne den Einsatz von CAD (computer-aided-design)-Methoden entworfen werden. Insgesamt l¨asst sich diese Entwicklung in drei Abschnitte unterteilen: • Nachdem die Zahl der Objekte in den unteren Entwurfsebenen (Geometrie, physikalische Ebene) aufgrund des Zeitaufwandes und der Fehleranf¨alligkeit ohne Automatisierung nicht mehr handhabbar war, wurden in Industrie und Forschung Modelle und Methoden entwickelt, die zum Beispiel auf Schaltungssimulation, Plazierung und Verdrahtung abzielten. • In einem weiteren Schritt wurden dann auch h¨ohere Abstraktionsebenen in die Automatisierung einbezogen, wie zum Beispiel die Simulation von Schaltungen auf LogikEbene oder auch die Logiksynthese. • Neue Anforderungen bez¨ uglich der System-Komplexit¨at, der Zeitpanne zwischen Produkt-Idee und Markteinf¨ uhrung sowie der Zuverl¨assigkeit f¨ uhren nun zur Entwurfsautomatisierung auf der noch abstrakteren Systemebene. Eine Betrachtung auf Systemebene ist nicht nur n¨aher an der u ¨ blichen Vorstellung eines Systementwicklers. Es w¨are zudem kaum vorstellbar, wie ein System, das aus mehreren verteilten Mikroprozessoren einschliesslich der zugeh¨origen Software sowie aus integrierten Schaltungen mit jeweils mehr als 100.000 Gattern besteht, auf andere Weise

3 spezifiziert, entworfen, getestet und dokumentiert werden kann. Je komplexer ein Entwurf ist, desto schwieriger wird es, die Funktionalit¨at aus Assembler-Programmen und LogikDiagrammen auf Gatter-Ebene zu verstehen. Auf der anderen Seite, wenn das System als eine Folge von komplexen Operationen beschrieben wird, die auf abstrakten Datentypen operieren und ihre Ergebnisse u ¨ber abstrakte Kan¨ale kommunizieren, so wird es dem Entwickler leichter fallen, die korrekte Funktionalit¨at des Entwurfs zu testen oder zu verifizieren und verschiedene Realisierungsalternativen zu evaluieren. Zusammenfassend haben die folgenden Kernpunkte entscheidend zu den riesigen Fortschritten auf dem Gebiet der Entwurfsautomatisierung beigetragen: • Modellierung und formale Spezifikation, • Hierarchie und Abstraktion, • Effiziente Synthesealgorithmen. Sie werden auch im Vordergrund der Vorlesung stehen. Die Vorlesung wird selbstverst¨andlich nicht alle Aspekte des Systementwurfs abdecken k¨onnen. Das liegt unter anderem daran, dass das gesamte Gebiet noch stark in Bewegung ist. Aus Zeitgr¨ unden werden wir uns speziell nicht mit formaler Verifikation und Simulationsverfahren auseinandersetzen.

Die Materialien Die vorliegenden Materialien wurden zur Begleitung der Vorlesung Architektur und Ent” wurf eingebetteter Systeme“ erstellt, die zum ersten Mal im Sommersemester 95 gehalten wurde. Zur Einsch¨atzung, was denn nun hier vor Ihnen liegt, sind vielleicht einige Bemerkungen angebracht: • Das Skript stellt nur eine Form der Unterlagen f¨ ur diese Vorlesung dar. Weiterhin werden Kopien der Vorlesungsfolien oder auch ausgew¨ahlte Publikationen zur Verf¨ ugung gestellt. • Das Skript soll als Referenz u ¨ber die in der Vorlesung behandelten Themenbereiche dienen. Wir stellen nicht an uns den Anspruch, ein Buch vorzulegen. Dies w¨ urde auch dem Charakter dieser Vorlesung widersprechen. • Das Skript befindet sich in einem dynamischen Zustand. Daher werden wesentliche Teile im Verlauf der Vorlesung erg¨anzt und an die H¨orer verteilt. In einigen Teilen bezieht sich die Vorlesung auf die B¨ ucher von Giovanni De Micheli [6] und Daniel Gajski et al. [8]. Weiterhin wurden wesentlich Teile dieser Vorlesung von J¨ urgen Teich in sein Buch [33] u ur wesentliche ¨bernommen. Es kann daher als Referenz f¨ Teile dieser Vorlesung dienen. Weitere Literaturhinweise findet man im jeweiligen Zusammenhang.

Einbettung Vielleicht stellt sich die Frage, wie denn die Vorlesung in das bestehende Angebot (speziell des Instituts f¨ ur Technische Informatik und Kommunikationsnetze) einzuordnen ist. Diese Frage dr¨angt sich vor allem deshalb auf, da sich ja schon in verschiedenen anderen Veranstaltungen mit eingebetteten Systemen auseinandergesetzt wird.

4 • In den Veranstaltungen Technische Informatik I/II“ werden die wesentlichen Grun” dagen zum Verst¨andnis von Hardware- und Softwarearchitekturen gelegt. Sie sind daher Voraussetzung f¨ ur diese Lehrveranstaltung. • Die Kernfachvorlesung Diskrete Ereignissysteme“ legt theoretische Grundlagen zum ” Verst¨andnis von Modellen und Methoden, die bei eingebetteten Systemen verwendet werden. Einige dieser Grundbegriffe werden im Rahmen dieser Vorlesung wiederholt. Diese Kernfachvorlesung ist demzufolge keine unbedingte Voraussetzung. • Die Kernfachvorlesung Prozessrechentechnik“ ist dem Bereich der Prozessrechner, ” der Kommunikation zwischen verteilten Systeme und der Echtzeitverarbeitung gewidmet. Hier wird also vor allem die Software-Seite des Systementwurfs beleuchtet. • Thema der neuen Vorlesung Eingebettete Systeme“ sind Modelle und Methoden des ” automatisierten Entwurfs heterogener Systeme, die also aus Hardware- und SoftwareKomponenten bestehen.

Inhaltsverzeichnis 1 Architekturen fu ¨ r eingebettete Systeme 1.1 Grundstrukturen von eingebetteten Systemen . . . 1.2 Implementierungstypen . . . . . . . . . . . . . . . 1.2.1 Ein-Chip-L¨osungen . . . . . . . . . . . . . . 1.2.2 Board-Level-Systeme . . . . . . . . . . . . . 1.3 Prozessoren . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Mikrocontroller . . . . . . . . . . . . . . . . 1.3.2 Mikroprozessoren . . . . . . . . . . . . . . . 1.3.3 Anwendungsspezifische Prozessoren (ASIP) 1.3.4 Digitale Signalprozessoren – DSPs . . . . . 1.4 Hardwareimplementierungen . . . . . . . . . . . . 1.4.1 ASIC-Entwurf . . . . . . . . . . . . . . . . 1.4.2 Programmierbare Hardware . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

7 7 7 7 12 13 13 16 19 21 24 24 27

2 Entwurfsmethodik 2.1 Entwurfsmethodik . . . . . . . . . . . . . . . . 2.1.1 Erfassen und simulieren . . . . . . . . . 2.1.2 Beschreiben und synthetisieren . . . . . 2.1.3 Spezifizieren, explorieren und verfeinern 2.2 Abstraktion und Entwurfsrepr¨asentationen . . 2.2.1 Modelle . . . . . . . . . . . . . . . . . . 2.2.2 Synthese . . . . . . . . . . . . . . . . . . 2.2.3 Optimierung . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

31 31 31 32 33 34 34 36 44

. . . . . . . . . . . . .

47 47 49 50 52 55 55 56 57 57 62 62 62 64

. . . . . . . .

. . . . . . . .

3 Spezifikation und Modellierung 3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Klassifikation von Modellen . . . . . . . . . . . . . . . 3.3 Petri-Netzmodell . . . . . . . . . . . . . . . . . . . . . 3.3.1 Dynamische Eigenschaften von Petri-Netzen . . 3.4 Zustandsorientierte Modelle . . . . . . . . . . . . . . . 3.4.1 Endliche Automaten (FSM) . . . . . . . . . . . 3.4.2 Erweiterte Zustandsmaschinenmodelle . . . . . 3.4.3 Hierarchische, nebenl¨aufige Zustandsmaschinen 3.4.4 Statecharts . . . . . . . . . . . . . . . . . . . . 3.5 Aktivit¨atsorientierte Modelle . . . . . . . . . . . . . . 3.5.1 Datenflussgraphen . . . . . . . . . . . . . . . . 3.5.2 Markierte Graphen . . . . . . . . . . . . . . . . 3.5.3 Synchrone Datenflussgraphen (SDF) . . . . . . 5

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

6

INHALTSVERZEICHNIS 3.6

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

67 67 69 69 73

4 Synthese 4.1 Fundamentale Syntheseprobleme . . . . . . . . . . . . . . . 4.1.1 Ablaufplanung . . . . . . . . . . . . . . . . . . . . . 4.1.2 Allokation . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Bindung . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Komplexit¨at kombinatorischer Optimierungsprobleme . . . 4.2.1 Entscheidungsprobleme und Optimierungsprobleme . 4.2.2 Algorithmen . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Klassifikation von Problemen . . . . . . . . . . . . . 4.3 Algorithmen zur Ablaufplanung . . . . . . . . . . . . . . . . 4.3.1 Ablaufplanung ohne Ressourcebeschr¨ankungen . . . 4.3.2 Ablaufplanung mit Zeitbeschr¨ankungen . . . . . . . 4.3.3 Ablaufplanung mit Ressourcenbeschr¨ankungen . . . 4.3.4 Iterative Verfahren zur Ablaufplanung . . . . . . . . 4.4 Algorithmen zur Bindung . . . . . . . . . . . . . . . . . . . 4.4.1 Algorithmen und Komplexit¨at der Bindung . . . . . 4.4.2 Bindung nach Ablaufplanung . . . . . . . . . . . . . 4.4.3 Bindung hierarchischer Graphen . . . . . . . . . . . 4.4.4 Bindung vor Ablaufplanung . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

75 75 76 76 77 81 81 81 82 83 83 86 88 108 110 114 115 115 115

5 Beispiele zur Architektursynthese 5.1 Architekturbewertungen . . . . . . . . . . . . . . . 5.1.1 Verarbeitungsgeschwindigkeit . . . . . . . . 5.1.2 Auslastung von Ressourcen . . . . . . . . . 5.1.3 Auslastung von Architekturen . . . . . . . . 5.1.4 Fliessbandtiefe . . . . . . . . . . . . . . . . 5.2 Architekturentwurf f¨ ur ein digitales Filter . . . . . 5.3 Speicher . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Lebenszeit von Variablen . . . . . . . . . . 5.3.2 Modellierung des Speicherbedarfs . . . . . . 5.4 Anwendung der Verfahren auf einen Videokodierer 5.4.1 Eine einfache Zielarchitektur . . . . . . . . 5.4.2 Ein realistisches Architekturbeispiel . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

119 119 119 119 120 120 121 124 124 125 126 128 134

3.7 3.8

Strukturorientierte Modelle . . . . . . . . . . . . . . 3.6.1 Komponenten- Verbindungsdiagramm (CCD) Heterogene Modelle . . . . . . . . . . . . . . . . . . . 3.7.1 Kontroll/Datenflussgraphen (CDFGs) . . . . K¨ onnen Programmiersprachen mehr? . . . . . . . . .

Literatur

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

139

Kapitel 1

Architekturen fu ¨ r eingebettete Systeme ¨ Es folgt eine Ubersicht u ¨ber die Grundstrukturen von eingebetteten Systemen. Zum einen werden unterschiedliche Implementierungsarten beschrieben. Hierzu geh¨oren EinChip-Systeme, Multi-Chip-Module und Boardsysteme. Was die softwareprogrammierbaren Komponenten angeht, werden verschiedene Prozessortypen klassifiziert. Gerade im Bereich von eingebetteten Systemen spielen Spezialprozessoren eine dominante Rolle. Dies sind zum Beispiel Mikrocontroller und Digitale Signalprozessoren (DSPs). Wenn Prozessoren f¨ ur einen einzelnen Anwendungsbereich zugeschnitten sind, spricht man auch von sog. ASIPs (engl. Application-Specific Instruction set Processors). Was die Realisierung von Hardware angeht, unterscheidet man auch verschiedene Implementierungsarten, wobei zum einen der ASIC-Entwurf (voll- bzw. halbkundenspezifisch) und zum anderen das Prototypisieren auf konfigurierbarer Hardware geh¨ort. Abb. 1.1 ¨ gibt einen Uberblick u ¨ ber die einzelnen Realisierungsformen zur Implementierung eines Problems.

1.1

Grundstrukturen von eingebetteten Systemen

¨ Abbildung 1.2 zeigt eine Ubersicht u ¨ber den Aufbau eines typischen eingebetteten Systems, bestehend aus Sensoren, Interfaces, dem digitalen System und Aktoren. In Tabelle 1.1 sind einige Beispiele dargestellt.

1.2 1.2.1

Implementierungstypen Ein-Chip-L¨ osungen

Im folgenden sollen die Gr¨ unde f¨ ur die Realisierung eines eingebetteten Systems als EinChip-L¨osung motiviert werden. • Kosten: Im allgemeinen gilt die Regel, dass Ein-Chip-Systeme aufgrund hoher Entwicklungskosten nur in hohen St¨ uckzahlen rentabel sind, sonst teurer als beispielsweise Platinenentw¨ urfe. • Gewicht, Gr¨ osse: Gewisse Anwendungsbereiche stellen Anforderungen an maximales Gewicht, maximale Gr¨osse, insb. der Bereich mobiler Ger¨ate (Laptops, Chipcards, 7

¨ EINGEBETTETE SYSTEME KAPITEL 1. ARCHITEKTUREN FUR

8

SOFTWAREprogrammierbar Vielzweckprozessoren: RISC, CISC Spezialprozessoren: DSP, Microcontroller

> Kosten

.. > Flexibilitat

> Performanz > Time-to-market

Core-basierte Spezialprozessoren: DSP, Microcontroller

> Leistungsverbrauch

Application-specific instruction set processors: ASIP Programmierbare Logik: FPGA Integrierte Schaltungen: ASIC, Systolic Array

Anwender denkt an HARDWARE

Abbildung 1.1: Spezialisierungsformen und Kriterien f¨ ur Hardware/Software-Entscheidungen

sensors

interface

digital target system

interface

communication ports

Abbildung 1.2: Grundaufbau eines typischen eingebetteten Systems

actors

1.2. IMPLEMENTIERUNGSTYPEN Beispiel/ Sensoren PC Maus, Tastatur Laserdrucker Hitzesensoren ser. Schnittstelle Tastenfeld, Schalter Autosteuerung Motordrehzahl Position Kurbelwelle etc.

9

Interface

Komm.ports

Interface

Aktoren

Ser./Par.Wandler

Ethernet-Transc. DMA

D/A-Wandler Video-SignalGenerator

Bildschirmsteuerung

A/D-Wandler DMA parallel

Ethernet-Transc. par./ser.

D/A-Wandler

Leistungselektronik, Motoren

A/D-Wandler Komparatoren

CAN-Bus Transc. parallel I/O

Pulsformer (PWM) PWM D/A-Wandler

Z¨ undung Einspritzung Gangschalt.

Tabelle 1.1: Typische Struktur von eingebetteten Systemen Handy). • Verl¨asslichkeit: Ein-Chip-Systeme sind i. allg. verl¨asslicher als Platinenentw¨ urfe, da Konnektoren, Kabel, Anschl¨ usse besonders kurz sind. Auch die St¨oranf¨alligkeit und elektromagnetische Vertr¨aglichkeit (EMV) sind h¨oher aufgrund kleinerer Dimensionen. • Leistungsverbrauch: gleiche Argumente wie f¨ ur Gr¨osse und Gewicht • Schutz intellektuellen Besitzes Beispiel 1.1 Abbildung 1.3 zeigt das Layout eines konfigurierbaren Ein-Chip-Systems von Texas Instruments (TI-cDSP). Neben einem Prozessorkern, einem digitalen Signalprozessor, enth¨alt der Chip konfigurierbaren RAM- und ROM-Bereich sowie ein Gatearray (links) zum Entwurf anwendungsspezifischer Hardware. H¨aufig kommen zu diesen Komponenten auch periphere Komponenten vor, z. B. eine A/D-Wandler-Zelle oder Schnittstellenzellen (ser./par.). Beispiel 1.2 Neben der Entscheidung Hardware oder Software betrifft ein weiterer Heterogenit¨atsaspekt eingebetteter Systeme die Frage analog oder digital. Abbildung 1.4 zeigt ein EinChip-System, das einen SMARTPOWER Mikrocontroller mit einer 3 A DC-Motorbr¨ ucke koppelt. Die vier in der rechten H¨alfte dargestellten regelm¨assigen Zellen des Layouts stellen DMOSLeistungstransistoren dar. Neben dem Mikrocontroller zur Steuerung der Motorbr¨ ucke existiert ein Eprom zur Programmierung von Funktionen wie beispielsweise die Einstellung von Spannungsreferenzen und Verst¨arkereinstellungen. Beispiel 1.3 Tabelle 1.2 zeigt unterschiedliche, vom Halbleiterhersteller Philips stammende, Konfigurationen von Ein-Chip-Systemen, die den Prozessor 8051 verwenden. Eine typische Konfiguration eines Ein-Chip-Systems mit einem 8051-Prozessor ist in Abb. 1.5 dargestellt.

Zusammenfassung Ein-Chip-L¨osungen:

10

¨ EINGEBETTETE SYSTEME KAPITEL 1. ARCHITEKTUREN FUR

Abbildung 1.3: Layout eines Ein-Chip-Systems von Texas Instruments (cDSP)

1.2. IMPLEMENTIERUNGSTYPEN

11

Abbildung 1.4: Layout des Ein-Chip-Systems SMARTPOWER

processor 80C51 15-vector interrupt timer0 (16 bit) timer1 (16 bit)

8K8 ROM (87C552 8K8 EPROM) 256x8 RAM A/DC 10-bit PWM

timer2 (16 bit)

UART

watchdog (T3)

I2C

parallel ports 1 through 5

Abbildung 1.5: Philips 83 C552: 8-Bit basierter Mikrocontroller

¨ EINGEBETTETE SYSTEME KAPITEL 1. ARCHITEKTUREN FUR

12 Eigenschaft

Rom Eprom Ram [Bytes] EEPROM [Bytes] I/O parallel I/O UART I/O I2 C Timer 0,1 Timer 2,3 ADC 8-Eing. PWM 2-Ausg. Int.vektoren Geh¨ause Dil40 PLCC-44 QFP-44 PLCC-68

83/87 C552 8K8 256

83/87 C562 8K8 256

83/87 C652 8K8 256

83/87 C662 8K8 256

83/87 C654 16K8 256

83/87 C528 32K8 256

6x8 x x x x 10 Bit x 15

6x8 x

4x8 x x x

4x8 x

4x8 x

x

4x8 x x x

83 C851 4K8 128 256 4x8 x

x

x

6

5

6

6

5

x x x

x x x

x x x

x x x

x x x

x

x x 8 Bit x 14

x

83/87 C592 8K8 256 6x8 x CAN x x 10 Bit x 15

x

Tabelle 1.2: Konfigurationen des 8051. Quelle: Philips Halbleiter • Prozessorhersteller bieten Makrozellen bekannter Prozessortypen (sog. Cores) an, die mit unterschiedlichsten anderen Komponenten (z. B. Speicher) in Art und Gr¨osse beliebig konfiguriert werden k¨onnen. • Cores erleichtern die Migration zwischen Versionen und Halbleiterherstellern und senken damit das Entwurfsrisiko. • Neben Speicher gibt es zahlreiche andere periphere Einheiten. • Unterst¨ utzt werden h¨aufig spezielle Powerdown-funktionen. • Die Architekturen verzichten h¨ aufig auf Caching, • der Datenspeicher ist klein gegen¨ uber dem Programmspeicher. • Baukastensysteme unterst¨ utzen die Wiederverwendbarkeit von Komponenten.

1.2.2

Board-Level-Systeme

Abbildung 1.6 zeigt den typischen Aufbau eines Platinenentwurfs. Als Gr¨ unde f¨ ur den Platinenentwurf lassen sich folgende Kriterien auff¨ uhren: • Vorteile gegen¨ uber der Ein-Chip-L¨osung: – Erf¨ ullbarkeit: Das System passt nicht auf einen einzelnen Chip. – Kosten: Die Benutzung von Standardchips ist kosteng¨ unstiger. – Entwurfszeit: h¨aufig kleiner als f¨ ur einen ASIC (1 Tag...1 Woche), da die Benutzung von existierenden Standardkomponenten m¨oglich ist.

1.3. PROZESSOREN

13

Prozessor(en)

Coprozessor(en)

A/DC D/AC Transceiver

Gluelogik (FPGA, PLD, ...) Leistungselektronik

Speicher Interfaceelektronik

Konnektoren

Abbildung 1.6: Typischer Aufbau eines Platinenentwurfs eines eingebetteten Systems ¨ – H¨ohere Flexibilit¨at bei sp¨aten Anderungen. – Verl¨asslichkeit: Ein-Chip-Entw¨ urfe sind technologiebedingt anf¨allig gegen eine Reihe von Defekten (Oxidation, heisse Ladungstr¨ager), Besch¨adigung des Geh¨auses. Hochsichere Systeme sind typischerweise verteilt. • Vorteile gegen¨ uber L¨osungen bestehend aus mehreren Platinen: – Performanz: H¨ohere Kommunikationsbandbreite m¨oglich, – Kosten: niedriger – Gr¨osse, Gewicht, EMV, Leistungsverbrauch: vgl. Ein-Chip-L¨osung. F¨ ur Multi-Chip-Module sprechen Argumente von sowohl Platinen- als auch Ein-ChipSystemen. F¨ ur Systeme, die aus mehreren Platinen bestehen (Multiboard-Systeme), sprechen schliesslich Gr¨ unde der Erf¨ ullbarkeit (z. B. wenn das System nicht auf eine Platine passt) sowie Gr¨ unde der Flexibilit¨ at, Skalierbarkeit, Wartbarkeit und Erweiterbarkeit. Nachteile sind hier vor allem die komplexere Kommunikationsstruktur der Teilsysteme untereinander und die dadurch h¨aufig bedingte Einbusse in der Kommunikationsrate zwischen Teilsystemen.

1.3

Prozessoren

¨ Tabelle 1.3 gibt eine Ubersicht u ¨ ber die Marktanteile von Mikrocontrollern und Mikroprozessoren unterschiedlicher Leistungsf¨ahigkeiten von 1993 und eine Vorhersage f¨ ur 1998.

1.3.1

Mikrocontroller

Mikrocontroller kennzeichnen eine Klasse von Prozessoren, die f¨ ur den speziellen Anwendungsbereich der Steuerung von Prozessen zugeschnitten sind. Die klassischen Mikrocontroller besitzen eine Wortbreite von 4-8 Bit, neuere Generationen mittlerweile Wortbreiten von 16-64 Bit. Erstere sind optimiert f¨ ur Anwendungen mit steuerungsorientierten Systemfunktionen. Die Eigenschaften lassen sich wie folgt charakterisieren:

14

¨ EINGEBETTETE SYSTEME KAPITEL 1. ARCHITEKTUREN FUR

Mikrocontroller 4-Bit 8-Bit 16- und 32-Bit DSP Mikroprozessoren 8-Bit und 16-Bit 32-Bit und 64-Bit 32-Bit 64-Bit

1993 44 % ($6.8B) 11 % ($1.8B) 25 % ($3.8B) 3 % ($0.5B) 5 % ($0.7B) 56 % ($8.7B) 5 % ($0.7B) 51.6 % ($8.0B)

total $15.5B

1998 (FCST) 38 % ($13.1B) 5 % ($1.7B) 18 % ($6.4B) 7 % ($2.3B) 8 % ($2.7B) 62 % ($21.9B) 1 % ($0.3B) 33 % ($11.6B) 28 % ($10.0B) total $35.2B

Tabelle 1.3: Markt von Mikrocontrollern und Mikroprozessoren. (Quelle: ICE, 94) • Integration von Zugriffsfunktionen auf Peripherie (I/O) im Instruktionssatz, • Bit- und Logikoperationen, • Register sind h¨aufig im RAM realisiert. Dadurch kann ein Kontextwechsel durch einfache Zeigeranweisungen bewerkstelligt werden. Diese Prozessoren erreichen Interruptlatenzen im Bereich von 1µs und genauso schnelle Kontextwechselzeiten. • Geringe Performanz (ca. 1µs/Instruktion). Beispiel 1.4 Der Prozessor 8051 ist einer der in steuerungsdominanten Anwendungen am h¨aufigsten eingesetzten Mikocontrollern. Er besitzt eine Wortbreite von 8 Bit. Die weiteren Eigenschaften lassen sich wie folgt zusammenfassen: • Akkumulatormaschine (1-Adress-Maschine), CISC, 8-Bit Register, • 8 B¨anke mit jeweils 8 Registern, realisiert als RAM, Umschaltung der B¨anke durch Interrupts oder Unterprogramme (sog. Registerwindowing). • Adressierungsarten direkt, indirekt, immediat, relativ, m-m, m-r und r-r-Transportbefehle. • I/O-Ports haben separaten Adressraum, insb. gibt es Spezialbefehle f¨ ur Zugriff auf I/O-Ports, sogar auf einzelne Bits. • Dichte Instruktionscodierung: 1-3 Bytes/Instruktion. • Mehrere Power-down-Modi.

Es gibt jedoch heute auch Mikrocontrollergenerationen, die eine Wortbreite von 16-64 Bit besitzen. Als Beispiele lassen die die Prozessorfamilien Motorola MC683xx, Siemens x166 und Intel x196 nennen. Die Zielgruppen solcher Mikrocontroller lassen sich wie folgt beschreiben: • Systeme mit h¨oheren Berechnungsanforderungen, z. B. Probleme aus Anwendungsbereichen der Signalverarbeitung und Regelungstechnik, • Systeme mit hohen Datenraten und vielen Datenmanipulationsoperationen, z. B. Anwendungen der Telekommunikation,

1.3. PROZESSOREN

15 IMB inter module bus

serial I/O

time processing unit TPU

IMB control

RAM

CPU32

I/O - channel 0 . . . I/O - channel 15

Abbildung 1.7: Architektur des Motorola MC68322-Prozessors • Systeme mit hohen Datenraten und steuerungsdominanten Aufgaben, z. B. bei der Automobiltechnik. Beispiel 1.5 Als Beispiel wird die Familie MC683xx von Motorola betrachtet. Die CPU besitzt eine Wortbreite von 32-Bit (CPU 32). Die weiteren Eigenschaften lassen sich wie folgt zusammenfassen: • 68000-Prozessor, erweitert durch die meisten der Eigenschaften des 68030. • CISC-Prozessor: erreicht hohe Codedichte! • Fliessbandverarbeitung • Standardregister (nicht in RAM!). Damit ist der Kontextwechsel langsamer als bei den 4-8-Bit Mikrocontrollern. • virtuelles Speichermodell • Benutzer- (User-) und privilegierter (Supervisor-)Programmiermodus; letzte beiden Eigenschaften zielen auf die Benutzung eines Betriebssystems. Abb. 1.7 zeigt als Beispiel die Architektur des MC68332, der auf Anwendungsbereiche zielt, bei denen eine Mischung von berechnungsintensiven Aufgaben und komplexen I/O-Operationen vorliegt. Die dargestellte Einheit TPU (engl. time processing unit) dient dazu, die CPU bei h¨aufigen I/O-Operationen zu entlasten, um die Performanz f¨ ur Berechnungen wegen Kontextwechseln nicht zu erniedrigen. Die TPU besitzt 16 Kan¨ale, die intern aus einem Z¨ahler und einem Komparator (capture & compare) bestehen. Die Z¨ahler k¨onnen u ¨ ber externe Ereignisevents bzw. in konstanten Zeitabst¨anden getriggert werden und generieren beim Nulldurchgang ein Ereignisevent an eine zusatzlich existierende mikroprogrammierte Steuerungseinheit, die zyklisch (Round-robin) alle Kan¨ale u uhrt. Diese k¨onnen einen oder mehrere Kan¨ale ¨ berwacht und I/O-Operationen durchf¨ betreffen. Da die 16 Kan¨ale zyklisch von einer einzigen Steuerungseinheit bedient werden, ergeben sich hohe Latenzen. Zusammenfassend kann die TPU als ein peripherer Coprozessor aufgefasst werden. Die Komponenten kommunizieren u ur I/O¨ ber einen Intermodulbus (IMB). Neben den hohen Latenzen f¨ Operationen besteht eine weitere Schwierigkeit bei peripheren Coprozessoren wie der TPU in deren Programmierung (Codegenerierung) und in der Schwierigkeit, eigene I/O-Funktionen zu definieren. Dies ist beim MC68332 zwar vorgesehen, aber beispielsweise nur u ¨ ber Anschluss von externem RAM m¨oglich.

¨ EINGEBETTETE SYSTEME KAPITEL 1. ARCHITEKTUREN FUR

16

Die Familien MC68332 und Siemens x166 sind Mitglieder von Baukastensystemen, bestehend aus • Modulbus inkl. – Bussystem (Motorola IMB, Siemens X-Bus), nach aussen gef¨ uhrt zur Erweiterung, – Interruptsystem (Vektor, flexible Priorisierung), – Kommunikationsmodell. • Prozessorkern (Cores): 16 Bit, 32 Bit, 64 Bit • Speicherkomponenten: ROM, RAM, EPROM • periphere Einheiten: TPU, SIO, DMA etc. • Coprozessoren, z. B. Fuzzycontrol, Graphik etc. • benutzerdefinierten Standardzell/Gatearray-Bl¨ocken. Jedes Systemhaus bietet unterschiedliche Familien an.

1.3.2

Mikroprozessoren

Beispiele: Power PC, Alpha, P6 etc. Anwendungsgebiete: • Systeme mit hohen Performanzanforderungen (z. B. PCs, Workstations), • Systeme mit hohen Anforderungen an Berechnungen und Datenmanipulationen (z. B. Graphik, Multimedia, Telekommunikation), • Anwendungen mit hohem Mass an Parallelit¨at. Gegen¨ uber bisher beschriebenen Prozessoren besitzen diese Prozessoren folgende Eigenschaften: • Parallelit¨at: mehrere Datenpfade (funktionale Einheiten) und Multiportspeicher (Registerfiles), • Arten der Parallelit¨at: – VLIW (engl. very long instruction word): Starten mehrerer Operationen in einer ¨ Instruktion; speicherintensiv, Arrangierung der Abarbeitung zur Ubersetzerzeit. – superskalar: dyn. Arrangierung nebenl¨aufiger Instruktionen (zur Laufzeit); komplexe Steuerung. – Instruktionspipelining.

Additional Features

+

+ x ÷

Reorder Buffer (6 Entry)

Completion Unit

Integer Unit 2

Integer Unit 1 I

32-Bit

Reservation Station

Reservation Station

2 Instructions

• Time Base Counter/Decrementer • Clock Multiplier • JTAG/COP Interface • Thermal/Power Management • Performance Monitor

MPC750 RISC Microprocessor Technical Summary

Abbildung 1.8: Aufbau eines PowerPC750 DTLB

SRs (Original) DBAT Array

Data MMU

32-Bit

CR

System Register Unit

Reservation Station

PA

Tags

32-Kbyte D Cache

64-Bit

32-Bit

CTR LR

64-Bit

Instruction Fetch Queue

17-Bit L2 Address Bus 64-Bit L2 Data Bus

Data Load Queue

L1 Castout Queue

FPR File

ITLB

SRs (Shadow) Tags

L2 Castout Queue

L2 Tags

L2CR

L2 Controller

Not in the MPC740

FPSCR FPSCR

+ x ÷

Floating-Point Unit

32-Kbyte I Cache

128-Bit (4 Instructions)

Reservation Station

L2 Bus Interface Unit

64-Bit

IBAT Array

Instruction MMU

Rename Buffers (6)

60x Bus Interface Unit

Store Queue

(EA Calculation)

+

Load/Store Unit

Reservation Station (2 Entry)

64-Bit (2 Instructions)

BHT

64 Entry

BTIC

Branch Processing Unit

32-Bit Address Bus 32-/64-Bit Data Bus

EA

Rename Buffers (6)

GPR File

Dispatch Unit

Instruction Queue (6 Word)

Fetcher

Instruction Unit

1.3. PROZESSOREN 17

Figure 1. MPC750 Microprocessor Block Diagram

3

18

¨ EINGEBETTETE SYSTEME KAPITEL 1. ARCHITEKTUREN FUR

Abbildung 1.9: Layout des PowerPC750

1.3. PROZESSOREN

19

Beispiel 1.6 Als Beispiel wollen wir nun exemplarisch den Prozessor PowerPC750 betrachten, dessen Aufbau in Abb. 1.8 beschrieben und dessen Layout in Abb. 1.9 dargestellt ist. Es handelt sich um eine RISC-Architektur. Der Prozessor kann mit Taktfrequenzen von 200266 MHz getaktet werden. Er besitzt eine Versorgungsspannung von 3.3V. Das Befehlsfliessband ist 4-stufig (fetch, decode/dispatch, execute, complete/write back) Die superskalare Architektur besitzt 6 funktionale Einheiten (Branch (BPU), 2 Integer-Einheiten (IUs), 1 Fliesspunkteinheit (FPU), 1 Load-Store-Einheit (LSU) und eine Systemregistereinheit (SRU)). Bis zu 4 Instruktionen k¨onnen gleichzeitig pro Zyklus gefetched werden. Am Layout in Abb. 1.9 erkennt man, dass bei heutigen Prozessoren das Steuerwerk einen betr¨achtlichen Anteil der Chipfl¨ache belegt. Weiterhin ist f¨ ur diese Klasse von Prozessoren typisch, dass die Speicherorganisation hierarchisch ist. So gibt es neben den Registern eine Cache-Hierarchie, die sowohl Instruktions-, als auch Datencache betrifft.

Beispiel 1.7 Als weiteres Beispiel betrachten wir den Prozessor Intel i960. Es handelt sich hier um eine Harvard-Architektur, bei der Daten- und Adressberechnungspfade getrennt sind. Die Wortbreite betr¨agt 32 Bit. Charakteristisch f¨ ur die Ausnutzbarkeit von Befehlsfliessbandverarbeitung sind gleich lange Befehle. Dies ist der Fall bei sog. RISC-Prozessoren (Einwortbefehle). Alle Befehle (ausser Lade- und Speicherbefehl) arbeiten auf Registeroperanden. Der Prozessor besitzt ebenfalls Cache, der auf dem Chip realisiert ist. Zusammenfassend l¨asst sich f¨ ur die vorgestellten High-Performance“-Prozessoren sa” gen, dass sie komplexeste IC-Technologie besitzen bei h¨ochstoptimierter Schaltungsstruktur, wobei der Entwicklungsaufwand heute schon in den Bereich mehrerer 100 Mannjahre geht. Wegen den breiten Anwendungsgebieten ist die Architektur nicht auf spezielle Anwendungsgebiete ausgelegt. Diese hohen Performanz- und Flexibilit¨atsanforderungen verbunden mit der Notwendigkeit, am Rande des technologisch m¨oglichen zu fertigen, sind Quellen f¨ ur eine grosse Anzahl von Entwurfsproblemen und Kosten. Der Einsatz der Prozessoren ist wegen der Gr¨osse auf Platinenentw¨ urfe beschr¨ankt (mehrere hundert Pins). Aus folgenden Gr¨ unden ist der Einsatz beschriebener Mikroprozessoren im Bereich eingebetteter Systeme schwierig bzw. nicht sinnvoll: • Akkurate Analyse des Zeitverhaltens schwierig wegen – Caches, – dynamische Ablaufplanung (Umordnen der Ausf¨ uhrung der Befehle durch den Prozessor), – gleichzeitige Abarbeitung mehrerer Anweisungsbl¨ocke. • Komplexe Interfaces: – hohe Anforderungen an Speichersystem – Caches, Koh¨arenzprotokolle, – Buskommunikationsbandbreite schwer absch¨atzbar.

1.3.3

Anwendungsspezifische Prozessoren (ASIP)

ASIPs besitzen spezielle Instruktionss¨atze, funktionale Einheiten, Register und spezielle Verbindungsstrukturen. Die Spezialisierung f¨ uhrte zu Architekturen, die sich von denen eines Mirkoprozessors stark unterscheidet.

20

¨ EINGEBETTETE SYSTEME KAPITEL 1. ARCHITEKTUREN FUR

ASIPs stellen offensichtlich bez¨ uglich Flexibilit¨at und Performanz die Nahtstelle von der Softwareseite zur Hardwareseite her. Aus Kostengr¨ unden ist ein ASIP oft nur ein abgespeckter“ Prozessor und damit g¨ unstiger als ein Vielzweckprozessor, aber aufgrund ” seiner (wenn auch beschr¨ankten) Programmierbarkeit immer noch flexibler als dedizierte Hardware. Gr¨ unde zur Entwicklung von anwendungsspezifischen Prozessoren (ASIPs) sind damit • Flexibilit¨ at: Allgemein programmierbare Prozessoren sind zu langsam, zu gross, haben zu viele Pins, passen nicht auf einen Chip etc. • Kosten: Sparen von Pins, kleineres Geh¨ause, einfachere Interface- und Speicherarchitektur ausreichend. • Leistungsverbrauch: Mobile Systeme, thermische Probleme,... Die Unterschiede zu allgemein programmierbaren Prozessoren beziehen sich insbesondere auf folgende Merkmale: • Instruktionssatz: – Operatorverkettung (z. B. Multipliziere/Akkumuliere, Vektoroperationen), dadurch weniger Instruktionsfetchzyklen und resultierend h¨ohere Performanz. – Ausnutzung von Parallelit¨at, z. B. nebenl¨aufige Daten- und Adressberechnungen. Dies k¨onnen VLIW und superskalare Maschinen zwar auch, aber hier ist ein geringerer Steuerungsaufwand erforderlich. Folglich erwartet man durch einen spezialisierten Instruktionssatz einen niedrigeren Steuerungsaufwand niedrigere Kosten und h¨ohere Codedichte, allerdings keine Ersparnis im Leistungsverbrauch. • Funktionseinheiten (FUs): – Spezialisierte Funktionen, z. B. Operationen auf Zeichenketten, Pixeloperationen, Verkettung von Operationen (DSP) – Adaption der Wortl¨ange bringt Gewinn in Kosten, Leistungsverbrauch, Programmausf¨ uhrungszeit, allerdings kann m¨oglicherweise die Zykluszeit einer Instruktion gr¨osser werden. • Speicherstruktur: – Anzahl und Gr¨osse der Speicherb¨anke, – Anzahl und Wortbreite der Speicherports, – Zugriffsarten (nx read, mx write, read-modify-write, page mode etc.), – Funktion (RAM, FIFO etc.) Der Gewinn zeichnet sich hier in den Kosten (Fl¨ache), in h¨oherer Parallelit¨at und dadurch h¨oherem Leistungsverbrauch aus. • Verbindungsstruktur: – optimierter Datenpfad mit reduzierter Verbindungsstruktur

1.3. PROZESSOREN

21

– Spezialregister (MUL/ACC, Zwischenergebnisse) Der Einfluss betrifft die Komplexit¨at der Verdrahtung und Steuerung und die Zykluszeit von Instruktionen. • Steuerwerk: – Fliessbandverarbeitung, – spekulative Ausf¨ uhrung, – Mikroprogrammiertes Steuerwerk oder FSM.

1.3.4

Digitale Signalprozessoren – DSPs

Zu der Klasse anwendungsspezifischer Prozessoren geh¨ort die Klasse der digitalen Signalprozessoren – DSPs. Die Anwendungsgebiete sind Bereiche bei • Dominanz von Datenfluss, • komplexen, regelm¨assigen arithmetischen Operationen auf Feldern, z. B. Filter, FFT, Matrizenoperationen, • hoher Nebenl¨aufigkeit, • speziellen Adressiersequenzen, z. B. linear (a1 x1 + a2 xs + · · · + an xn ), modulo, bitrevers. Deren wesentliche Merkmale von DSPs lassen sich stichpunktartig wie folgt zusammenfassen: • Festpunkt- und Fliesspunktarithmetik, • Wortl¨angen 16-64 Bit, • Leistungsverbrauch mW...W, • spezielle Speicher- und Busstruktur • Mehrprozessorsysteme und Architekturen mit Coprozessoren. Beispiele f¨ ur k¨aufliche Signalprozessoren sind ADSP21060 (Analog Devices), TMS320 C80 (Texas Instruments), Motorola M56000 (Festpunkt) und M96000 (Fliesspunkt). Die ersten beiden sind sehr unterschiedliche Architekturen, die jedoch die wesentlichen f¨ ur DSPs typischen Architekturmerkmale besitzen. Beispiel 1.8 Als Beispiel wird der Signalprozessor ADSP21060 (SHARC) von Analog Devices betrachtet. Es handelt sich um eine Load-Store-Architektur mit einer 32-Bit Fliesspunkt-ALU (siehe Abb. 1.10). Das Operationswerk (links) besitzt 3 parallele Einheiten: eine ALU, eine Schiebeeinheit (MultiBit) und eine Multipliziereinheit. Die entsprechenden Befehle des Instruktionssatzes sind EinZyklen-Befehle. Die Prozessorfrequenz betr¨agt nach Hersteller 40 MHz. Weiterhin unterst¨ utzt der Instruktionssatz spezielle Instruktionen, z. B. zur Betragsbildung. In einer Instruktion k¨onnen mehrere nebenl¨aufige Operationen initiiert werden. An Datenregistern liegen zwei B¨anke mit jeweils

22

¨ EINGEBETTETE SYSTEME KAPITEL 1. ARCHITEKTUREN FUR

Abbildung 1.10: Signalprozessor ADSP21060 (SHARC) 16 40-Bit-Registern (interne Wortbreite) vor. Die zweite Bank kann z. B. bei einem Kontextwechsel zwischen zwei Tasks eingesetzt werden. Spezielle Befehle zur Schleifenabarbeitung werden im Programmsequenzer unterst¨ utzt, insb. von geschachtelten Schleifen. Der kleine Instruktionscache mit 32 Eintr¨agen l¨asst auch darauf schliessen, dass die Abarbeitung von Bl¨ocken bestehend aus einzelnen Instruktionen beschleunigt werden soll, damit performanzsteigernd bei kleinen, h¨aufig iterierte Schleifen wirkt. Es existieren zwei unabh¨angige Adressgenerierungseinheiten. Das Speichersystem besteht aus einem grossen Zwei-Port-Speicher, organisiert in zwei B¨anken, was typisch f¨ ur DSP-Prozessoren ist. Der erste Port wird u ur Daten- und Adressbus gemultiplext. Der zweite Port ist ¨ ber einen Crossbar-Switch f¨ exklusiv f¨ ur den dargestellten I/O-Prozessor reserviert. Desweiteren besitzt der SHARC-Prozessor 6 4-Bit-Link Ports, die eine Daten¨ ubertragung zu 6 mit einem Prozessor verbindbaren anderen gleichartigen Prozessoren mit einer Datenrate von 40 MBytes/s pro Kanal erlauben. Damit lassen sich Punkt-zu-Punkt-Verbindungen erzeugen. Alle Instruktionen sind 48-Bit W¨orter, wobei wie bereits angedeutet, in einer Instruktion max. 3 parallele Operationen initiiert werden k¨onnen. Schliesslich besitzt der Prozessor auch u ¨ ber eine komplexe DMA-Einheit. Der Aufbau des I/O-Prozessors zielt folglich auf die Beschleunigung von Speicherund Datentransferoperationen.

Als weiteres Beispiel wird der Prozessor TMS320C80 von Texas Instruments betrachtet. Beispiel 1.9 Beim Prozessor TMS320C80 von Texas Instruments handelt es sich um eine Mehrprozessorarchitektur mit 4 32-Bit Festpunkt-Prozessoren und einem 32-Bit Fliesspunktprozessor (Master DSP) auf einem Chip, siehe Abb. 1.11. Die Speicherarchitektur ist ¨ausserst komplex (lokale Register in den DSPs, 4x2 KBytes RAM-B¨anke (512 Worte/Bank), 2 KBytes Instruktionscache pro Prozessor (256 Worte)). Damit existiert gegen¨ uber dem SHARC eine h¨ohere Nebenl¨aufigkeit im Speicherzugriff, allerdings ist der Speicher viel kleiner. Zur Verbindung der Prozessoren existiert ein nahezu vollst¨andiger Crossbar-Switch. Dieser reduziert Kommunikationsbeschr¨ankungen und Zugriffskonflikte des Shared Memories. Dadurch

1.3. PROZESSOREN

23

Abbildung 1.11: Aufbau eines TMS320C80 (MVP) von Texas Instruments

Abbildung 1.12: Datenpfad des TMS320C80

¨ EINGEBETTETE SYSTEME KAPITEL 1. ARCHITEKTUREN FUR

24

soll eine hohe interne Speicher- und Kommunikationsbandbreite erreicht, was offensichtlich das unt¨atige Warten der DSPs auf Daten verhindern soll. Als Controller dient ein 32-Bit RISC-Fliesspunktprozessor. Die 4 Festpunktprozessoren (Advanced DSP) besitzen folgende Eigenschaften (siehe Abb. 1.12): • Multiplizierer, Schiebeeinheit, ALU mit 3 Eing¨angen, die in kleinere 8-Bit Einheiten aufgespalten werden kann. • Unterst¨ utzung spezieller Operationen auf Bitebene (u. a. Pixelexpander), • 2 Adress-ALUs f¨ ur Indexberechnungen, • Instruktionswortbreite 64 Bit (horizontal) f¨ ur parallele Datenoperation, Datentransfer und einen globalen Datentransfer. Gebaut wurde der Prozessor f¨ ur Video- und Multimediaapplikationen. Die Architektur erlaubt die beschleunigte Ausf¨ uhrung vor allem kleiner (256 Worte), berechnungsintensiver Programme auf kleinen Datenbereichen bei einfachen Operationen.

1.4 1.4.1

Hardwareimplementierungen ASIC-Entwurf

Hierzu geh¨oren der vollkundenspezifische Entwurf integrierter Schaltungen, bei dem die Schaltung bis auf das Layout vom Entwerfer gestaltet wird. Desweiteren geh¨ort dazu der Standardzellenentwurf, der vom Fertigungsaufwand gleichsam aufwendig ist wie der vollkundenspezifische Entwurf. Jedoch ist der Entwurfsprozess dahingehend einfacher, dass f¨ ur verwendetete elementare Gatter Bibliotheken mit Standardzellenlayouts vorliegen, die dann plaziert und verdrahtet werden m¨ ussen. Beide Entwurfstypen sind aus Kostengr¨ unden nur bei hohen St¨ uckzahlen empfehlenswert. Jedoch gibt es auch ASICs, die bereits eine vorgefertigte Halbleiterstruktur besitzen und bei der Fertigung nur noch die Verdrahtung der Zellen untereinander als Fertigungsschritt zu vollziehen ist. Hierzu geh¨oren beispielsweise Gatearrays und Sea-of-Gates. Bei ersten liegen vorgefertigte Zellen in Reihen fest, die durch dedizierte Verdrahtungskan¨ale miteinander verdrahtet werden k¨onnen. Bei letzteren verr¨at der Name bereits, dass hier auch Zellen als Verdrahtungszellen zwischen Gates konfiguriert werden k¨onnen. Aufgrund der Vorfertigung ist die Fl¨achenausbeute bei diesen Typen von ASICs verst¨andlicherweise geringer als beim vollkundenspezifischen Entwurf. Beispiel 1.10 Als weiteres Beispiel zeigt Abb. 1.13 ein Ein-Chip-System, bei dem ein Mikrocontroller mit einer kundenspezifischen Gatearray-Schaltung (siehe oben) u ¨ ber einen chipinternen Bus verbunden ist. Das System C167 der Firma Siemens stellt einen Chip zur Motorregelung dar.

Beispiel 1.11 Abbildung 1.14 zeigt ein Ein-Chip-System der Firma Motorola. Es handelt sich um einen Rastergraphikprozessor, der einen MC68332 als Makrozelle in einem Standardzellentwurf integriert. Andere Beispiele von eingebetteten Ein-Chip-Systemen, bei denen ein Standardprozessor anwendungsspezifische Hardware eingesetzt wird, sind Prozessoren f¨ ur Laserdrucker (z. B. Motorola Flexcore) oder PCMCIA-Controller Chips (z. B. SUNDISK).

1.4. HARDWAREIMPLEMENTIERUNGEN

Abbildung 1.13: C167-Mikrocontroller mit kundenspezifischem Gatearray

25

26

¨ EINGEBETTETE SYSTEME KAPITEL 1. ARCHITEKTUREN FUR

Abbildung 1.14: Rastergraphikprozessor mit Standardzellenentwurf und MC68322Prozessor

1.4. HARDWAREIMPLEMENTIERUNGEN

27

Abbildung 1.15: Aufbau eines FPGA (Xilinx)

1.4.2

Programmierbare Hardware

Hierzu geh¨oren u. a. FPGAs (engl. field programmable gate arrays), und PLAs (engl. programmable logic arrays). W¨ahrend PLAs nur Boolesche Funktionen einer bestimmten Form (zweistufige Form) implementieren k¨onnen, kann man mit FPGAs auch Speicherzellen realisieren. FPGAs eignen sich dazu hervorragend, Steuerwerke (FSMs) zu realisieren. Abbildung 1.15 zeigt den prinzipiellen Aufbau eines Xilinx FPGA (XC4005PG156). Realisiert k¨onnen 5000 Gatter¨aquivalente. Das FPGA wird durch einen Strom von Daten konfiguriert. Dies kann auf unterschiedliche Art erfolgen. Ferner gibt es eine Funktion, mit der man den inneren Zustand s¨amtlicher Speicherzellen des FPGA auslesen kann (sog. Readback-Funktion). Der beschriebene Baustein besitzt 112 I/O-Pins und 196 (14x14) Logikbl¨ocke (sog. CLBs), siehe Abb. 1.16. Insgesamt k¨onnen 6272 Bit RAM gebraucht werden und 616 Flipflops realisiert werden. Ein CLB kann jede Boolesche Funktion von 5 Eing¨angen bzw. 2 Boolesche Funktionen von 4 Eing¨angen implementieren. IOBs (siehe Abb. 1.17) sind spezielle Bl¨ocke, die das Ein- und Auslesen von Registerwerten u ¨ber die Pins von bzw. nach aussen erm¨oglichen. Auch diese k¨onnen in ihrer Funktion (Richtung, Modus) konfiguriert werden. F¨ ur das Plazieren und Verdrahten einer Netzliste auf einem FPGA gibt es spezielle Software, die als Eingabe die Netzliste nimmt und als Ergebnis dis Konfigurationsdatei ausgibt, die seriell in das FPGA eingelesen wird und die Zellen konfiguriert. Heutzutage gibt es FPGAs mit mehreren 100 000 Gatter¨aquivalenten.

28

¨ EINGEBETTETE SYSTEME KAPITEL 1. ARCHITEKTUREN FUR

Abbildung 1.16: CLB

Abbildung 1.17: Aufbau eines IOBs

1.4. HARDWAREIMPLEMENTIERUNGEN

29

Die Einsatzgebiete von FPGAs im Bereich des Entwurfs komplexer eingebetteter Systeme l¨asst sich wie folgt zusammenfassen: • Applikationsgebiete, bei denen – Entwurfszeit hohe Priorit¨at hat, – Softwarel¨osungen nicht die erforderliche Performanz haben, – ASIC-L¨osungen aufgrund der Kosten nicht geeignet sind (St¨ uckzahl!), – Gr¨osse und Leistungsverbrauch zweitrangig sind, ¨ – Flexibilit¨at wichtig ist (f¨ ur sp¨ate Anderungen, Anpassungen an andere Systeme, Erweiterung der Funktionalit¨at) • Der Einsatz ist damit zur Realisierung einer kleinen Teilmenge von Systemfunktionen berechtigt, die einen Hardwareeinsatz bei hoher Flexibilit¨at erfordern.

30

¨ EINGEBETTETE SYSTEME KAPITEL 1. ARCHITEKTUREN FUR

Kapitel 2

Entwurfsmethodik Dieses erste Kapitel dient dazu, die Vorlesung in unterschiedlicher Art und Weise einzubetten. Abschnitt 2.1 enth¨alt eine historische und inhaltliche Einbettung, die den Systementwurf, so wie er hier verstanden wird, in die heutige Praxis einbettet. Der folgende Abschnitt 2.2 dient der Erl¨auterung der wesentlichen Grundbegriffe: Abstraktion und Entwurfsrepr¨asentationen. In Abschnitt wird dann eine Einbettung in die sonstigen Lehrveranstaltungen des Instituts f¨ ur Technische Informatik und Kommunikationsnetze angeschlossen.

2.1 2.1.1

Entwurfsmethodik Erfassen und simulieren

Bis heute werden die meisten integrierten Schaltungen auf der Basis einer Entwurfsmethodik entworfen, die sich aus den beiden Hauptkomponenten Erfassen und Simulieren“ ” zusammensetzt. Man startet mit einer informalen, umgangssprachlichen Spezifikation des Produktes, die noch keine Informationen u ¨ber die konkrete Implementierung enth¨alt. Es wird also nur die Funktionalit¨at bestimmt, aber nicht die Art und Weise ihrer Realisierung. Anschliessend wird dann eine grobe Blockstruktur der Architektur entworfen, die eine verfeinerte, aber immer noch unvollst¨andige Spezifikation des Gesamtsystems darstellt. In weiteren Verfeinerungsschritten werden die einzelnen Bl¨ocke dann in Logik- oder sogar Transistor-Diagramme umgesetzt und in entsprechende Software-Systeme eingegeben. Auf dieser Basis lassen sich dann umfangreiche Simulationen der Funktionalit¨at und des Zeitverhaltens sowie Untersuchungen der Testbarkeit durchf¨ uhren. Diese erfassten Diagramme dienen zudem m¨oglicherweise dazu, Zellen auf physikalischer Ebene zu plazieren und miteinander zu verdrahten oder auch das Layout einer integrierten Schaltung automatisch zu generieren. Dieser Ansatz des Erfassens und Simulierens“ wird nicht nur im Bereich des Hardware” Entwurfs sondern auch bei der Programmierung von Mikroprozessorsystemen, also beim Software-Entwurf, eingesetzt. Eine informale Spezifikation wird in Blockstrukturen und anschliessend in Assembler-Programme verfeinert. Es folgen Simulationen und Emulationen zur Validierung von Funktionalit¨at und Zeitverhalten, bevor das endg¨ ultige Programm in Maschinensprache generiert wird. 31

32

KAPITEL 2. ENTWURFSMETHODIK

2.1.2

Beschreiben und synthetisieren

In den letzten Jahren wurde die Logik-Synthese integraler Teil der Entwurfsmethodik von Hardware-Systemen. Ein Entwurf wird hier bez¨ uglich seines Verhaltens in einer simulierbaren, das heisst ausf¨ uhrbaren Beschreibungssprache spezifiziert; so kann man zum Beispiel ein Steuerungssystem durch Boolesche Gleichungen und Zustandsdiagramme beschreiben. Die Struktur der Implementierung wird dann automatisch durch entsprechende Syntheseverfahren generiert, im Vergleich zum Hand-Entwurf eine sehr viel schnellere und vor allem sichere Entwurfsart. Dieser Weg des Beschreibens und Synthetisierens“ kann nun bei verschiedenen Teil” problemen eines gesamten Entwurfs durchgef¨ uhrt werden. Auf der Logik-Ebene werden funktionale Einheiten (z.B. ALUs, Vergleicher, Multiplizierer) und Steuerungseinheiten (z.B. Zustandsmaschinen) durch die Logiksynthese automatisch generiert. Hierzu geh¨oren Verfahren zur Minimierung Boolescher Ausdr¨ ucke, Zustandsminimierungen und die Technologie-Abbildung, d.h. Implementierung der minimierten Funktionen mit Gattern aus einer speziellen Entwurfsbibliothek. Ein anderes Beispiel ist die Architektur-Synthese. Hier k¨onnen integrierte Schaltungen synthetisiert werden, die aus Speicherbausteinen, Steuerungslogik und funktionalen Bausteinen bestehen. Das Verhalten dieser Prozessoren kann durch Algorithmen, Flussdiagramme, Datenflussgraphen, Instruktions-S¨atze oder auch durch verallgemeinerte Zustandsmaschinen beschrieben werden, bei denen mit jedem Zustand eine beliebig komplexe Berechnung verbunden sein kann. Die Transformation in eine strukturelle Beschreibung erfolgt anschliessend durch die drei Syntheseaufgaben Allokation, Ablaufplanung und Bindung. • Aufgabe der Allokation ist es, die Zahl und Art der Komponenten zu bestimmen, die in der Implementierung verwendet werden sollen, also zum Beispiel die Zahl der Register und Speicherb¨anke, die Zahl und Arten der internen Busse zur Datenkommunikation sowie die verwendeten funktionalen Einheiten, wie Multiplizierer oder ALUs. Daher ist die Allokation auch wesentlich mit der Balancierung von Kosten gegen¨ uber Leistungsf¨ahigkeit der Schaltung befasst. • Die Ablaufplanung teilt dem spezifizierten Verhalten Zeitintervalle zu, so dass anschliessend in jedem Zeitschritt bekannt ist, welche Daten von einem Register zu einem anderen transportiert werden und wie sie dabei von den funktionalen Einheiten transformiert werden. • Die Bindung ordnet abschliessend jeder Variablen eine entsprechende Speicherzelle, jeder Operation eine funktionale Einheit und jeder Datenkommunikation einen Bus oder eine Verbindungsleitung zu. Auch hier wieder gibt es eine direkte Parallelit¨at zum Software-Entwurf. Im Gegensatz zum Erfassen und Simulieren“ wird die Funktionalit¨at des Systems durch eine ab” ¨ lauff¨ahige Hochsprache spezifiziert, z.B. C, C++, Oberon. Aufgabe des Ubersetzers ist dann die automatische Generierung des Maschinenprogramms. Wenn es sich um eine parallele Zielarchitektur handelt, sind wiederum die drei wesentlichen Aufgaben der Allo¨ kation, Ablaufplanung und Bindung bei der Ubersetzung auszuf¨ uhren. Auch wenn beim Software-Entwurf die Zielarchitektur im allgemeinen gegeben ist, sind in beiden F¨allen fast die gleichen Ablaufplanungs-, Bindungs- und Optimierungs-Problemstellungen zu l¨osen.

2.1. ENTWURFSMETHODIK

33

¨ So sind auch bei der Software-Ubersetzung die Operationen und Datentransporte Zeitschritten zuzuordnen unter Ber¨ ucksichtigung der zur Verf¨ ugung stehenden Ressourcen, wie Busbandbreite, Zahl der Busse, Zahl der internen Register, Speicherbedarf und Zahl und Art der parallelen arithmetische Einheiten. Ziel der Bindung ist dann auch hier, die Variablen, Operationen und Datentransporte den vorhandenen physikalischen Einheiten ¨ zuzuordnen. Diese Verfahren werden vor allem in Ubersetzern f¨ ur die heutigen superscalaren RISC-Prozessoren (z.B. PowerPC, Alpha-Prozessor), f¨ ur VLIW-Rechner (Very Long Instruction Word) oder auch f¨ ur Signalprozessoren eingesetzt, da sie alle durch interne Parallel- und Fliessbandverarbeitung (Pipelining) ausgezeichnet sind.

2.1.3

Spezifizieren, explorieren und verfeinern

Auf der Ebene komplexer Systeme ist die Entwurfsmethodik bei weitem noch nicht so ausgereift wie in den bisher beschriebenen Bereichen. Dennoch scheint sich hier ein Paradigma durchzusetzen, das durch die Stichworte spezifizieren, explorieren und verfeinern“ ” beschrieben werden kann. In der Spezifikationsphase wird in einem sehr fr¨ uhen Stadium des Entwurfsprozesses eine ausf¨ uhrbare Spezifikation des Gesamtsystems erstellt. Sie ist Ausgangspunkt und Grundlage f¨ ur • die Beschreibung der Funktionalit¨at eines Systems (z.B. um die Wettbewerbsf¨ahigkeit eines Produktes abzusch¨atzen), • die Dokumentation des Entwurfsprozesses in allen Schritten, • die automatische Verifikation kritischer Systemeigenschaften, • die Untersuchung und Exploration verschiedener Realisierungsalternativen, • die Synthese der Teilsysteme und • die Ver¨anderung und Nutzung bereits bestehender Entw¨ urfe. Die Explorationsphase dient dazu, verschiedene Realisierungsalternativen bez¨ uglich Ihrer Kosten und Leistungsf¨ahigkeit miteinander zu vergleichen. Wesentliche Aufgabe ist es hier, die Systemfunktionen auf m¨ogliche Komponenten eines heterogenen Systems zu verteilen. Diese Teilsysteme k¨onnen nun anwendungsspezifische integrierte Schaltungen, vorgefertigte Mikroprozessoren aber auch vorhandene Spezialbausteine sein. Da jede neue Partitionierungsvariante einer unterschiedlichen Systemrealisierung entspricht, verlangt die Bewertung eine Voraussch¨atzung wesentlicher Eigenschaften, wie Verarbeitungsleistung, Kosten, Leistungsverbrauch und Testbarkeit. In der anschliessenden Verfeinerungsphase wird die Spezifikation entsprechend der Partitionierung und Allokation auf die verschiedenen Hardware- und Softwarekomponenten verteilt und die korrekte Kommunikation zwischen diesen Einheiten sichergestellt. Die Ausgangslage ist also vergleichbar mit der nach der Bestimmung eines Block-Diagramms auf der Grundlage einer informalen Spezifikation, siehe Abschnitt 2.1.1. Im Unterschied dazu wurde diese Aufteilung aber nach der Exploration eines grossen Entwurfsraumes erhalten und die Verfeinerung steht auf sicheren F¨ ussen“, da sie formal aus der gegebenen ” Spezifikation abgeleitet wurde. In weiteren Verfeinerungsschritten kann dann der gesamte Prozess der Exploration und Verfeinerung“ wiederholt werden, bis eine vollst¨andig ” strukturelle Beschreibung zur Implementierung des Systems vorliegt. Durch eine solches

34

KAPITEL 2. ENTWURFSMETHODIK

Software

Hardware

System

Modul

Architektur

Verhalten

... Block

Logik

Struktur

Abbildung 2.1: Graphische Darstellung einiger wichtiger Abstraktionsebenen und Sichten beim Systementwurf Vorgehen werden nicht nur fr¨ uhzeitig m¨ogliche Entwurfsalternativen (z.B. Software statt Hardware, anwendungsspezifische Schaltungen statt Standardkomponenten) gepr¨ uft sondern es entfallen auch teure und zeitraubende Entwurfsiterationen.

2.2

Abstraktion und Entwurfsrepr¨ asentationen

Die folgenden Abschnitte enthalten eine kurze Darstellung der verschiedenen Abstraktionsebenen und Sichten eines Systems sowie eine Klassifizierung der Synthese und Optimierungsaufgaben beim Systementwurf.

2.2.1

Modelle

Unter einem Modell versteht man die formale Beschreibung eines Systems oder Teilsystems. Hierbei wird das zu modellierende Objekt unter einem ganz bestimmten Blickwinkel“ be” trachtet, dass heisst es werden nur bestimmte Eigenschaften ohne die zugeh¨origen Details gezeigt. Diesen Vorgang nennt man Abstraktion. Die vorangegangene Abschnitte sollten deutlich gemacht haben, das der Entwurf eines Systems auf dem Prinzip der Verfeinerung beruht: Der Grad an Detailliertheit wird beim Entwurf schrittweise erh¨oht. Man kann also Modelle anhand des Grades Ihrer Verfeinerung nach Abstraktionsebenen klassifizieren. Auf der anderen Seite gibt es aber auch unterschiedliche Sichten eines Objektes. So kann man eine Schaltung als Verbindung von Einzelkomponenten betrachten oder auch als eine Einheit mit bestimmtem Verhalten. Abstraktionsebenen und Sichten sind in gewisser Weise orthogonal zueinander. Obwohl man nat¨ urlich (fast) beliebig viele Schichten an Sichten und Abstraktion einf¨ uhren kann, werden wir uns im Rahmen der Vorlesung vor allem mit den Abstraktionsebenen Architektur und Logik beim Hardware-Entwurf, Modul und Block beim SoftwareEntwurf und System beim Entwurf heterogener Systeme sowie mit den Sichten Verhalten und Struktur auseinandersetzen, siehe auch die graphische Darstellung in Bild 2.1.

¨ 2.2. ABSTRAKTION UND ENTWURFSREPRASENTATIONEN

35

Die folgende Aufstellung soll die unterschiedlichen Abstraktionsebenen stichwortartig beschreiben: System : Die Modelle der System-Ebene beschreiben das zu entwerfende Gesamtsystem auf der Ebene von Netzwerken aus komplexen, miteinander kommunizierenden Teilsystemen. Architektur : Die Architektur-Ebene geh¨ort zum Bereich des Hardware-Entwurfs. Modelle auf dieser Ebene beschreiben kommunizierende funktionale Bl¨ocke, die komplexe Operationen ausf¨ uhren. Logik : Die Logik-Ebene geh¨ort ebenfalls zum Hardware-Bereich. Die Modelle dieser Ebene beschreiben verbundene Gatter und Register, die Boolesche Funktionen berechnen. Modul : Die Modul-Ebene geh¨ort zum Software-Bereich. Die entsprechenden Modelle beschreiben Funktion und Interaktion komplexer Module. Block : Die Block-Ebene geh¨ort ebenfalls zum Software-Bereich. Die entsprechenden Modelle beschreiben Programme bis hin zu Instruktionen, die auf der zugrundeliegenden Rechnerarchitektur elementare Operationen ausf¨ uhren. Neben dieser Klassifizierung von Modellen nach ihrem Grad der Abstraktion unterscheidet man zudem verschiedene Sichten innerhalb einer Abstraktionsebene. Verhalten : In der Verhaltens-Sicht werden Funktionen unabh¨angig von ihrer konkreten Implementierung beschrieben. Struktur : In der strukturellen Sicht hingegen werden kommunizierende Komponenten beschrieben. Die Aufteilung und Kommunikation entsprechen der tats¨achlichen Implementierung. Anhand dieser Klassifizierung l¨asst sich (sehr vereinfacht dargestellt) der Entwurf eines komplexen Systems als Abfolge von Verfeinerungsschritten verstehen, bei denen einer Verhaltensbeschreibung strukturelle Informationen u ugt wer¨ber die Implementierung zugef¨ den und die entstehenden Teilmodule dann wieder Ausgangspunkte von Verfeinerungen auf der nachst niedrigeren Abstraktionsebene sind, siehe auch Bild 2.1. Bei dieser Darstellung wird allerdings stark vereinfachend ausser Acht gelassen, dass bei einem konkreten Entwurf viele Iterationen zwischen den Abstraktionsebenen notwendig werden, also nicht nur top down“, sondern auch bottom up“ in den Abstraktionsebenen ” ” vorgegangen wird. Einige Systemteile werden zudem direkt auf unteren Abstraktionsebenen entworfen, so dass zu einem bestimmten Zeitpunkt im Entwurfsprozess nicht alle Systemteile den gleichen Abstraktions- oder Verfeinerungsgrad aufweisen. Aufgabe der Synthese ist nun die (teil)-automatische Transformation zwischen den verschiedenen Abstraktionsebenen und Sichten. Um die Zusammenh¨ange etwas deutlicher zu machen, sollen nun anhand von Synthesebeispielen zumindest einige der besprochenen Ebenen und Sichten n¨aher erl¨autert werden.

36

KAPITEL 2. ENTWURFSMETHODIK

2.2.2

Synthese

2.2.2.1 Architektur-Synthese Aufgabe der Synthese auf Architektur-Ebene ist es, eine strukturelle Sicht aus einer Verhaltensbeschreibung zu generieren. Demzufolge wird hier der Grad der Parallelit¨at von Operationen bestimmt. Wesentliche Aufgaben sind (siehe Abschnitt 2.1.2) • Identifikation von Hardware-Elementen, die die spezifizierten Operationen ausf¨ uhren k¨onnen (Allokation), • Ablaufplanung zur Bestimmung der Zeitpunkte, an denen die Operationen ausgef¨ uhrt werden, • Zuordnung von Variablen zu Speichern, Operationen zu funktionalen Einheiten und Kommunikationskan¨ale zu Bussen (Bindung). Die makroskopischen Eigenschaften, wie Schaltungsfl¨ache und Verarbeitungsleistung h¨angen wesentlich von der Optimierung auf dieser Abstraktionsebene ab. Beispiel 2.1 Das folgende Beispiel soll eine Schaltung modellieren, die eine Differentialgleichung der Form y 00 + 3xy 0 + 3y = 0 im Intervall [x, a] mit der Schrittweite dx und Anfangswerten y(0) = y, y 0 (0) = u mit Hilfe der Euler-Methode numerisch l¨ost. Eine Verhaltensspezifikation in einer Beschreibungssprache (hier VHDL) w¨ urde etwa folgendermassen aussehen: ENTITY dgl IS PORT(x_in,y_in,u_in,dx_in,a_in: IN REAL; activate: IN BIT; y_out: OUT REAL); END dgl; ARCHITECTURE behavioral OF dgl IS BEGIN PROCESS (activate) VARIABLE x, y, u, dx, a, x1, u1, y1: REAL; BEGIN x := x_in; y := y_in; u := u_in; dx := dx_in; a := a_in; LOOP x1 := x + dx; u1 := u - (3 * x * u * dx) - (3 * y * dx); y1 := y + (u * dx); x := x1; u := u1; y:= y1; EXIT WHEN x1 > a; END LOOP; y_out zero state τ (vi ) > t − wi } Dann erfolgt die Ablaufplanung: F¨ ur jeden Ressourcetyp k wird basierend auf der festgelegten Priorit¨atsliste der Operationen, beschreibbar durch eine Funktion p : VS → Z+ , eine Menge St an Operationen aus der Kandidatenmenge Ut,k mit maximaler Priorit¨at ausgew¨ahlt und geplant. Dabei kann St maximal so viele Operationen enthalten, wie es die Ressourcenbeschr¨ankung |St |+ |Tt,k | ≤ α(vk ) erlaubt. Der ganze Algorithmus l¨asst sich damit wie folgt formulieren:

4.3. ALGORITHMEN ZUR ABLAUFPLANUNG

91

LIST(GS (VS , ES ),GR (VR , ER ),a,p){ t := 1; REPEAT { FOR k=1 to |VR | { Bestimme Kandidatenmenge Ut,k ; Bestimme Menge nicht beendeter Operationen Tt,k ; W¨ahle eine Menge maximaler Priorit¨at St ⊆ Ut,k : |St | + |Tt,k | ≤ α(vk ) τ (vi ) := t ∀i : vi ∈ St ; } t := t + 1; } UNTIL (vn geplant); RETURN (τ ); } Die Berechnungskomplexit¨at dieses Algorithmus ist O(|VS |). Der Algorithmus konstruiert einen Ablaufplan, der per definition die Ressourcebeschr¨ankungen erf¨ ullt. Das heuristische Dringlichkeitsmass wird statisch vor Ablauf des Algorithmus bestimmt. Beispiel 4.13 Wir betrachten erneut den Ablaufplan in Abb. 4.1. Der Ressourcegraph zur Modellierung der Ressourcebeschr¨ankungen wurde in Beispiel 4.2 beschrieben und ist in Abb. 4.3 dargestellt. Es gibt zwei Ressourcetypen (r1 : Multiplizierer, r2 : ALU (Addierer, Subtrahierer und Vergleichsbildung)) mit α(r1 ) = 1, α(r2 ) = 1 allozierten Ressourcen. Die in Abb. 4.2 dargestellte Ablaufplanung entspricht der durch Listscheduling berechneten Ablaufplanung mit der durch den l¨angsten Pfad bestimmten Priorit¨atsliste p(v1 ) = p(v2 ) = 4, p(v3 ) = p(v6 ) = 3, p(v4 ) = p(v7 ) = p(v8 ) = p(v10 ) = 2 und p(v5 ) = p(v9 ) = p(v11 ) = 1. In diesem Beispiel gilt Tt,k = 0 ∀t, k, weil wi = 1 ∀vi ∈ VS . Die erzielte Latenz ist in diesem Fall optimal. Um zu zeigen, dass es bereits einfache Beispiele gibt, bei denen Listscheduling suboptimale L¨osungen erzeugt, wollen wir ein weiteres Beispiel anf¨ ugen. Beispiel 4.14 Wir betrachten den Sequenzgraph in Abb. 4.11a und den zugeh¨origen Ressourcegraphen in Abb. 4.11b mit der Allokation α(r1 ) = 1, α(r2 ) = 1. In Abb. 4.12a sehen wir den mit Listscheduling gefundenen Ablaufplan. Abb. 4.12b zeigt, dass es einen Ablaufplan gibt, der eine um einen Zeitschritt geringere Latenz aufweist. Man kann zeigen, dass der Listschedulingalgorithmus exakt ist, wenn der Sequenzgraph (nach Streichen des Anfangsknotens) ein Baum ist und alle Berechnungszeiten 1 sind. Force Directed Scheduling Force Directed Scheduling [28] stellt eine Erweiterung des Verfahrens Listscheduling dar. Es handelt sich auch um ein Verfahren, dass iterativ konstruktiv einen Ablaufplan erzeugt. Das Dringlichkeitsmass der Planung einer Operation wird hier allerdings nicht statisch vor Beginn des Verfahrens bestimmt, sondern wird dynamisch in jedem Schritt auf den Stand des bisher aufgebauten Ablaufplans angepasst, was i.a. zu verbesserten Ergebnissen der Ablaufplanung f¨ uhrt. Die Entscheidung der Planung einer Operation in einem Zeitschritt wird durch Berechnung von Kr¨ aften entschieden. Kr¨afte zwingen Operationen in gewisse Schritte. Um uns nun n¨aher mit dem Verfahren besch¨aftigen zu k¨onnen, definieren wir einige Gr¨ossen, die im Verfahren berechnet werden:

92

KAPITEL 4. SYNTHESE a) G

NOP 0

b) G

S 1

R 1

2

1 4 3

1 1

r 1

2

r

5 4

2

2

2

α (r1)=1

α (r2)=1

3 5

NOP

n

Abbildung 4.11: Sequenzgraph und Ressourcegraph aus Beispiel 4.14. 1. Mobilit¨atsintervall einer Operation vi ∈ VS : [τ (vi )S , τ (vi )L ] 2. Ausf¨ uhrungswahrscheinlichkeit pi,t einer Operation vi ∈ VS : (

pi,t =

1 µ(vi )+1

0

∀t ∈ [τ (vi )S , τ (vi )L ] sonst

mit der Mobilit¨at µ(vi ) = τ (vi )L − τ (vi )S . 3. Belegung qk,t des Ressourcetyps rk zum Zeitpunkt t: Hierzu werden zu jedem Zeitschritt t die Ausf¨ uhrungswahrscheinlichkeiten der Operationen addiert, die durch eine Ressource des Typs rk ausgef¨ uhrt werden k¨onnen, d.h. qk,t =

X

pi,t

∀i:(vi ,rk )∈ER

Diese Verteilung kann in einem Belegungsgraphen dargestellt werden, siehe Beispiel 4.15. Beispiel 4.15 Wir betrachten erneut den Sequenzgraphen in Abb. 4.1 mit dem Ressour¯ = 4 (aus ASAP- und ALAPcegraphen in Abb. 4.3. Mit einer Latenzschranke von L Ablaufplanung) haben wir die Mobilit¨aten der Operationen in Beispiel 4.7 ermittelt. Zum Beispiel ist die Mobilit¨at µ(v1 ) der Operation v1 gleich null. Folglich gilt p1,1 = 1, ur Operation v2 . Operation v6 hat Mobilit¨at µ(v6 ) = 1 p1,2 = p1,3 = p1,4 = 0. Das gleiche gilt f¨ und den Zeitrahmen [1, 2]. Folglich gilt p6,1 = p6,2 = 0.5, p6,3 = p6,4 = 0. Operation v8 hat Mobilit¨at µ(v8 ) = 2 und den Zeitrahmen [1, 3]. Deshalb gilt p8,1 = p8,2 = p8,3 = 0.3, p8,4 = 0. Damit erh¨alt man als Verteilung des Multiplizierers (k = 1) im Zeitschritt eins ur Multiplizierer und ALU (k = 2) sind in q1,1 = 1 + 1 + 0.5 + 0.3 = 2.8. Die Verteilungen f¨ Abb. 4.13 graphisch dargestellt.

4.3. ALGORITHMEN ZUR ABLAUFPLANUNG

a)Listscheduling

93

b) latenzoptimale Ablaufplanung NOP 0

Zeit 1

2

1

Zeit 2

Zeit 3

Zeit 6

Zeit 1

Zeit 2

3

Zeit 4

4

Zeit 5

5

NOP

1

3

Zeit 3

Zeit 4

Zeit 5

NOP 0

Zeit 6

2

4

5

NOP

n

Abbildung 4.12: Listscheduling ist i.a. suboptimal.

n

94

KAPITEL 4. SYNTHESE Multiplizierer 0

ALU 1

2

0

3

Zeit 1

Zeit 1

Zeit 2

Zeit 2

Zeit 3

Zeit 3

Zeit 4

Zeit 4

1

2

3

Abbildung 4.13: Belegungsgraphen der Typen Multiplizierer und ALU 4. Selbstkraft: Die Planung einer Operation zu einem Zeitschritt basiert auf einer einfachen Analogie zu dem mechanischen Modell einer Feder, bei der die Beziehung zwischen Elongation x, Federkonstante c und Kraft F durch das Hookesche Gesetz gegeben ist gem¨ass F = cx. Wird eine Operation zu einem Zeitschritt geplant, so uhrungswahrscheinlichkeit auf eins in diesem Zeitschritt und auf ¨andert sich ihre Ausf¨ ¨ null in allen anderen Zeitschritten. Diese Anderung ist vergleichbar mit der Elongation einer Feder. Die Analogie zur Federkonstante l¨asst sich durch den Wert der Verteilung qk,t herstellen. Da diese Analogie jedoch nicht sehr weit tr¨agt, wird hier S einer Operation v bez¨ das Verfahren direkt interpretiert. Die Selbstkraft Fi,t uglich i eines Zeitpunkts t wird definiert als S Fi,t = qk,t − qk,i

wobei qk,i

1 = µ(vi ) + 1

τ (vi )L

X

qk,m

m=τ (vi )S

S also den Unterschied zwischen der Belegung der zur Offensichtlich bezeichnet Fi,t Operation vi geh¨origen Ressource rk zum fraglichen Zeitpunkt t und dem Mittelwert qk der Belegungen im Mobilit¨atsintervall der Operation Operation vi . Sie ist also ein Mass daf¨ ur, ob ein Planungszeitpunkt t bez¨ uglich des Ressourcetypen rk stark belegt ist.

Beispiel 4.16 Betrachten wir Operation v6 in Beispiel 4.13 vom Typ Multiplizierer (k = 1). Die Ausf¨ uhrungswahrscheinlichkeit in den ersten zwei Zeitschritten ist jeweils p6,1 = ur die Verteilung gilt d1,1 = 2.8 und d1,2 = 2.3. Plant man Operation v6 zum p6,2 = 0.5, f¨

4.3. ALGORITHMEN ZUR ABLAUFPLANUNG

95

Zeitpunkt 1, dann ¨ andern sich die Wahrscheinlichkeiten um 1 − 0.5 f¨ ur Schritt 1 und um 0 − 0.5 f¨ ur Schritt 2. Die Selbstkraft betr¨agt folglich 2.8(1 − 0.5) + 2.3(0 − 0.5) = 0.25. Die Kraft tr¨agt ein positives Vorzeichen, da die Nebenl¨aufigkeit der Multiplikationen im Zeitschritt 1 h¨oher als im Zeitschritt 2 ist. Falls v6 im zweiten Zeitschritt geplant wird, betr¨agt die Selbstkraft 2.8(0 − 0.5) + 2.3(1 − 0.5) = −0.25.

5. Vorg¨ anger- und Nachfolgerkr¨ afte: Da die Planung einer Operation die Zeitrahmen anderer Operationen einschr¨anken kann, betrachtet man zus¨atzlich Vorg¨anger- und Nachfolgerkr¨afte, das sind Kr¨ afte auf Vorg¨anger- oder Nachfolgerknoten im Sequenzgraphen. Ausgangspunkt ist die Tatsache, dass zum Beispiel die Planung einer Operation die Mobilit¨at nachfolgender Operationen einschr¨anken k¨onnte. Aus Rechenzeitgr¨ unden werden jedoch nur die direkten Vorg¨anger- oder Nachfolgeknoten im Sequenzgraphen betrachtet. Nehmen wir an, dass eine Operation vj direkter Vorg¨anger oder Nachfolger einer Operation vi ist und sich das Mobilit¨atsintervall von vj durch eine Planung von vi von [τ (vj )S , τ (vj )L ] mit µ(vj ) = τ (vj )L − τ (vj )S nach e(vj ) = τe(vj )L − τe(vj )S ¨ [τe(vj )S , τe(vj )L ] mit µ andert. Dann erh¨alt man als Vorg¨angeroder Nachfolgerkraft N Fj,t = qg k,j − qk,j wobei 1 qg k,j = e(vj ) + 1 µ

e τ (vj )L X m=e τ (vj

qk,m

)S

N Fj,t

ist also ein Mass daf¨ ur, wie stark sich die mittlere Belegung des zu einer Vorg¨ anger- oder Nachfolgeroperation geh¨origen Ressourcetypen erh¨oht.

Beispiel 4.17 Die Planung von Operation v8 im Zeitschritt 2 impliziert die Planung von Operation v9 zu Zeitschritt 3 oder 4. Die Variation der Kraft auf v9 ist 1/2(q2,3 + q2,4 ) − 1/3(q2,2 + q2,3 + q2,4 ) = 0.5(2 + 1.6) − 0.3(1 + 2 + 1.6) = 0.3. 6. Gesamtkraft: Die Gesamtkraft auf eine Operation erh¨alt man nun durch Summation der Selbstkraft und der Kr¨afte durch alle ihre Vorg¨anger- und Nachfolgerknoten: S Fi,t = Fi,t +

X

∀vj :(vi ,vj )∈ES

N Fj,t +

X

∀vj :(vj ,vi )∈ES

N Fj,t

Beispiel 4.18 Die Planung von Operation v6 im Zeitschritt 2 impliziert die Planung von Operation v7 auf Zeitschritt 3. Die Nachfolgekraft von v7 ist q1,3 − 0.5(q1,2 + q1,3 ) = 2.3 − 0.5(2.3+0.8) = −0.75. Die Gesamtkraft auf v6 im Zeitschritt 2 ist die Summe aus Selbstkraft und Nachfolgerkraft, also −0.25 − 0.75 = −1. Insgesamt erh¨alt man als Gesamtkr¨afte auf v6 in den Zeitschritten 1 und 2 die Werte 0.25 beziehungsweise −1. Mit diesen Gesamtkr¨aften lassen sich zwei Algorithmen formulieren. Die Grundstruktur des Force-Directed-List-Scheduling-Algorithmus ist ¨ahnlich dem Algorithmus Listscheduling. Jedoch werden die Zeitrahmen und Kr¨afte der Operationen in jedem Schritt aktualisiert. Das Auswahlverfahren besteht darin, in jedem Schritt diejenigen ablaufbereiten Operationen auszuw¨ahlen, die die h¨ochsten Kr¨afte aufweisen. Dies entspricht in jedem Schritt dem Streben nach einer maximalen Nebenl¨aufigkeit unter Wahrung der Ressourcebeschr¨ankungen. Der Algorithmus konstruiert einen Ablaufplan, der per definition die Ressourcebeschr¨ankungen erf¨ ullt und bem¨ uht ist, die Latenz zu minimieren. W¨ unscht man dahingegen die Minimierung der Ressourcen unter Einhaltung einer vorgegebenen Latenz, so wird man versuchen, eine m¨oglichst geringe Nebenl¨aufigkeit zu erreichen. Die Grundstruktur des Force-Directed-Scheduling-Algorithmus lautet wie folgt:

96

KAPITEL 4. SYNTHESE

FORCEDIRECTED(...){ REPEAT { Bestimme Mobilit¨atsintervalle aller nicht geplanten Operationen; Bestimme Belegungen und Ausf¨ uhrungswahrscheinlichkeiten; Bestimme Gesamtkr¨afte aller Operationen; Plane Operation mit der geringsten Kraft; } UNTIL (alle Operationen geplant); RETURN } Im Gegensatz zum Listscheduling, bei dem ein Zeitpunkt nach dem anderen mit Operationen aufgef¨ ullt wird, wird hier also eine Operation nach der anderen geplant. Somit ist die Einhaltung der Latenzbeschr¨ankung garantiert. Ganzzahlige lineare Programmierung Eine weitere M¨oglichkeit, Ablaufpl¨ane unter Ber¨ ucksichtigung endlicher Ressourcen zu bestimmen, besteht in der Formulierung als ganzzahlige lineares Programm. Eine der ersten Arbeiten, in der formale Methoden beschrieben wurden, um digitale Logik mit algebraischen Relationen auf der Ebene von Datenpfadsystemen zu modellieren und RegisterTransfer-Logik zu synthetisieren, wurde von Hafer und Parker ([13]) ver¨offentlicht. Zahlreiche weitere Arbeiten bauen direkt oder indirekt auf dem von den Autoren vorgeschlagenen Ansatz auf, z.B. [19, 22, 31, 10]. Theorem 4.1 (Ablaufplanung mit Ressourcenbeschr¨ ankungen) Gegeben seien ein Sequenzgraph GS , ein Ressourcegraph GR , die Zahl der verf¨ ugbaren Instanzen α(vt ) des Ressourcetypen vt , die Ausf¨ uhrungszeiten ws der Operationen vs und die mit ASAP- und ALAP-Planungsverfahren berechneten fr¨ uhest beziehungsweise sp¨atestm¨oglichen Ausf¨ uhrungszeitpunkte ls := τ (vs )S und hs := τ (vs )L der Operationen vs ∈ VS . Eine zul¨assige L¨ osung des folgenden Ungleichungssystems ist dann eine L¨ osung des zul¨assigen Planungsproblems: xi,t hi X

∈ {0, 1}

xi,t = 1

∀vi ∈ VS , ∀t : li ≤ t ≤ hi ∀vi ∈ VS

(4.2)

t=li hi X

t · xi,t = τ (vi )

∀vi ∈ VS

(4.3)

∀(vi , vj ) ∈ ES

(4.4)

∀vk ∈ VT , ∀1 ≤ t ≤ max{hi : vi ∈ VS }

(4.5)

t=li

τ (vj ) − τ (vi ) ≥ wi X

min{wi −1,t−li }

∀i:(vi ,vk )∈ER

p0 =max{0,t−hi }

X

xi,t−p0 ≤ α(vk )

Es folgt eine kurze Erl¨auterung zu den einzelnen Gleichungen und Ungleichungen: • Die bin¨are Variable xi,t dr¨ uckt die Ablaufplanung der Operationen vi ∈ VS aus: (

xi,t =

1 : falls vi zum Zeitpunkt τ (vi ) = t ausgef¨ uhrt wird 0 : sonst

4.3. ALGORITHMEN ZUR ABLAUFPLANUNG

97

Der G¨ ultigkeitsbereich der Variablen xi,t erstreckt sich jeweils vom fr¨ uhest bis zum sp¨atest m¨oglichen Kontrollschritt, an dem die Ausf¨ uhrung von Operation vi begonnen werden kann. • Da xi,t den Wert 1 genau zu dem Zeitpunkt annimmt, an dem vi ausgef¨ uhrt wird, wird durch die Summation von xi,t in (4.2) u uhrungszeit¨ber alle m¨oglichen Ausf¨ punkte t mit li ≤ t ≤ hi gew¨ahrleistet, dass vi genau einmal w¨ahrend einer Iteration ausgef¨ uhrt wird. • Die Eigenschaft, dass xi,t den Wert 1 am Ausf¨ uhrungszeitpunkt τ (vi ) = t annimmt, wird in (4.3) ausgenutzt, um τ (vi ) explizit zu berechnen. Die Multiplikation von xi,t mit dem Zeitschritt t hat zum Zeitpunkt t = τ (vi ) den Wert τ (vi ) und ansonsten den Wert 0. Die Summation u ¨ber das Produkt t · xi,t liefert demzufolge genau τ (vi ). • Das Planungsverfahren muss die durch den Sequenzgraphen GD implizierten Datenabh¨angigkeiten gew¨ahrleisten: F¨ ur alle Kanten (vi , vj ) ∈ ES muss gelten, dass die Ausf¨ uhrung von Operation vj erst begonnen werden kann, wenn die Berechnung von Operation vi beendet ist. Die Differenz der Ausf¨ uhrungszeitpunkte von vj und vi , τ (vj ) − τ (vi ) muss also mindestens so gross wie Dauer der Ausf¨ uhrung von vi , das heisst wi , sein. Dies wird durch die G¨ ultigkeit von (4.4) gew¨ahrleistet. • Schliesslich muss garantiert werden, dass zu keinem Zeitpunkt mehr als die zur Verf¨ ugung stehenden Instanzen der Resssourcetypen benutzt werden. F¨ ur die innere Summe in (4.5) gilt durch die Indexverschiebung mit p0 : wX i −1 p0 =0

(

xi,t−p0 =

1 : ∀t : τ (vi ) ≤ t ≤ τ (vi ) + wi − 1 0 : sonst

Diese Summe hat also genau w¨ ahrend der Ausf¨ uhrungszeit einer Operation vi , das heisst f¨ ur alle Kontrollschritte t mit τ (vi ) ≤ t ≤ τ (vi ) + wi − 1, jeweils den Wert 1. Durch Summation u ¨ ber alle Operationen, die denselben Ressourcetypen vk beanspruchen, erh¨alt man f¨ ur einen festen Zeitpunkt t die Anzahl der Operationen, die auf den Ressourcetypen vk an dem betreffenden Zeitpunkt zugreifen. Es seien jeweils α(vk ) Instanzen von dem Ressourcetypen vk ∈ VT vorhanden. Mithin gew¨ahrleistet das Ungleichungssystem, dass f¨ ur alle Kontrollschritte t und f¨ ur alle Ressourcetypen vk ∈ VT niemals mehr als die zur Verf¨ ugung stehende Anzahl von Instanzen eines Ressourcetyps ben¨otigt wird. Die etwas komplexeren Summengrenzen max{0, t − hi } bzw. min{wi − 1, t − li } stellen sicher, dass nur definierte Variablen xi,t−p0 aufsummiert werden. Durch Auswertung von Ungleichungssystem (4.5) f¨ ur alle Kontrollschritte t mit 1 ≤ t ≤ γ wird ein Benutzungsprofil eines Ressourcetyps berechnet. Ein derartiges Benutzungsprofil wird im folgenden Beispiel dargestellt. Beispiel 4.19 Gegeben sei der Ressourcegraph nach Abbildung 4.14 mit den Operationen v1 und v2 , die die Berechnungszeiten von 4 und 3 Kontrollschritten auf Ressource r haben. Die Startzeitpunkte der Ausf¨ uhrung der Operationen seien τ (v1 ) = 2 und τ (v2 ) = 4. Durch Auswertung der inneren Summe des Ungleichungssystems (4.5) erh¨alt man die beiden linken Diagramme in Abbildung 4.15, w¨ahrend die Summe f¨ ur jeden Kontrollschritt im rechten Teil zu sehen ist. Offensichtlich gibt der zu jedem Kontrollschritt zugeh¨orige Wert die Anzahl der ben¨otigten Ressourcen an.

98

KAPITEL 4. SYNTHESE

w =4 1,1

v 1

r1 v

w =3 2,1

2

Abbildung 4.14: Ressourcegraph aus Beispiel 4.19.

Σ x 1,t-p’

(p’) 2 1 1

3

5

7

9

Σ Σ x i,t-p’ (i) (p’)

t 2

Σ x 2,t-p’

1

(p’) 2

1

3

5

7

9

t

1 1

3

5

7

9

t

Abbildung 4.15: Berechnung der Ressourceausnutzung in Beipspiel 4.19.

4.3. ALGORITHMEN ZUR ABLAUFPLANUNG

99

Iterative Algorithmen Die bisher betrachtete Klasse von Algorithmen konnte durch (azyklische) Sequenzgraphen beschrieben werden. Das heisst, alle Operationen wurden genau einmal ausgef¨ uhrt. Aber zum Beispiel Algorithmen der Bild- und Signalverarbeitung sind dadurch gekennzeichnet, dass bestimmte Operationen immer wieder auf jeweils unterschiedliche Daten angewendet werden. Beim Beispiel des Hybridcoders in der Einleitung hiess dies, dass f¨ ur jedes Bild einer Videosequenz die Kodierschleife zu durchlaufen war. Es liegt daher nahe, die Klasse der Algorithmen wie folgt zu erweitern: Definition 4.10 (Iterative Algorithmen) Ein iterativer Algorithmus besteht aus einer Menge von V quantifizierten, linear indizierten Gleichungen Si [l]: S1 [l] . . . Si [l] . . . SV [l]

∀l ≥ 0

Jede Gleichung Si [l] ist von der Form xi [l] = Fi [. . . , xj [l − dji ], . . .] wobei der Index l die Iteration des Algorithmus angibt. Die Variablen xi [l] sind skalar indiziert und Fi sind beliebige Funktionen. Zwischen der Berechnung von Variablen xi [l] und xj [l] k¨ onnen konstante Indexverschiebungen dji ∈ N bestehen. Die Gleichungen Si [l] werden iterativ f¨ ur alle l ∈ Z+ ausgewertet. Eine Indexverschiebungen dji bewirkt, dass die Berechnung der Variablen xi um mindestens dji Iterationen gegen¨ uber der Berechnung der Variablen xj verz¨ogert ist. Beispiel 4.20 Bei dem einfachen iterativen Algorithmus x2 [l] = x3 [l] =

f2 (x1 [l]) f3 (x1 [l])

x4 [l] =

f4 (x2 [l], x3 [l])

∀l ≥ 0 ∀l ≥ 0 ∀l ≥ 0

besteht zwischen der Berechnung der Variablen x2 und x1 eine Indexverschiebung um eine Iteration. Dieser Algorithmus l¨asst sich nat¨ urlich auch in Form eines imperativen Schleifenprogramms darstellen, zum Beispiel in VHDL: ... LOOP x2(l) := f2(x1(l)); x3(l) := f3(x1(l)); x4(l) := f4(x2(l), x3(l)); l := l+1 END LOOP; ...

Die Struktur und Datenabh¨angigkeiten eines iterativen Algorithmus lassen sich wiederum durch einen Sequenzgraphen darstellen. Zus¨atzlich sind jedoch noch die den Kanten zugeordnenten Indexverschiebungen zu definieren. Die Funktion d : ES → Z ordnet jeder Kante (vj , vi ) des Sequenzgraphen die zugeh¨orige Indexverschiebung dji zu. Beispiel 4.21 Der um die Indexverschiebungen erweiterte Sequenzgraph des im Beispiel 4.20 eingef¨ uhrten Algorithmus ist in Abb. 4.16 dargestellt.

100

KAPITEL 4. SYNTHESE d =0 12

v 2

d =0 24

v1

v 4 d =0 13

v 3

d =0 34

Abbildung 4.16: Beispiel eines erweiterten Sequenzgraphen. Es folgen noch einige weitere Definitionen, die f¨ ur das Verst¨andnis iterativer Algorithmen und deren Implementierung wichtig sind. Zun¨achst soll der Begriff der Iteration genauer erl¨autert werden. Definition 4.11 (Iteration) Eine Iteration ist die Berechnung aller Variablen xi [l] eines nach Definition 4.10 gegebenen iterativen Algorithmus f¨ ur ein festes l. W¨ahrend einer Iteration wird daher der entsprechende Algorithmus genau einmal vollst¨andig abgearbeitet. Es werden die zu einem vollst¨andigen Satz von Eingabedaten geh¨origen Ausgangsdaten berechnet. Unter einer Iteration versteht man demnach die Ausf¨ uhrung einer Einheits-Berechnungsaufgabe. Bei der Abbildung eines Algorithmus auf eine Architektur ist die Verarbeitungsgeschwindigkeit ein wichtiges Leistungsmerkmal. Das Iterationsintervall und die Latenz sind zwei wichtige Begriffe, die die Ausf¨ uhrungszeit von Algorithmen betreffen. Definition 4.12 (Iterationsintervall) Das Iterationsintervall P bezeichnet die Anzahl von Taktzyklen zwischen dem Beginn zweier aufeinanderfolgender Iterationen. Da zu jeder Iteration ein neuer Satz von Eingangsdaten verarbeitet wird, ist das Iterationintervall demnach das Inverse der Durchsatzrate. Es ist mithin ein ¨ausserst wichtiges Mass f¨ ur den Datendurchsatz und die Verarbeitungsgeschwindigkeit einer Implementierung. Neben der Rate, mit der neue Daten einem System zugef¨ uhrt werden k¨onnen, ist auch die Latenz wichtig, die Zeit, die zwischen der ersten und letzten Operation einer Iteration vergeht. Beispiel 4.22 Die Begriffe Iteration, Iterationsintervall und Latenz werden anhand von Abb. 4.17 veranschaulicht. Es wird vorausgesetzt, dass die Ausf¨ uhrungszeit der Operationen jeweils einen Taktzyklus ben¨otigt. Die Iterationen werden mit einem Iterationsintervall von 1 Taktzyklus abgearbeitet, da zu jedem Taktzeitpunkt eine neue Iteration gestartet wird. Da die Abarbeitung einer Iteration 4 Taktzyklen erfordert, betr¨agt die Latenz 4 Taktzyklen. Funktionale Fliessbandverarbeitung und Schleifenfaltung Die so beschriebenen iterativen Algorithmen zeichnen sich durch inh¨arenten Parallelismus auf zwei Ebenen aus. Zum einen k¨onnen die Werte zweier Variablen xi [l] und xj [l] innerhalb einer Iteration l parallel berechnet werden, wenn keine direkten Datenabh¨angigkeiten zwischen den Operationen besteht. Zum anderen kann, bevor eine Iteration beendet ist, eine neue Iteration begonnen werden. Dies f¨ uhrt dazu, dass Variablen aus verschiedenen Iterationen parallel berechnet werden k¨onnen und mehrere Operationen gleichzeitig

4.3. ALGORITHMEN ZUR ABLAUFPLANUNG

101

Iteration v 1

v 2

v 3

v 1

v 2

v 3

v 4

v 1

v 2

v 3

v 4

v 2

v 3

v 4

4 3 2 v 1

1

v 4

Zeit 1

2

3

4

5

6

7

8

Abbildung 4.17: Iterationsintervall und Latenz. v 1

v 2

w =4 11

w =2 22

r 1 v 3

w =3 31

r 2 v 4

w =2 42

Abbildung 4.18: Ressourcegraph aus Beispiel 4.23. berechnet werden. Dies ist auch unter dem Begriff funktionale Fliessbandverarbeitung bekannt; in Abb. 4.17 sieht man, dass Operation v1 der ersten Iteration parallel zu Operation v2 der zweiten Iteration ausgef¨ uhrt wird. Definition 4.13 (Funktionale Fliessbandverarbeitung) Gegeben seien ein iterativer Algorithmus nach Definition 4.10 und ein Iterationsintervall P nach Definition 4.12. Unter funktionaler Fliessbandverarbeitung (Makrofliessbandverarbeitung, functional pipelining, macro pipelining) versteht man die gleichzeitige Bearbeitung von zu unterschiedlichen Iterationen geh¨orenden Datens¨atzen. Es gibt also Kontrollschritte t, an denen Operationen mit Daten aus verschiedenen Iterationen l ausgef¨ uhrt werden. Im Fall unbegrenzter Ressourcen ist das minimal erreichbare Iterationsintervall (und damit die maximal erreichbare Durchsatzrate) durch das Maximum aller Rechenzeiten gegeben: Pmin = max(w((vs , vt ))) ∀(vs , vt ) ∈ ER . Ein Beispiel f¨ ur funktionale Fliessbandverarbeitung wird im folgenden gegeben. Beispiel 4.23 Gegeben seien der Abh¨angigkeitsgraph nach 4.16 und der zugeh¨orige Ressourcegraph nach Abbildung 4.18. Ein nach Ungleichungssystem (4.2,4.4,4.5) berechneter zul¨assiger Ablaufplan f¨ ur diese Konfiguration ist in Tabelle 4.1 dargestellt. Nach diesem Ablaufplan betr¨agt das Iterationsintervall P = 9 Kontrollschritte; das heisst alle 9 Kontrollschritte kann die Berechnung eines neuen Datensatzes begonnen werden. Aus Abbildung 4.19, die die Belegung der Ressourcen durch die Operationen darstellt, geht hervor, dass Ressource r2 w¨ahrend der Kontrollschritte 0 bis 3 jeder Iteration nicht arbeitet. Nach Berechnung von Operation v3 auf Ressource r1 ist es bei geeigneter Speicherung der Zwischenergebnisse offensichtlich m¨oglich, gleichzeitig mit dem Beginn der Berechnung von Operation v4 auf Ressource r2 , die Berechnung eines neuen Datenuckt bedeutet dies, dass satzes durch Operation v1 auf Ressource r1 zu beginnen. Anders ausgedr¨

102

KAPITEL 4. SYNTHESE P vi β(vi ) τ (vi )

9 v1 r1 0

v2 r1 4

v3 r2 4

v4 r2 7

Tabelle 4.1: Ein einfacher Ablaufplan

r2

v2

r1

v1

v4

v3 t

0

1

2

3

4

5

6

7

8

Abbildung 4.19: Ablaufplanung und Bindung. die Operationen v1 , v2 , v3 in Iteration l und Operation v4 in Iteration l + 1 berechnet werden. Ein Ablaufplan, der funktionale Fliessbandverarbeitung ber¨ ucksichtigt, ist in Tabelle 4.2 dargestellt. Das Iterationsintervall betr¨agt jetzt P = 7 Kontrollschritte. Abbildung 4.20 zeigt die entsprechende Auslastung der Ressourcen.

P vi β(vi ) τ (vi )

7 v1 r1 0

v2 r1 4

v3 r2 4

v4 r2 7/0

Tabelle 4.2: Ein Ablaufplan mit funktionaler Fliessbandverarbeitung

Eine Erweiterung von funktionaler Fliessbandverarbeitung stellt die Schleifenfaltung dar. Definition 4.14 (Schleifenfaltung) Bei einem Ablaufplan mit Schleifenfaltung und funktionaler Fliessbandverarbeitung k¨onnen Anfangs- und Endzeitpunkte der Ausf¨ uhrung einer Operation in aufeinanderfolgenden Iterationen liegen. Ein Beispiel f¨ ur funktionale Fliessbandverarbeitung mit Schleifenfaltung sei im folgenden gegeben: Beispiel 4.24 Gegeben seien der Abh¨angigkeitsgraph nach 4.16 und der zugeh¨orige Ressourcegraph nach Abbildung 4.18. Das Iterationsintervall kann auf P = 6 Kontrollschritte gesenkt werden, wenn der Beginn der Ausf¨ uhrung von Operation v3 an Kontrollschritt t = 4 beginnt und an Kontrollschritt t = 1 des darauffolgenden Abarbeitungszyklus endet. Entsprechend verschiebt sich der Beginn von Operation v4 auf Kontrollschritt t = 1. Der Ablaufplan ist in Tabelle 4.3 dargestellt, die entsprechende Belegung der Ressourcen in Abbildung 4.21.

4.3. ALGORITHMEN ZUR ABLAUFPLANUNG r2

103

v4

r1

v3

v1

v2 t

0

1

2

3

4

5

6

Abbildung 4.20: Ablaufplanung mit fkt. Fliessbandverarbeitung. P vi β(vi ) τ (vi )

6 v1 r1 0

v2 r1 4

v3 r2 4

v4 r2 7/1

Tabelle 4.3: Ein Ablaufplan mit funktionaler Fliessbandverarbeitung und Schleifenfaltung

Ganzzahlige lineare Programmierung zur Ablaufplanung iterativer Algorithmen Das in Theorem 4.1 beschriebene Verfahren zur Ablaufplanung mit endlichen Ressourcen wird nun auf iterative Algorithmen erweitert. Zun¨achst wollen wir jedoch davon ausgehen, dass es keine Datenabh¨angigkeiten zwischen Iterationen gibt, also dij = 0 gilt f¨ ur alle Kanten (vi , vj ) ∈ ES des Sequenzgraphen GS .

Theorem 4.2 (Fliessbandverarbeitung und Schleifenfaltung) Gegeben seien ein Sequenzgraph GS mit dji = 0 f¨ ur alle (vj , vi ) ∈ ES , ein Ressourcegraph GR , das Iterationsintervall P , die maximal erlaubte Latenz L mit P < L und die mit ASAP- und ALAPPlanungsverfahren berechneten fr¨ uhest beziehungsweise sp¨atestm¨oglichen Ausf¨ uhrungszeitpunkte li und hi der Operationen vi ∈ VS . Wird in dem Ungleichungssystem (4.2,4.4,4.5) das Ungleichungssystem (4.5) durch das folgende System (4.6) ersetzt, so ist eine zul¨assige L¨ osung des resultierenden Ungleichungssystems (4.2,4.4,4.6) eine L¨ osung des Planungs-

r2

v3

r1

v4

v3

v1

v2 t

0

1

2

3

4

5

6

Abbildung 4.21: Ablaufplanung bei Fliessbandverarbeitung und Schleifenfaltung.

104

KAPITEL 4. SYNTHESE

problems mit funktionaler Fliessbandverarbeitung und Schleifenfaltung. X

wX i −1

∀i:(vi ,vk )∈ER p0 =0

X ∀p:li ≤t−p0 +p·P ≤hi

xi,t−p0 +p·P ≤ α(vk )

∀1 ≤ t ≤ P, ∀vk ∈ VT

(4.6)

Der Beweis dieses Theorems st¨ utzt sich auf die Ausf¨ uhrungen in Zusammenhang mit Theorem 4.1. • Zur mathematischen Modellierung des Planungsverfahrens mit Ber¨ ucksichtigung von funktionaler Fliessbandverarbeitung und Schleifenfaltung wird die in Theorem 4.1 definierte bin¨are Variable xi,t benutzt. • Ebenso wie im rein azyklischen Fall muss gew¨ahrleistet sein, dass jede Operation genau einmal in jedem Iterationsintervall ausgef¨ uhrt wird, siehe (4.2). Durch (4.4) wird gew¨ahrleistet, dass die Datenabh¨angigkeiten zwischen den Operationen erhalten bleiben. • Etwas schwieriger sind nun die Ressourcenbeschr¨ankungen zu modellieren, da sich Operationen u uhrungszyklus erstrecken k¨onnen. Die ¨ ber die Grenzen eines Ausf¨ Ausf¨ uhrung der Operationen vi mit dem Index l eines iterativen Algorithmus beginnen an den Kontrollschritten ti = τ (vi ) + l · P . Wird die Ausf¨ uhrung einer Operation vi zum Kontrollschritt τ (vi ) begonnen, belegt sie entsprechend Ressourcen w¨ahrend der Kontrollschritte t mit t = τ (vi ) + p0 − p · P

(4.7)

0

0 ≤ p ≤ wi − 1

(4.8)

li ≤ t − p + p · P ≤ hi

(4.9)

∀p

∀p

: :

0

0

F¨ ur p = 0 ergibt die Auswertung von (4.8) die Kontrollschritte t mit τ (vi ) ≤ t ≤ τ (vi )+wi −1; dies entspricht den Ausf¨ uhrungszeitpunkten von vi im azyklischen Fall. F¨ ur p 6= 0 sind dies die jeweils um p · P Kontrollschritte verschobenen Ausf¨ uhrungszeitpunkte von Operation vi . Die Grenzen f¨ ur p ergeben sich aus der Forderung, dass sich alle Kontrollschritte innerhalb des zul¨assigen Bereichs f¨ ur vi befinden m¨ ussen. Die Auswertung der beiden inneren Summen von Ungleichung (4.6) f¨ ur eine gegebene Operation vi ergibt, dass die Summe wX i −1

X

p0 =0

∀p:li ≤t−p0 +p·P ≤hi

xi,t−p0 +p·P

f¨ ur alle t, zu denen Operation vi innerhalb einer Iteration 1 ≤ t ≤ P eine Ressource belegt, den Wert 1 hat, sonst den Wert 0. Wiederum wird durch Summation u uhrt wer¨ ber alle Operationen vi , die auf demselben Ressourcetypentypen vk ausgef¨ den, sichergestellt, dass zu keinem Kontrollschritt mehr als die von diesem Typ zur Verf¨ ugung stehenden Instanzen benutzt werden. Das bis jetzt vorgestellte Verfahren zur Ablaufplanung setzt voraus, dass keine Datenabh¨angigkeiten zwischen den Iterationen bestehen. In zahlreichen Algorithmen der Signalverarbeitung werden jedoch Daten, die in Iteration l berechnet werden, in einer der

4.3. ALGORITHMEN ZUR ABLAUFPLANUNG

105

folgenden Iterationen benutzt. Ein bekanntes Beispiel ist ein Algorithmus Filter: yt =

N −1 X

1

f¨ ur ein FIR-

aj · ut−j

j=0

Der Ausgangswert yt zum Zeitpunkt t wird als Summe der mit aj gewichteten Eingangswerte u der Zeitpunkte t . . . t − N + 1 berechnet. Es ist daher sinnvoll, als Erweiterung des bisherigen Modells auch iterative Algorithmen mit Datenabh¨angigkeiten zwischen den Iterationen zu betrachten. Weiterhin wird zugelassen, dass die von den iterativen Algorithmen implizierten Sequenzgraphen Zyklen aufweisen. Die Berechnung der fr¨ uhest- beziehungsweise sp¨atestm¨oglichen Ausf¨ uhrungszeitpunkte der Operationen mit ASAP- und ALAP-Verfahren kann unter Vernachl¨assigung aller Datenabh¨angigkeiten mit dij 6= 0 durchgef¨ uhrt werden. Theorem 4.3 (Datenabh¨ angigkeiten zwischen Iteration) Gegeben seien ein m¨ oglicherweise zylischer Sequenzgraph GS , ein Ressourcegraph GR , das Iterationsintervall P , die maximal zugelassene Latenz L mit P < L und die mit ASAP- und ALAPPlanungsverfahren berechneten fr¨ uhest beziehungsweise sp¨atestm¨oglichen Ausf¨ uhrungszeitpunkte li und hi der Operationen vi ∈ VS . Wird in dem Ungleichungssystem (4.2,4.4,4.6) die Ungleichung (4.4) durch das folgende Ungleichungssystem (4.10) ersetzt, so ist eine zul¨ assige L¨ osung des resultierenden Ungleichungssystems eine L¨osung des Planungsproblems mit Datenabh¨angigkeiten zwischen Iterationen sowie funktionaler Fiessbandverarbeitung und Schleifenfaltung. τ (vj ) − τ (vi ) ≥ wi − dij · P

∀(vi , vj ) ∈ ES

(4.10)

Zur mathematischen Modellierung des Planungsverfahrens mit Ber¨ ucksichtigung der Datenabh¨angigkeiten zwischen Iterationen sowie funktionaler Fliessbandverarbeitung und Schleifenfaltung wird die in Theorem 4.1 definierte bin¨are Variable xi,t benutzt. Die Argumentation f¨ ur die G¨ ultigkeit der Ungleichungen (4.2,4.6) bleibt unver¨andert. F¨ ur die Knoten vi , vj ∈ VS existiere eine Kante (vi , vj ) ∈ ES , der ein Gewicht dij zugeordnet sei. Die in Iteration l durch die Ausf¨ uhrung von Operation vi erzeugten Daten werden in Iteration l + dij von Operation vj ben¨otigt. Die Ausf¨ uhrung von Operation vi beginne an Kontrollschritt t = τ (vi ). F¨ ur den fr¨ uhest m¨oglichen Kontrollschritt t = τ (vj ), an dem die Ausf¨ uhrung von Operation vj beginnen kann, gilt also τ (vj ) + dij · P ≥ τ (vi ) + wi . Beispiel: FIR-Filter Zur Veranschaulichung der Ergebnisse wollen wir nun ein konkretes Beispiel betrachten. Beispiel 4.25 Gegeben sei ein FIR-Filter zweiter Ordnung, der durch den iterativen Algorithmus y(t) = a0 x(t) + a1 x(t − 1) + a2 x(t − 2)

∀t ≥ 0

(4.11)

gegeben ist. Eine direkte Implementierung dieser Differenzengleichung ist der in Abb. 4.22 dargestellte Signalflussgraph. 1

Es handelt sich hier nur um eine kompakte Schreibweise f¨ ur einen iterativen Algorithmus

106

KAPITEL 4. SYNTHESE x(t)

y(t)

a(0)

a(1)

a(2)

D

D

Abbildung 4.22: Signalflussgraph eines FIR-Filters zweiter Ordnung v

x(t) 1

x(t-1) 2

0 x(t-2) 3

4

5 y(t)

vn

Abbildung 4.23: Sequenzgraph FIR-Filter Um eine Implementierung mit beschr¨ankten Ressourcen (≤ 3 Multiplizierer, ≤ 2 Addierer) zu erzielen, modellieren wir den Filter mit dem Sequenzgraphen in Abb. 4.23, den man aus Abb. 4.22 erh¨alt durch Auftrennen der R¨ uckkopplung an Verz¨ogerungselementen (gekennzeichnet mit D) und nach Einf¨ uhren eines Startknotens v0 und eines Endknotens vn . Beispiel 4.26 Der Sequenzgraph in Abb. 4.23 erlaubt die Ablaufplanung des FIR-Filters mit beschr¨ankten Ressourcen. Nun wollen wir das Problem der Latenzminimierung mit Ressourcenbeschr¨ankungen mit Hilfe eines ganzzahligen linearen Programms beschreiben. Beispiel 4.27 Gegeben sei der Sequenzgraph des FIR-Filters in Abb. 4.23. Wir nehmen an, dass zwei Ressourcen des Ressourcetyps r1 (Multiplizierer) (α(r1 ) = 2) und eine Ressourcs des Typs r2 (Addierer) (α(r2 ) = 1) alloziert seien. Um die Anzahl der Variablen des ganzzahligen linearen ¯ = 5 die Programms m¨oglichst klein zu halten, berechnen wir f¨ ur eine gew¨ahlte Latenzschranke L fr¨ uhesten und sp¨atesten Startzeitpunkte von Operationen mit Hilfe der Algorithmen ASAP und ALAP. Das Ergebnis sind Zeitintervalle, die in Abb. 4.24 dargestellt sind.

4.3. ALGORITHMEN ZUR ABLAUFPLANUNG

107 v

x(t) 1 [1,2]

0

x(t-1)

x(t-2)

2 [1,2]

3 [1,3]

4 [3,4]

5 [4,5]

y(t)

vn

¯ = 5 am Beispiel des FIR-Filters Abbildung 4.24: ASAP und ALAP mit L Beispiel 4.28 Unter den Vorgaben in Beispiel 4.27 erhalten wir folgendes System von Beschr¨ankungen f¨ ur unser ganzzahliges lineares Programm: 1. Einf¨ uhrung bin¨arer Variablen: τ (v1 ) = 1x1,1 + 2x1,2 ,

x1,1 + x1,2 = 1

τ (v2 ) = 1x2,1 + 2x2,2 ,

x2,1 + x2,2 = 1

τ (v3 ) = 1x3,1 + 2x3,2 + 3x3,3 ,

x3,1 + x3,2 + x3,2 = 1

τ (v4 ) = 3x4,3 + 4x4,4 ,

x4,3 + x4,4 = 1

τ (v5 ) = 4x5,4 + 5x5,5 ,

x5,4 + x5,5 = 1

2. Datenabh¨angigkeiten: τ (v4 ) − τ (v2 ) ≥ 2 τ (v4 ) − τ (v2 ) ≥ 2 τ (v5 ) − τ (v3 ) ≥ 2 τ (v5 ) − τ (v4 ) ≥ 1 τ (v1 ), τ (v2 ), τ (v3 ) ≥ 1 3. Berechnung der Belegungen durch Faltung und Summation der Belegungen: x1,1 + x2,1 + x3,1 ≤ 2

(t = 1)

x1,1 + x1,2 + x2,1 + x2,2 + x3,1 + x3,2 ≤ 2

(t = 2)

x1,2 + x2,2 + x3,2 + x3,3 ≤ 2

(t = 3)

x3,3 ≤ 2

(t = 4)

108

KAPITEL 4. SYNTHESE Mul 2 1

1,2

1,2 3

1

2

3

3 4

5

6

7

8

t 9

10

11

Add 2 1 4 1

2

5 3

4

4 5

6

7

t

5 8

9

10

11

Abbildung 4.25: Ablaufplan FIR-Filter Eine L¨osung des ganzzahligen linearen Programms f¨ uhrt zu der L¨osung in Abb. 4.25. Die Latenz betr¨agt L = 5 und entspricht dem Iterationsintervall. Offensichtlich sind die Ressourcen schlecht ausgenutzt, da aufeinanderfolgende Iterationen nicht u ¨ berlappen. Eine bessere Formulierung des Algorithmus ist der in Abb. 4.26 dargestellte Abh¨angigkeitsgraph, der nicht nur eine Iteration des Algorithmus darstellt. Beispiel 4.29 Abb. 4.26 zeigt eine ¨aquivalente Darstellung des Algorithmus in Glg. (4.11), die den Vorteil hat, dass eine bessere Ablaufplanung m¨oglich ist durch gleichzeitiges Planen mehrerer Iterationen. Ein besserer Ablaufplan mit Iterationsintervall 4 ist in Abb. 4.27 dargestellt. Diesen Vorteil kann man nun auch erzielen, indem man funktionale Fliessbandverarbeitung und Schleifenfaltung erlaubt. Beispiel 4.30 Die in Abb. 4.27 dargestellte L¨osung kann man auch durch Betrachtung unseres erweiterten Sequenzgraphmodells erzielen. Dieser ist in Abb. 4.28 dargestellt.

4.3.4

Iterative Verfahren zur Ablaufplanung

Zur Vervollst¨andigung unserer Verfahren m¨ochten wir hinzuf¨ ugen, dass es auch Verfahren zur iterativen Verbesserung von Abaufpl¨anen gibt. Hierzu geh¨ort beispielsweise Simulated Annealing [7]. Ein anf¨anglicher Ablaufplan wird iterativ verbessert durch Umplanung einzelner Operationen. Die Umplanungsschritte erfolgen zufallsgesteuert. Schritte, die die aktuelle Latenz verkleinern, werden generell akzeptiert. Um jedoch die M¨oglichkeit zu vermeiden, dass man ein lokales Minimum erzielt, werden auch Umplanungen mit schlechterer Latenz mit einer Wahrscheinlichkeit akzeptiert. Diese Wahrscheinlichkeit nimmt im Verlaufe des Verfahrens ab. Simulated Annealing ist ein exaktes Verfahren. Es zeichnet sich aber durch eine i.a. hohe Laufzeit aus. Ein anderes Verfahren zur iterativen Verbesserung von Ablaufpl¨anen sind Genetische Algorithmen [11, 18]. Aus Zeitgr¨ unden k¨onnen wir hier nicht weiter auf diese Verfahren eingehen.

4.3. ALGORITHMEN ZUR ABLAUFPLANUNG

109

x(-2)

x(-1)

x(0)

y(0)

x(1)

y(1)

x(2)

y(2)

Abbildung 4.26: Abh¨angigkeitsgraph des FIR-Filters

Mul 2 1

1,2

1,2 3

1

2

3

3 4

5

6

7

t 8

9

10

11

Add 4 2 1 4 1

2

5 3

4

4 5

6

t

5 7

8

9

Abbildung 4.27: Ablaufplan FIR-Filter

10

11

110

KAPITEL 4. SYNTHESE v d 01=0

d

d =1 02 x(t-1)

x(t) 1

0

2 0

03

=2 x(t-2)

3 0 0

4 0 5 0

y(t)

vn

Abbildung 4.28: Erweiterter Sequenzgraph FIR-Filter

4.4

Algorithmen zur Bindung

Bindung spezifiziert, welche Instanz eines Ressourcetypen welche Operationen implementieren wird. Bindung kann entweder nach erfolgter Ablaufplanung oder davor durchgef¨ uhrt werden. Wir zeigen zun¨achst, dass Optimierungsprobleme im Zusammenhang mit der Bindung auf Grundprobleme der Graphentheorie zur¨ uckf¨ uhrbar sind und betrachten dann Spezialf¨alle, Algorithmen und deren Komplexit¨aten. Zwei Operationen eines gegebenen Sequenzgraphen k¨onnen offensichtlich auf eine Ressource abgebildet werden, wenn die Operationen nicht nebenl¨aufig sind und wenn sie vom gleichen Ressourcetyp sind. Zwei Operationen sind genau dann nicht nebenl¨aufig, wenn sie auf einem gerichteten Pfad liegen, wenn ihre Ausf¨ uhrungsintervalle disjunkt sind oder wenn sie alternativ sind. Die Vertr¨aglichkeit von Operationen l¨asst sich folglich durch Analyse des Sequenzgraphen bestimmen. F¨ ur nichthierarchische Sequenzgraphen erhalten wir insbesondere folgende Definitionen von Vertr¨aglichkeit: Definition 4.15 (Vertr¨ aglichkeit) Gegeben sei ein nichthierarchischer Sequenzgraph GS = (VS , ES ) und ein Ressourcegraph GR = (VR , ER ). Zwei Operationen vi , vj ∈ VS heissen • schwach vertr¨aglich, falls β(vi ) = β(vj ); • ablaufplanvertr¨aglich, falls vi und vj schwach vertr¨ aglich sind und f¨ ur die Startzeiten τ (vi ) der Operationen bei Ausf¨ uhrungszeiten wi gilt: τ (vj ) ≥ τ (vi ) + wi ∨ τ (vi ) ≥ τ (vj ) + wj • stark vertr¨aglich, falls vi und vj schwach vertr¨aglich sind und falls in GS ein gerichteter Pfad von vi nach vj existiert. Die Vertr¨aglichkeitsrelation zwischen vi und vj dr¨ ucken wir mit Schreibweise vi ∼ vj aus.

4.4. ALGORITHMEN ZUR BINDUNG

111

Die Vertr¨aglichkeitsrelation ∼ ist reflexiv und symmetrisch, im Falle schwacher und starker Vertr¨aglichkeit zus¨atzlich sogar transitiv. Beispiel 4.31 Wir betrachten den Sequenzgraphen in Abb. 4.1. Operationen v1 , v2 , v3 , v6 , v8 sind vom Typ Multiplizierer und damit schwach vertr¨aglich, v1 und v3 sind stark vertr¨aglich und damit auch ablaufplanvertr¨aglich. Operationen v1 und v7 sind ablaufplanvertr¨aglich, aber nicht stark vertr¨aglich.

Die Vertr¨aglichkeit aller Operationen h¨alt man in einem Vertr¨aglichkeitsgraphen fest: Definition 4.16 (Vertr¨ aglichkeitsgraph) Ein (Ressourcen)Vertr¨aglichkeitsgraph GV ( VV , EV ) bezeichnet einen ungerichteten Graphen mit VV = VS und EV = {(vi , vj ) : vi ∼ vj , vi , vj ∈ VV }. Beispiel 4.32 Abb. 4.29 zeigt die Vertr¨aglichkeitsgraphen f¨ur die Ressourcetypen Multiplizierer und ALU aus Beispiel 4.31 f¨ ur a) schwache Vertr¨aglichkeit, b) Ablaufplanvertr¨aglichkeit und c) starke Vertr¨aglichkeit. Ein Vertr¨aglichkeitsgraph besitzt mindestens |VT | disjunkte Komponenten. Eine Menge gegenseitig vertr¨aglicher Operationen entspricht einer Clique in GV . 2 Eine maximale Vertr¨aglichkeitsmenge entspricht einer maximalen Clique in GV 3 . Eine kostenoptimale Bindung liegt dann vor, wenn eine minimale Anzahl von Ressourcen eines jeden Typs ben¨otigt werden. Eine Clique in GV entspricht offensichtlich einer Instanz eines Ressourcetyps. Folglich besteht das Problem der kostenoptimalen Bindung darin, den Graphen GV mit einer mimimalen Anzahl von Cliquen zu partitionieren. Beispiel 4.33 Betrachten wir die Vertr¨aglichkeitsgraphen in Abb. 4.29. Im Falle schwacher Vertr¨aglichkeit bilden die Knoten v1 , v2 , v3 , v6 , v7 , v8 und die Knoten v4 , v5 , v9 , v10 , v11 jeweils eine Clique, die maximal ist. Im Falle von Ablaufplanvertr¨aglichkeit bilden z.B. Knoten v4 , v5 , v10 eine Clique, die allerdings nicht maximal ist. Die Clique v4 , v5 , v9 , v10 hingegen ist maximal. Der Graph des Ressourcetyps Multiplizierer kann in vier Cliquen partitioniert werden und der Graph der ALU in zwei Cliquen. Man br¨auchte also 4 Instanzen des Typs Multiplizierer und 2 Instanzen des Typs ALU. Diese L¨osung entspricht der bereits in Abb. 4.4 dargestellten Bindung. Eine alternative Untersuchungsmethode besteht darin, Paare von Operationen zu bestimmen, die einen Konflikt hinsichtlich der Bindung auf eine Instanz einer Ressource erzeugen. Definition 4.17 (Konflikt) Gegeben sei ein nichthierarchischer Sequenzgraph GS = (VS , ES ) und ein Ressourcegraph GR = (VR , ER ). Zwei Operationen vi , vj ∈ VS sind in einem Konflikt genau dann, wenn sie nicht vertr¨ aglich sind im Sinne von Definition 4.15. Konflikte lassen sich in einem Konfliktgraphen darstellen: Definition 4.18 (Konfliktgraph) Ein (Ressourcen)Konfliktgraph GK (VK , EK ) bezeichnet einen ungerichteten Graphen mit VK = VS und EK = {(vi , vj ) : vi 6∼ vj , vi , vj ∈ VK }. Die Konfliktrelation zwischen vi und vj dr¨ ucken wir mit der Schreibweise vi 6∼ vj aus. 2

Eine Clique bezeichnet ein Teilgraphen eines Graphen mit der Eigenschaft, dass es eine Kante zwischen jedem Knotenpaar dieser Teilmenge gibt. Eine Clique ist ein vollst¨ andiger Teilgraph. 3 Eine Clique heisst maximal, wenn sie in keiner anderen Clique enthalten ist.

112

KAPITEL 4. SYNTHESE

a) schwache Verträglichkeit 7 3

6

11

5

10

4

11

5

10

4

11

5

10

4

1

9 2 8 b) Ablaufplanverträglichkeit 7 3

6

1

9 2 8 c) starke Verträglichkeit 7 3

6

1

9 2

8

Abbildung 4.29: Vertr¨aglichkeitsgraphen f¨ ur den Sequenzgraphen in Abb. 4.1 im Falle a) schwacher Vertr¨aglichkeit, b) Ablaufplanvertr¨aglichkeit und c) starker Vertr¨aglichkeit.

4.4. ALGORITHMEN ZUR BINDUNG

113

a) schwacher Konfliktgraph 7

3

6

1

11

5

10

4

11

5

10

4

9 2 8 b) Konfliktgraph nach Ablaufplanung

7

3

6

1 9

2

8

c) Konfliktgraph komplementär zum Verträglichkeitsgraphen bei starker Verträglichkeit 5 11 7

3

6

1

9 10

2

4

8

Abbildung 4.30: Konfliktgraphen f¨ ur den Sequenzgraphen in Abb. 4.1

Offenbar sind Vertr¨aglichkeitsgraph und Konfliktgraph komplement¨ar. Eine Menge gegenseitig vertr¨aglicher Knoten in VV entspricht einer unabh¨angigen Menge 4 in GK . Auf der Ebene des Konfliktgraphen erh¨alt man eine Bindung durch F¨arbung der Knoten, so dass Knoten, zwischen denen es eine Kante gibt, eine unterschiedliche Farbe zugewiesen bekommen. Folglich besteht das Problem der kostenoptimalen Bindung darin, den Graphen GV mit einer minimalen Anzahl von Farben zu f¨arben. Da Operationen unterschiedlichen Typs immer in Konflikt stehen, ist es anschaulicher, die Konfliktgraphen der einzelnen Typen unabh¨angig voneinander zu betrachten. Diese Graphen sind komplement¨ar zum Vertr¨aglichkeitsgraphen des entsprechenden Typs.

Beispiel 4.34 Betrachten wir erneut den Sequenzgraph in Abb. 4.1. Die Konfliktgraphen sind in Abb. 4.30 dargestellt. Wir betrachten die Graphen der einzelnen Ressourcetypen unabh¨angig voneinander. 4 Eine unabh¨ angige Menge eines Graphen bezeichnet eine Teilmenge von Knoten, von denen keiner mit irgendeinem anderen Knoten dieser Teilmenge adjazent ist.

114

4.4.1

KAPITEL 4. SYNTHESE

Algorithmen und Komplexit¨ at der Bindung

Wir haben das Problem der optimalen Bindung reduziert auf das klassische Problem der Cliquenpartitionierung bei gegebenem Vertr¨aglichkeitsgraphen bzw. dem Graphf¨arbungsproblem bei gegebenem Konfliktgraphen. In beiden F¨allen sind die entsprechenden Entscheidungsprobleme f¨ ur allgemeine Graphen NP-vollst¨andig. Folglich ist man an Heuristiken zu deren L¨osung interessiert. Da das Problem Cliquepartitionierung ¨aquivalent zum Problem der F¨arbung des komplement¨aren Graphen ist, wollen wir uns auf die Beschreibung von Algorithmen zur Graphf¨arbung beschr¨anken. Algorithmen zur Graphf¨ arbung Eine einfache Heuristik zur F¨arbung eines ungerichteten Graphen G(V, E) erh¨alt man durch sequentielles Durchlaufen der Knotenmenge V . Farben werden durch positive ganze Zahlen dargestellt. VERTEXCOLOR(G(V, E)) { FOR i = 1 TO |V | { c := 1; WHILE (∃ Knoten adjaz. zu vi mit Farbe c { c := c + 1; } F¨arbe vi mit Farbe c; } } Beispiel 4.35 Betrachten wir den Konfliktgraphen in Abb. 4.29b). Wir beginnen den Algorithmus VERTEXCOLOR mit F¨arbung von Knoten v1 mit Farbe c = 1. Dann wird v2 mit Farbe c = 2 gef¨arbt. Im Falle von v3 wird die Farbe c = 1 zugewiesen, da der adjazente Knoten v7 noch nicht gef¨arbt ist. v6 ist adjazent mit Knoten v1 und v2 und bekommt deshalb die Farbe c = 3 zugewiesen. v7 wird mit Farbe c = 2 gef¨arbt. Schliesslich wird v8 mit Farbe c = 4 gef¨arbt, da v8 adjazent mit drei unterschiedlich gef¨arbten Knoten ist. Die Knoten der Konfliktgraphen jeden Ressourcetyps k¨onnen unabh¨angig voneinander betrachtet werden. Der Algorithmus VERTEXCOLOR ist empfindlich gegen¨ uber der Reihenfolge der Knotennumerierung. Man kann zeigen, dass f¨ ur chordale Graphen 5 das F¨arbungsproblem in polynomieller Zeit gel¨ost werden kann, da diese Graphen erlauben, eine Reihenfolge zu definieren, bei der bereits gef¨arbte Knoten nicht mehr umgef¨arbt werden m¨ ussen um eine optimale F¨arbung zu erzielen. Der Berechnungsaufwand zum Test, ob ein Graph chordal ist und zur Berechnung einer entsprechenden Graphf¨arbung ist O(|V | + |E|) [14]. F¨ ur eine 6 Teilklasse chordaler Graphen, sogenannte Intervallgraphen wollen wir noch einen bekannten Algorithmus vorstellen. Intervallgraphen spielen bei der Optimierung von Schaltkreisen (z.B. Kanalverdrahtung) eine grosse Rolle. Oft spezifiert man beispielsweise Probleme u ¨ber Intervalle [li , hi ], i ∈ {1, · · · , |I|}. Diese induzieren einen Intervallgraphen. Der folgende exakte Algorithmus [16] mit Komplexit¨at O(|V |log|V |) wird h¨aufig benutzt zur L¨osung des Graphf¨arbungsproblems. 5

Ein ungerichteter Graph heisse chordal, wenn jeder Zyklus u ¨ ber mehr als drei Kanten eine Kante (chord) enth¨ alt, die inzident mit zwei nicht aufeinanderfolgenden Knoten dieses Zyklus ist. 6 Ein Intervallgraph ist ein chordaler Graph mit der Eigenschaft, dass man mit jedem Knoten ein nichtleeres Intervall assoziieren kann, so dass zwei Knoten genau dann adjazent sind, wenn sich ihre Intervalle u ¨ berschneiden.

4.4. ALGORITHMEN ZUR BINDUNG

115

LEFTEDGE(I) { Sortiere Elemente von I in Liste L aufsteigender Reihenfolge li ; c := 0; WHILE (∃ noch nicht gef¨arbtes Intervall) { S := { }; h := 0; /* initialisiere gr¨osste rechte Grenze von Elementen in S */ WHILE (∃ Element in L, deren linke Grenze gr¨osser h ) { s := erstes Element in L mit ls >= h; S := S ∪ {s}; h := hs ; L¨osche s aus L; } c := c + 1; F¨arbe die Knoten in S mit Farbe c; } } Beispiel 4.36 Wir betrachten den Intervallgraphen in Abb. 4.31a). Abb. 4.31b) zeigt die sortierten Intervalle, Abb. 4.31c) den gef¨arbten Graphen und Abb. 4.31d) gepackte Intervalle.

4.4.2

Bindung nach Ablaufplanung

Im Falle der Bindung nach erfolgter Ablaufplanung ist man bereits im Besitz eines Intervallgraphen. Sei τ (vi ) der Startzeitpunkt von Operation vi , dann gilt f¨ ur das Intervall seiner Ausf¨ uhrung [τ (vi ), τ (vi )+wi −1]. Diese Intervalle bestimmen die Kanten im Konfliktgraphen nach Ablaufplanung. Eine optimale Bindung mit dem LEFTEDGE Algorithmus kann in polynomieller Zeit bestimmt werden. Man betrachtet die F¨arbung der einzelnen Ressourcetypen getrennt voneinander. Beispiel 4.37 Abb. 4.32 zeigt den Intervallgraph und eine F¨arbung mittels LEFTEDGE Algorithmus f¨ ur das Beispiel in Abb. 4.1. Man ben¨otigt 4 Instanzen des Ressourcetyps Multiplizierer und 2 Instanzen des Typs ALU.

4.4.3

Bindung hierarchischer Graphen

Ein einfacher Ansatz der Bindung hierarchischer Graphen besteht darin, jede Einheit des Sequenzgraphen getrennt zu betrachten. Eine geeignete Methode, die Vertr¨aglichkeit u ¨ber Hierarchiegrenzen zu ermitteln, ist die Aufl¨osung der Hierarchie. Es sei hier nur am Rande erw¨ahnt, dass die Berechnung von Vertr¨aglichkeits- und Konfliktgraphen zwar genauso erfolgt wie bisher, jedoch haben diese Graphen i.a. nicht mehr die Eigenschaften, chordal bzw. Intervallgraphen zu sein. Folglich muss man sich mit Heuristiken behelfen.

4.4.4

Bindung vor Ablaufplanung

Oft ist es interessant, die Bindung vor der Ablaufplanung durchzuf¨ uhren. Beispielsweise erh¨alt man auf der Ebene der Architektursynthese eine akkuratere Absch¨atzung von Fl¨ache bzw. Speicherbedarf, wenn die Bindung schon erfolgt ist.

116

KAPITEL 4. SYNTHESE

a) Intervallgraph

b) Sortierte Intervalle 0 1 2 3 4 5 6 7 8

1

6

1 6

7

4

4

3

7 2 2

5

3 5

c) 1

d) gepackte Intervalle

6

0 1 2 3 4 5 6 7 8 1 7

4

3

2

6

7

3 5

4 2

5

Abbildung 4.31: Demonstration des Algorithmus LEFTEDGE zur F¨arbung von Intervallgraphen.

4.4. ALGORITHMEN ZUR BINDUNG b) Sortierte Intervalle

d) gepackte Intervalle

Multiplizierer ALU 0 1 2 3 4 0 1 2 3 4

Multiplizierer ALU 0 1 2 3 4 0 1 2 3 4 1 3

10

1

117

2

9

2 7

6

11

6 4

8 3

10 9 4 5 11

8 5

7

Abbildung 4.32: Intervallgraph und F¨arbung mittels LEFTEDGE Algorithmus f¨ ur den Sequenzgraphen in Abb. 4.1 Den Fall der Minimierung der Kosten entspricht dem trivialen Fall der Benutzung nur einer Instanz eines jeden Ressourcentyps. Im Gegensatz zur Benutzung der Ablaufvertr¨aglichkeit benutzt man hier die Definition von schwacher Vertr¨aglichkeit. Die Partitionierung des Vertr¨aglichkeitsgraphen bzw. F¨arbung des Konfliktgraphen ist in diesem Falle trivial (siehe z.B. Abb. 4.29a)). F¨ ur jeden Ressourcetyp muss man anschliessend alle Operationen sequentialisieren, da diese nicht nebenl¨aufig geplant werden k¨onnen. Diese Aufgabe heisst Konfliktaufl¨osung und erfolgt durch Einf¨ uhrung geeigneter Sequentialisierungskanten im Sequenzgraphen. Beispielsweise kann man einen latenzoptimalen Ablaufplan unter der Allokation, dass es von jedem Ressourcetyp nur eine Instanz gibt, bestimmen. Oder man f¨ uhrt einfach Sequentialisierungskanten ein, die konsistent mit der durch den Sequenzgraphen implizierten Partialordnung sind. Eine andere Definition von Vertr¨aglichkeit, die keiner Einf¨ uhrung von Sequentialisierungskanten bedarf und damit die Latenz von Ablaufpl¨anen nicht beeinflusst, ist die der starken Vertr¨aglichkeit. Da die Definition besagt, dass zwei Operationen auf einem gerichteten Pfad liegen, impliziert eine Bindung keine weiteren Sequentialisierungskanten. Der Vertr¨aglichkeitsgraph bei starker Vertr¨aglichkeit ist der ungerichtete Graph, den man durch Bildung der transitiven H¨ ulle des Sequenzgraphen (ohne Betrachtung von Quell- und Senkeknoten) erh¨alt. Das Bindungsproblem l¨asst sich auch hier in polynomieller Zeit exakt l¨osen.

118

KAPITEL 4. SYNTHESE

Kapitel 5

Beispiele zur Architektursynthese 5.1

Architekturbewertungen

In den vergangenen Kapiteln wurden graphische und algorithmische Modelle zur Beschreibung von Schaltungen vorgestellt. Es wurden auf ganzzahliger linearer Programmierung basierende Planungsverfahren entwickelt, mit denen die Synthese solcher Systeme durchgef¨ uhrt werden kann. Es ist jetzt notwendig, die Konzepte einzuf¨ uhren, mit denen es m¨oglich ist, Architekturen auf ihre Leistungsf¨ahigkeit hin zu untersuchen und entsprechend zu bewerten. Architekturen k¨onnen mit unterschiedlichen Leistungsmassst¨aben bewertet werden. Ein in vielen Optimierungsproblemen auftretendes Dilemma besteht darin, dass die Leistungsverbesserung einer Architektur hinsichtlich eines Kriteriums κ1 die Verschlechterung hinsichtlich eines anderen Kriteriums κ2 bedeutet. Ein Beispiel ist die Verbesserung der Durchsatzrate einer CMOS-Schaltung durch Erh¨ohung der Taktfrequenz, was jedoch eine Erh¨ohung des dynamischen Leistungsverbrauchs bewirkt.

5.1.1

Verarbeitungsgeschwindigkeit

Zwei wichtige Kriterien zur Beurteilung der Verarbeitungsgeschwindigkeit einer Schaltung sind das Iterationsintervall P und die Latenz L. Das Iterationsintervall P ist ein direktes Mass f¨ ur die Geschwindigkeit, mit der eine Schaltung einen Strom von Eingangsdaten verarbeiten kann. Die Latenz L beschreibt die Geschwindigkeit, mit der ein Satz von Eingabedaten vollst¨andig bearbeitet wird. Zum Kontrollschritt t = ti beginnt die Verarbeitung der zur i-ten Iteration geh¨origen Menge von Eingangsdaten δ(i). Die Verarbeitung der n¨achsten Menge von Eingangsdaten δ(i + 1) beginnt entsprechend zum Zeitpunkt ti + P . Zum Zeitpunkt ti + L stehen alle δ(i) entsprechenden Ausgangsdaten zur Verf¨ ugung.

5.1.2

Auslastung von Ressourcen

Zur Beurteilung der Leistungsf¨ahigkeit einer Architektur geh¨ort neben der Beurteilung der Verarbeitungsgeschwindigkeit auch die Frage, wie gut die eingesetzten Ressourcen einer Implementierung ausgenutzt werden. Definition 5.1 (Effizienz eines Ressourcetypen) Die Effizienz E(rk ) eines Ressourcetyps rk ist die mittlere Zahl belegter Ressourcen durch die Zahl allozierter Ressourcen α(rk ). 119

120

KAPITEL 5. BEISPIELE ZUR ARCHITEKTURSYNTHESE

Entsprechend ist auch die Effizienz einer einzelnen Ressource definiert. So ist zum Beispiel die Effizienz E(p) eines Prozessors p der Bruchteil des Iterationsintervalls, w¨ahrend dem der Prozessor p Daten verarbeitet. Die Effizienz ist mithin ein wichtiges Entscheidungskriterium f¨ ur die Zuordnung von Operationen zu Prozessoren. Es kann etwa sinnvoll sein einen schlecht ausgelasteten Spezialprozessor, der viel Fl¨ache ben¨otigt, durch einen besser ausgelasteten Universalprozessor zu ersetzen, falls ein damit verbundener Verlust an Verarbeitungsgeschwindigkeit tolerierbar ist.

5.1.3

Auslastung von Architekturen

Der Lastausgleichsfaktor Z ist ein Mass zur Bewertung der Auslastungen der einzelnen Ressourcen einer Architektur. Definition 5.2 (Lastausgleichsfaktor eines Ressourcetypen) Gegeben seien die entsprechend Definition 5.1 definierten Effizienzen einer Ressource. Dann gilt f¨ ur den Lastausgleichsfaktor eines Ressourcetypen rk : Z(rk ) :=

min{E(p) : alle Ressourcen p eines Ressourcetypen rk } max{E(p) : alle Ressourcen p eines Ressourcetypen rk }

(5.1)

Der Lastausgleichsfaktor Z gibt daher das Verh¨altnis von minimaler zu maximaler Auslastung der Ressourcen eines Ressourcetypen an. Falls zum Beispiel alle Prozessoren eines Prozessortyps r gleichm¨assig ausgelastet sind, ist mit Z(r) = 1 der Lastausgleichsfaktor maximal. Die Effizienz E(r) dieses Prozessortyps r ist dann durch die Effizienz der einzelnen Prozessoren p gegeben E(r) = E(p)

∀

Prozessoren p des Typs r

(5.2)

In allen anderen F¨allen ist die Effizienz E(r) wie folgt begrenzt: E(p) · Z ≤ E(r) ≤ E(p)/Z

(5.3)

Bedingung zur guten Auslastung einer Schaltung sind also sowohl gleichm¨assige als auch hohe Auslastung der Prozessoren.

5.1.4

Fliessbandtiefe

Wie im vergangenen Kapitel dargestellt wurde, kann durch funktionale Fliessbandverarbeitung die Durchsatzrate einer Schaltung gesteigert werden. Das Verh¨altnis aus Latenz L und Iterationsintervall P wird als (funktionaler) Fliessbandfaktor F bezeichnet. Definition 5.3 (Fliessbandfaktor) Der Fliessbandfaktor F wird als Quotient aus Latenz L und Iterationsintervall P berechnet: L F = (5.4) P Es gibt dementsprechend Zeitschritte, an denen Berechnungen und Speicheroperationen auf Daten in dF e verschiedenen Iterationen durchgef¨ uhrt werden. Werden nun die Daten einer Operation vi mit (vi , vj ) ∈ ES u ber mehrere Iterationen gespeichert bis sie von ¨ vj benutzt werden, so muss der Speicher entsprechend vergr¨ossert werden. In einer rein seriellen Anwendung mit L = P ist der Speicherbedarf nach unten durch die Operation mit dem gr¨ossten Bedarf begrenzt. Der Fliessbandfaktor F hat mithin Einfluss auf die Gr¨osse des notwendigen Speichers und auf die Komplexit¨at des Kontrollbausteins f¨ ur den Speicher.

¨ EIN DIGITALES FILTER 5.2. ARCHITEKTURENTWURF FUR

5.2

121

Architekturentwurf fu ¨r ein digitales Filter

In diesem Abschnitt wird die Anwendung der Verfahren auf den Entwurf eines digitalen elliptischen Filters 5. Ordnung nach [32] gezeigt. Der Sequenzgraph des Filters ist in Abbildung 5.1 dargestellt. Die Knoten A und O stellen Ein- und Ausgang der Schaltung dar, w¨ahrend die Knoten 1, . . . , 27 Additionen und die Knoten a, . . . , h Multiplikationen repr¨asentieren. Die dicker dargestellten Querstriche in den Kanten stellen Indexverschiebungen um eine Iteration dar. Zur Ausf¨ uhrung der Operationen stehen Addierer und Multiplizierer zur Verf¨ ugung, deren Rechenzeiten eine beziehungsweise zwei Taktzyklen betragen. Die folgenden beiden Konfigurationen werden untersucht: • F¨ ur die ersten Untersuchungen wurde nur der azyklische Abh¨angigkeitsgraph betrachtet; er geht aus dem Abh¨angigkeitsgraph nach Abbildung 5.1 hervor, indem die Kanten, die eine Indexverschiebung enthalten, entfernt wurden und anschliessend die Knoten 3, 23, 24, 14, 26, 27, 21 mit dem Schaltungsausgang und die Knoten 2, 22, 23, 6, 10, 17, 25, 26, 19, 20 mit dem Eingang verbunden wurden. F¨ ur diese Konfiguration wurden Ablaufpl¨ane ermittelt, wobei f¨ ur ein vorgegeben Iterationsintervall mit der zugeh¨origen minimalen Latenz der Bedarf an arithmetischen Einheiten optimiert wurde. Demzufolge fehlen also die Datenabh¨angigkeiten zwischen Iterationen. • In einer weiteren Untersuchungsreihe wurden Ablaufpl¨ane f¨ ur den zyklischen Abh¨angigkeitsgraphen nach Bild 5.1 berechnet. Auch hier wurden f¨ ur vorgegebene Werte des Iterationsintervalls der Verbrauch an Ressourcen unter Annahme minimaler Latenz optimiert. In Tabelle 5.1 sind die Ergebnisse zusammengefasst. Die Spalten P und L stellen die Werte des Iterationsintervalls P und der zugeh¨origen minimalen Latenz L dar, f¨ ur die Planungen der Filters berechnet wurden. Die Spalten + und × geben die mindestens notwendige Anzahl von Addierern und Multiplizierern zur Realisierung der Ablaufpl¨ane an. Die Geschwindigkeit, mit der die L¨osungen ermittelt wurden, wird in der Spalte I angegeben; es ist die Anzahl von Iterationen des Simplex Algorithmus, die das verwendete Programmpaket durchf¨ uhrte. Die in Tabelle 5.1 dargestellten Ergebnisse zeigen, dass bei Erh¨ohung P 16 17 18 19 20 21

L 19 19 19 19 20 21

+ 3 2 2 2 2 2

zyklisch × I 2 3440 2 638 2 211 2 294 2 322 1 349

azyklisch + × I 2 2 288 2 2 481 2 2 153 2 2 306 2 2 282 2 1 293

Tabelle 5.1: Ergebnisse f¨ ur das elliptische Filter

des Iterationsintervalls der Hardwareverbrauch gesenkt werden kann. Man kann also auf Kosten der Durchsatzrate den Bedarf an Hardware reduzieren. Bei konstant gehaltenem Iterationsintervall kann man durch Erh¨ohen der Latenz ebenfalls den Hardwareverbrauch

h g

21 18

e

17

14 13

d c

7

b

3

a

A

1

2

4

22

5

6

24

8

9

10

12

15

25

16

26

26

19

20

f

O

KAPITEL 5. BEISPIELE ZUR ARCHITEKTURSYNTHESE

23

122

Abbildung 5.1: Digitales elliptisches Filter f¨ unfter Ordnung

¨ EIN DIGITALES FILTER 5.2. ARCHITEKTURENTWURF FUR

123

Abbildung 5.2: Ablaufplan eines digitalen elliptischen Filters

senken. Im Fall des azyklischen Abh¨ angigkeitsgraphen wurden f¨ ur unterschiedliche Werte des Iterationsintervalls Ablaufpl¨ane mit gr¨osserer Latenz als in Tabelle 5.1 dargestellt berechnet. Die Resultate sind in Tabelle 5.2 angegeben. Bei einem Iterationsintervall von P = 17 Kontrollschritten kann bei einer Erh¨ohung der zul¨assigen Latenz L von 19 auf 20 Kontrollschritte eine Realisierung gefunden werden, die nur einen Multiplizierer ben¨otigt. In Abbildung 5.2 ist der Vollst¨andigkeit halber noch ein Ablaufplan f¨ ur das digitale Filter

P 16 17 18 19

L 19 20 21 22

+ 2 2 2 2

× 2 1 1 1

Tabelle 5.2: Ergebnisse f¨ ur das elliptische Filter, azyklischer Sequenzgraph

dargestellt; es ist ein Ergebnis f¨ ur den azyklischen Fall bei einem Iterationsintervall von P = 16 Kontrollschritten und einer Latenz von L = 19 Kontrollschritten, wobei die Anzahl ben¨otigtet Addierer und Multiplizierer minimiert wurde.

124

KAPITEL 5. BEISPIELE ZUR ARCHITEKTURSYNTHESE

5.3

Speicher

Als Voraussetzung f¨ ur das folgende Beispiel wird noch kurz auf die Modellierung des Speicherbedarfs einer Schaltungsarchitektur eingegangen. Eine zentrale Rolle beim Entwurf von Schaltungen auf Architekturebene ist die korrekte Modellierung, Synthese und Optimierung des Speicherbedarfs. Die folgenden Punkte motivieren den Bedarf an speziellen Entwurfsm¨oglichkeiten f¨ ur Speicher und grenzen die Anforderungen an Entwurfssysteme der Systemebene gegen¨ uber denen anderer Entwurfsebenen ab. • Beim Entwurf von Datenpfadsystemen auf algorithmischer Ebene wird der Speicher als Register in den Datenpfaden modelliert ([22, 10]). Beim Entwurf von Multiprozessorsystemen auf der Systemebene wird neben den Registern der einzelnen Prozessoren schneller Speicher ben¨otigt, in dem Berechnungsergebnisse abgelegt werden k¨onnen. Dies kann zur Zwischenspeicherung w¨ahrend der Bearbeitung einer Operation notwendig sein oder um Ergebnisdaten abzulegen, die sp¨ater als Eingangsdaten von anderen Operationen ben¨otigt werden. Derartige Cache“-Speicher werden als ” Speicherb¨anke auf dem Prozessor selbst oder als externe Module realisiert. Neben dem Speicher m¨ ussen geeignete Verbindungsstrukturen entworfen werden, mit deren Hilfe der Datenaustausch abgewickelt wird. • Eine grundlegende Gr¨osse bei der Betrachtung des Speicherbedarfs ist die Fl¨ache, da sie einen nicht zu vernachl¨assigenden Anteil an der gesamten Schaltungsfl¨ache einnimmt. Der Optimierung des Speicherbedarfs kommt daher eine wichtige Rolle bei der Schaltungssynthese zu. • Speichermodule k¨onnen f¨ ur einzelne Prozessoren reserviert sein oder mehrere Prozessoren k¨onnen sich ein Speichemodul teilen. Das Teilen von Speichermodulen (shared memory) bietet den Vorteil besserer Ausnutzung und des Wegfalls von Kopieroperationen zwischen Speichermodulen, wenn Daten zwischen Prozessoren ausgetauscht werden. In diesem Fall m¨ ussen allerdings Zugriffskonflikte durch gemeinsamen Zugriff von Prozessoren verhindert werden. • Eine weitere wichtige Anforderung an ein Synthesewerkzeug ist neben der reinen Optimierung der Gr¨osse des Speichers die M¨oglichkeit, Operationen bestimmten Speicherbereichen zuweisen zu k¨onnen. • Da die Daten der Operationen auf Speicherb¨anken abgelegt werden, ist die genaue Berechnung der Lebenszeit von Variablen von besonderer Wichtigkeit.

5.3.1

Lebenszeit von Variablen

Die exakte Berechnung der Lebenszeit von Variablen ist von essentieller Bedeutung f¨ ur die korrekte Berechnung des Speicherbedarfs. F¨ ur jede Kante (vi , vj ) ∈ ES kann ein Transfer von Daten von der generierenden Operation vi zu der benutzenden Operation vj stattfinden. Die von vi erzeugten Daten m¨ ussen im Speicher verweilen, bis sie von vj benutzt werden. Im hier benutzten Modell f¨ ur den Transfer von Daten werden die folgenden Annahmen getroffen: • G¨ ultige Ausgangsdaten einer Operation vi werden vom Kontrollschritt t = τ (vi ) an erzeugt, an dem die Ausf¨ uhrung von vi beginnt.

5.3. SPEICHER

125

• Alle Operationen vj , die direkt datenabh¨angig von vi sind, benutzen den gleichen Satz von Ausgangsdaten. • Die von vi erzeugten Ausgangsdaten verweilen bis zum Kontrollschritt t = τ (vj ) im Speicher, an dem die Ausf¨ uhrung der letzten Operation vj beginnt, die direkt von vi datenabh¨angig ist. • Die Gr¨osse des f¨ ur eine Operation reservierten Speicherbereichs ¨andert sich nicht w¨ahrend der Kontrollschritte, an denen auf den Bereich zugegriffen wird. • Speicherbereiche, die nicht mehr ben¨otigt werden, um Daten zu speichern, k¨onnen anschliessend von anderen Operationen benutzt werden. Definition 5.4 (Lebenszeit von Variablen) Gegeben sei ein Sequenzgraph GS . Es seien τ (vi ) und τ (vj ) die Kontrollschritte, an denen die Ausf¨ uhrung einer Operation vi beziehungsweise einer von vi datenabh¨angigen Operation vj mit (vi , vj ) ∈ ES beginnen. Die Lebenszeit der Variablen, die von der Operation vi generiert werden, ist die Anzahl von Kontrollschritten τ (vk ) − τ (vi ), f¨ ur die gilt: τ (vk ) = max{τ (vj ) : (vi , vj ) ∈ ES } Die Lebenszeit der von einer Operation vi erzeugten Variablen ist daher das Intervall zwischen dem Kontrollschritt τ (vi ), an dem die Ausf¨ uhrung von vi beginnt, und dem letzten Kontrollschritt τ (vk ), an dem die Ausf¨ uhrung einer direkt von vi datenabh¨angigen Operation vj beginnt. Es wird demnach von der Annahme ausgegangen, dass mit dem Beginn der Ausf¨ uhrung einer Operation g¨ ultige Daten f¨ ur nachfolgende Operationen zur Verf¨ ugung stehen. Es ist hier lediglich angemerkt, dass sich auch die Lebenszeiten von Variablen in Form linearer Gleichungen und Ungleichungen darstellen lassen. Hierzu werden neue Variablen zi,t bestimmt mit (

zi,t =

5.3.2

1 : w¨ahrend der Lebenszeit der von vi erzeugten Variablen 0 : sonst

Modellierung des Speicherbedarfs

Nachdem im letzten Abschnitt die Lebenszeit von Variablen definiert wurde und Methoden zur ihrer exakten Berechnung angedeutet wurden, kann jetzt der Speicherbedarf von Operationen modelliert und berechnet werden. Der Speicherbedarf von Operationen wird nach Arbeitsspeicher und Transferspeicher unterschieden. Diese rein konzeptionelle Unterteilung betrifft nur die Modellbildung. Der errechnete Bedarf einer Operation an Arbeitsspeicher beziehungsweise Transferspeicher kann auf dem gleichen Speicherbaustein zur Verf¨ ugung gestellt werden. Ein geeignetes Werkzeug zur Modellierung des Speicherbedarfs von Operationen bez¨ uglich Transfer- und Arbeitsspeicher sind wieder die zur Modellierung des Prozessorbedarfs verwendeten Ressourcegraphen. Die Knoten stellen nun die Operationen des Sequenzgraphen sowie Speichermodule dar, die Kanten ordnen den Operationen die Speichermodule zu. Die Kantengewichte geben die Gr¨osse der von den Operation erzeugten Datenmenge an, die dann auf dem zugeordneten Speichermodul abgelegt wird. Die Gr¨osse des auf einem Modul zur Verf¨ ugung stehenden Speicherbereichs (Allokation) wird den Knoten der Speichermodule zugeordnet. Die Konzepte von Arbeits- und Transferspeicher werden nun n¨aher erl¨autert.

126

KAPITEL 5. BEISPIELE ZUR ARCHITEKTURSYNTHESE

Transferspeicher Die Ergebnisdaten einer Operation vi m¨ ussen allen von ihr direkt datenabh¨angigen Operationen vj mit (vi , vj ) ∈ ES zur Verf¨ ugung stehen. Es wird davon ausgegangen, dass g¨ ultige Ausgangsdaten vom Beginn der Ausf¨ uhrung einer Operation vi an produziert werden; sie werden solange im Speicher gehalten, bis die Ausf¨ uhrung der letzten Operation vj , die direkt von vi abh¨angt, beginnt. Die Definition der Lebenszeiten von Variablen impliziert direkt, dass der Transferspeicher mit Hilfe der Variablen zi,t mit Hilfe linearer Gleichungen berechnet werden kann. Arbeitsspeicher W¨ahrend der Ausf¨ uhrung einer Operation werden nicht nur Ergebnisdaten f¨ ur nachfolgende Operationen erzeugt; ebenso werden Daten und Zwischenresultate, die sp¨ater in der Berechnung ben¨otigt werden, gespeichert und gelesen. Der Speicherbereich, der f¨ ur diesen Zweck reserviert ist, wird Arbeitsspeicher genannt. Operationen ben¨otigen Arbeitsspeicher nur w¨ahrend ihrer Ausf¨ uhrungszeit; es liegt daher nahe, dass der Bedarf an Arbeitsspeicher auf gleiche Weise wie die Belegung einer Prozessorressource abgleitet werden kann. Zugriffskonflikte Beim konkurrierenden Zugriff mehrerer Prozessoren auf gemeinsame Speichermodule kann es zu Zugriffskonflikten kommen. Zugriffskonflikte auf Speichermodule lassen sich durch Verwendung von n-Tor Speicher vermeiden, wenn n gen¨ ugend gross ist. Der Aufwand zur Realisierung und Steuerung von Speicher mit vielen Toren, auf die gleichzeitig gelesen und geschrieben wird, ist jedoch sehr gross. Es ist daher vern¨ unftig, anzunehmen, dass die Tore von Speicher als eigene Ressource anzusehen sind; Zugriffskonflikte k¨onnen dann vermieden werden, wenn zu keinem Kontrollschritt mehr als die jeweils zur Verf¨ ugung stehende Anzahl von Toren f¨ ur Schreib- und Lesezugriffe benutzt wird. Die geeignete Modellierung ist wieder ein Ressourcegraph. Hierbei modellieren die Knoten die Operationen sowie die Tore der Speichermodule. Eine Kante stellt den Zugriff einer Operation auf das entsprechende Speichertor dar. Die auf einem Speichermodul zur Verf¨ ugung stehende Anzahl von Toren ist den Tor-Knoten zugeordnet.

5.4

Anwendung der Verfahren auf einen Videokodierer

Die im vergangenen Abschnitt dargestellten Verfahren und Methoden werden nun benutzt, um verschiedene M¨oglichkeiten der Implementierung eines hybriden Videokodierers nach CCITT Empfehlung H.261 zu entwerfen und zu vergleichen. Die zugrundegelegten Architekturparameter wurden [21] entnommen. Der Vollst¨andigkeit halber soll hier nochmals der Algorithmus erl¨autert werden. Bild 5.3 zeigt das vereinfachte Blockschaltbild der Kodierschleife. Der Bildaufbau des in Standard CCITT H.261 unterst¨ utzten Common Intermediate Format ist in Abbildung 5.4 dargestellt. In Abbildung 5.5 ist die Anordnung der Informationen f¨ ur Luminanz Y und Chrominanz Cr und Cb dargestellt. Das grundlegende Datenformat in der Kodierschleife sind die Makrobl¨ ocke. Jeder Makroblock besteht aus einem Block von 16×16 Bildpunkten, der die Luminanzinformation enth¨alt sowie einem 8 × 8 Block, der die Chrominanzinformationen enth¨alt.

5.4. ANWENDUNG DER VERFAHREN AUF EINEN VIDEOKODIERER

127

Komprimierter Bitstrom RLC Inverse

Referenz

Vorhersage BM

DIFF

DCT

Q

IQ

IDCT

REC

Suchfenster

Abbildung 5.3: Kodierschleife nach CCITT H.261

352 Pixel Cr

176 Pixel 144 Zeilen

Y

144 Zeilen

288 Zeilen

176 Pixel

Cb

Abbildung 5.4: Bildaufbau des Common Intermediate Format f¨ ur Video Quellen nach H.261

Y-Werte C r- und C b -Werte

Abbildung 5.5: Anordnung der Luminanz- und Chrominanzinformation

128

KAPITEL 5. BEISPIELE ZUR ARCHITEKTURSYNTHESE

IN

DIFF

DCT

TH

Q

BM

LF

REC

IDCT

IQ

RLC

Abbildung 5.6: Abh¨angigkeitsgraph eines einfachen Videokodierers Die wichtigsten Funktionsbl¨ocke der Kodierschleife werden kurz beschrieben, um ihre Implementierungsm¨oglichkeiten in Hardware besser verstehen zu k¨onnen ([30]). Die Schl¨ usseltechniken eines Videokodierers nach H.261 sind diskrete Cosinustransformation, Bewegungssch¨atzung (motion estimation) durch Blockvergleich (block matching) und zweidimensionale variable Laufl¨angenkodierung (run length coding). Mit diskreter Cosinustransformation (DCT), Quantisierung (Q) und Laufl¨angenkodierung (RLC) werden die Daten innerhalb eines Makroblocks komprimiert, durch die Bewegungssch¨atzung (ME) werden die Daten zwischen zeitlich aufeinanderfolgenden Makrobl¨ocken komprimiert. Zur Bewegungssch¨atzung wird ein zu u ¨bertragender Makroblock mit den Makrobl¨ocken eines ¨ Suchfensters verglichen und nur der Verschiebungsvektor u ur den ein Ahn¨ bertragen, f¨ lichkeitskriterium zwischen Makrobl¨ocken maximal wird. In Abbildung 5.3 wird der zu u ¨bertragende Makroblock als Referenz bezeichnet. Der in dieser Implementierung eingesetzte Algorithmus f¨ ur den Blockvergleich besteht im wesentlichen aus der Berechnung von Differenzen und Absolutwerten; der Einsatz eines dedizierten Prozessors liegt also nah. Im Gegensatz zu den anderen Operationen wird die Bewegungssch¨atzung nur auf der Luminanzinformationen ausgef¨ uhrt. Mit den inversen Operation IDCT und IQ sowie der Rekonstruktion REC wird der Bewegungsvektor wieder hergestellt. Zwischen den Operationen DCT und IDCT wird gegen¨ uber den restlichen Operationen der Kodierschleife mit doppelter Genauigkeit gerechnet.

5.4.1

Eine einfache Zielarchitektur

Die ersten Untersuchungen wurden an einem einfachen Grundalgorithmus und einer einfachen Zielarchitektur durchgef¨ uhrt. In Abbildung 5.6 ist der zugrunde liegende Datenabh¨angigkeitsgraph GD dargestellt; er l¨asst sich direkt aus dem Blockschaltbild des Videokodierers nach Abbildung 5.3 herleiten. Gegen¨ uber Abbildung 5.3 wurde die Bewegungssch¨atzung (ME) in Blockvergleich (BM) und Schleifenfilterung LF (Loop Filter) verfeinert. Weiterhin wurde die Quantisierung Q in die eigentliche Quantisierung und die variable Schwellwertbildung TH (Threshold) unterteilt. Die Zielarchitektur, auf die der Abh¨angigkeitsgraph nach Abbildung 5.6 abgebildet werden soll, ist in Bild 5.7 dargestellt. Die Architektur enth¨alt die drei Prozessoren BMM, DCTM und PUM. BMM und DCTM sind Spezialprozessoren, die zur Ausf¨ uhrung des Blockvergleichs BM beziehungsweise der diskreten Cosinustransformationen DCT und IDCT vorgesehen sind. Die restlichen Operationen werden auf dem allgemeinen Prozessor PUM abgearbeitet. Die Bewegungssch¨atzung wurde in Blockvergleich BM und Schleifenfilter LF aufgespalten; da nur BM auf BMM ausgef¨ uhrt wird, reduziert sich auf diesem Prozessor die Rechenzeit. Alle Prozessoren sind mit einem gemeinsamen Zwischenspeicher verbunden, der die w¨ahrend

5.4. ANWENDUNG DER VERFAHREN AUF EINEN VIDEOKODIERER

129

Bildspeicher BUS

Zwischenspeicher

BMM

DCTM

PUM

Abbildung 5.7: Zielarchitektur eines einfachen Videokodierers einer Iteration ben¨otigten Daten speichert. Der Zwischenspeicher seinerseits ist u ¨ ber einen Bus mit dem Bildspeicher verbunden, aus dem u ber die IN-Operation die Daten f¨ ur Such¨ und Referenzgebiet entnommen werden. In Tabelle 5.3 sind die Operationen vi mit den entsprechenden Ausf¨ uhrungszeiten wi auf den ihnen zugeordneten Prozessoren sowie dem Bedarf an Transferspeicher µi und Arbeitsspeicher νi aufgef¨ uhrt. Die Ausf¨ uhrungszeiten sind in Vielfachen von dimensionslosen Kontrollschritten angegeben, die Einheiten f¨ ur den Speicherbedarf sind 8 × 8 Pixelbl¨ocke. Der Speicherbedarf von BM resultiert aus der Verarbeitung von 10 Bl¨ocken des Suchfensters, die die Luminanzinformation enthalten. Da zwischen DCT und IDCT die Daten mit doppelter Rechengenauigkeit verarbeitet werden, ist dort der Speicherbedarf entsprechend doppelt so gross wie bei den sonstigen Operationen. Die Aufspaltung des Speichers in Arbeits- und Transferspeicher l¨asst eine genaue Modellierung des Speicherbedarfs von Operationen zu. F¨ ur DCT betr¨agt der Bedarf an Arbeitsspeicher 6 Einheiten, w¨ahrend zur nachfolgenden Operation 12 Einheiten transferiert werden; IDCT arbeitet intern auf 12 Einheiten und u ¨ bertr¨agt nur 6 Einheiten zu REC. vi IN BM LF DIF DCT Q IQ IDCT REC TH RLC

wi 0 22 9 1 8 1 1 8 1 8 8

µi 0 40 6 6 6 12 12 12 6 12 12

νi 0 6 6 6 12 12 12 6 6 12 0

Prozessor BMM PUM PUM DCTM PUM PUM DCTM PUM PUM PUM

Tabelle 5.3: Ausf¨ uhrungszeiten und Speicherbedarf im einfachen Architekturmodell

130

KAPITEL 5. BEISPIELE ZUR ARCHITEKTURSYNTHESE

LF IDCT

Q IQ

TH

RLC BM

DCTM

DCT

IDCT

PUM

DIF REC

LF

Iterationsinterval = 29 Latenz = 71

BMM

0

5

10

15

20

25 Taktzyklen

Abbildung 5.8: Abfolge der Operationen

Die Architektursynthese wurde von einem Planungsverfahren f¨ ur funktionale Fliessbandverarbeitung mit Schleifenfaltung und Speicherberechnung durchgef¨ uhrt. Modulauswahl wurde nicht betrachtet. Bei dem minimal m¨oglichen Iterationsintervall von P = 29 Kontrollschritten und einer zugeh¨origen minimalen Latenz von L = 71 Kontrollschritten wurde eine Planung der Operationen ermittelt, wobei zus¨atzlich der Speicherbedarf minimiert wurde. Die Abbildungen 5.8 und 5.9 stellen die Abarbeitung der Operationen auf den entsprechenden Prozessoren aus unterschiedlichen Blickwinkeln dar. In Bild 5.8 werden funktionale Fliessbandverarbeitung und Schleifenfaltung illustriert: Aus dem Abh¨angigkeitsgraph nach Abbildung 5.6 geht hervor, dass LF vor IDCT ausgef¨ uhrt werden muss, wenn diese Operationen zur selben Iteration geh¨oren. Da nach Abbildung 5.8 die Operationen LF und IDCT gleichzeitig auf unterschiedlichen Prozessoren ausgef¨ uhrt werden, m¨ ussen diese Operationen zu verschiedenen Iterationen geh¨oren. Der Ablaufplan realisiert weiter Schleifenfaltung, wie aus der Tatsache hervorgeht, dass Beginn und Ende der Ausf¨ uhrung von LF und IDCT in aufeinanderfolgenden Iterationen liegen. In Abbildung 5.9 ist hingegen die Abfolge der Operationen w¨ahrend der Periode einer Latenz dargestellt. Es wird ersichtlich, dass die durch den Abh¨angigkeitsgraphen 5.6 implizierten Datenabh¨angigkeiten eingehalten werden. Die wichtigsten der in Abschnitt 5.1 definierten Leistungsmerkmale dieser einfachen Architektur sind in der folgenden Tabelle 5.4 zusammengestellt. Im hier betrachteten einfachen Architekturmodell greifen alle Verarbeitungselemente auf das gleiche Speichermodul zu. Der Beitrag von LF zum Gesamtspeicherbedarf ist exemplarisch in Abbildung 5.10 illustriert. Die Ausf¨ uhrung von Operation LF beginnt an Kontrollschritt t = 23. Von diesem Kontrollschritt an muss Arbeitsspeicher in der Gr¨osse von 6 Einheiten zur Ablage interner

5.4. ANWENDUNG DER VERFAHREN AUF EINEN VIDEOKODIERER

131

RLC

BM

DCTM

REC IDCT

Q IQ

DCT

PUM

TH

LF

DIF

Iterationsinterval = 29 Latenz = 71

BMM

0

5

10

15

20

25

30

35

40

45

50

60

55

65 70 Taktzyklen

Speicherbedar

Abbildung 5.9: Entfaltete Abfolge der Operationen

Start von LF 12

Start von REC

10

20

30

40

50

60 Taktzyklen

Abbildung 5.10: Speicherbedarf der Operation LF

132

KAPITEL 5. BEISPIELE ZUR ARCHITEKTURSYNTHESE Merkmal Iterationintervall P Latenz L Effizienz E(BM ) Effizienz E(DCT M ) Effizienz E(P U M ) Lastausgleichsfaktor Z Fliessbandfaktor F

Wert 29 71 0.76 0.27 1 0.27 2.5

Tabelle 5.4: Bewertung der einfachen Beispielarchitektur

Daten reserviert werden. Gleichzeitig wird begonnen, Transferspeicher ebenfalls in Gr¨osse von 6 Einheiten f¨ ur den Datentransport zu nachfolgenden Operationen zu reservieren. Die Ausf¨ uhrung von LF dauert 9 Kontrollschritte; von Kontrollschritt t = 23 bis t = 31 betr¨agt der gesamte Speicherbedarf also 12 Einheiten. An Kontrollschritt t = 32 wird der f¨ ur Arbeitsspeicher reservierte Bereich freigegeben und nur Transferspeicher gehalten. Die Ausf¨ uhrung der von LF datenabh¨angigen Operationen DIFF und REC beginnt an den Kontrollschritten t = 32 beziehungsweise t = 62. Da der Transferspeicher von LF reserviert bleibt, bis die Ausf¨ uhrung der letzten von LF datenabh¨angigen Operation beginnt, muss dieser Bereich bis zum Kontrollschritt t = 61 erhalten bleiben. Aus Abbildung 5.8 geht hervor, dass der Speicher an Kontrollschritt t = 62 wieder freigegeben ist. In diesem einfachen Architekturmodell wird angenommen, dass alle Operationen auf eine gemeinsame Speicherbank GC zugreifen. Der Gesamtspeicherbedarf ergibt sich daher als Summe der Erfordernisse der einzelnen Operationen, wie in Bild 5.11 f¨ ur die Dauer eines Iterationsintervalls dargestellt ist. Mit dem Iterationsintervall von P = 29 Kontrollschritten und einem maximalen Speicherbedarf von 94 Einheiten ergibt sich eine Effizienz des Speicher von E(GC) = 0.625 Die bis jetzt diskutierten Architekturparameter wie Ablaufplanung, Modulzuweisung, Latenz und Iterationsintervall beeinflussen stark den Speicherbedarf einer Implementie¨ rung. Die folgenden Uberlegungen dienen der Erkl¨arung dieser Abh¨angigkeiten. Das Erh¨ohen des Iterationsintervalls bei einer gegebenen Latenz reduziert den ¨ Fliessbandfaktor. Die daraus resultierende reduzierte Uberlappung von Iterationen kann zu einer Reduktion des ben¨otigten minimalen Speicherbedarfs f¨ uhren. Der minimale Speicherbedarf des Videokodierers nach Abbildung 5.6 mit den Kenndaten nach Tabelle 5.3 wurde f¨ ur zwei feste Werte der Latenz L bei ver¨anderlichem Iterationsintervall bestimmt. Die Ergebnisse der Versuchsreihe sind in Abbildung 5.12 dargestellt. Die obere Kurve entspricht einer maximalen Latenz von L = 71 Kontrollschritten; dies ist die minimal erreichbare Latenz bei dem kleinst m¨oglichen Iterationsintervall von P = 29 Kontrollschritten. Da es bei diesen Werten nur einen kleinen Freiheitsgrad bei der Ablaufplanung der Operationen gibt, kann es sogar zu einem Anstieg des ben¨otigten Speicherbedarfs kommen. Wie aus Abbildung 5.12 ferner hervorgeht, konnte f¨ ur Werte des Iterationsintervalls von P = 33, 34, 35 Kontrollschritten kein zul¨assiger Ablaufplan berechnet werden. Die sprungartige Abnahme im Speicherbedarf bei einem Iterationsintervall von P = 59 erkl¨art sich aus der Tatsache, dass in den entsprechenden Ablaufpl¨anen die Operation BM vor allen anderen Operationen ausgef¨ uhrt werden kann. Der Arbeitsspeicher von BM u ¨ berlappt

Speicherbedar

5.4. ANWENDUNG DER VERFAHREN AUF EINEN VIDEOKODIERER

90 84 78 72 66 60 54 48 10

5

20

15

25 Taktzyklen

Speicher

Abbildung 5.11: Gesamtspeicherbedarf

Latenz = 71

90

80 Latenz > 85 70

60

50 30

•

40

50

60 Iterationsintervall

Abbildung 5.12: Speicherbedarf als Funktion des Iterationsintervalls

133

134

KAPITEL 5. BEISPIELE ZUR ARCHITEKTURSYNTHESE

Abbildung 5.13: Vollst¨andiger Abh¨angigkeitsgraph eines Videokodierers sich daher nicht mehr mit dem Speicherbedarf der anderen Operationen. • Eine Vergr¨osserung der Latenz L bei festem Iterationsintervall f¨ uhrt im allgemeinen zu erh¨ohtem Speicherbedarf. Dies gilt dann, wenn die Latenz ausgenutzt wird, so dass der rechnerische Fliessbandfaktor F = L/P mit dem tats¨achlichen u ¨ bereinstimmt. Das Planungsverfahren sollte jedoch in der Lage sein, bei entsprechenden Zielfunktionen einen Ablaufplan so zu bestimmen, dass Optimalit¨at erzielt wird und die Anfangszeiten der Operationen innerhalb der Latenz entsprechend verteilt werden. So wird bei Optimierung des Speicherbedarf nach Abbildung 5.12 bei einem Iterationsintervall von P = 29 Kontrollschritten die Latenz von L = 71 Kontrollschritten ben¨otigt: Eine kleinere Latenz ist nicht m¨oglich und es ergibt sich ein Fliessbandfaktor von F = 2.5. Bei einem Iterationsintervall von P = 60 kann die Ausf¨ uhrung der letzten Operation schon an Kontrollschritt t = 60 begonnen werden, so dass sich ein Fliessbandfaktor von F = 1 ergibt. Entsprechend klein ist dann auch der Speicherbedarf. Andererseits geht aus Abbildung 5.12 auch hervor, dass es bei kleinem Iterationsintervall manchmal sinnvoll sein kann, die Latenz zu erh¨ohen, da dann dann die Anzahl von Kontrollschritten t erh¨oht wird, an denen die Ausf¨ uhrung einer Operation begonnen werden kann.

5.4.2

Ein realistisches Architekturbeispiel

In diesem Abschnitt werden ein genaueres Algorithmenmodell und realistischere Architekturmodelle des Videokodierers vorgestellt. Abbildung 5.13 und 5.14 stellen den Abh¨angigkeitsgraph und die Zielarchitektur dar. Dieses Beispiel zeigt, wie sich Algorithmen- und Architekturentwurf gegenseitig beeinflussen. Im allgemeinen wird bei Videokonferenzsystemen Sende- und Empfangsbetrieb gew¨ unscht. Der Videokodierer muss daher neben der Kodierschleife auch den umgekehrten Prozess gestatten. Der Algorithmus wurde daher um die Operationen des Dekodierers erweitert; es sind dies die inverse Laufl¨angenkodierung IRD, die inverse Quantisierung IQD, die inverse diskrete Cosinustransformation IDD, die Signalrekonstruktion RECD und die Schleifenfil-

5.4. ANWENDUNG DER VERFAHREN AUF EINEN VIDEOKODIERER

CPM

135

Bildspeicher BUS

BMC

BMM

GC

M1

M2

Abbildung 5.14: Realistische Zielarchitektur eines Videokodierers terung LFD. Zus¨atzlich eingef¨ uhrt wurden die Kopieroperationen CRB (Copy Reference Block), CSA (Copy Search Area) und CBM (Copy Best Match). Gegen¨ uber der in Bild 5.7 gezeigten Architektur sind die folgenden Ver¨anderungen vorgenommen worden: Zur Abarbeitung der Prozessoren sind drei Prozessoren BMM, M1 und M2 vorhanden. Der Algorithmus nach Bild 5.13 wurde auf zwei Zielarchitekturen nach Abbildung 5.14 abgebildet und die unterschiedlichen Leistungs- und Kostenparameter untersucht. Die Architekturen unterscheiden sich bez¨ uglich der Typen der Prozessoren M1 und M2 und der Zuweisung von Operationen zu den Prozessoren. Gemeinsam ist die Abarbeitung des Blockvergleichs BM auf einem Spezialprozessor BMM. • Modell 1 Die Zielarchitektur nach Modell 1 benutzt als Prozessorelemente M1 und M2 einen Vielzweckprozessor PUM und einen Spezialprozessor DCTM zur Ausf¨ uhrung der diskreten Cosinustransformationen. • Modell 2 In der Zielarchitektur nach Modell 2 werden zwei Vielzweckprozessoren PU1 und PU2 eingesetzt. Die Zuweisung der Operationen zu den Prozessoren ist nicht festgelegt; sie erfolgt durch Modulauswahl nach dem Kriterium der Minimierung von Iterationsintervall (gleichbedeutend mit Maximierung der Durchsatzrate) und der Optimierung des Speicherbedarfs. In Tabelle 5.5 sind die Parameter der Architekturen nach Modell 1 und Modell 2 aufgef¨ uhrt. Im Architekturmodell nach Abbildung 5.7 greifen alle Prozessoren auf einen gemeinsamen Speicher GC zu. Die realistischeren Architekturmodelle sehen zwei Speichermodule vor: Der Spezialprozessor BMM hat einen eigenen Speicher BMC, die Prozessoren M1 und M2 teilen sich einen gemeinsamen Speicher GC. Da die Prozessorelemente nur auf die ihnen zugeteilten Speicherelementen zugreifen k¨onnen, muss der Algorithmus so ver¨andert werden, dass zus¨atzliche Kopieroperationen die Daten zwischen den Speicherbl¨ocken kopieren, wenn die Daten zweier Operationen vi und vj mit (vi , vj ) ∈ ED in verschiedenen Speicherbl¨ocken abgelegt werden. Dies sind die Operationen CRB (Copy Reference Block), CSA (Copy Search Area) und CBM (Copy Best Match). Da diese Operationen von dem Kontrollbaustein des Speichers ausgef¨ uhrt werden, wird ihnen der dedizierte Prozessor CPM (Copy Module) zugeordnet.

136

KAPITEL 5. BEISPIELE ZUR ARCHITEKTURSYNTHESE vi ∈ ES IN BM LF DIF DCT Q IQ IDCT REC CRB CSA TH RLC IRD IQD IDD CBM RECD LFD

wi,k 0 22 9 1 8/4 1 1 8/4 1 1 1 8 8 1 1 8/4 1 1 9

µi,GC 0 0 6 6 6 12 12 12 6 0 0 12 12 6 6 6 0 6 6

νi,GC 0 0 6 6 12 12 12 6 6 6 0 12 0 6 6 6 6 0 6

µi,BM C 0 40 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6 0 0

νi,BM C 0 6 0 0 0 0 0 0 0 0 6 0 0 0 0 0 0 0 0

Ressourcetypen BMM PUM PUM DCTM/PUM PUM PUM DCTM/PUM PUM PUM PUM PUM PUM PUM PUM DCTM/PUM PUM PUM PUM

Tabelle 5.5: Parameter der Architekturen nach Modell 1 und 2

Mit den beschriebenen Planungsverfahren wurden Ablaufpl¨ane f¨ ur die obigen Architekturmodelle berechnet. In den Abbildungen 5.15 und 5.16 sind Ergebnisse f¨ ur Ablaufpl¨ane mit minimalem Iterationsintervall und der jeweils minimalen Latenz dargestellt. Die Ablaufpl¨ane beinhalten die Optimierung des Speicherbedarfs. Wie bereits erl¨autert, kann es bei konkurrierendem Zugriff von Prozessoren auf Speichermodule zu Zugriffskonflikten kommen. Im vorliegenden Fall greifen die Prozessoren CPM, M1 und M2 auf den gemeinsamen Speicher GC zu. Als Realisierungsform f¨ ur den Speicher sind Bausteine vorgesehen, die jeweils gleichzeitiges Lesen und Schreiben auf zwei Toren gestatten (dual ported RAM). Um den gemeinsamen Zugriff von CPM, M1 und M2 zu verhindern, werden die beiden Tore als Ressource betrachtet, von der nur zwei Exemplare zur Verf¨ ugung stehen. Wie aus Abbildung 5.16 hervorgeht, verhindert diese zus¨atzliche Bedingung, dass f¨ ur Modell 2 ein Ablaufplan mit dem theoretischen Minimum des Iterationsintervalls von γ = 27 Kontrollschritten berechnet werden kann. Andererseits m¨ usste zur Realisierung dieses unwesentlich schnelleren Ablaufplans ein bedeutend aufwendigerer Speicherbaustein eingesetzt werden. Bild 5.17 zeigt den Verlauf der Speicherbelegung f¨ ur Modell 2. Die Leistungsbewertungen f¨ ur die Architekturen nach Modell 1 und Modell 2 sind in Tabelle 5.6 zusammengestellt. Es ergibt sich direkt, dass Modell 2 hinsichtlich Verarbeitungsgeschwindigkeit die u ¨ berlegene Implementierung darstellt. Ausserdem ist offensichtlich, dass die Effizienz von Modell 2 h¨oher ist, da die Operationen gleichm¨assig auf die Module PU1 und PU2 aufgeteilt werden. Wie andererseits aus Tabelle 5.7 hervorgeht, ist der Fl¨achenverbrauch eines Universalprozessors PU h¨oher als der eines Spezialprozessors DCTM. Der Speicherbedarf von Modell 2 ist ebenfalls h¨oher als der von Modell 1;

5.4. ANWENDUNG DER VERFAHREN AUF EINEN VIDEOKODIERER

137

DIF LFD

LF IDD

BM

DCTM

REC IRD IQD

RLC IDCT

Q IQ

DCT

PUM

TH

LFD

CPM

RECD

CSA

CBM CRB

Iterationsinterval = 41 Latenz = 69

BMM

0

10

5

20

15

30

25

40 35 Taktzyklen

Abbildung 5.15: Ablaufplan f¨ ur Modell 1

BMM

0

5

10

15

20

Abbildung 5.16: Ablaufplan f¨ ur Modell 2

25 Taktzyklen

LF REC

IDCT

RECD

Q IQ IRD IQD

IDD

BM

PU1

TH

RLC

PU2

DCT

DIF

LF

CPM

LFD

CSA

CRB CBM

Iterationsinterval = 28 Latenz = 58

KAPITEL 5. BEISPIELE ZUR ARCHITEKTURSYNTHESE Cache size

138 54

GC

46

BMC

0

5

10

15

20

25 Clock cycles

Abbildung 5.17: Speicherbedarf des Videokodierers Parameter Iterationsintervall P Latenz L Speicherbedarf Effizienz E Lastausgleichsfaktor Z Fliessbandfaktor F

Modell 1 41 69 88 0.55 0.07 1.68

Modell 2 28 58 100 0.7 0.11 2.07

Tabelle 5.6: Leistungsbewertungen der Architekturen nach Modell 1 und Modell 2

dies lasst sich mit dem h¨oheren Fliessbandfaktor P erkl¨aren. Der erh¨ohte Speicherbedarf wirkt sich nat¨ urlich auf die Fl¨ache von einer Implementierung von Modell 2 aus. Die Optimierung dieser Kriterien kann einfach in das ganzzahlige lineare Programm u ¨ bernommen werden, indem man dem Speicherbedarf und den Verarbeitungsmodulen Kosten zuweist, die den Fl¨achenbedarf messen. Falls f¨ ur den Fl¨achenbedarf der Prozessoren die Angaben aus Tabelle 5.7 angenommen werden, folgt f¨ ur den Fl¨achenbedarf A der Architekturen nach Modell 1 und Modell 2: A(Modell 1) = 74 A(Modell 2) = 89 Um nun Verarbeitungsgeschwindigkeit und Fl¨achenbedarf einer Schaltung gegeneinander abwiegen zu k¨onnen, wurde das AT -Mass als das Produkt von Fl¨ache A und Durchsatzrate T einer Schaltung eingef¨ uhrt. Da die Durchsatzrate T mit dem Iterationsintervall P identisch ist, ergibt sich f¨ ur den Vergleich AT (Modell 1) = 3034 AT (Modell 2) = 2492

5.4. ANWENDUNG DER VERFAHREN AUF EINEN VIDEOKODIERER Modul BMM DCTM PUM ¨ Uberhang Speicher

139

Fl¨ache 4 8 20 20 0.25 / (8 × 8 Block)

Pipelining factor f

Tabelle 5.7: Fl¨achenbedarf der Module

Model 2

2

1.8

1.6

Model 1

1.4

1.2

28

30

32

34

36

38

40

42

44

48 46 50 Iteration interval

Abbildung 5.18: Vergleich der Fliessband-Faktoren Da ein m¨oglichst kleines AT -Produkt angestrebt wird, ist eine Realisierung mit dem Architekturmodell 2 vorzuziehen. In Abbildung 5.18 werden die Fliessband-Faktoren der beiden Architekturmodelle verglichen. Obwohl Modell 2 ein geringeres Iterationsintervall zul¨asst, hat es einen erh¨ohten Speicherbedarf. Dies, verbunden mit dem h¨oheren Fliessband-Faktor, kann zu einem erh¨ohten Aufwand bei der Adress-Generierung f¨ uhren.

140

KAPITEL 5. BEISPIELE ZUR ARCHITEKTURSYNTHESE

Literaturverzeichnis [1] B. Baumgarten. Petri-Netze Grundlagen und Anwendungen. BI Wissenschaftsverlag, Mannheim, 1990. [2] G. Berry. Programming a digital watch in ESTEREL. Technical Report 08–91, Centre de Mathematiques Appliquees, Ecole des Mines de Paris, Sophia-Antipolis, 1991. [3] F. Commoner and A.W. Holt. Marked directed graphs. Journal of Computer and System Sciences, 5:511–523, 1971. [4] T. Cormen, C. Leiserson, and R. Rivest. Introduction to Algorithms. McGraw-Hill, Cambridge, MA, 1990. [5] S. Davidson, D. Landskov, B.D. Shriver, and P.W. Mallett. Some experiments in local microcode compaction for horizontal machines. IEEE Transactions on Computers, C-30(7):460–477, 1981. [6] G. DeMicheli. Synthesis and Optimization of Digital Circuits. Mc Graw Hill, New York, 1994. [7] S. Devadas and R. Newton. Algorithms for hardware allocation in data-path synthesis. IEEE Trans. on CAS, CAD-8(7):768–781, 1989. [8] D. Gajski, F. Vahid, S. Naranyan, and J. Gong. Specification and Design of Embedded Systems. Prentice Hall, Englewood Cliffs, NJ, 1994. [9] M.R. Garey and D.S. Johnson. Computers and Intractability: A Guide to the Theory of NP-Completeness. Freeman, New York, 1976. [10] C. Gebotys and M. I. Elmasry. Global optimization approach for architectural synthesis. IEEE Journal on CAD, 12(9):1266–1278, September 1993. [11] David E. Goldberg. Genetic Algorithms in Search, Optimization and Machine Learning. Addison-Wesley Publishing Company, Inc., Reading, Massachusetts, 1989. [12] G. Goosens and other. An efficient microcode compiler for custom microprocessor DSP systems. In Proc. of the Int. Conf. on CAD, pages 24–27, 1987. [13] L. Hafer and A.C. Parker. A formal method for the specification, analysis and design of register-transfer digital logic. IEEE Transactions on Computer-Aided Design, CAD2:4–18, 1983. [14] F. Harary. Graph Theory. Addison-Wesley, Reading, MA, 1972. 141

142

LITERATURVERZEICHNIS

[15] D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8, 1987. [16] A. Hashimoto and J. Stevens. Wire routing by optimizing channel assignment within large apertures. In Proc. of the 8th Design Automation Workshop, pages 155–163, 1971. [17] C.A.R. Hoare. Communicating Sequential Processes. Prentice Hall, Englewood Cliffs, NJ, 1985. [18] John H. Holland. Adaption in Natural and Artificial Systems. Bradford Book, MIT Press, Cambridge, Massachusetts, 1992. [19] C.T. Hwang, J.H. Lee, and Y.C. Hsu. A formal approach to the scheduling problem in high level synthesis. IEEE Transactions on Computer-Aided Design, CAD-10(4):464– 475, April 1991. [20] IEEE. IEEE Standard VHDL Language Reference Manual. IEEE, IEEE STd. 10761987, 1987. [21] M. Sch¨obinger J. Wilberg and P. Pirsch. Hierarchical multiprocessor system for video signal processing. In Proc. SPIE, volume 1818, pages 1076–1087, 1992. [22] R. Kaneshiro, K. Konstantinides, and J. Tani. Task allocation and scheduling models for multiprocessor digital signal processing. IEEE Trans. on Accoustics, Speech and Signal Processing, 38(12):2151–2161, December 1990. [23] E.A. Lee and D.G. Messerschmitt. Synchronous dataflow. Proceedings of the IEEE, 75(9):1235–1245, 1987. [24] P. Marwedel. A new synthesis algorithm for the mimola software system. In Proc. of the 23rd Design Automation Conference, pages 271–277, ACM, IEEE, 1986. [25] M.C. McFarland, A.C. Parker, and R. Camposano. The high-level synthesis of digital systems. Proceedings of the IEEE, 78(2):301–318, February 1990. [26] R. Milner. A calculus of communicating systems. Lecture Notes in Computer Science, Springer Verlag, 92, 1980. [27] B. Pangrle and D. Gajski. Design tools for intelligent silicon compilation. IEEE Trans. on CAD, CAD-6(6):1098–1112, November 1987. [28] P.G. Paulin and J.P. Knight. Force-directed scheduling for the behavioral synthesis. IEEE Transactions on Computer-Aided Design, CAD-8(6):661–679, July 1989. [29] C. A. Petri. Interpretations of a net theory. Technical Report 75–07, GMD, Bonn, W. Germany, 1975. [30] P. Pirsch, editor. VLSI Implementations for Image Communications. Number 2 in Advances in Image Communication. Elsevier, 1993. [31] S. Prakash and A. C. Parker. SOS: Synthesis of application-specific heterogeneous multiprocessor systems. Journal Parallel and Distributed Computing, 16:338–351, 1992.

LITERATURVERZEICHNIS

143

[32] H. J. Whitehouse S. Y. Kung and T. Kailath. VLSI and Modern Signal processing. Prentice Hall, Eaglewood Cliffs, NJ, 1985. [33] J. Teich. Digitale Hardware/Software-Systeme. Springer Verlag, ISBN 3-540-62433-3, Berlin, Heidelberg, 1997. [34] H. Trickey. Flamel: A high level hardware compiler. IEEE Trans. on CAD, 6(2):259– 269, 1987. [35] C. Tseng and D. P. Siewiorek. Automated synthesis of datapaths in digital systems. IEEE Trans. on CAD, 5(3):274–277, July 1986. [36] H. J. Whitehouse, S. Y. Kung, and T. Kailath. VLSI and Modern Signal Processing. Prentice Hall, Englewood Cliffs, NJ, 1985.