Abschlussbericht - boles.de · 2.5 Anforderungen an die Infrastruktur ... 5.8 Überblick über die Struktur des MHA-FPGAs ... 5.24 Zustandsautomat der Hanning-Komponente

Projektgruppe MHA2

Abschlussbericht

C A R LV O N

O S S I E T Z K Y

Version vom 9. Oktober 2006

Neben dem Abschlussbericht umfasst dieDokumentation folgende Dokumente:

• Entwickler-Handbuch

• Benutzer-Handbuch

• CD-ROM mit Quellcodes

• Seminarband

ii

AbschlussberichtProjektgruppe MHA2

WS 2005/2006 und SS 2006

LeitungProf. Dr.-Ing. Wolfgang Nebel

BetreuerDipl.-Inf. Carsten BethDipl.-Inf. Mark HillersDipl.-Inf. Frank PoppenDipl.-Inf. Arne Schulz

MitgliederWincent BalinKai BesoldFriedrich KretschmerOlaf MeyerFrerk MüllerAlexander NeumannMalte VietTobias Weidelt

iii

iv

Inhaltsverzeichnis

Glossar 1

1 Einleitung 7

2 Projektmanagement 92.1 Projektziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Projektplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.4 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.5 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.1 Veränderung der Anforderungen . . . . . . . . . . . . . . . . . 192.3.2 Lieferungsverzögerungen . . . . . . . . . . . . . . . . . . . . . . 192.3.3 Unterschätzung des Umfangs . . . . . . . . . . . . . . . . . . . 202.3.4 Mangelnde Infrastruktur . . . . . . . . . . . . . . . . . . . . . . 202.3.5 Unterschätzung der PCI-Komplexität . . . . . . . . . . . . . . 202.3.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4 Kostenübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5 Anforderungen an die Infrastruktur . . . . . . . . . . . . . . . . . . . . 21

2.5.1 Hardware-Ressourcen . . . . . . . . . . . . . . . . . . . . . . . 212.5.2 Software-Resourcen . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.6 Qualitätssicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.6.1 Sicherungsmechanismen . . . . . . . . . . . . . . . . . . . . . . 232.6.2 Berichterstattungsmechanismen . . . . . . . . . . . . . . . . . . 232.6.3 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.6.4 Produktüberprüfung . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Anforderungsdefinition 273.1 Allgemeine Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Anforderungen des Benutzers . . . . . . . . . . . . . . . . . . . . . . . 273.3 Anforderungen des Entwicklers . . . . . . . . . . . . . . . . . . . . . . 28

4 Analyse 294.1 Plattformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1 Industrie-PC-Plattformen . . . . . . . . . . . . . . . . . . . . . 304.1.2 Spielekonsolenplattformen . . . . . . . . . . . . . . . . . . . . . 314.1.3 PDA-Plattformen . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Systemanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

v

Inhaltsverzeichnis

4.2.1 Überprüfung der Auslagerungsstrategien . . . . . . . . . . . . . 364.2.2 Testergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2.3 Diskussion der Testergebnisse . . . . . . . . . . . . . . . . . . . 42

4.3 Busstandards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3.1 Compact Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3.2 PCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3.3 USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3.4 ATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4 Spezielle Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.5 Akkutypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5 Entwurf 535.1 Gesamtsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.1 Datenflüsse im Gesamtsystem . . . . . . . . . . . . . . . . . . . 545.2 Embedded-PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.2.1 PC-Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.2.2 Betriebssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.2.3 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.2.4 Adapterkonzept für Plugins . . . . . . . . . . . . . . . . . . . . 575.2.5 PCI-Treiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.3 Benutzungsschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . 585.4 PCI-FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.5 MHA-FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.5.1 Gesamtsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.5.2 Externe Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . 635.5.3 Speicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.5.4 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.5.5 Hardware-Plugins . . . . . . . . . . . . . . . . . . . . . . . . . 72

6 Implementierung 916.1 Gesamtsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.2 Kommunikationsprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.2.1 Datenpaket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.2.2 Konfigurationspaket . . . . . . . . . . . . . . . . . . . . . . . . 936.2.3 Fehlerpaket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.3 Schaltungsentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.3.1 Ein- und Ausgabekomponenten . . . . . . . . . . . . . . . . . . 966.3.2 Beschleuniger . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.3.3 Spannungsversorgung . . . . . . . . . . . . . . . . . . . . . . . 100

6.4 PC-Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016.5 PC-Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

6.5.1 Entwicklungssystem für die Zielplattform . . . . . . . . . . . . 1036.5.2 Erstellung des Zielsystems . . . . . . . . . . . . . . . . . . . . . 1036.5.3 Kommunikationschema . . . . . . . . . . . . . . . . . . . . . . 1056.5.4 PCI-Treiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.5.5 MHA-Adapter-Plugins . . . . . . . . . . . . . . . . . . . . . . . 108

vi

Inhaltsverzeichnis

6.5.6 Menüsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1106.6 MYGERMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1126.7 PCI-FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6.7.1 Lokaler Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146.7.2 PCI-Kern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

6.8 MHA-FPGA (Signalprozessor) . . . . . . . . . . . . . . . . . . . . . . 1256.8.1 Gesamtsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 1266.8.2 externe Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . 1266.8.3 SRAM-Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 1296.8.4 Plugin-Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . 1306.8.5 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326.8.6 Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446.8.7 Hardware-Plugins . . . . . . . . . . . . . . . . . . . . . . . . . 145

6.9 Gehäuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

7 Komponenten- und Integrationstests 1617.1 MHA-FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

7.1.1 Test der externen Schnittstelle . . . . . . . . . . . . . . . . . . 1617.1.2 Controllertest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

7.2 PCI-FPGA-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1647.2.1 Test des Local Bus Controller . . . . . . . . . . . . . . . . . . . 1647.2.2 Test des PCI-Kernes . . . . . . . . . . . . . . . . . . . . . . . . 164

7.3 Testen des Softwarekommunikation . . . . . . . . . . . . . . . . . . . . 1667.4 Testen der Menüführung . . . . . . . . . . . . . . . . . . . . . . . . . . 167

8 Fazit 169

A Anhang 171A.1 Testsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

A.1.1 Betriebssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 171A.1.2 Testhardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172A.1.3 Testwerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . 172A.1.4 MHA-Konfigurationen . . . . . . . . . . . . . . . . . . . . . . . 174

A.2 Schaltpläne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175A.3 Projektplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Literaturverzeichnis 189

Index 193

vii

Inhaltsverzeichnis

viii

Abbildungsverzeichnis

4.1 Messergebnisse der gezählten Prozessor-Instruktionen . . . . . . . . . 384.2 Messergebnisse der gezählten Prozessor-Operationen . . . . . . . . . . 384.3 Messergebnisse der gezählten Fließkommaberechnungen in Prozent . . 394.4 Berechnung der relativen Auslastung . . . . . . . . . . . . . . . . . . . 39

5.1 Überblick über das Gesamtsystem . . . . . . . . . . . . . . . . . . . . 535.2 Datenfluss im Gesamtsystem: Soundkarte → MHA-FPGA . . . . . . . 545.3 Datenfluss im Gesamtsystem: Soundkarte ← MHA-FPGA . . . . . . . 555.4 MHA-Adapterkonzept für Hardwarebeschleunigung . . . . . . . . . . . 575.5 Entwurf der Menüstruktur . . . . . . . . . . . . . . . . . . . . . . . . . 595.6 Entwurf der PCI-FPGA-Konfiguration . . . . . . . . . . . . . . . . . . 605.7 Paketvermittlung im PCI-FPGA . . . . . . . . . . . . . . . . . . . . . 615.8 Überblick über die Struktur des MHA-FPGAs . . . . . . . . . . . . . . 625.9 Daten vom PCI-FPGA empfangen . . . . . . . . . . . . . . . . . . . . 635.10 Hauptautomat der externen Schnittstelle . . . . . . . . . . . . . . . . . 645.11 Rahmen der Kontrollautomaten des MHA-FPGAs . . . . . . . . . . . 665.12 Empfangsmodule des MHA-FPGAs . . . . . . . . . . . . . . . . . . . . 675.13 Versandmodule des MHA-FPGAs . . . . . . . . . . . . . . . . . . . . . 685.14 Verarbeitungsprozess im MHA-FPGAs . . . . . . . . . . . . . . . . . . 695.15 Kontrollfluss des wave2spec-Plugins . . . . . . . . . . . . . . . . . . . . 745.16 wave2spec-Controller: Datentransfer von Eingangspuffer zu Window-

ing-Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.17 wave2spec-Controller: Datentransfer Windowing → Hanning-Funktion 755.18 wave2spec-Controller: Datentransfer von FFT zum Ausgangspuffer . . 755.19 Blockschaltbild des Windowing . . . . . . . . . . . . . . . . . . . . . . 765.20 Schema des Windowing . . . . . . . . . . . . . . . . . . . . . . . . . . 775.21 Kontrollautomat des Windowing . . . . . . . . . . . . . . . . . . . . . 785.22 Beispiel Hanning-Kurve . . . . . . . . . . . . . . . . . . . . . . . . . . 785.23 Schnittstelle der Hanning-Komponente . . . . . . . . . . . . . . . . . . 795.24 Zustandsautomat der Hanning-Komponente . . . . . . . . . . . . . . . 805.25 Butterfly-Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.26 Blockschaltbild der Butterfly . . . . . . . . . . . . . . . . . . . . . . . 815.27 Zustände einer pipeline-fähigen Butterfly . . . . . . . . . . . . . . . . . 815.28 Ordnung der Werte nach einer „Interlaced Decomposition“ . . . . . . 825.29 Darstellung der Drehfaktoren auf Einheitskreis . . . . . . . . . . . . . 825.30 Schnittstellenerweiterung der FFT-Komponente um die iFFT-Fähigkeit 835.31 Überblick über den Datenfluss der kompletten FFT . . . . . . . . . . . 845.32 Zustandsautomat der FFT/iFFT . . . . . . . . . . . . . . . . . . . . . 855.33 „Compute Data“-Zustand der FFT/iFFT-Komponente . . . . . . . . . 85

ix


5.34 spec2wave-Plugin Daten- und Kontrollfluss . . . . . . . . . . . . . . . 865.35 spec2wave-Controller: Datentransfer Eingangspuffer zu iFFT . . . . . 875.36 spec2wave-Controller: Datentransfer iFFT zu Overlap-Add . . . . . . 875.37 spec2wave-Controller: Datentransfer Overlap-Add zu Ausgangspuffer . 885.38 Blockschaltbild der Overlap-Add . . . . . . . . . . . . . . . . . . . . . 885.39 Schema der Overlap-Add . . . . . . . . . . . . . . . . . . . . . . . . . 895.40 Kontrollautomat der Overlap-Add . . . . . . . . . . . . . . . . . . . . 89

6.1 Gesamtsystemübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . 926.2 Blockschaltbild des Gesamtsystems . . . . . . . . . . . . . . . . . . . . 966.3 Blockschaltbild des Beschleunigers . . . . . . . . . . . . . . . . . . . . 986.4 Blockschaltbild der Spannungsversorgung des Gesamtsystems . . . . . 1016.5 Sequenzdiagramm Software-Kommunikation . . . . . . . . . . . . . . . 1066.6 Implementierung des Menüsystems . . . . . . . . . . . . . . . . . . . . 1116.7 Ablaufdiagramm des MYGERMS-Monitorprogramms . . . . . . . . . 1126.8 Blockschaltbild der PCI-FPGA-Konfiguration . . . . . . . . . . . . . . 1136.9 Registersatz des LBC . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156.10 Zeitdiagramm der Intrakommunikation . . . . . . . . . . . . . . . . . . 1196.11 Aufbau des PCI-Kerns . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206.12 Registersatz des PCI-Kerns . . . . . . . . . . . . . . . . . . . . . . . . 1226.13 Bits im Statusregister des PCI-Kerns . . . . . . . . . . . . . . . . . . . 1236.14 Interface Blockschaltbild der externen Schittstelle . . . . . . . . . . . . 1276.15 Register-File-Blockschaltbild der externen Schnittstelle . . . . . . . . . 1286.16 Task Logic Blockschaltbild der externen Schnittstelle . . . . . . . . . . 1296.17 Blockschaltbild des SRAM-Controllers . . . . . . . . . . . . . . . . . . 1306.18 Hardwareplugin: Blockschaltbild Avalon Interface . . . . . . . . . . . . 1316.19 Grafik zur Erläuterung der Kontrollstruktur . . . . . . . . . . . . . . . 1346.20 Implementierung des MHA-FPGA-Rahmenautomaten . . . . . . . . . 1376.21 Implementierung des MHA-FPGA-Empfangsmoduls . . . . . . . . . . 1376.22 Implementierung des MHA-FPGA-Versandmodule . . . . . . . . . . . 1386.23 Implementierung der MHA-FPGA-Verarbeitungseinheit . . . . . . . . 1396.24 Datenfluss für FFT und iFFT . . . . . . . . . . . . . . . . . . . . . . . 1466.25 Datenfluss der Windowing-Komponente . . . . . . . . . . . . . . . . . 1486.26 Blockschaltbild der Hanning-Komponente . . . . . . . . . . . . . . . . 1496.27 ROM-Aufbau der Hanning-Komponente . . . . . . . . . . . . . . . . . 1506.28 Aufbau der Prozesse innerhalb der Hanning-Komponente . . . . . . . 1506.29 Blockschaltbild der Butterfly-Komponente . . . . . . . . . . . . . . . . 1516.30 Aufbau der Prozesse innerhalb der Butterfly-Komponente . . . . . . . 1526.31 Blockschaltbild der FFT-Komponente . . . . . . . . . . . . . . . . . . 1536.32 Kontrollprozesse der FFT-Komponente . . . . . . . . . . . . . . . . . . 1546.33 FFT-Komponente: Ansteuerung der Counter und Speicher . . . . . . . 1546.34 Datenfluss der Overlap-Add-Komponenten . . . . . . . . . . . . . . . . 1586.35 Gehäusekomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . 1596.36 Gehäuseentwurf ohne Texturen . . . . . . . . . . . . . . . . . . . . . . 1596.37 Gehäuseentwurf mit Texturen . . . . . . . . . . . . . . . . . . . . . . . 1606.38 Fertiges Gehäuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

x


A.1 Bitbelegung der verwendeten MSRs . . . . . . . . . . . . . . . . . . . 173A.2 Schaltbild der 6-Tasten-Tastatur . . . . . . . . . . . . . . . . . . . . . 175A.3 Schaltbild der Anzeige . . . . . . . . . . . . . . . . . . . . . . . . . . . 176A.4 Schaltbild der Anzeigesteuerung . . . . . . . . . . . . . . . . . . . . . . 177A.5 Schaltbild: PC/104-Plus-Anbindung des Beschleunigers . . . . . . . . 178A.6 Schaltbild: PCI-FPGA-Bank I . . . . . . . . . . . . . . . . . . . . . . . 179A.7 Schaltbild: PCI-FPGA-Bank II . . . . . . . . . . . . . . . . . . . . . . 180A.8 Schaltbild: PCI-FPGA-Bank III . . . . . . . . . . . . . . . . . . . . . . 181A.9 Schaltbild: PCI-FPGA-Bank IV . . . . . . . . . . . . . . . . . . . . . . 182A.10 Schaltbild: PCI-FPGA-SRAM . . . . . . . . . . . . . . . . . . . . . . . 183A.11 Schaltbild: Steckverbindung Parallax-Modul (MHA-FPGA) . . . . . . 184A.12 Schaltbild: MHA-FPGA-SRAM . . . . . . . . . . . . . . . . . . . . . . 185A.13 Schaltbild: Netzteil des Beschleunigers . . . . . . . . . . . . . . . . . . 186

xi


xii

Tabellenverzeichnis

2.1 Materialausgaben für das Projekt . . . . . . . . . . . . . . . . . . . . . 21

3.1 Allgemeine Anforderungen an die Plattform . . . . . . . . . . . . . . . 273.2 Benutzeranforderungen an die Plattform . . . . . . . . . . . . . . . . . 283.3 Entwickleranforderungen an die Plattform . . . . . . . . . . . . . . . . 28

4.1 Vergleich möglicher Industrie-PC-Plattformen . . . . . . . . . . . . . . 324.2 Vergleich möglicher Industrie-PC-Plattformen (Forts.) . . . . . . . . . 334.3 Vergleich möglicher SpielekonsolenPlattformen . . . . . . . . . . . . . 344.4 Vergleich möglicher PDA-Plattformen . . . . . . . . . . . . . . . . . . 354.5 Ergebnisse Leistungsmessung von (i)FFT . . . . . . . . . . . . . . . . 374.6 wave2spec-/spec2wave-Anforderungen . . . . . . . . . . . . . . . . . . 414.7 Maximale Bandbreiten der untersuchten Busstandards . . . . . . . . . 444.8 Compact Flash-Bandbreiten . . . . . . . . . . . . . . . . . . . . . . . . 444.9 PCI-Busbandbreiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.10 USB-Bandbreiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.11 ATA-Bandbreiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.12 Tabellarische Bewertung untersuchter Bauteilkategorien . . . . . . . . 484.13 Akkumulatorenvergleich . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.1 Entwurf: PC-Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.1 Aufbau des Datenpakets . . . . . . . . . . . . . . . . . . . . . . . . . . 936.2 Aufbau des Konfigurationspakets . . . . . . . . . . . . . . . . . . . . . 946.3 Aufbau des Fehlerpakets . . . . . . . . . . . . . . . . . . . . . . . . . . 946.4 Aufbau des Statusregisters des LBC . . . . . . . . . . . . . . . . . . . 1176.4 Aufbau des Statusregisters des LBC . . . . . . . . . . . . . . . . . . . 1186.5 Aufbau des Statusregisters des PCI-Kernes . . . . . . . . . . . . . . . 1236.5 Aufbau des Statusregisters des PCI-Kernes . . . . . . . . . . . . . . . 1246.6 Statussignale der FIFOs . . . . . . . . . . . . . . . . . . . . . . . . . . 1286.7 Signale für den NIOS II . . . . . . . . . . . . . . . . . . . . . . . . . . 1296.8 Signale für den PCI-FPGA . . . . . . . . . . . . . . . . . . . . . . . . 1296.9 Hardware-Plugin – Konventionen des Adresseingangs . . . . . . . . . . 1316.10 Hardware-Plugin – Konventionen des Statusregisters . . . . . . . . . . 1326.11 Hardware-Plugin – Konventionen des Kontrollregisters . . . . . . . . . 1326.12 Auflistung der Fehlercodes des MHA-FPGA . . . . . . . . . . . . . . . 1436.13 wave2spec- / spec2wave-Parameteradressierung . . . . . . . . . . . . . 1456.13 wave2spec- / spec2wave-Parameteradressierung . . . . . . . . . . . . . 1466.14 Megafunctions Windowing . . . . . . . . . . . . . . . . . . . . . . . . . 1476.15 Schnittstelle Windowing . . . . . . . . . . . . . . . . . . . . . . . . . . 148

xiii

Tabellenverzeichnis

6.16 Megafunctions in Hanning . . . . . . . . . . . . . . . . . . . . . . . . . 1496.17 Megafunctions in der Butterfly-Komponente . . . . . . . . . . . . . . . 1526.18 Instanzen in der FFT -Komponente . . . . . . . . . . . . . . . . . . . . 1556.19 Megafunctions Overlap-Add . . . . . . . . . . . . . . . . . . . . . . . . 1576.20 Schnittstelle Overlap-Add . . . . . . . . . . . . . . . . . . . . . . . . . 157

xiv

Glossar

A

Akkumulator (Akku) Eine wiederaufladbare Batterie.

Altera Quartus Eine Systementwicklungs-Software von Altera.

Application Specific Integrated Circuit (ASIC) Ein integrierter Schaltkreis, der füreine spezifische Anwendung spezialisiert ist.

Avalon Bus (Avalon) Der Avalon Bus [1] ist ein Bussystem entwickelt vom Unter-nehmen Altera [2] und ist für den Anwendungsbreich System-On-Chipkonzipiert. Es mit einem geschalteten Netzwerk vergleichbar, an dem et-waige Komponenten angeschlossen sind und Verbindungen zwischen die-sen über „Schaltmatrizen“ realisiert werden.

C

Compact Flash (CF) Bezeichnung für einen Bustandard für den Bereich der mobileinsetzbaren Massenspeicher.

D

Demultiplexer (DMUX) Bezeichnet ein Selektionsschaltnetz mit dem ein Signal aufeinen vom mehreren Ausgängen umleiten kann.

F

Fast Fourier Transformation (FFT) Algorithmus, der Audiodaten vom Zeitbereichin den Frequenzbereich überführt.

Field Programmable Gate Array (FPGA) Ein FPGA ist ein „im Feld“ – d.h. vorOrt – programmierbarer Schaltkreis, der sequentielle und kombinatori-sche Logikschaltungen implementieren kann.

First in first out (FIFO) Beizeichnet eine Speicherstruktur, die Dateninhalte in derReihenfolge zurückgibt, in der sie gespeichert wurden.

Fließkommainstruktionen Fließkommaintensive Berechnungen werden häufig durcheinen zusätzlichen Prozessor (Co-Prozessor) beschleunigt, der für die-se Berechnungen optimiert ist. Dieser als „Floating point unit“ (FPU)bezeichnete Prozessor kann extern an den Hauptprozessor (Central pro-cessing unit, CPU) angeschlossen sein, ist in gängigen Rechensystemenjedoch meist direkt in die CPU integriert. In Systemen, in denen keine

1

GLOSSAR

zusätzliche FPU vorhanden ist, wird die Fließkommaberechnung softwa-reseitig so umgewandelt, dass sie vom Prozessor als Ganzzahlberechnungabgearbeitet werden kann. Da diese Umwandlung sehr rechenintensiv ist,führt dies zu einem erheblichen Zuwachs der Prozessorlast.

GGentoo Eine Linux-Distribution, die sich u.a. dadurch auszeichnet, dass Pro-

gramm-Pakete nicht binär sondern im Quellcode verteilt werden. Erst beider Installation werden diese kompiliert. Dadurch ist Gentoo besondersflexibel anpassbar und in hohem Maße auf die Hardware abstimmbar.

IInstructionset (ISA) In einer als Instructionset (ISA) bezeichneten Architektur ei-

nes Systems wird unter anderem der Befehlssatz eines Prozessors festge-legt, der auf diesem implementiert ist. Diese Befehle können unterschied-licher Art sein: Es wird allgemein zwischen arithmetischen, Kontrollfluss-,Vergleichs-, Test-, Stack- und privilegierten Operationen sowie Speicher-und IO-Zugriffen unterschieden. Das Ausführen dieser unterschiedlichenInstruktionen kann je nach Architektur unterschiedlich viel Zeit in An-spruch nehmen. Kompilierte Programme führen diese Instruktionen aus,weshalb die Messung der Instruktionsaufrufe zur Laufzeit Schlüsse überdie durch ein Programm hervorgerufene Prozessorlast zulässt.

Intellectual Property (IP) IP-Komponenten sind vorgefertigte Komponenten in ei-ner Hardware-Beschreibungssprache, die in den eigenen Entwurf einge-bunden werden können und somit in ASICs oder FPGAs verwendet wer-den können. Diese Komponenten können urheberrechtlich geschützt unddaher nicht-einsehbar sein.

Interkommunikation Mit Interkommunikation wird in diesem Dokument die Kom-munikation zwischen Industrie-PC und Beschleuniger verstanden.

Interrupt-Service-Routine (ISR) Behandlungsroutine, die nach einem Interrupt aus-geführt wird und genau diesem Interrupt zugeordnet ist.

Intrakommunikation Mit Intrakommunikation wird in diesem Dokument die Kom-munikation zwischen den FPGAs auf dem Beschleuniger verstanden. Die-se Kommunikation erfolgt über den lokalen Bus und wird durch den PCI-FPGA gesteuert.

Inverse Fast Fourier Transformation (iFFT) Algorithmus, der Audiodaten von demFrequenzbereich in den Zeitbereich überführt.

JJACK Audio Connection Kit (JACK) Eine Software-Komponente für die Betriebs-

systeme Linux und OS X von Apple, die den echtzeitfähigen Austauschvon Audiodaten zwischen verschiedenen Applikationen ermöglicht.

2

GLOSSAR

JIDA Schnittstelle für den Zugriff auf integrierte Komponenten des Industrie-PC, z.B. Temperatursensor digitale Ein-, Ausgabe.

M

MFLOPS Engl. Abk. für million floating point operations per second, bezeichnetdie Anzahl an ausgeführten Fließkommaoperationen pro Sekunde.

MHA-FPGA Der MHA-FPGA ist ein FPGA auf dem Beschleuniger, der einen Teilder Signalverarbeitung des MHA-Rahmenwerkes übernimmt.

Mikrooperationen Innerhalb eines Prozessors werden Prozessorinstruktionen in un-terschiedliche Mikrooperationen zerlegt. Eine Mikrooperation stellt dabeieinen elementaren Verarbeitungsschritt in der Abarbeitung der Instruk-tion dar. Je Art der Instruktion, besteht diese aus unterschiedlich vielenMikrooperationen.

model specific registers (MSR) bezeichnet in Prozessoren vorhande Register, dieim Betrieb mit Statusinformationen vom Prozessor beschrieben und vomBetriebssytem ausgelesen werden können.

MOPS Millionen Mikrooperationen in einer Sekunde (siehe auch Mikrooperatio-nen).

Multiplexer (MUX) Bezeichnet ein Selektionsschaltnetz mit dem einen von mehre-ren Eingängen auf einen Ausgang umleiten kann.

MYGERMS Mit MYGERMS wird in diesem Dokument ein Programm bezeich-net, welches vom GERMS-Monitor [3, S. 16ff] des Unternehmens Alteraabgeleitet wurde. MYGERMS unterstützt nicht den vollen Funktionsum-fang des GERMS-Monitors und ist speziell auf die Speicherverhältnissedes eingesetzten PCI-FPGAs zugeschnitten. MYGERMS dient nach demSystemstart dem Herunterladen eines Programmes für einen Soft-Core-Prozessor in den FPGAs des Beschleunigers.

N

NIOS Ein Soft-Core-Prozessor [4] des Unternehmens Altera.

NIOS II Nachfolgeprodukt des NIOS Soft-Core-Prozessors.

NIOS II IDE Die NIOS II IDE ist die Entwicklungsumgebung von Altera für denNIOS II.

P

PCI-FPGA Der PCI-FPGA ist ein FPGA auf dem Beschleuniger, der für die In-terkommunikation zwischen Beschleuniger und Industrie-PC und für dieIntrakommunikation zwischen PCI- und MHA-FPGA zuständig ist.

3

GLOSSAR

PCI Special Interest Group (PCISIG) Bezeichnet ein Konsortium, das mit der Wei-terentwicklung des PCI-Standards beauftragt ist.

Peripheral Component Interconnect (PCI) Bezeichnung für einen Busstandard zurVerbindung verschiedenster Geräte, wie z.B. Grafik-, Sound- oder Netz-werkkarten. Dieser Bus findet in sowohl in Hochleistungsrechnern als auchin Rechnern für den privaten Endanwender Anwendung.

Personal Digital Assistant (PDA) Bezeichnung für einen tragbaren Kleinstrechnervorwiegend für die Verwaltung von Adressen und Terminen. Neuere Mo-delle erlauben ebenfalls den mobilen Zugriff auf das Internet.

Phase Locked Loop (PLL) Eine frequenzumsetzende Schaltung, welche die Pha-senbeziehung von Ein- zu Ausgangsfrequenz regelt.

Plattform Unter Plattform wird in diesem Dokument die Laufzeitumgebung desMHA-Rahmenwerkes verstanden. Dies umfasst sowohl Hardware als auchSoftware.

Prozessorinstruktionen Instruktion aus dem Instructionset eines Prozessors.

Rread only memory (ROM) Speicherstruktur auf der nur lesend zugegriffen werden

kann.

SS-Record-Format (S-Record) Ein von Motorola entwickeltes Dateiformat zur Spei-

cherung von Binärprogrammen.

SOPC Builder (SOPC) Der SOPC Builder [5] ist ein Programm der Firma Alteraund ermöglicht die komponentenbasierte Entwicklung für programmier-bare Logiken dieses Unternehmens.

spec2wave Audioplugin, welches Audiodaten vom Frequenzbereich in den Zeitbe-reich unter Verwendung von störeffektunterdrückenden Funktionen über-führt.

Spielekonsole Unter Spielekonsole wird ein Kleinstrechner verstanden, der auf dieVerarbeitung und Wiedergabe von Computerspielen spezialisiert ist.

Static RAM (SRAM) Ein wahlfrei zugreifbarer Speicher. Die Speicherung der Da-ten erfolgt statisch in bistabilen Kippstufen.

UUniversal Asynchronous Receiver Transmitter (UART) Bezeichnung für einen uni-

versellen, asynchronen Empfänger und Sender. Diese Komponente ermög-licht den Datentransfer ohne gegenseite Synchronisation der Kommuni-kationspartner in beide Richtungen, z.B. RS-232.

4

GLOSSAR

Universal Serial Bus (USB) Bezeichnet eine Weiterentwicklung serieller Periphe-rieschnittstellen. Ein besonderes Augenmerk liegt auf einfache Verbin-dung der Geräte und auf hohe Flexibilität [6].

VVery High Speed Hardware Description Language (VHDL) Hardwarebeschreibungs-

sprache zur Spezifikation, Synthese und Simulation von elektrischen Schalt-kreisen in FPGAs oder ASICs (anwendungsspezifischen, integrierten Schalt-kreisen).

Video Electronics Standards Association Local Bus (VLB) Busstandard der Vi-deo Electronics Standards Association für IBM-kompatible PCs.

Wwave2spec Audioplugin, welches Audiodaten vom Zeitbereich in den Frequenzbe-

reich unter Verwendung von störeffektunterdrückenden Funktionen über-führt.

5

GLOSSAR

6

1 Einleitung

Dieser Bericht dokumentiert die Arbeit der Projektgruppe MHA2 an der Carl-von-Ossietzky-Universität Oldenburg im Wintersemester 2005/2006 und Sommersemes-ter 2006. Auftraggeber des Projekts waren das OFFIS (Oldenburger Forschungs-und Entwicklungsinstitut für Informatikwerkzeuge und -Systeme) und die HörTechgGmbH.

Die Aufgabenstellung sah vor, ein System auf Basis eines PDAs zu entwickeln, aufdem die Software MHA (Master Hearing Aid) betrieben werden kann. Die MHA-Software wurde von der HörTech gGmbH entwickelt und ist ein Framework zur Ent-wicklung und Evaluation von Hörgeräte-Algorithmen. Für den Einsatz des MHA wur-de bisher ein leistungsfähiger Desktop-PC benötigt. Um die entwickelten Algorithmenin alltäglichen Umgebungen und Situationen, wie z.B. öffentlichen Verkehrsmittelnoder Konzerthallen, testen zu können, wäre allerdings ein mobiler Einsatz der Softwa-re wünschenswert. Aus diesem Grund bestand Nachfrage nach einem kompakteren,mobilen Endgerät.

Das Ziel der Projektgruppe bestand somit darin, ein mobiles System zu entwickeln,das ausreichend Rechenleistung besitzt, um das MHA mit gängigen Algorithmenkom-binationen zu betreiben. An dieser Stelle sei erwähnt, dass sich die Realisierung desSystems auf Basis eines PDA als unrealistisch herausstellte, weswegen der ursprüngli-che Projekttitel „Entwicklung eines PDA-basierten Hörgeräts“ in „MHA mobile hard-ware acceleration“ (kurz MHA2) gewandelt wurde, um die Frage nach der Basis desSystems offen zu lassen.

Angesichts der Anforderungen, wie Gewicht, Größe und Leistungsaufnahme wurdeein Industrie-PC verwendet und ein FPGA basierter Hardware-Beschleuniger entwi-ckelt, der Teile der digitalen Signalverarbeitung übernimmt. Der verwendete FPGA-Typ ist für DSP-Anwendungen optimiert und hat eine geringere Leistungsaufnahmeals gewöhnliche, multifunktionale CPUs, die mit dieser Aufgabe konfrontiert werden.Überdies ermöglicht der Einsatz von FPGAs, den Verwendungszweck des Beschleu-nigers flexibel zu halten.

Im Folgenden soll eine Übersicht über den Inhalt dieses Berichts sowie weitererDokumente gegeben werden. Kapitel 2 befasst sich mit dem Projektmanagement derProjektgruppe. Die Anforderungsdefinition in Kapitel 3 fasst die Anforderungen andas System zusammen. Diese sind in Benutzer-, Entwickler- und allgemeine Anfor-derungen gegliedert. Kapitel 4 beschreibt die Analyse der Anforderungen und doku-mentiert die Entwurfsraumexploration. Es werden verschiedene Lösungsvorschläge inKategorien gegenübergestellt und bewertet. Das Kapitel beinhaltet ebenfalls Emp-fehlungen, die aus der Analyse resultieren und zu Kaufentscheidungen führten. DerEntwurf des Systems wird in Kapitel 5 vorgestellt. Dort wird auf abstrakter Ebene dieKommunikation zwischen den einzelnen Komponenten erläutert, als auch Daten- undKontrollflüsse innerhalb der Komponenten vorgestellt. Die Implementierung wird inKapitel 6 dargestellt. Das Kapitel umfasst die Beschreibung des Treibers, der Kom-

7

1 Einleitung

munikationskomponenten, des Kommunikationsprotokolls, der Kontrollstruktur desBeschleunigers und der realisierten Algorithmen. Die durchgeführten Tests werden inKapitel 7 aufgeführt. Das Dokument schließt mit einem Fazit in Kapitel 8. In diesemKapitel wird zusammenfassend ein Überblick über das Projekt gegeben. Des Weite-ren wird im Ausblick vorgestellt, wie nach Ende des Projekts mit den Ergebnissenund dem entwickelten Prototypen verfahren werden könnte. Dies geschieht auch imHinblick auf neue Technologien.

Neben dem Abschlussbericht stehen außerdem ein Benutzerhandbuch, ein Entwick-lerhandbuch, eine CD-ROM mit Quellcodes und ein Seminarband zur Verfügung. DasBenutzerhandbuch soll einem möglichen Probanden eine Einführung in die Benutzungdes Prototypen geben. Das Entwicklerhandbuch hingegen beschreibt Vorgehenswei-sen und Konventionen zur Entwicklung eigener Algorithmen für die Beschleunigungs-Hardware.

8

2 Projektmanagement

Dieses Kapitel liefert einen Bericht über den Verlauf des Projektes. Besonderes Au-genmerk wurde auf den Projektplan, der in Abschnitt 2.2 vorgestellt wird, gelegt.Im Projektplan werden die einzelnen Arbeitspakete vorgestellt, sowie deren Verlaufüber die Projektlaufzeit. Im Abschnitt 2.3 wird die Behandlung erkannter Risikendiskutiert. Nachfolgend wird im Abschnitt 2.4 eine Auflistung der Kosten präsentiertund in 2.5 werden Aspekte der Infrastruktur erläutert. Abschließend werden in 2.6die von der Gruppe festgelegten Qualitätssicherungsmechanismen vorgestellt.

2.1 ProjektzielZiel des Projektes war es, innerhalb eines Jahres mit den zur Verfügung stehendenMitteln von ca. 1200e einen Prototypen zu entwickeln, der den Anforderungen derAuftraggeber entspricht. Der Schwerpunkt wurde auf die Entwicklung eines Kon-zeptes gesetzt, dass es ermöglicht, einfach und effizient Algorithmen für das MHA-Rahmenwerk unter Nutzung eines Hardware-Beschleunigers zu entwickeln.

Zur Validierung des Konzepts wurde ein Prototyp implementiert. Dieser Prototypliefert die Basis für zukünftige Entwicklungsschritte.

2.2 ProjektplanUm das Projekt für das Projektmanagement handhabbar zu gestallten wurde dasProjekt in Arbeitspaktete aufgeteilt. Diese werden im Folgenden näher erläutert.Beteiligte der Arbeitspakete werden aufgeführt, sowie Informationen über Paketab-hängigkeiten. Das entsprechende Gantt-Chart zu den Arbeitspaketen ist im Anhangals Faltplan zu finden.

2.2.1 Analyse [ID: 00]

Arbeitspaket: Benchmarks [ID: 01]Beteiligte: Tobias Weidelt, Frerk Müller, Friedrich KretschmerAbhängigkeit: keineBeschreibung: Durchführung der Benchmarktests zur Ermittlung der

Hardware-Anforderungen

Arbeitspaket: Marktanalyse Industrie-PC [ID: 02]Beteiligte: Olaf Meyer, Tobias WeideltAbhängigkeit: Benchmarks [ID: 01]Beschreibung: Der Markt der Industrie-PC-Anbieter wurde untersucht, um

leistungsfähige Kandidaten zu finden.

9

2 Projektmanagement

Arbeitspaket: Marktanalyse Busstandards [ID: 03]Beteiligte: Olaf MeyerAbhängigkeit: Benchmarks [ID: 01], Marktanalyse Industrie-PC [ID: 02]Beschreibung: Marktanalyse der verfügbaren Busstandards. Diese wurden hi-

nischtlich ihrer Eigenschaften und Verfügbarkeit untersucht.

Arbeitspaket: Marktanalyse Akkumulatoren [ID: 04]Beteiligte: Olaf Meyer, Wincent BalinAbhängigkeit: Benchmarks [ID: 01], Marktanalyse Industrie-PC [ID: 02]Beschreibung: Der Markt der Akkumulatoren wurde untersucht, um einen Ak-

ku mit hinreichender Kapazität für die mobile Energieversor-gung auszuwählen.

Arbeitspaket: FPGA-Anforderungen [ID: 14]Beteiligte: Kai Besold, Malte Viet, Alexander NeumannAbhängigkeit: Benchmarks [ID: 01]Beschreibung: Berechnung der FPGA Anforderungen und der Busauslastung

Arbeitspaket: FPGA-Auswahl [ID: 15]Beteiligte: Wincent BalinAbhängigkeit: Benchmarks [ID: 01]Beschreibung: Suche nach vorgefertigten Platinen mit FPGAs im BGA-

Gehäuse, nach Möglichkeit mit PCI/104-Anbindung

2.2.2 Entwurf [ID: 05]2.2.2.1 Hardware-Plugins [ID: 06]

Arbeitspaket: Wave2Spec: Windowing [ID: 07]Beteiligte: Kai BesoldAbhängigkeit: FPGA-Auswahl [ID: 15]Beschreibung: Entwurf der Windowing-Komponente

Arbeitspaket: Wave2Spec: Hanning-Funktion [ID: 08]Beteiligte: Alexander NeumannAbhängigkeit: FPGA-Auswahl [ID: 15]Beschreibung: Entwurf der Hanning-Funktion

Arbeitspaket: Wave2Spec: FFT [ID: 09]Beteiligte: Alexander NeumannAbhängigkeit: FPGA-Auswahl [ID: 15]Beschreibung: Entwurf der FFT. Dies beinhaltet den Entwurf der Butterfly

und der Kontrollstruktur der FFT.

10

2.2 Projektplan

Arbeitspaket: Spec2Wave: iFFT [ID: 10]Beteiligte: Alexander NeumannAbhängigkeit: FPGA-Auswahl [ID: 15], Wave2Spec: FFT [ID: 09]Beschreibung: Entwurf der iFFT. Dies beinhaltet lediglich eine Modifikation

der FFT, da die Butterfly und die Basisstruktur identisch mitder iFFT sind.

Arbeitspaket: Spec2Wave: Hanning-Rampen [ID: 11]Beteiligte: Alexander NeumannAbhängigkeit: FPGA-Auswahl [ID: 15],Wave2Spec: Hanning-Funktion [ID: 08]Beschreibung: Entwurf der Hanning-Rampenfunktion. Dies ist eine Erwei-

terung der Hanning-Funktion um die Funktionswerte derHanning-Rampenfunktion.

Arbeitspaket: Spec2Wave: Overlap-Add [ID: 12]Beteiligte: Kai BesoldAbhängigkeit: FPGA-Auswahl [ID: 15]Beschreibung: Entwurf der Overlap-Add-Komponente

Arbeitspaket: Wave2Spec und Spec2Wave: Controller / Interface[ID: 13]

Beteiligte: Malte VietAbhängigkeit: FPGA-Auswahl [ID: 15], Spec2Wave: Overlap-Add [ID: 48],

Spec2Wave: Hanning-Rampen [ID: 46], Spec2Wave: iFFT[ID: 44], Wave2Spec: FFT [ID: 42], Wave2Spec: Hanning-Funktion [ID: 40], Wave2Spec: Windowing [ID: 38]

Beschreibung: Entwurf des Steuerwerks für die Hardware-Komponenten derwave2spec/spec2wave-Plugins. Zusätzlich Entwurf der Avalon-Schnittstelle

2.2.2.2 MHA-Controller [ID: 16]

Arbeitspaket: MHA-Localbus-Schnittstelle [ID: 17]Beteiligte: Frerk Müller, Malte VietAbhängigkeit: FPGA-Auswahl [ID: 15]Beschreibung: Entwurf der externen Schnittstelle vom Local-Bus an den MHA-

FPGA. Dies umfasst den Entwurf der Kontrollstruktur unterBerücksichtigung der Localbus-Spezifikation.

Arbeitspaket: MHA-Controller [ID: 18]Beteiligte: Frerk Müller, Malte VietAbhängigkeit: FPGA-Auswahl [ID: 15], MHA-Localbus-Schnittstelle [ID: 17]Beschreibung: Entwurf des MHA-Controllers. Dies umfasst die Kontrollstruk-

tur und die dynamische Speicherverwaltung.

11

2 Projektmanagement

Arbeitspaket: MHA-Plugin-Schnittstellen [ID: 19]Beteiligte: Frerk Müller, Malte VietAbhängigkeit: FPGA-Auswahl [ID: 15], MHA-Controller [ID: 18]Beschreibung: Entwurf der Plugin-Schnittstellen. Schnittstellen für Hard-

und Software-Plugins wurden spezifiziert. Für die Hardware-Plugins wurden die Steuersignale zwischen MHA-Controller undHardware-Plugin festgelegt und der Datenfluss konzepiert. Ein-und Ausgabewerte der Software-Plugins wurden festgelegt.

2.2.2.3 PCI-FPGA [ID: 21]

Arbeitspaket: PCI-Architektur [ID: 22]Beteiligte: Olaf Meyer, Wincent BalinAbhängigkeit: FPGA-Auswahl [ID: 15]Beschreibung: Die Architektur des PCI-Kernes wurde entworfen.

Arbeitspaket: Localbus-Architektur [ID: 23]Beteiligte: Olaf MeyerAbhängigkeit: FPGA-Auswahl [ID: 15]Beschreibung: Entwurf der Intrakommunikation des Beschleunigers.

2.2.2.4 Hardware-Komponenten [ID: 24]

Arbeitspaket: Beschleuniger-Architektur [ID: 25]Beteiligte: Olaf MeyerAbhängigkeit: FPGA-Auswahl [ID: 15]Beschreibung: Die Architektur des Beschleunigers wurde entworfen. Dies um-

fasst die Skizzierung einer Architektur sowie die Auswahl derBauteile.

Arbeitspaket: Benutzungsschnittstellen [ID: 26]Beteiligte: Olaf MeyerAbhängigkeit: FPGA-Auswahl [ID: 15]Beschreibung: Die Benutztungsschnittstelle bestehend aus Anzeige und Tasta-

tur wurde entworfen. Dies umfasst den Entwurf der Hardwaresowie der Software zur Ansteuerung der Anzeige.

2.2.2.5 Industrie-PC [ID: 27]

Arbeitspaket: MHA-Adapter-Plugin [ID: 28]Beteiligte: Tobias Weidelt, Frerk Müller, Friedrich KretschmerAbhängigkeit: Marktanalyse Industrie-PC [ID: 02]Beschreibung: Entwicklung des Adapter-Plugin-Konzepts

12

2.2 Projektplan

Arbeitspaket: PCI-Treiber [ID: 29]Beteiligte: Tobias Weidelt, Frerk MüllerAbhängigkeit: Marktanalyse Industrie-PC [ID: 02]Beschreibung: Einarbeitung in Treiberprogrammierung und Erstellung eines

Treibergerüstes

Arbeitspaket: Design der grafischen Menüführung [ID: 30]Beteiligte: Tobias Weidelt, Friedrich KretschmerAbhängigkeit: Marktanalyse Industrie-PC [ID: 02]Beschreibung: Design der grafischen Menüführung und der Struktur des Menüs.

2.2.2.6 Gehäuse [ID: 31]

Arbeitspaket: Gehäusedesign [ID: 32]Beteiligte: Friedrich KretschmerAbhängigkeit: Marktanalyse Industrie-PC [ID: 02]Beschreibung: 3D-Gehäusedesign

2.2.3 Implementierung [ID: 33]

2.2.3.1 Hardware-Plugins [ID: 36]

Arbeitspaket: Wave2Spec: Windowing [ID: 38]Beteiligte: Kai BesoldAbhängigkeit: Wave2Spec: Windowing [ID: 07]Beschreibung: Implementierung der Windowing-Komponente

Arbeitspaket: Wave2Spec: Hanning-Funktion [ID: 40]Beteiligte: Alexander NeumannAbhängigkeit: Wave2Spec: Hanning-Funktion [ID: 08]Beschreibung: Implementierung der Hanning-Funktion

Arbeitspaket: Wave2Spec: FFT [ID: 42]Beteiligte: Alexander NeumannAbhängigkeit: Wave2Spec: FFT [ID: 09]Beschreibung: Implementierung der FFT. Dies beinhaltet die Umsetzung der

Butterfly und der Kontrollstruktur der FFT.

Arbeitspaket: Spec2Wave: iFFT [ID: 44]Beteiligte: Alexander NeumannAbhängigkeit: Spec2Wave: iFFT [ID: 10]Beschreibung: Implementierung der iFFT (Variation der implementierten

FFT-Komponente).

13

2 Projektmanagement

Arbeitspaket: Spec2Wave: Hanning-Rampen [ID: 46]Beteiligte: Alexander NeumannAbhängigkeit: Spec2Wave: Hanning-Rampen [ID: 11]Beschreibung: Erweiterung der Hanning-Funktion um die Funktionswerte der

Hanning-Rampenfunktion.

Arbeitspaket: Spec2Wave: Overlap-Add [ID: 48]Beteiligte: Kai BesoldAbhängigkeit: Spec2Wave: Overlap-Add [ID: 12]Beschreibung: Implementierung der Overlap-Add-Komponente

Arbeitspaket: Wave2Spec und Spec2Wave: Controller / Interface[ID: 13]

Beteiligte: Malte VietAbhängigkeit: Wave2Spec und Spec2Wave: Controller / Interface [ID: 13]Beschreibung: Implementierung des Steuerwerks für die Hardware-

Komponenten der wave2spec/spec2wave-Plugins. ZusätzlichUmsetzung der Avalon-Schnittstelle

2.2.3.2 MHA-Controller [ID: 51]

Arbeitspaket: MHA-Localbus-Schnittstelle [ID: 52]Beteiligte: Frerk Müller, Malte VietAbhängigkeit: MHA-Localbus-Schnittstelle [ID: 17]Beschreibung: Umsetzung der entworfenen Schnittstelle in VHDL.

Arbeitspaket: MHA-Speichermanagement [ID: 53]Beteiligte: Malte VietAbhängigkeit: MHA-Controller [ID: 18]Beschreibung: Umsetzung des dynamischen Speichermanagements in ANSI-C

Arbeitspaket: MHA-Controller [ID: 54]Beteiligte: Frerk MüllerAbhängigkeit: MHA-Controller [ID: 18]Beschreibung: Umsetzung der MHA-Kontrollstruktur. Dies beinhaltet

Interrupt-Serviceroutinen, Makro-Funktionen und die Si-cherstellung des Kontrollflusses. Verwendete Hochsprache:ANSI-C

Arbeitspaket: MHA-Plugin-Management [ID: 55]Beteiligte: Frerk MüllerAbhängigkeit: MHA-Plugin-Schnittstellen [ID: 19]Beschreibung: Umsetzung der Plugin-Schnittstellen. Dies beinhaltet zusätzlich

die Implementierung von Makro-Funktionen, um die Aufgabenzu standardisieren.

14

2.2 Projektplan

Arbeitspaket: MHA-MYGERMS [ID: 56]Beteiligte: Olaf Meyer, Frerk Müller, Malte VietAbhängigkeit: MHA-Plugin-Management [ID: 55], MHA-Controller

[ID: 18],MHA-Controller [ID: 18]Beschreibung: Anpassung des GERMS-Monitors an den MHA-FPGA. Zu-

sätzlich Zusammensetzung des SOPC-Gesamtsystem mit derSRAM-Komponente, der externen Schnittstelle, NIOS II undden ANSI-C-Komponenten

2.2.3.3 PCI-FPGA [ID: 57]

Arbeitspaket: PCI-Architektur [ID: 58]Beteiligte: Olaf Meyer, Wincent BalinAbhängigkeit: PCI-Architektur [ID: 22]Beschreibung: Umsetzung der PCI-Architektur in VHDL

Arbeitspaket: Localbus-Architektur [ID: 59]Beteiligte: Olaf MeyerAbhängigkeit: Local-Bus-Architektur [ID: 23]Beschreibung: Umsetzung der Localbus-Architektur in VHDL

2.2.3.4 Beschleuniger [ID: 60]

Arbeitspaket: Leiterplatten-Design [ID: 61]Beteiligte: Olaf MeyerAbhängigkeit: Beschleunigerarchitektur [ID: 25]Beschreibung: Entwicklung des Layout der Leiterplatte.

Arbeitspaket: Leiterplattenbestückung [ID: 62]Beteiligte: Olaf MeyerAbhängigkeit: Leiterplatten-Design [ID: 61]Beschreibung: Bestückung der Leiterplatte mit den ausgewählten Komponen-

ten.

2.2.3.5 Benutzungsschnittstelle [ID: 63]

Arbeitspaket: Anfertigung der Benutzungsschnittstelle [ID: 64]Beteiligte: Olaf MeyerAbhängigkeit: Benutzungsschnittstellen [ID: 26]Beschreibung: Die Benutztungsschnittstelle bestehend aus Anzeige und Tas-

tatur wurde implementiert. Dies umfasst die Anfertigung derHardware sowie zweier Programme zur Kommunikation mit derAnzeige.

15

2 Projektmanagement

Arbeitspaket: Linux-Portierung der Display-Ansteuerung [ID: 65]Beteiligte: Wincent BalinAbhängigkeit: Anfertigung der Benutzungsschnittstelle [ID: 64]Beschreibung: Ergänzung des Programms für die Ansteuerung des LC-Displays

um Linux-spezifische Funktionen zur Kommunikation über dieserielle Schnittstelle

2.2.3.6 Industrie-PC [ID: 66]

Betriebssystem [ID: 67]

Arbeitspaket: Betriebssystem: Anpassung des Kernel [ID: 68]Beteiligte: Tobias Weidelt, Frerk Müller, Friedrich KretschmerAbhängigkeit: keineBeschreibung: Linux-Einrichtung: Kernel-Anpassung, Kernel-Patches

Arbeitspaket: Betriebssystem: „Abspecken“ des Systems [ID: 69]Beteiligte: Tobias Weidelt, Frerk Müller, Friedrich KretschmerAbhängigkeit: Betriebssystem: Anpassung des Kernel [ID: 68]Beschreibung: „Abspecken“ des Gentoo-Systems

Arbeitspaket: Betriebssystem: ucLibC und Busybox [ID: 70]Beteiligte: Tobias Weidelt, Frerk Müller, Friedrich KretschmerAbhängigkeit: Betriebssystem: „Abspecken“ des Systems [ID: 69]Beschreibung: Evaluation von ucLibC und Busybox

Arbeitspaket: Betriebssystem: Installation von Bluetooth [ID: 71]Beteiligte: Tobias Weidelt, Friedrich KretschmerAbhängigkeit: Betriebssystem: ucLibC und Busybox [ID: 70]Beschreibung: Installation und Testen von Bluetooth

MHA-System [ID: 85]

Arbeitspaket: MHA-Adapter-Plugin [ID: 73]Beteiligte: Tobias Weidelt, Friedrich KretschmerAbhängigkeit: MHA-Adapter-Plugin [ID: 28]Beschreibung: Implementierung des MHA-Adapter-Plugins

Arbeitspaket: PCI-Treiber [ID: 72]Beteiligte: Tobias Weidelt, Friedrich KretschmerAbhängigkeit: PCI-Treiber [ID: 29]Beschreibung: komplette Implementierung des Treibers

16

2.2 Projektplan

Arbeitspaket: Umsetzung des graphischen Menüs [ID: 74]Beteiligte: Tobias Weidelt, Friedrich KretschmerAbhängigkeit: Design der graphischen Menüführung [ID: 30]Beschreibung: Implementierung der grafischen Menüführung sowie der Bedien-

skripte

2.2.3.7 Gehäuse [ID: 81]

Arbeitspaket: Gehäuse: Verkabelung, Lötarbeiten [ID: 82]Beteiligte: Tobias Weidelt, Frerk Müller, Friedrich KretschmerAbhängigkeit: Gehäusedesign [ID: 32]Beschreibung: Verkabelung der Komponenten, Stecker löten etc.

Arbeitspaket: Gehäuse: Fertigung [ID: 83]Beteiligte: Friedrich KretschmerAbhängigkeit: Gehäuse: Verkabelung, Lötarbeiten [ID: 82]Beschreibung: Besorgen der Bauteile, Fertigung des Gehäuses

Arbeitspaket: Gehäuse: Anpassung [ID: 84]Beteiligte: Tobias Weidelt, Friedrich KretschmerAbhängigkeit: Gehäuse: Fertigung [ID: 83]Beschreibung: weitere Anpassungen am Gehäuse. Neue Bohrungen und Aus-

sparungen

2.2.3.8 Prototypen [ID: 76]

Arbeitspaket: Prototyp 1 [ID: 76]Beteiligte: Tobias Weidelt, Frerk Müller, Friedrich KretschmerAbhängigkeit: keineBeschreibung: Integration der Komponenten zu einem 1. Prototyp

Arbeitspaket: Prototyp 2 [ID: 77]Beteiligte: Tobias Weidelt, Friedrich KretschmerAbhängigkeit: keineBeschreibung: Integration der Komponenten zu einem 2. Prototyp

2.2.4 Tests [ID: 86]2.2.4.1 Komponententests [ID: 87]

Arbeitspaket: Leiterplattentest [ID: 95]Beteiligte: Olaf MeyerAbhängigkeit: Leiterplattenbestückung [ID: 62]Beschreibung: Elektrische Tests des Beschleunigers durchgeführt.

17

2 Projektmanagement

Arbeitspaket: PCI-Kern [ID: 88]Beteiligte: Olaf Meyer, Wincent BalinAbhängigkeit: PCI-Architektur [ID: 58]Beschreibung: Die VHDL-Programme des PCI-Kernes wurden getestet.

Arbeitspaket: MHA-FPGA-seitiger Localbus-Test [ID: 89]Beteiligte: Kai Besold, Malte VietAbhängigkeit: Implemtentierung des MHA-Controllers [ID: 51]Beschreibung: Konzeption und Implementierung einer Testkomponente, die die

Intrakommunikation auf elektrischer Ebene testet - Daten vonEingangs-FIFO nach Ausgangs-FIFO transferieren

Arbeitspaket: Hardware-Plugin-Test [ID: 90]Beteiligte: Malte VietAbhängigkeit: Implemtentierung des MHA-Controllers [ID: 51]Beschreibung: Test der Hardware-Plugin-Schnittstelle des Controllers. Um die

Aufgabe erfüllen zu können, wurde ein simples Hardware-Pluginimplementiert, das einen vollständigen Test der Schnittstellezuließ. Des Weiteren wurden Testpakete definiert, die durch denPCI-FPGA versand wurden.

Arbeitspaket: Software-Plugin-Test (NIOS II) [ID: 91]Beteiligte: Frerk MüllerAbhängigkeit: Implementierung des MHA-Controllers [ID: 51]Beschreibung: Test der Software-Plugin-Schnittstelle des Controllers. Um die

Aufgabe erfüllen zu können, wurde ein simples Software-Pluginimplementiert, das einen vollständigen Test der Schnittstellezuließ. Des Weiteren wurden Testpakete definiert, die durch denPCI-FPGA versand wurden.

Arbeitspaket: PCI-Treiber [ID: 96]Beteiligte: Tobias Weidelt, Friedrich KretschmerAbhängigkeit: PCI-Treiber (Implementierung) [ID: 72]Beschreibung: Erstellung eines Tesprogramms zum Test des Treibers

2.2.4.2 Intra-Kommunikationstests [ID: 92]

Arbeitspaket: MHA-FPGA / PCI-FPGA 1 [ID: 93]Beteiligte: Frerk Müller, Malte Viet, Olaf MeyerAbhängigkeit: MHA-FPGA-seitiger Localbus-Test [ID: 89], Leiterplattentest

[ID: 95], PCI-Kern [ID: 88]Beschreibung: Umfangreicher Test der externen Schnittstelle in Zusammen-

hang mit dem PCI-FPGA. Tests wurden hinsichtlich Stabilitätund aller möglichen Pakettypen und Paketgrößen vorgenommen.

18

2.3 Risikomanagement

Arbeitspaket: MHA-FPGA / PCI-FPGA 2 [ID: 94]Beteiligte: Frerk MüllerAbhängigkeit: MHA-FPGA / PCI-FPGA 1 [ID: 93]Beschreibung: Vollständiger Test des MHA-Controllers. Dies bezieht sich auf

die Zusammenarbeit mit der externen Schnittstelle, den Hard-und Software-Plugins, dem Speichermanagement sowie der Ve-rifizierung der Kontrollstruktur.

2.2.5 Dokumentation [ID: 78]

Arbeitspaket: Zwischenbericht [ID: 79]Beteiligte: gesamte GruppeBeschreibung: Zusammenfassen der Ergebnisse bis zur Hälfte der Projektlauf-

zeit

Arbeitspaket: Abschlussbericht [ID: 80]Beteiligte: gesamte GruppeBeschreibung: Zusammenfassen der Ergebnisse des gesamten Projektes

2.3 RisikomanagementDieser Abschnitt befasst sich mit der Erkennung und Behandlung aufgetretener Ri-siken. Da es sich bei dem Projekt um eine Studienleistung handelt und die Gruppen-mitglieder über wenig Erfahrung mit Projekten dieser Größe verfügten, konnten vieleRisiken erst zur Projektlaufzeit erkannt werden. Im Folgenden werden die im Projekterkannten Risiken und deren Behandlung näher erläutert.

2.3.1 Veränderung der AnforderungenZu Beginn des Projektes wurden vom Auftraggeber Anforderungen hinsichtlich derzu verwendenden Hardwaregrundlage gestellt. Die Realisierbarkeit des Systems unterdiesen Bedingungen wurde durch ausgiebige Tests widerlegt. Auf Basis der Tester-gebnisse wurden die Anforderungen in Zusammenarbeit mit den Auftraggeber neudefiniert. Es wurde also auf die Verwendung eines PDAs verzichtet und statt dessenein Industrie-PC als Basis für das MHA-Framework eingesetzt.

2.3.2 LieferungsverzögerungenDa innerhalb des Projektes Hardware-Komponenten entwickelt wurden, wurden re-gelmäßig Bestellungen von Bauteilen durchgeführt. Um zu verhindern, dass Liefe-rungsverzögerungen Auswirkungen auf das Projekt hatten, wurden die Bestellungenso früh wie möglich aufgegeben. Bestellungen die dennoch nicht rechtzeitig eintrafen,wurden durch Umstellung des Projektplans kompensiert.

Dies traf auf die in Auftrag gegebene Fertigung der Beschleuniger-Platine undauf die Lieferung des Parallax SmartPack zu. Die geplanten Intrakommunikations-tests konnten somit nicht planmäßig durchgeführt werden, so dass die Kommunika-

19

2 Projektmanagement

tion so weit wie möglich durch Simulation getestet und die weitere Entwicklung vonHardware-Komponenten vorgezogen worden ist.

Die Lieferungsverzögerung des Industrie-PCs wurde kompensiert, indem vorläufigein IBM-kompatibler PC eingesetzt wurde. Nach Eintreffen der Hardware wurde dasBetriebssystem auf den Industrie-PC portiert.

2.3.3 Unterschätzung des Umfangs

Verzögerungen des Projektes durch Unterschätzung des Umfangs einzelner Arbeits-pakete konnten durch den Projektplan früh erkannt werden. Eine Behandlung dieserVerzögerung war nur durch die Verlagerung von Resourcen oder durch zusätzlicheÜberstunden möglich.

Diese Problematik trat im Arbeitspaket MHA-Controller auf. Um die Fertigstel-lung des Projektes nicht zu gefährden, wurden beide Lösungsansätze durchgeführt.Die Verantwortlichkeiten wurden neu organisiert und die dadurch nicht kompensierteArbeit durch Überstunden abgefangen.

Auch der Entwurf und die Implementierung der Hardware-Plugins wave2spec undspec2wave wurden unterschätzt. Die Anzahl der Entwickler wurde verdreifacht, den-noch war es nicht möglich, diese Komponente bis zum Projektende fertigzustellen.

2.3.4 Mangelnde Infrastruktur

Mängel in der Infrastruktur wurden vom Projektmanagement im Vorfeld nicht alsRisiko identifiziert. Sie traten vorwiegend in der Implementierungsphase auf undmanifestierten sich in fehlende Lizenzen für Entwicklungswerkzeuge. PCs mit denentsprechenden Entwicklungssoftware waren erst in den späten Abendstunden zu-gänglich und führten zur Nachtarbeit. Verspätungen des Projektes waren die Folge.Die Anschaffung einer Lizenz und eines Arbeitsplatzes, der ausschließlich den Pro-jektgruppenmitgliedern zur Verfügung stand, verbesserte diese Situation erheblich.

2.3.5 Unterschätzung der PCI-Komplexität

Bei der Entwicklung des PCI-Kernes wurde auf strikte Standardkonformität geach-tet. Weiterhin erfolgte das Layout der Leiterplatte unter Berücksichtigung möglichstkurzer Leiterbahnlängen vom PCI-FPGA zum Stecker des PCI-Busses. Simulatio-nen des PCI-Kernes liefen erfolgreich ab. Im Zusammenspiel mit dem verwendetenEmbedded-PC versagte der PCI-Controller allerdings. Weder Messungen mit demSignalTap II-Logikanalysator von Altera, noch eine Adaptation des Verhaltens desentwickelten PCI-Kernes an den Kern von Altera brachten Erfolg.

Als Ausweichlösung wurde eine zeitlich eingeschränkte Version des PCI-Kerns vonAltera verwendet. Dieser funktionierte im FPGA und mit der entwickelten Leiterplat-te, auch im Zusammenspiel mit dem Embedded-PC. Die Verwendung dieses Kernesmacht jedoch den Kauf einer weiteren Lizenz erforderlich, so dass die Mobilität desGesamtsystems zur Zeit nicht gegeben ist.

20

2.4 Kostenübersicht

2.3.6 Fazit

Viele der möglichen Risikofaktoren wie Veränderung der Anforderungen, Lieferver-zögerungen, Unterschätzung des Umfangs, Unterschätzung der PCI-Komplexität undmangelnde Infrastruktur sind während des Projekts eingetreten. Die Notwendigkeiteines Risikomanagements zeigt sich alleine durch diesen Sachverhalt. Allerdings ist diekorrekte Einschätzung der Risiken im Vorfeld die eigentliche Aufgabe des Risikoma-nagements und kann nur auf Basis von Erfahrungen in einem qualitativ ausreichendenMaß sichergestellt werden. Besondere Bedeutung kommt den Faktoren zu, die im Vor-feld als ausgeschlossen angesehen werden, wie z.B. Mängel in der Infrastruktur. Trittein solches Ereignis ein, so sind die negativen Auswirkungen verhältnismäßig hoch.

2.4 KostenübersichtDieser Abschnitt gibt einen Überblick über die aufgetretenen Kosten. Folgende Listebeinhaltet lediglich Materialkosten. Kosten, die für den Erwerb von Lizenzen oderanderer Infrastruktur auftraten, sind nicht aufgeführt. Diese

Artikel Preis [e]

Parallax Stratix 672 SmartPack Rev B/C 500,00Altera Cyclone II FPGA 25,00Konfigurationsspeicher EPCS4 15,80Leiterplatte Beschleuniger 130,00Grafische Anzeige EA-DIP122B-5NLW 32,15Leiterplatten für Anzeige 14,00PC/104-Plus-Buchsen 20,00Industrie-PC speedMOPSlcdCE 345,68Spannungsregler 23,00Gehäuseteile 30,00Kleinteile (Kondensatoren, Widerstände,Kabel etc.)

40,00

Gesamt 1175,63

Tabelle 2.1: Materialausgaben für das Projekt

2.5 Anforderungen an die InfrastrukturIn diesem Abschnitt wird die zur Entwicklung des Gesamtsystems notwendige Infra-struktur aufgezeigt. Diese lässt sich Software-Werkzeuge und Hardware-Werkzeugegliedern. Gemäß dieser Kategorisierung folgen zwei Unterabschnitte, die sich mit je-weils einer Kategorie befassen.

2.5.1 Hardware-Ressourcen

Die für die Entwicklung notwendige Hardware ist in der folgenden Auflistung be-schrieben.

21

2 Projektmanagement

Labornetzteil Das Netzteil ist notwendig, um das Gesamtsystem während der Ent-wicklung mit Energie zu versorgen und um verschiedene Tests durchführen zukönnen. Das Netzteil muss einen kontinuierlichen Spannungsbereich von 0–12 Vumfassen und über diesen Spannungsbereich einen Strom von mindestens 5 Aliefern können. Verschiedene Netzteile mit hinreichenden Eigenschaften sind imLabor verfügbar.

Lötwerkzeuge Zur Anfertigung selbstentwickelter Hardware sind Werkzeuge zum Lö-ten elektronischer Bauteile notwendig. Diese Werkzeuge müssen über Tempa-raturregulierung und Potentialausgleich verfügen, um die verarbeiteten Bautei-le nicht zu beschädigen. Weiterhin müssen die Lötwerkzeuge die Bearbeitungkleiner Strukturen zulassen. Diese Werkzeuge stehen im Labor des OFFIS zuVerfügung. Sowohl eine SMD-Lötstation zur Bearbeitung kleiner Strukturen alsauch eine zur Verarbeitung größerer Strukturen sind verfügbar.

Messgeräte In der Testphase sind verschiedene Messungen zur Verifikation des Ge-samtsystems zu tätigen. Dazu sind Messgeräte für Spannung, Strom und Wi-derstand sowie zur Messung zeitvarianter elektrischer Größen notwendig. Ers-tere können mittels eines Multimeters und letztere über ein Oszilloskop erfasstwerden. Diese Geräte stehen im Labor mit hinreichenden Charakteristika zurVerfügung.

Arbeitsplatz Die Empfindlichkeit integrierter Schaltkreise auf elektrostatische Ent-ladungen macht einen Arbeitsplatz erforderlich, der Schutzmaßnahmen gegendiese Effekte aufweist. Weiterhin sind geltende Unfallverhütungsvorschriftender Elektronikindustrie zu beachten. Ein Arbeitsplatz mit diesen Eigenschaf-ten wird im Labor des OFFIS zur Verfügung gestellt.

allg. Werkzeuge Weiterhin sind verschiedene Werkzeuge wie Schraubendreher, Zan-gen, Pinzetten, Lupen etc. erforderlich. Diese sind im Labor des OFFIS verfüg-bar.

2.5.2 Software-Resourcen

Zur Untersützung und Verwaltung des Entwicklungsprozesses des Gesamtsystems,wurden folgende Programme mit den jeweils beschriebenen Charakteristika benötigt.

FPGA-Synthese Zur Synthese einer VHDL-Beschreibung sind Werkzeuge für FPGAsdes Unternehmens Altera notwendig. Diese Werkzeuge sind in der Entwicklungs-umgebung Quartus II [7] enthalten und werden durch das OFFIS zur Verfügunggestellt. Ebenso ist eine kostenfreie, eingeschränkte Version von Quartus II überdas Internet durch Altera verfügbar.

FPGA-Simulation Für die Simulation von VHDL-Entwürfen bietet die Entwicklungs-umgebung Quartus II einen integrierten Simulator an. Weiterhin ist das Werk-zeug ModelSim [8] von Mentor Graphics [9] über das OFFIS verfügbar.

C++-Entwicklung Die Programmentwicklung für die Komponenten des Gesamtsys-tems erfordert spezifische Entwicklungsumgebungen für die jeweilige Kompo-

22

2.6 Qualitätssicherung

nente. Mit den Entwicklungsumgebungen KDevelop [10], SDCC [11], NIOSII-IDE [12] und NIOS GNU-Tools [3] sind für jeden Bereich entsprechende Umge-bungen verfügbar. Die Entwicklungsumgebungen für NIOS-Prozessoren werdendurch das OFFIS zur Verfügung gestellt. Alle anderen Werkzeuge können überdas Internet kostenfrei bezogen werden.

Schaltungsentwurf Für den Schaltungsentwurf wird das Programm CadStar [13] desUnternehmens Zuken [14] verwendet, welches im OFFIS zur Verfügung steht.

Versionsverwaltung Die Versionsverwaltung aller Dokumente wird mit dem Werk-zeug Subversion [15] durchgeführt und ist über das Internet kostenfrei zu be-ziehen.

Dokumentation Die Dokumentation erfolgt mit dem Schriftsatzsystem LATEX [16],welches kostenfrei bezogen werden kann.

2.6 QualitätssicherungDieser Abschnitt befasst sich mit Konventionen, die hinsichtlich der Qualität des Pro-jektes getroffen worden sind. Dies beinhaltet Sicherheitsaspekte gegenüber der Siche-rung von Informationen, Richtlinien für Dokumentationen und Aspekte der Qualitätgegenüber dem zu entwickelnden Produkt.

2.6.1 Sicherungsmechanismen

Alle hier beschriebenen Sicherheitsmechanismen dienten der Sicherung von Dateien.Dies bezieht sich sowohl auf Quellcodes, Schaltpläne, Gehäuse-Entwürfe, als auchauf jegliche Form von Dokumentation. Folgende Sicherheitsaspekte wurden hierbeiberücksichtigt:

• Datensicherheit durch zusätzliche zentrale Speicherung der Daten

• Vermeidung von Konflikten verursacht durch das Arbeiten mehrerer Projekt-mitglieder an einer Datei

• Wiederherstellungsmöglichkeit älterer Versionen des Produktes

Um diese Sicherheitsaspekte zu erfüllen, wurde ein SVN-Repository verwendet. Esberücksichtigt diese Probleme und stellt zudem allen Projektbeteiligten die Datendynamisch zur Verfügung.

2.6.2 Berichterstattungsmechanismen

Um innerhalb des Projektes die Kommunikation zu fördern, wurden zwei Gruppen-sitzungen pro Woche abgehalten. Diese Sitzungen gaben die Möglichkeit, sowohl Pro-blem hinsichtlich der Entwicklung zu besprechen, als auch den aktuellen Entwick-lungsstand für die Gruppe transparent zu halten. Um Entscheidungen hinsichtlichdes Projektes festzuhalten, wurden während der Sitzungen Protokolle angefertigt,die in einem SVN-Repository zugreifbar waren. Dies ermöglichte auch der Sitzung

23

2 Projektmanagement

ferngebliebenen Personen den Zugriff auf die besprochene Informationen. Des Wei-teren wurden Kommunikationsmedien wie E-Mail-Verteiler und Messenger-Systemeverwendet. Dies bot eine schnelle und einfach zu handhabende Plattform, um Pro-bleme bezüglich des Produktes zu diskutieren.

Die Auftraggeber waren einmal pro Woche während der Sitzungen anwesend. Aufdiesem Wege konnten finanzielle Belange oder Fragen hinsichtlich der Anforderun-gen an das Produkt unkompliziert gelöst werden. Des Weiteren waren die Auftrag-geber ebenfalls über einen E-Mail-Verteiler erreichbar. Um den Auftraggebern eineÜberblick über das Projekt zu gewähren, wurde zur Mitte der Projektlaufzeit einZwischenbericht angefertigt, der den aktuellen Stand der Arbeit dokumentierte. Diesbeinhaltete Entwurfsentscheidungen, die aus der Analyse der Problemstellung resul-tierten und einen Prototypen, der einen Ausblick über das finale Produkt gab. ZumAbschluss des Projektes wurde ein Abschlussbericht mit einem Überblick über dasgesamte Projekt verfasst. Ebenso wie Entwickler- und Benutzerhandbuch und diefinale Version des Produktes.

2.6.3 DokumentationIm Projekt wurden vier unterschiedliche Arten von Dokumentationen benötigt. Diesbetrifft Berichte, Handbücher, Protokolle und die Dokumentation von Quellcode. Füralle Dokumentationen wurde eine Richtline verfasst, die hier kurz im erläutert werden.

Berichte: Es wurden zwei Berichte verfasst. Der Zwischenbericht und der Abschluss-bericht, die den Auftraggebern einen Überblick über das Produkt vermittelten.Da diese Dokumente von der gesamten Gruppe erstellt wurden, war es nötigRichtlinien aufzustellen, deren Berücksichtigung die Qualität des Produktes er-höhten. Diese Richtlinien wurden der Gruppe im Repository bereitgestellt unddynamisch aktualisiert. Um das Layout des Dokumentes einheitlich zu gestaltenund die Integrierbarkeit zu erhöhen, wurde LATEXals Schriftsatzsprache verwen-det.

Handbücher: Um die weitere Verwendbarkeit des Produktes zu gewährleisten wur-den zwei Handbücher verfasst. Zum einem das Benutzerhandbuch, dessen Zieles ist, einem technisch nicht versierten Benutzer die Bedienung des Produktesso einfach wie möglich zu gestalten und dem Entwicklerhandbuch, das das Ent-wickeln von Algorithmen auf dem Beschleuniger vereinfacht. Beide Handbücherwurden in LATEXverfasst und mit Grafiken zum besseren Verständnis illustriert.

Sitzungsprotokolle: In den Gruppensitzungen wurden Protokolle geschrieben. Diesdiente dazu, Beschlüsse der Gruppe in schriftlicher Form festzuhalten. Um dieStruktur des Dokumentes zu wahren, wurde ein Template erzeugt. Bestandteiljedes Protokolls waren somit: „Datum, Autor, Sitzungsleiter, Überprüfung derAnwesenheit, Zusammenfassung der Sitzung“. Sitzungsprotokolle wurden ausGründen der Effektivität als einfach Text-Dateien verfasst.

Quellcode: Der Quellcode wurde innerhalb der Dateien direkt kommentiert. Dieserhöht die Lesbarkeit. Um die weitere Verwendbarkeit nach Abschluss des Pro-jektes zu erhöhen, wurde beschlossen die Kommentare in englischer Spracheeinzupflegen. Dies ermöglicht die internationale Nutzung des Quellcodes.

24

2.6 Qualitätssicherung

2.6.4 ProduktüberprüfungDie Produktqualität wurde auf zwei Wegen sichergestellt. Zum einen wurde der Grup-pe in regelmäßigen Abständen die erstellte Arbeit vorgestellt, was half, fehlerhafteoder unvollständige Spezifikationen aufzudecken. Zum Anderen wurden umfangreicheTests am Produkt vorgenommen. Die Tests wurden auf drei Ebenen durchgeführt,die im nachfolgenden kurz beschrieben werden:

Ebene 1 Komponententest: In dieser Ebene wurden lediglich die einzelnen Kompo-nenten in sich getestet. Es war keine Kommunikation zwischen zwei Kompo-nenten vorgesehen. Testziel war die Verifikation der Komponente.

Ebene 2 Integrationstest: Der Integrationstest war ein Test, der grundsätzlich dieKommunikation zweier Komponenten verifizierte. Ziel ist die Überprüfung elek-trischer Funktionalität und Identifikation konzeptueller Fehler.

Ebene 3 Gesamtsystemtest: Der Gesamtsystemtest testete die Kommunikation al-ler Komponenten. Das Ziel ist identisch mit den Integrationstests und bildeteden finalen Test.

25

2 Projektmanagement

26

3 Anforderungsdefinition

Die Aufgabe der Projektgruppe, ein mobiles Endgerät für das MHA bereitzustel-len, wurde von verschiedenen Anforderungen begleitet. Diese ergaben sich zum einendurch die Auftraggeber des Projektes als auch aus Recherche- und Entwicklungs-arbeiten im Laufe des Projektes. Im Folgenden sollen diese Anforderungen näherbetrachtet werden. Dazu erfolgt eine Gliederung in allgemeine Anforderungen undsolche von Benutzern und Entwicklern des Systems.

3.1 Allgemeine AnforderungenEin Einsatz des MHA auf einer mobilen Plattform erfordert eine Soundkarte mit hin-reichenden Eigenschaften. Diese sind neben der Anzahl von mindestens 6 Eingangs-und zwei Ausgangskanälen, solche wie geringe Latenz zwischen Ein- und Ausgabeder Soundkarte. Die Abmessungen der Plattform sind möglichst minimal zu gestal-ten, wobei ein zulässiges Gesamtgewicht von 1 kg nicht überschritten werden sollte.Weiterhin ist eine Betriebslaufzeit im mobilen Einsatz von drei Stunden verlangt.Diese Anforderungen sind in Tabelle 3.1 nochmals zusammengefasst.

Allgemeine AnforderungenGewicht max. 1 kgAbmessungen kompakt (tragbar)Laufzeit mit Akku mindestens 3 StundenSchnittstellen USB-Schnittstelle(n) notwendig

Tabelle 3.1: Überblick über die allgemeinen Anforderungen an die zu entwickelndePlattform

Zwei Typen von Endanwendern sind an der Aufstellung dieser Anforderungen be-teiligt: Das Endgerät soll einerseits von Testpersonen genutzt werden, die den Einsatzvon Algorithmen zur Verbesserung des Höreindruckes in Feldversuchen erproben. An-dererseits sollen Entwickler die Möglichkeit haben, neue Algorithmen für die Platt-form zu entwickeln und diese komfortabel auf dem Endgerät zu betreiben.

3.2 Anforderungen des BenutzersDas Bedienfeld des Gerätes soll einfach gehalten werden, um auch technisch unver-sierten Personen eine einfache Nutzung zu ermöglichen. Das Gerät muss ein- undausschaltbar sein. Ebenso ist gefordert, die Lautstärke regeln sowie zwischen deneinzelnen Plugin-Ketten umschalten zu können. Des Weiteren soll ein Benutzerhand-buch zur Einführung in das System mitgeliefert werden. Die Tabelle 3.2 fasst dieseAnforderungen nochmals zusammen.

27

3 Anforderungsdefinition

BenutzeranforderungenBedienung möglichst einfachInteraktion mit dem Benutzer Regeln der Lautstärke,

Umschalten zwischen den Ketten,Ein- und Ausschalten des Gerätes

Dokumentation leicht verständliches Bentzerhandbuch

Tabelle 3.2: Überblick über die Benutzeranforderungen an die Plattform

3.3 Anforderungen des EntwicklersDie allgemeine Problematik vieler MHA-Plugins ist die große Nachfrage nach Rechen-leistung. Ebenso sollen alle für den Entwickler benötigten Algorithmen auch weiter-hin auf der mobilen Plattform einsetzbar sein. Dabei darf eine Gesamtlatenz zwischenEin- und Ausgabe von maximal 15 ms nicht überschritten werden, um den Hörein-druck nicht zu verfälschen. Diese Anforderungen legen die Auslagerung rechenintensi-ver Plugins auf dedizierter Hardware nahe. Die Auslagerung muss aus Sicht des Ent-wicklers jedoch transparent erscheinen oder mit wenig Aufwand realisierbar sein. Esist somit ein effektives Zusammenspiel von Soft- und Hardware-Plugins im Endgerätangestrebt. Selbstverständlich müssen die neuen Möglichkeiten zur Erweiterung undBeschleunigung durch ausgelagerte Hardware-Plugins in einem Entwicklerhandbuchdokumentiert werden, um dem Entwickler die Nutzung des Gerätes zu ermöglichen.Die Anforderungen des Entwicklers sind in Tabelle 3.3 nochmals zusammengestellt.

EntwickleranforderungenBetriebssystem LinuxLaufzeitumgebung MHA

gemeinsame Verwendung von Hard- undSoftware-Plugins in einer Berechnungsket-te

Max. Latenz 15 msDokumentation Entwicklerhandbuch

Tabelle 3.3: Überblick über die Entwickleranforderungen an die Plattform

28

4 Analyse

Nachdem die Anforderungen an das System feststanden, wurde eine Exploration desmöglichen Entwurfsraumes vorgenommen. Im Vorfeld wurden Ideen bezüglich derRealisierung des Gesamtsystems gesammelt. Auf Basis dieser Ideen wurden möglicheKomponenten und Architekturen zusammengestellt und hinsichtlich ihrer Eignungfür das Gesamtsystem bewertet.

In diesem Kapitel ist die Analyse niedergeschrieben. Zu Beginn werden möglichePlattformen und deren Anbindung an externe Komponenten über Busse zur Be-schleunigung des Gesamtsystems untersucht. Im Anschluss folgt eine Untersuchungder Belastung der Plattform durch das MHA und der sich daraus ergebenden Auslage-rungsstrategien zur Entlastung derselben. Im weiteren Verlauf des Kapitels folgt eineMarktrecherche für spezielle Komponenten, die rechenintensive Aufgaben des MHAübernehmen könnten. Sodann folgt eine Charakterisierung möglicher Akkumulatorenzur mobilen Energieversorgung des Gesamtsystems. Das Kapitel schließt mit einerEingrenzung der analysierten Komponenten, die zur Realisierung des Gesamtsystemsals verwendbar erscheinen.

4.1 PlattformenUnter dem Begriff Plattform wird an dieser Stelle die Betriebsumgebung für dasMHA-Rahmenwerk verstanden. Die Plattform stellt somit die Basis für das Gesamt-system dar, deren Schnittstellen maßgeblich für die Anbindung von beschleunigenderHardware sind. Es ist offensichtlich, dass die Wahl der Plattform kritisch in Bezugauf die Optimierung des angestrebten Gesamtsystems ist.

Die Plattformen

• Industrie-PCs,

• tragbare Spielekonsolen oder

• tragbare Kleinstrechner (PDA)

kamen in Betracht, da sie ein hohes Maß an Rechenleistung und lange Akkulaufzeitenaufwiesen. Des Weiteren sind diese allgemein verfügbar, kostengünstig, sowie tragbar.In den folgenden Abschnitten werden die Geräte dieser Kategorien untersucht undauf ihre Tauglichkeit als Laufzeitumgebung für das MHA-Rahmenwerk bewertet. DieAuswahl und Bewertung erfolgt auf Basis folgender Kriterien:

Prozessortyp: Der MHA-Umgebung muss ein leistungsfähiger Prozessor zugestandenwerden, damit die Verarbeitung der Audiodaten hinreichend schnell geschieht.Ebenso verlangt das Betriebssystem Ressourcen zur Bereitstellung einer echt-zeitfähigen Laufzeitumgebung.

29

4 Analyse

Hauptspeicherkapazität: Die Hauptspeicherkapazität muss dergestalt sein, dass diezur Verarbeitung anstehenden Signaldaten sowie Teile des Betriebsystems undder Algorithmen dort vorgehalten werden können. Ebenso muss die Pufferungund Verwaltung der zu verarbeitenden Audiodaten ermöglicht werden, da zu-sätzliche Verarbeitungseinheiten wie Hardwarebeschleuniger evtl. unterschiedli-che Charakteristika hinsichtlich ihrer Datenübertragungseigenschaften aufwei-sen können.

Schnittstellen: Zur Anbindung einer Beschleunigungselektronik sind Schnittstellenmit einer hohen Bandbreite unabdingbar. Insbesondere sind USB 2.0-Schnittstel-len von Interesse, da im weiteren Projektverlauf der Anschluss einer USB 2.0-Soundkarte geplant ist.

Energieversorung: Eine möglichst einfache Versorgung der Plattform mit Energie istvon großer Wichtigkeit, da sie die Komplexität des Gesamtsystems reduziert.Auch ist eine hohe Effizienz von Bedeutung, um möglichst lange Akkulaufzeitenzu erreichen.

Abmessungen und Gewicht: Das Gesamtsystem unterliegt räumlichen Beschränkun-gen, so dass diese Beschränkungen ebenso der Plattform obliegen. Auch er-fordert der mobile Einsatz ein geringes Gewicht des Gesamtsystems, um dieBewegungsfreiheit des Anwenders nicht zu beeinträchtigen.

Preis: Der finanzielle Rahmen des Projektes erzwingt eine besonders kostengünstigePlattform.

In den folgenden Unterabschnitten werden die untersuchten Plattformkategorienvorgestellt und Vertreter dieser mit ihren Eigenschaften genannt. Dabei wurden nursolche Geräte erwähnt, die mindestens die oben genannten Kriterien bestmöglichsterfüllen. Daher ist zu beachten, dass viele Geräte jeder Kategorie unerwähnt bleiben.

4.1.1 Industrie-PC-PlattformenUnter der Bezeichnung Industrie-PC wird eine kompakte Ausführung eines IBM-kompatiblen PCs verstanden, der hinsichtlich industrieller Anwendungen optimiertwurde. Dies betrifft insbesondere den zulässigen Temperaturbereich, die vorhandenenSchnittstellen, die Abmessungen, sowie die Energieversorgung des PCs. AngestrebteAnwendungsbereiche liegen daher vorwiegend in der Automation und der Robotik.

Diese Eigenschaften lassen einen Industrie-PC auch als Plattformalternative fürdas MHA als sinnvoll erscheinen. Zum einen erhält man durch den Einsatz eines sol-chen PCs die bekannte Entwicklungs- und Laufzeitumgebung eines IBM-kompatiblenPCs. Dies beschleunigt wiederum die Entwicklung, da ein weiteres Studium der Ent-wicklungsumgebung weitgehend unterbleiben kann und vereinfacht die Installation,da das Betriebssystem Linux ohne größere Änderungen auf den Industrie-PC portiertwerden kann. Zum anderen können die geforderten Eigenschaften des angestrebtenGesamtsystems, wie geringe Abmessungen und Energiebedarf, durch einen Industrie-PC befriedigt werden.

Die Recherche des Marktes der Industrie-PC-Anbieter ist in den Tabellen 4.1 und4.2 niedergeschrieben. Bei der Auflistung wurden PCs mit offensichtlich zu gerin-

30

4.1 Plattformen

ger Leistung, sowie solche mit unzureichenden Schnittstellen, nicht mit aufgeführt.

4.1.2 Spielekonsolenplattformen

Unter dem Begriff Spielekonsole wird hier ein auf die Verarbeitung von Computer-spielen spezialisierter Kleinstrechner verstanden. Die fortwährende Weiterentwicklungauf diesem Gebiet bringt permanent neue und leistungsfähigere Spielekonsolen her-vor, wobei die Architekturen dieser Geräte auch geeignet sind, außer Computerspielenauch verschiedene Programme auszuführen. Diese beiden Aspekte machen den Ein-satz einer solchen Spielekonsole als Laufzeitumgebung für das MHA-Rahmenwerkdenkbar.

Die Recherche auf dem Markt der Hersteller dieser Konsolen erbringt die Resultatein der Tabelle 4.3. Es wird deutlich, dass nur wenige über die notwendigen Schnittstel-len verfügen, um weitere Beschleunigerelektronik anschließen zu können. Des Weite-ren ist es durch die hohe Spezialisierung nicht ohne weiteres möglich, die Spielekonsolefür anwendungsfremde Programme einzusetzen. In vielen Fällen wird keine frei verfüg-bare und verlässliche Entwicklungsumgebung bereitgestellt. Diese Umstände machenden Einsatz von Spielekonsolen als Laufzeitumgebung des MHA-Rahmenwerks nurbedingt möglich.

4.1.3 PDA-Plattformen

Unter der Bezeichnung Personal Digital Assistant wird im Allgemeinen ein tragbarerKleinstrechner verstanden, der vorrangig für Planung und Verwaltung von Terminenoder Adressen konzipiert ist. Die zunehmende Rechenleistung dieser Kleinstrechnerdurch voranschreitende Systemintegration erlaubt stetig komplexer werdende Appli-kationen. Dies umfasst z.B. das Abspielen von Videos oder den mobilen Internet-Zugriff.

Dieser Trend der zunehmenden Funktionsvielfalt und Rechenleistung kann zu Guns-ten einer Laufzeitumgebung für das MHA-Rahmenwerk ausgenutzt werden. Dies wirdinsbesondere dadurch ermöglicht, dass viele PDAs mit dem Betriebssystem Linuxausgeliefert werden oder auf dieses nachträglich umgestellt werden können. Die Ent-wicklungsumgebung ist somit bekannt und die Einarbeitung in ein proprietäres Ent-wicklungssystem für einen speziellen PDA kann unterbleiben. Dies erleichtert dieEntwicklung und Portierung des MHA-Rahmenwerkes auf einen derartigen PDA.

Die Recherche auf dem Markt der PDA-Hersteller ist in der Tabelle 4.4 wieder-gegeben. Bei der Recherche wurde ersichtlich, dass nur sehr wenige PDAs über aus-reichende Rechenleistung und Fließkommaunterstützung verfügen. Ebenso sind beivielen PDAs die Schnittstellen nur mit unzureichender Bandbreite ausgestattet. Diein der Tabelle aufgeführten PDAs stellen in dieser Hinsicht die zur Zeit bestmöglicheAuswahl dar. Allen ist die Verfügbarkeit einer Linux-Entwicklungsumgebung und dasVorhandensein vergleichsweise leistungsfähiger Schnittstellen gemeinsam.

31

4 Analyse

Her

stel

ler

Fort

ecFo

rtec

Eval

ueEv

alue

Bez

eich

nung

Coo

lFro

ntR

unne

rC

oolR

oadR

unne

rII

IEC

M-3

610

ECM

-361

1

Proz

esso

rA

MD

Geo

deG

X50

0,36

6MH

zIn

telU

LVC

eler

on(6

50M

Hz)

,Pe

ntiu

mII

I(9

33M

Hz)

VIA

C3

Low

Pow

er1G

Hz

VIA

C3

Low

Pow

er1G

Hz

FPU

••

••

Hau

ptsp

eich

er25

6MB

(fes

t)m

ax51

2MB

max

512M

Bm

ax1G

B

Schn

ittst

elle

n•U

SB4x

USB

1.1

2xU

SB1.

12x

USB

1.1

4xU

SB2.

0•A

TAAT

A-6

6AT

A66

UD

MA

100

UD

MA

133,

SATA

•PC

/104

PC/1

04-P

lus

PC/1

04-P

lus

PC/1

04PC

/104

-Plu

s(n

urPC

I)•A

udio

••

••

•Eth

erne

t•

••

•

Vers

orgu

ng/L

eist

ung

5V/6

,5W

(366

MH

z)5V

/15,

5W(6

50M

Hz)

5V,1

2V/1

2,5W

(400

MH

z)5V

,12V

/12,

5W(1

GH

z)

Tem

pera

turb

erei

ch-2

0◦C

–+

60◦ C

-20◦

C–

+60

◦ C0◦

C–

+60

◦ C0◦

C–

+60

◦ C

Gew

icht

ca.1

50g

ca.1

50g

ca.2

50g

200g

Abm

essu

ngen

90m

mx

96m

m95

,9m

mx

115,

6mm

146m

mx

101m

m14

6mm

x10

1mm

Prei

s(ine

)59

9,-

699,

-(fü

r93

3MH

z)

Sons

tiges

Wat

chdo

gW

atch

dog,

TV

-Out

Wat

chdo

g,C

FW

atch

dog,

CF

Tabelle 4.1: Vergleichende Auflistung möglicher Industrie-PC-Plattformen.

32

4.1 Plattformen

Her

stel

ler

Kon

tron

Adv

ante

chK

ontr

on

Bez

eich

nung

EPIC

/CE

PCM

-338

0sp

eedM

OPS

lcdC

E

Proz

esso

rIn

telL

VC

eler

on73

3MH

zIn

telP

entiu

m-M

1,1G

Hz

Inte

lLV

Cel

eron

733M

Hz,

1GH

z

FPU

••

•

Hau

ptsp

eich

erm

ax51

2MB

max

1GB

max

512M

B

Schn

ittst

elle

n•U

SB6x

USB

2.0

6xU

SB2.

02x

USB

2.0

•ATA

UD

MA

100

UD

MA

100

UD

MA

133

•PC

/104

PC/1

04-P

lus

PC/1

04-P

lus

PC/1

04-P

lus

•Aud

io•

••

•Eth

erne

t•

••

Vers

orgu

ng/L

eist

ung

5V/1

4,6W

(256

MB

,96M

BC

F-C

ard)

5V,1

2V/1

4,7W

(1,1

GH

z)5V

/14W

(733

MH

z)16

W(1

GH

z)(2

56M

B)

Tem

pera

turb

erei

ch-1

0◦C

–+

85◦ C

0◦C

–+

60◦ C

0◦C

–+

60◦ C

Gew

icht

ca.3

00g

ca.3

00g

ca.1

95g

Abm

essu

ngen

115m

mx

165m

m10

8mm

x11

5mm

96m

mx

147m

m

Prei

s(ine

)31

2,-

469,

-34

5,-

Sons

tiges

Wat

chdo

g,di

gita

leEi

n-,A

usga

beC

FT

ypI,

II,

Wat

chdo

gJI

DA

Schn

ittst

elle

Tabelle 4.2: Vergleichende Auflistung möglicher Industrie-PC-Plattformen (Forts.).

33

4 Analyse

Her

stel

ler

Giz

mon

doEu

rope

Ltd.

Sony

Gam

epar

kH

oldi

ngs

Bez

eich

nung

Gism

ondo

PSP

GP2

X

Proz

esso

rA

RM

9(4

00M

Hz)

MIP

SR

4000

(333

MH

z)A

RM

920T

(200

MH

z)

FPU

◦•

◦

Hau

ptsp

eich

erun

beka

nnt

32M

B64

MB

Schn

ittst

elle

n•U

SB◦

USB

2.0

USB

2.0

(clie

nt)

•Blu

etoo

th•

◦◦

•SD

-Car

d•

◦•

•WLA

N◦

•◦

Vers

orgu

ng/L

eist

ung

unbe

kann

t3,

6V/1

,8W

3V/0

,3W

Mas

seca

.400

gca

.280

gca

.168

g

Abm

essu

ngen

120m

mx

90m

m17

0mm

x74

mm

x23

mm

143,

6mm

x82

,9m

mx

34m

m

Prei

s(ine

)33

5,-

232,

-18

9,-

Sons

tiges

Win

dow

sC

E,G

PRS

UM

DD

rive,

2MB

Vid

eosp

eich

er

SDK

erhä

ltlic

hLi

nux

betr

iebe

nFl

ash

Spei

cher

Tabelle 4.3: Vergleichende Auflistung möglicher Spielekonsolen-Plattformen.

34

4.1 Plattformen

Her

stel

ler

Shar

pC

ompa

qH

ewle

ttPa

ckar

d

Bez

eich

nung

Zaur

usSL

6000

iPaq

H36

00iP

aqH

X47

00

Proz

esso

rIn

telX

Scal

e(P

XA

255,

AR

M40

0MH

z)St

rong

AR

M15

0(2

06M

Hz)

Inte

lXSc

ale

PXA

270

(624

MH

z)

FPU

•◦

◦

Hau

ptsp

eich

er64

MB

32M

B12

8MH

Flas

h64

MB

RA

M

Schn

ittst

elle

n

•USB

USB

1.1

USB

1.1

(clie

nt)

USB

1.1

(clie

nt)

•Aud

io•

••

•IrD

A•

••

•CF

••

••R

S232

◦•

••B

luet

ooth

◦◦

••W

LAN

◦◦

•

Vers

orgu

ng/L

eist

ung

3,7V

/ca.

0,7W

3,7V

/ca.

0,7W

3,7V

/ca.

0,8W

Tem

pera

turb

erei

ch0◦

C–

+60

◦ C0◦

C–

+60

◦ C0◦

C–

+60

◦ C

Gew

icht

400g

ca.4

00g

187g

Abm

essu

ngen

81m

mx

157m

mx

20m

m17

mm

x83

mm

x13

0mm

77m

mx

15m

mx

131m

m

Prei

s(ine

)58

0,-

350,

-ca

.500

,-

Sons

tiges

Linu

x-En

twic

klun

gsum

gebu

ngvo

rhan

den

Linu

x-En

twic

klun

gsum

gebu

ngvo

rhan

den

Linu

x-En

twic

klun

gsum

gebu

ngvo

rhan

den

Tabelle 4.4: Vergleichende Auflistung möglicher PDA-Plattformen.

35

4 Analyse

4.2 SystemanalyseDie Problematik gängiger Plugins (Algorithmen) des MHA ist der hohe Anspruchan Rechenleistung. Dieser Anspruch erfordert eine hinreichend leistungsfähige undgleichzeitig energieeffiziente Plattform. Daher wurde die Entwicklung einer exter-nen Beschleunigerelektronik in Betracht gezogen, die an erhältliche Endgeräte ange-schlossen werden kann (siehe Abschnitt 4.1). Diese Beschleunigerelektronik soll daszusätzliche Maß an Rechenleistung bereitstellen, so dass insgesamt eine hinreichendeLeistung zur Verfügung steht.

In den folgenden Abschnitten wird es um die Herleitung der Rechenbelastung desMHA und die Herleitung unterer Schranken für die nötige Rechenleistung gehen. Ausdiesen Ergebnissen kann sodann ein Maß für die Beschleunigerelektronik entwickeltwerden, das eine Orientierung hinsichtlich der notwendigen Rechenleistung angibt.

4.2.1 Überprüfung der AuslagerungsstrategienIm Vorfeld wurden mit Hilfe der MHA-Entwickler der Sinn verschiedener Auslage-rungsstrategien besprochen. Die Gespräche ergaben, dass Fließkommaoperationenvermutlich einen Großteil aller Berechnungen innerhalb des MHA ausmachen. Au-ßerdem wurde vermutet, dass etwa die Hälfte der Gesamtrechenlast auf Kosten derPlugins gehen, die eine Fourier-Transformation umsetzen. Fourier-Transformationenwerden in einer Berechnungskette prinzipiell beliebig oft, meist mindestens zweimalverwendet: Einmal in Form einer Fast-Fourier-Transformation (FFT) zu Beginn, daszweite Mal in Form einer inversen FFT (iFFT) am Ende der Verarbeitungskette.Auf Grund dieser Vermutungen wurden zwei Auslagerungsstrategien entwickelt undwährend der Systemanalyse geprüft. Diese soll im Folgenden diskutiert werden.Auslagerungsstrategie 1: Auslagerung aller FließkommaoperationenDem Großteil der betrachteten Plattformen mangelt es an Berechnungseinheiten fürFließkommaarithmetik. Dieser Mangel erfordert eine Emulation dieser Arithmetik inSoftware unter Verwendung des Hauptprozessors. Dies bedingt einen unvermeidba-ren Zusatzaufwand hinsichtlich der gesamten Ausführungszeit gegenüber Plattformenmit Fließkommaberechnungseinheiten. Eine Auslagerung von Fließkommaoperatio-nen könnte somit zu einer wahrnehmbaren Entlastung des Hauptprozessors führen.Um diese Auslagerungsstrategie bewerten zu können, wurde der Anteil dieser ArtArithmetik bei Betrieb der MHA-Software und einer Plugin-Referenzkette an derGesamtheit der durchgeführten Berechnungen bestimmt (das genaue Verfahren wirdin Abschnitt Testsysteme unter „MHA-Konfiguration: belastetes System“ beschrie-ben).

In einem weiteren Schritt wurde dann überprüft, ob die durch das MHA anfal-lende Anzahl von Fließkommaoperationen und der damit verbundenen Datenmengetheoretisch über einen von der Projektgruppe einsetzbaren Bus hinreichend schnellübertragen werden könnte, um diese in externer Hardware verarbeiten zu können.Auslagerungsstrategie 2: Auslagerung der Fourier-TransformationAlternativ zur Auslagerung einzelner Fließkommaoperation bietet sich die Auslage-rung der Fourier-Transformation an. Um diese Strategie bewerten zu können, musstedie Rechenlast verursacht durch FFT und iFFT ermittelt werden. Hierfür wurde dieProzessorlast bei laufender MHA-Software einmal mit und ohne dem MHA-eigenen

36

4.2 Systemanalyse

Messung AMD Athlon 64 3000+ Intel Pentium III 500 MHzMINS MOPS MFLOPS MINS MOPS MFLOPS

Identität 27,55 33,76 6,21 27,25 42,94 1,75FFT & iFFT 167,56 186,85 81,16 167,25 234,23 26,74Gesamt 316,96 347,5 169,28 316,05 426,93 56,18AnteilFFT & iFFT 44,17 % 44,05 % 44,27 % 44,29 % 44,80 % 44,48 %

Tabelle 4.5: Ergebnisse der Leistungsmessung und Berechnung des FFT-/iFFT-Anteils

FFT-Plugin „wave2spec“ und dem iFFT-Plugin „spec2wave“ gemessen (das genaueVerfahren wird im Abschnitt Testsysteme unter „MHA-Konfiguration: unbelastetesSystem“ und „MHA-Konfiguration: Belastung durch FFT/iFFT“ beschrieben). DasAusmaß der Änderung der Gesamtrechenlast ist ein Indiz für die Rechenlast der FFTund iFFT. Des Weiteren wurde berechnet, wie hoch die benötigte Datentransferra-te dieser Plugins ist, d.h. welche Zeitschranken eingehalten werden müssen, um dieVerarbeitung der (i)FFT durch externe Hardware transparent erscheinen zu lassen.

4.2.2 TestergebnisseDie Prozessorlast wurde anhand von drei Parametern gemessen: Gesamtzahl ausge-führter Instruktionen, Mikrooperationen und Fließkommainstruktionen. Mit diesenParametern kann der Anteil der Fließkommaoperationen an der Gesamtzahl der aus-geführten Befehle ermittelt werden.

Da es an dieser Stelle um die Untersuchung der in Frage kommenden Auslage-rungsstrategien geht, werden zur Steigerung der Lesbarkeit im Folgenden lediglichdie Messergebnisse zweier Testsysteme vorgestellt, ohne die Systeme genauer zu be-schreiben.

Eine detailierte Beschreibung der verwendeten Testsysteme kann im Abschnitt A.1im Anhang nachgelesen werden. Die Messung ergibt für das Referenzsystem IntelPentium III 500 MHz bei Verarbeitung einer einzelnen Referenzkette ein Wert von56 MFLOPS. Dieses Ergebnis kann mit der Tabelle 4.5 und den Abbildungen 4.1bis 4.4 nachvollzogen werden.

37

4 Analyse

Abbildung 4.1: Messergebnisse der gezählten Prozessor-Instruktionen

Abbildung 4.2: Messergebnisse der gezählten Prozessor-Operationen

38

4.2 Systemanalyse

Abbildung 4.3: Messergebnisse der gezählten Fließkommaberechnungen in Prozent

Abbildung 4.4: Berechnung der relativen Auslastung

39

4 Analyse

4.2.2.1 Theoretische Busbelastung bei Auslagerung allerFließkommaoperationen

Die theoretische Busbelastung bei 56 MFLOPS kann wie folgt berechnet werden.Dabei werden folgende Annahmen gemacht:

• Eine Fließkommazahl hat eine Breite von 32 Bit.

• Für eine Fließkommaoperation treten als Eingaben zwei Operanden (32-Bit-Fließkommazahl) und als Ausgabe das Ergebnis (32-Bit-Fließkommazahl) auf.Diese Daten müssen zur Abarbeitung des Befehls transferiert werden.

• Die Größe der Befehlskodierung ist bezüglich der Größe von Ein- (Operanden)und Ausgaben (Ergebnis) vernachlässigbar klein.

Mit diesen Annahmen lässt sich folgende Formel für die Datentransferlast bei derAbarbeitung von Fließkommaoperationen ableiten:

p =n · 106 · 3 · 4

10242,

wobei n die Anzahl Millionen Fließkommaberechnungen pro Sekunde [s] und p dieerzeugte Datentransferlast auf dem Bus in Megabyte [MB] ist. Setzt man die Mess-ergebnisse in diese Formel ein, so ergibt sich

p =56 · 106 · 3 · 4Byte

10242≈ 640MB .

Pro Sekunde müssten somit etwa 640 MB an Daten über den Bus zur Verarbeitungder gegebenen Anzahl an Fließkommaoperationen transferiert werden.

4.2.2.2 Theoretische Busbelastung bei Auslagerung der FFT/iFFT

Um die theoretische Busbelastung der FFT/iFFT zu berechnen, wurden die Daten-transferraten der MHA-eigenen FFT- und iFFT-Plugins „wave2spec“ und „spec2wave“berechnet. Da bei einer Auslagerung dieser Einheit in jedem Fall eine gleichwertigeFunktionalität der ausgelagerten Plugins wünschenswert wäre, ist davon auszugehen,dass bei Auslagerung eine ähnliche Busbelastung auftreten würde.

Zur weiteren Berechnung wurden folgende Minimal- und Maximalanforderungender Plugins ermittelt.

Auf Basis der Maximalanforderungen, die in Tabelle 4.6 beschrieben sind, wirdim Folgenden der durch die wave2spec-/spec2wave-Plugins erzeugte Datentransfer dberechnet.Der gesamte Datentransfer setzt sich aus den Daten, die zum Plugin transferiertwerden und den Daten die vom Plugin erzeugt werden, zusammen. Abschließendwerden die Teildatenmengen summiert und der resultierende Datentransfer für denBus aufgezeigt.

Daten zum wave2spec-PluginIn einer Sekunde werden genau die durch die Abtastfrequenz bedingte Anzahl anDaten zum Plugin transferiert. Es ergibt sich

dtoWave2spec = w · f,

40

4.2 Systemanalyse

Maximalanforderungen Minimalanforderungen

Anzahl der Instanzen 60 2Punkte 512 512Abtastrate 44100 Hz 44100 HzAuflösung 32 Bit 32 BitBlockrate 64 64Kanäle 6 2

Tabelle 4.6: Anforderungen an die wave2spec-/spec2wave-Komponente

mit w Wortbreite und f Abtastfrequenz. Einsetzung der gegebenen Werte (Tab. 4.6)liefert

dtoWave2spec = 32Bit · 44100 · 1/s = 1411200Bit/s,

und schließlich angenähert

dtoWave2spec ≈ 0, 168MB/s.

Die Datentransferrate zum wave2spec-Plugin beläuft sich somit auf 0, 168 MB/s.

Daten vom wave2spec-PluginBei einer Blockrate von 64 wird alle 64 Abtastungen eine FFT durchgeführt, die 512Werte mit 32-Bit-Wortbreite als Ergebnis liefert. Es ergibt sich somit ein Datentrans-fervolumen von

dfromWave2spec = aFFT ·N · w,

mit aFFT Anzahl FFT pro Sekunde, N Anzahl der Ergebnisse und w Wortbreite.Weiterhin folgt durch Einsetzung der gegebenen Werte (Tab. 4.6)

dfromWave2spec =4410064s

· 512 · 32Bit ,

dfromWave2spec = 11289600Bit/s,

und somit die Näherung

dfromWave2spec ≈ 1, 346MB/s.

Die Datentransferrate vom wave2spec-Plugin beträgt daher ca. 1, 346MB/s

Daten zum spec2wave-PluginDie Datenmenge die zum spec2wave-Plugin transferiert wird, entspricht der Daten-menge, die vom wave2spec-Plugin erzeugt wird. Die Plugins nach dem wave2spec-Plugin haben keine quantitative Wirkung auf die Daten. Somit gilt

dtoSpec2wave = dfromWave2spec

und somit schließlichdtoSpec2wave ≈ 1, 346MB/s.

Die Datentransferrate vom spec2wave-Plugin beträgt daher ca. 1, 346MB/s.

41

4 Analyse

Daten vom spec2wave-PluginDie in den Zeitbereich transformierten Daten entsprechen quantitativ den Daten vorder Durchführung des wave2spec-Plugins. Somit gilt

dfromSpec2wave = dtoWave2spec,

und genähert folgtdfromSpec2wave ≈ 0, 168MB/s.

Die Datentransferrate vom spec2wave-Plugin beträgt somit 0, 168MB/s.

Berechnung der maximalen DatenübertragungsrateDie Datenübertragungsrate bei 60 aktiven wave2spec-/spec2wave-Plugins ergibt sichaus der Summe von Daten, die zum Plugin transferiert und den Daten die vom Pluginerzeugt werden. Die Summe für das wave2spec-Plugin entspricht der Datenmengedes spec2wave-Plugins. Es muss keine Unterscheidung der beiden Plugins gemachtwerden. Die Summation ergibt

dsum60 = (dtoWave2spec + dfromWave2spec) ·AFFT/iFFT ,

und mit eingesetzten Werten

dsum60 = (0, 168 + 1, 346) · 60MB/s.

Dies führt zur Näherung von

dsum60 = 90, 84MB/s.

Bei 60 wave2spec- bzw. spec2wave-Plugins beträgt die Datentransferrate 90, 84MB/s.

4.2.3 Diskussion der Testergebnisse

In Tabelle 4.5 werden die Messergebnisse vorgestellt. Während sich die Werte derMINS (Millionen Instruktionen pro Sekunde) für beide Testsysteme gleichen, un-terscheiden sich die Messwerte für MOPS und MFLOPS zwischen beiden Systemendeutlich. Dies stellt jedoch kein Problem dar, da laut Datenblättern Intel-Prozesso-ren in den MSRs abgearbeitete Fließkommainstruktionen zählen. AMD-Prozessorenhingegen legen in diesem Register die Anzahl abgearbeiteter Makro-Operationen ab.Instruktionen werden von AMD-Prozessoren in Makro-Operationen zerlegt, die wie-derum in Form mehrerer Mikro-Operationen abgearbeitet werden. Vergleicht mandie Werte für MFLOPS bei unterschiedlicher Belastung relativ, zeigt sich eine großeÜbereinstimmung.

Auswertung Auslagerungsstrategie 1: Auslagerung von Fließkommaoperationen.Bei Belastung des Intel Pentium III-Referenzsystems durch MHA-Software und Re-ferenzkette (MHA-Konfiguration: belastetes System) wurden 56 MFLOPS gemessen.Bei dem AMD Athlon 64-Referenzsystem mehr als das Dreifache. In Abschnitt 4.2.2wurde die zu diesem Zweck benötigte Übertragungsrate ermittelt. Keine derzeit ver-fügbare Schnittstelle eines mobilen Gerätes kann diese Leistung erbringen. Auslage-rungsstrategie 1 scheidet aus. Eine vollständige Auslagerung der Fließkommaeinheit

42

4.3 Busstandards

ist nicht realisierbar. Da die Auslagerung der Fließkommaeinheit ausscheidet und ei-ne Fließkommaemulation durch Prozessoren sehr ineffektiv arbeitet, scheiden Geräteohne Fließkommaeinheit für das Projekt ebenfalls aus.

Auswertung Auslagerungsstrategie 2: Auslagerung der Fourier-Transformation.Anhand der gemessenen Werte und unserer Berechnungen, konnte ein Anteil vonetwa 44 % der FFT und iFFT an der Gesamtprozessorlast ermittelt werden (4.5).Die Berechnung der theoretisch anfallenden Datenlast ergab bei gleichzeitiger Be-rechnung von 60 FFT und iFFT Plugins 90,84 MB/s. Dieser Wert stellt eine immernoch mit herkömmlichen Bussystemen bewältigbare Größe dar. Eine Auslagerung derFFT/iFFT scheint eine implementierbare und sinnvolle Möglichkeit darzustellen.

Ob eine Auslagerung dieser Funktionsblöcke jedoch zu einer tatsächlichen Prozes-sorentlastung von 44 % führen ist fragwürdig. Durch eine Auslagerung ist eine Zusatz-belastung unvermeidlich. Abhängig von der gewählten Realisierung kann diese unter-schiedlich hoch ausfallen. Denkbar wäre zum Beispiel eine Hardware-Implementierungmit direktem Speicherzugriff (DMA), oder eine Implementierung unter Zuhilfenahmedes Prozessors für das Schreiben und Lesen der Daten (PIO).

Da die FFT-/iFFT-Funktionsblöcke fast die Hälfte der anfallenden Rechenleistunghervorrufen, scheint Auslagerungsstrategie 2, die Auslagerung der FFT/iFFT, einesinnvolle Alternative darzustellen und wird im nachfolgendem Abschnitt genauer be-trachtet. Die tatsächliche Entlastung des Prozessors ist stark von der Implementie-rung abhängig.

4.3 Busstandards

Zur Anbindung zusätzlicher Recheneinheiten an die im Abschnitt 4.1 (ab S. 29ff)erwähnten Plattformen, ist eine Schnittstelle mit einer hinreichend hohen Bandbreitenotwendig. Die analysierten Plattformalternativen bieten eine begrenzte Menge vonSchnittstellen, die in den folgenden Abschnitten hinsichtlich ihrer Leistungsfähigkeituntersucht werden. Die Leistungsfähigkeit definiert sich dabei über die Bandbreite B([B] = Byte/s) der Schnittstelle. Untersucht werden

• Compact Flash,

• PCI,

• USB und

• ATA,

da diese Schnittstellen durch ihre Verfügbarkeit bei den erwähnten Plattformen unddurch ihre Leistungsfähigkeit auffallen.

An dieser Stelle sei bereits eine Zusammenfassung der folgenden Abschnitte geben.Die Tabelle 4.7 zeigt für jeden der untersuchten Busstandards die maximal möglicheBandbreite. Die Tabelle stellt somit eine kompakte Zusammenfassung der Ergebnisseder folgenden Abschnitte dar und ermöglicht einen schnellen Vergleich der verschie-denen Busstandards.

43

4 Analyse

Busstandard Bandbreite [MB/s]

PCI 503,54ATA 63,58USB 57,22CompactFlash 31,78

Tabelle 4.7: Maximale Bandbreiten der untersuchten Busstandards.

Transferart Bandbreite [MB/s] Referenz

I/O Input Read 23,84 [18, S. 45ff]I/O Output Write 23,84 [18, S. 47ff]True IDA PIO Mode Read/Write 23,84 [18, S. 48ff]True IDE Multiword DMA Mode Read/Write 23,84 [18, S. 50ff]True IDE Ultra DMA Mode Read/Write 31,78 [18, S. 52ff]

Tabelle 4.8: Übersicht über die Transferarten und deren Bandbreiten des CompactFlash-Standards.

4.3.1 Compact Flash

Der Busstandard Compact Flash (CF) wurde von der 1995 gegründeten CompactFlash Association [17] entwickelt und liegt aktuell in der Version 4.0 vor. Die Analysebeschränkt sich jedoch auf die Version 3.0 des Standards [18], da die Version 4.0 zumZeitpunkt der Analyse noch nicht verfügbar war.

Basierend auf den PCMCIA-Standard [19] bietet der CF-Standard die in Tabelle 4.8aufgelisteten Transferarten an. Angegeben sind ebenfalls die maximalen Bandbreiten,die mit der jeweiligen Transferart erreicht werden können.

4.3.2 PCI

Die Bezeichnung PCI [20] ist eine Abkürzung für Peripheral Component Interconnectund bezeichnet einen synchronen Busstandard. Dieser wurde vom Unternehmen In-tel [21] als Nachfolger für den VLB-Standard entwickelt und erstmals im Juni 1992in Version 1.0 veröffentlicht. Fortan wird die Weiterentwicklung des PCI-Standardsdurch das Konsortium PCISIG [22] übernommen. Die andauernde Evolution führtheute zu diversen PCI-Derivaten, die spezifisch auf bestimmte Anwendungsgebie-te und Anforderungen wie Abwärtskompatibilität, Geschwindigkeit oder Formfaktor(physikalische Größe) abgestimmt sind. Unter anderem seien die folgenden Derivatezu erwähnen:

Conventional PCI Eine Weiterentwicklung des PCI-Busses, die dem PCI-Bus in denersten Versionen sehr ähnlich ist und fortan nur noch ausschließlich Geräte miteiner Betriebsspannung von 3,3 V und Taktfrequenzen von 33 MHz und 66 MHzzulässt.

PCI Express Eine spezifisch auf Bandbreite und Nebenläufigkeit der Bustransaktio-nen optimierte Version des PCI-Busses. Hierbei handelt es sich im Gegensatz

44

4.3 Busstandards

Busbreite [Bit] Bustakt [MHz] Bandbreite [MB/s] Referenz

32 33 125,88 [20, S. 16]32 66 251,77 [20, S. 16]64 66 503,54 [20, S. 16]

Tabelle 4.9: Übersicht über die Bandbreiten des PCI-Busses.

zu anderen Derivaten um einen seriellen Bus.

PCI-X Eine rückwärts-kompatible Weiterentwicklung des PCI-Busses, die mit höhe-ren Taktraten höhere Bandbreiten erreicht.

Aus den erwähnten Derivaten bieten die Plattformen des Abschnittes 4.1 ledig-lich Schnittstellen für Conventional PCI [20] an. Dieses Derivat wird auch unter demNamen PC/104-Plus [23] vertrieben, wobei lediglich physikalische Festlegungen ge-genüber dem Conventional PCI-Standard abgeändert wurden. Übertragungsproto-koll und elektrische Rahmenbedingungen blieben unverändert. Der PC/104-Plus-Busfindet vorwiegend im Bereich der Industrie-PCs Anwendung. Die Bandbreiten desBusses sind in Tabelle 4.9 niedergeschrieben.

4.3.3 USBDie Bezeichnung USB [6] steht für die Abkürzung Universal Serial Bus und be-zeichnet einen seriellen Busstandard, konzipiert zur Verbindung verschiedener Ein-und Ausgabegeräte. Verfügbar war dieser Standard erstmals 1994 in der Version 0.7und seit April 2000 in Version 2.0. Die Topologie eines USB-Bussystems ähnelt ei-ner Baumstruktur. An der Spitze steht der USB-Host, der die Steuerung des Bussesübernimmt. An diesen werden weitere USB-Geräte angeschlossen und bilden weitereKnoten in der Baumstruktur. Längere Pfade innerhalb dieses Baumes werden mittelsHubs (engl. für Nabe) erreichbar, indem diese neue Wurzelknoten in einem neuenTeilbaum bilden, der an den bestehenden Baum angehängt wird. Dabei ist aus Ge-schwindigkeitsgründen die Länge der Pfade auf sieben Geräte bzw. auf fünf Hubsbeschränkt [6, Abschnitt 4.1.1].

Das Busprotokoll sieht verschiedenen Transfertypen vor, je nach Anwendungsfallund Anforderung. Definiert werden die folgenden Typen:

Kontrolltransfers dienen dem Einstellen von angeschlossenen Geräten und Statusab-fragen derselben [6, Abschnitt 5.5].

Isochrone Transfers bieten eine periodische, zeitkritische Kommunikation mit kon-stanter Datenrate mit einem USB-Gerät [6, Abschnitt 5.6].

Interrupt-Transfers dienen der sporadischen Kommunikation mit beschränkter La-tenz, wobei im Fehlerfall automatisch neue Versuche der Datenübertragung ge-startet werden [6, Abschnitt 5.7].

Bulk-Transfers sind für die Übertragung großer Datenmengen konzipiert, wobei imFehlerfall automatisch neue Versuche zur Übertragung der Daten unternommen

45

4 Analyse

werden, jedoch keine Garantien über die Datenraten und Latenzen der gesamtenDatenübertragung ausgesprochen werden [6, Abschnitt 5.8].

Elektrisch wird die Datenübertragung differentiell und Bit-seriell realisiert. Diesbedingt, dass zu jedem Zeitpunkt genau zwei Geräte miteinander kommunizierenkönnen. Die Übertragung kann je nach Version des Standards mit unterschiedlichenGeschwindigkeiten erfolgen. In Version 1.1 sind die Geschwindigkeiten 1,5 MBit/sund 12 MBit/s definiert. Die Version 2.0 erweitert diesen Geschwindigkeitsbereichnochmals um eine Übertragungsrate von 480 MBit/s [6, Abschnitt 4.2.1]. Die mitdiesen Übertragungsgeschwindigkeiten theoretisch erreichbaren Datenraten sind inTabelle 4.10 niedergeschrieben. Dabei sei darauf hingewiesen, dass in der Praxis nurselten vergleichbar hohe Übertragungsgeschwindigkeiten erreicht werden.


Kontrolltransfers 0,0028 – 57,22 [6, S. 41ff]Isochrone Transfers 0,14 – 57,22 [6, S. 45ff]Interrupt-Transfers 0,0085 – 57,22 [6, S. 49ff]Bulk-Transfers 0,1 – 57,22 [6, S. 54ff]

Tabelle 4.10: Übersicht über die Bandbreiten des USB-Busses. Das Minimum beziehtsich auf eine Nutzdatenlast von 1 Byte bei kleinster Übertragungsge-schwindigkeit, das Maximum auf die theoretisch mögliche Bandbreitebei größter Übertragungsgeschwindigkeit.

4.3.4 ATADer AT Attachement-Busstandard definiert eine Schnittstelle für den Anschluss vonMassenspeichergeräten, speziell Festplattenspeichern. Entwickelt um 1989 vom Unter-nehmen Western Digital und publiziert in der Version ATA-1, liegt die Verantwortungfür die fortwährende Weiterentwicklung dieses Standards im T13-Komitee [24]. DieWeiterentwicklung führte zu der aktuellen Version 7 und erweitert den Standard umeine serielle Schnittstelle, so dass heute zwischen Parallel-ATA (P-ATA) und Serial-ATA (S-ATA) unterschieden wird.

Hier von Interesse ist die parallele Version der Schnittstelle, da ausschließlich diesedurch einige der in Abschnitt 4.1 angesprochenden Plattformen angeboten wird. InTabelle 4.11 sind die möglichen Bandbreiten der jeweiligen Transferarten aufgelistet.Hier ist eine Ähnlichkeit zu dem Compact Flash-Standard (siehe Abschnitt 4.3.1) zuerkennen, die daher rührt, dass PCMCIA wiederum teilweise auf ATA basiert.


Register Transfer 7,95 [25, Absch. 12.2.1]PIO Data Transfer 7,95 [25, Absch. 12.2.1]Multiword DMA Data Transfer 15,89 [25, Absch. 12.2.3]Ultra DMA Data Transfer 63,58 [25, Absch. 12.2.4]

Tabelle 4.11: Übersicht über die Bandbreiten der jeweiligen Transferarten des ATA-Busses.

46

4.4 Spezielle Hardware

4.4 Spezielle Hardware

In diesem Abschnitt sollen aktuelle Produkte für die digitale Signalverarbeitung aufihre Eignung als Beschleunigungsmittel für Berechnungen des MHA untersucht wer-den. Eine erste Übersicht der angebotenen Produkte lässt folgende Kategorisierungzu:

• digitale Signalprozessoren,

• ASICs und

• FPGAs.

Die Produkte dieser Kategorien wurden auf Basis folgender Eigenschaften in Bezugauf ihre Eignung für den Beschleuniger bewertet:

Fließkommaarithmetik Der Abschnitt 4.2 zeigt deutlich auf, dass Fließkommaarith-metik ein wesentlicher Bestandteil der Berechnungen des MHA ist. Somit wirdder Frage nach einer Möglichkeit, diese Art von Arithmetik in spezieller Hard-ware zu beschleunigen bzw. zu unterstützen, ein hoher Stellenwert beigemessen.

Entwicklungskosten Wegen des eingeschränkten, finanziellen Rahmen des Projekteskommen lediglich preisgünstige Produkte in Frage.

elektr. Leistung Da mobile Energieversorgungen stets nur begrenzte Betriebslauf-zeiten anbieten und möglichst lange Testphasen erwünscht sind, muss die Aus-wahl von Beschleunigerkomponenten auf energieeffiziente Produkte fokussiertwerden.

Komplexität Der zeitliche Rahmen des gesamten Projektes umfasst 1 Jahr. Dies unddie Komplexität der gestellten Aufgabe erfordern ein hohes Maß an Unterstüt-zung durch effiziente Entwicklungsumgebungen und Erfahrungen im Einsatzder zu Grunde liegenden Entwurfspraktiken. Daher werden Bausteine bekann-ter Architekturen vorgezogen.

Anhand der Eigenschaften lassen sich folgende Bewertungen der aktuell verfügba-ren Produkte erstellen:

DSP Moderne digitale Signalprozessoren verfügen über Recheneinheiten, die eben-falls Fließkommaarithmetik beherrschen und zu Kosten unter 50,-e zu ordernsind. Viele DSPs verfügen darüber hinaus über Energieeinsparmodi und spe-zielle Architekturen, so dass der Energieumsatz aktiv begrenzt werden kann.Negativ anzumerken sind die Kosten für eine Entwicklungsumgebung, sowiedie Komplexität auf ISA- und elektrischer Ebene. Dies ist in Anbetracht desZeitrahmens als kritisch zu werten.

ASIC Die Kosten und Komplexität der Entwicklung eines ASICs machen den Einsatzdieser Technik unter den gegebenen Rahmenbedingungen nicht möglich.

47

4 Analyse

Bausteinfamilie DSP ASIC FPGA

Fließkommaarithmetik bausteinabhängig nach Bedarf nach BedarfEntwicklungskosten hoch sehr hoch mittelelektr. Leistung mittel gering mittelKomplexität hoch sehr hoch hoch

Tabelle 4.12: Übersicht über die Bewertungen der untersuchten Bausteinkategorien.Diese Bewertung bezieht sich auf die Eignung für dieses Projekt und istzwischen den Bausteinen relativ zu verstehen.

FPGA Der Einsatz von FPGAs zur digitalen Signalverarbeitung offenbart vergleich-bare Potentiale, wie der von DSPs. Es sind zahlreiche vorgefertigte IP-Kompo-nenten für FPGAs auf dem Markt zu haben, die sich mit genau diesem Themabeschäftigen. Weiterhin sind verschiedene dieser vorgefertigten Komponentenund entsprechende Entwicklungsumgebungen für die Projektgruppe zugänglich,so dass Anschaffungskosten entfallen. Mit FPGAs ist es ebenso wie mit DSPsmöglich, den Energieumsatz aktiv zu beeinflussen, so dass sich hier Möglich-keiten für längere Akkulaufzeiten ergeben. Ebenso sind bereits Erfahrungen imUmgang mit FPGAs von verschiedenen Projektgruppenteilnehmern gesammeltworden, was die Zeitplanung des Projektes positiv zu beeinflussen vermag.

Die Eigenschaften der untersuchten Bausteinfamilien sind in der Tabelle 4.12 zu-sammengefasst.

4.5 AkkutypenDie Anforderungsdefinition (Tab. 3.1, S. 27) weist eine Laufzeit des Gesamtsystemsmit mobiler Energieversorung von ca. 3 Stunden aus. Die mobile Energieversorgungwird dabei durch einen Akkumulator realisiert. Zur Auswahl einer angemessenenTechnologie des Akkumulators wurden folgende Eigenschaften in der Bewertung be-rücksichtigt:

Spannung Die Urspannung des Akkumulators, muss auf die Versorgungsspannungdes Gesamtsystems abgestimmt sein. Dies hilft die Komplexität der Spannungs-wandlung im Netzteil zu reduzieren und steigert somit die Effizienz der Ener-gieversorgung.

Kapazität Laut Anforderungsdefinition (Tab. 3.1, S. 27) muss das Gerät im mobilenEinsatz mindestens eine Laufzeit von drei Stunden aufweisen. Dies ergibt eineuntere Schranke für die Akkumulatorkapazität.

Maximaler Entladestrom Der Akkumulator ist derart zu wählen, dass der Strom desGesamtsystems den maximal zulässigen Entladestrom des Akkumulators nichtübersteigt. Eine Missachtung hätte die Zerstörung des Akkumulators und eineGefährdung des Benutzers zur Folge.

Möglichkeit der Tiefentladung Da das Gerät von Benutzern u.U. solange verwendetwerden kann, bis der Akkumulator in den Zustand der Tiefentladung gelangt,

48

4.6 Fazit

ist entsprechend ein Akkumulator zu wählen, der diesen Zustand ohne Schadeneinnehmen kann.

Gewicht Die Anforderungsdefinition (Tab. 3.1, S. 27) beschränkt das Gesamtgewichtdes Gesamtsystems auf 1 kg, was für die mobile Energieversorgung eine Ein-schränkung darstellt, da hohe Akkumulatorkapazitäten für lange Laufzeitenein hohes Gewicht bedingen.

Maße Für kompakte Abmessungen des Gesamtsystems sind ebenso kompakte Ab-messungen des Akkumulators wünschenswert.

Preis Die beschränkten finanziellen Rahmenbedingungen erfordern einen kostengüns-tigen Akkumulator.

Die untersuchten Technologien sind folgend aufgelistet [26].

Blei-Säure / Blei-Gel Blei-Säure-Akkumulatoren zeichnen sich insbesondere durchhohe Entladeströme aus. Im Gegensatz zur bekannteren Blei-Säure-Technologie(Autoakku) ermöglicht die Blei-Gel-Technologie Akkumulatoren in hermeti-schen Gehäusen. Tiefentladung führt zu dauerhafter Schädigung des Akkumu-lators.

Nickel-Kadmium (NiCd) Diese Technologie ermöglicht preiswerte Akkus mit (kurz-zeitig) hohen Entladeströmen. Gleichwohl fällt diese Technologie negativ durchden „Memory-Effekt“ auf. Dieser Effekt führt zu verringerter Kapazität, wennder Akkumulator in mehreren Lade-Entlade-Zyklen nicht vollständig ge- undentladen wird [26].

Nickel-Metall-Hydrid (NiMH) Bei dieser Technologie handelt es sich um eine Ver-besserung der Nickel-Kadmium-Technologie. Der Memory-Effekt wurde erheb-lich reduziert, gleichzeitig wurde die Kapazität deutlich erhöht. Der Preis bleibtim unteren Bereich.

Lithium-Ion (Lithium-Polymer, LiIon, LiPo) Die Lithium-Ion-Akkumulatoren habendie größtmögliche Energiedichte von allen untersuchten Akkumulatoren; da-durch ergibt sich ebenfalls ein geringes Gewicht. Dagegen sind sie preislich imoberen Bereich angesiedelt. Lithium-Polymer-Technologie ermöglicht die Her-stellung von Akkumulatoren in vielfältigen Bauformen.

Das Ergebnis der Bewertung von auf dem Markt aktuell verfügbaren Akkumula-toren ist in der Tabelle 4.13 niedergeschrieben. Die aufgeführten Akkumulatortypenerfüllen die oben diskutierten Bewertungskriterien in ihren jeweiligen Technologiedo-mänen derart, dass sie als Repräsentanten der Technologie und als für das Gesamt-system am geeignetsten angesehen werden.

4.6 FazitAbschließend wird basierend auf den Ergebnissen der Analyse zusammengefasst, wel-che Auswahl für die Durchführung des Projekts getroffen wurde. Bei der Wahl einer

49

4 Analyse

Her

stel

ler

Pana

soni

cPa

naso

nic

Cel

lcon

Emco

tec

Dist

ribut

orR

eich

elt

Rei

chel

tR

eich

elt

rcel

ectr

onic

Bez

eich

nung

LCR

-6V

7,2P

RC

-AK

KU

NC

7221

CR

C-A

KK

U72

33-C

ELLO

NG

GO

3300

“N“

Tech

nolo

gie

Ble

i-Gel

NiC

dN

iMH

LiPo

Span

nung

6V

7,2

V7,

2V

7,4

V

Kap

azitä

t7,

2A

h2,

1A

h3,

3A

h3,

3A

hM

axim

aler

Entla

dest

rom

–15

A33

A13

AM

oglic

hkei

tde

rT

iefe

ntla

dung

nein

jaja

ja

Gew

icht

1,3

kg–

0,37

2kg

0,17

7

Maß

e15

1mm×

100m

m×

34m

m13

2mm×

23m

m×

46m

m13

6mm×

25m

m×

46m

m14

6mm×

65m

m×

13,2

mm

Prei

s(ine

)12

,60

10,6

517

,50

89,0

0

Ener

gied

icht

e5,

54A

h/kg

–8,

87A

h/kg

18,6

4A

h/kg

Ener

giek

oste

n1,

75e

/Ah

5,07e

/Ah

5,3e

/Ah

26,9

7e

/Ah

Tabelle 4.13: Vergleich der untersuchten Akkumulatoren. Gezeigt sind die Eigenschaf-ten der ausgewählten Repräsentanten der jeweiligen Technologie.

50

4.6 Fazit

Systemplattform mussten die PDAs und die Spielekonsolen ausgeschlossen werden, dasie entweder nicht über die benötigten Schnittstellen verfügen, oder keine Fließkom-maarithmetik besitzen. Während der Systemanalyse wurde deutlich, dass eine Fließ-kommaeinheit zwingend notwendig und im Rahmen der Projektgruppe nicht auslager-bar ist (siehe Abschnitt 4.2). Industrie-PCs sind mit USB 2.0-Schnittstellen verfügbarund ermöglichen somit den Anschluss einer Soundkarte, die für das MHA entwickeltwird. Sie sind zudem meist mit einer PCI-Schnittstelle und eine leistungsstarkenCPU mit Fließkommaarithmetik ausgestattet (siehe Abschnitt 4.1). Eine sinnvolleEntlastung des Prozessors kann durch Auslagerung der FFT-/iFFT-Komponente er-zielt werden (siehe Abschnitt 4.2). Der PCI-Bus bietet ausreichend Bandbreite, umdie Datenmenge dieser ausgelagerten Plugins zu transportieren. Daraus resultierendwurde ein Industrie-PC als Systemplattform gewählt, über dessen PCI-Schnittstelleder Beschleuniger angebunden wird.

Für die Beschleuniger-Hardware fiel die Entscheidung auf FPGAs. Im Gegensatzzu DSPs ist ihre Programmierung vergleichsweise komfortabel, was einer schnellerenEntwicklung zuträglich ist. Zudem besitzen einige FPGA-Typen integrierte DSP-Zellen, so dass auch sie ähnliche Leistungscharakteristika in Signalverarbeitungs-applikationen aufweisen. Ein weiterer Vorteil besteht in ihrer Flexibilität, die sichin einer schnellen Rekonfigurierbarkeit mit anderen Entwürfen zeigt. Des Weiterenwaren Entwicklungsumgebungen für FPGAs bereits vorhanden. Entwicklungsumge-bungen für DSPs hätten zu hohen Kosten käuflich erworben werden müssen (sieheAbschnitt 4.4).

Für die Stromversorgung des Gesamtsystems sollen Nickel-Metall-Hydrid-Akkumu-latoren verwendet werden, da diese die erwünschte Betriebsdauer ermöglichen undeine solide und kostengünstige Lösung darstellen (siehe Abschnitt 4.5).

51

4 Analyse

52

5 Entwurf

In diesem Kapitel wird das Gesamtsystem abstrakt beschrieben. Das bedeutet, dasshier auf die grundlegende Funktionsweise und Interaktion der Komponenten einge-gangen wird. Es werden keine konkreten Entwurfsentscheidungen für spezifische Kom-ponenten getroffen. Dies geschieht im Kapitel 6 über die Implementierung.

Das Kapitel beginnt mit einem Überblick über das Gesamtsystem, um dessen Kom-ponenten kennenzulernen und für die weitere Diskussion zu benennen. Im Anschlusswerden die Komponenten zur Ein- und Ausgabe, der Industrie-PC sowie der Beschleu-niger thematisiert.

5.1 GesamtsystemDie Architektur des Gesamtsystems zeigt Abbildung 5.1. Das Gesamtsystem teiltsich in drei Teile: in Komponenten zur Ein- und Ausgabe, die Systemplattform alsLaufzeitumgebung für das MHA und in Komponenten zur Beschleunigung etwaigerBerechnungen des MHA auf.

Abbildung 5.1: Überblick über das Gesamtsystem und dessen Komponenten

Die Ein- und Ausgabe für den Benutzer zur Steuerung des Systems wird mittelsder Komponenten Display und Bedienelement ermöglicht. Die Komponente Sound-karte ist darüber hinaus zur Aufnahme und Wiedergabe von Audiosignalen im Systeminstalliert. Sie dient somit der Aquisition und Präsentation der von den nachgeschal-teten Komponenten verarbeiteten Daten.

Die Laufzeitumgebung für das MHA wird durch einen Industrie-PC bereitgestellt.Diese Plattform besitzt die im Abschnitt 4.1 aufgezeigten Vorteile gegenüber ande-ren untersuchten Plattformen. Diese bestehen u.a. im Vorrat an Schnittstellen hoher

53

5 Entwurf

Bandbreite. Diese Schnittstellen werden für die Verbindung von Soundkarte und Be-schleuniger mit dem Industrie-PC benötigt. Anderen Plattformalternativen fehlendiese Schnittstellen, so dass diese als Laufzeitumgebung nicht in Frage kommen. Aufeine weitere Diskussion der Auswahlkriterien sei an dieser Stelle auf die Abschnitte 4.1und 4.6 verwiesen.

Der Beschleuniger soll der Entlastung des Industrie-PCs um einen Anteil der ins-gesamt durchzuführenden Berechnungen dienen. Hierfür sind auf dem Beschleunigerzwei FPGAs installiert. Einer übernimmt eine Vermittlerfunktion und ermöglicht so-mit den Datenfluss zwischen dem zweiten FPGA und dem Industrie-PC. Dieser zweiteFPGA ist primär für die Berechnung von MHA-Plugins verantwortlich. Im Folgen-den wird der FPGA zur Vermittlung der Daten als PCI-FPGA und der andere alsMHA-FPGA bezeichnet.

Auf weitere Einzelheiten wird an dieser Stelle verzichtet. Hierfür wird auf das Kapi-tel 6 verwiesen. Dort wird detailierter auf die Auswahl und Realisierung der erwähntenKomponenten eingegangen.

5.1.1 Datenflüsse im GesamtsystemDie Datenflüsse im Gesamtsystem werden anhand der Abbildungen 5.2 und 5.3 er-läutert. Sie zeigen jeweils den Hin- und Rückweg der von der Soundkarte akquiriertenDaten.

Abbildung 5.2: Datenfluss im Gesamtsystem von der Soundkarte über den Industrie-PC und MHA zum MHA-FPGA

Als Hinweg wird der Fluss der Daten von der Soundkarte durch den Industrie-PCund das MHA über den PCI-Bus und PCI-FPGA zum MHA-FPGA verstanden.Dieser Fluss ist in Abbildung 5.2 dargestellt. Dort ist zu sehen, dass die SoundkarteAudiodaten über Mikrofone aufzeichnet und diese dann über den JACK-Server andas MHA weitergereicht werden (grüne Pakete in der Abbildung). Im MHA werdendiese Pakete an etwaige Algorithmen (Plugins) weitergereicht und dort verarbeitet(gelbes Paket in der Abbildung). Diese Verarbeitung kann durch den Beschleunigerunterstützt sein. Dies erfordert einen Transport der Daten zum MHA-FPGA, so wiees durch die roten Pakete in der Abbildung dargestellt ist. Der Treiber ist dafür

54

5.1 Gesamtsystem

verantwortlich, die Pakete des MHA in die richtige Größe zu zerlegen, sowie dieseüber den PCI-Bus an den Beschleuniger zu transportieren.

Nach der Verarbeitung der Daten im MHA-FPGA werden diese an das MHA imIndustrie-PC zurückgesendet. Dieser Datenfluss ist in Abbildung 5.3 dargestellt. Hierist der MHA-FPGA für die Zerlegung der Datenpakete in eine adäquate Größe ver-antwortlich. Nach diesem Schritt werden die Daten über den lokalen Bus des Be-schleunigers einzeln zum PCI-FPGA und schließlich über den PCI-Bus zum Treibertransportiert (rote Pakete in der Abb.). Nach Zusammensetzung der kleineren Pa-kete zum ursprünglichen Paket im Treiber, wird dieses im Anschluss an das Pluginim MHA weitergereicht (gelbes Paket in der Abbildung). Von dort werden die Datenüber den JACK-Server an die Soundkarte zur Ausgabe gesandt (grüne Pakete in derAbbildung).

Plugin

Abbildung 5.3: Datenfluss im Gesamtsystem vom MHA-FPGA über den Industrie-PC und MHA zur Soundkarte

Der Inhalt der Pakete lässt sich in zwei Kategorien einteilen: Konfigurations- undDatenpakete. Konfigurationspakete dienen der Übermittlung von Parametern für spe-zifische Berechnungseinheiten im MHA-FPGA. Diese Berechnungseinheiten überneh-men Verarbeitungsschritte von Algorithmen im MHA und müssen, bevor sie ihreTätigkeit aufnehmen können, mit spezifischen Parametern konfiguriert werden. Die-se Parameter können z.B. Verstärkungsfaktoren eines Equalizer oder Fensterbreiteneiner FFT sein. Nach der Konfiguration eines Plugins kann dieses Datenpakete entge-gennehmen. In diesen Paketen werden Daten transportiert, die an Plugins im MHAgesendet werden und nun der Entlastung der CPU dienen.

55

5 Entwurf

5.2 Embedded-PC

Die Grundlage des Systems bildet ein Industrie-PC. Auf einem angeschlossenenMassenspeicher befindet sich ein Betriebssystem und die weitere benötigte Software.

5.2.1 PC-Hardware

Folgende Mindestanforderungen an den Industrie-PC ergeben sich aus der Analyse-phase:

Schnittstellen: USB 2.0PCI oder PCI-104RS-232

Prozessor: 500 MHzRAM: 256 MBMassenspeicher: 256 MB

Tabelle 5.1: Mindestanforderungen an PC-Hardware

Die Beschleunigererweiterung wird über die PCI-Schnittstelle angebunden. Ein Dis-play kann über die serielle RS-232-Schnittstelle angesteuert werden. Die Soundausga-be erfolgt über eine Onboard-Soundkarte. Eine externe Soundkarte mit einer größerenAnzahl von Ein- und Ausgabekanälen kann später über USB nachgerüstet werden.

5.2.2 Betriebssystem

Als Betriebssystem wird ein Linux mit Kernel 2.6 verwendet. Mit dieser Version desLinux-Kernels wurde ein verbesserter Scheduler eingeführt. Er eignet sich aufgrundgeringerer Latenzen bei der Abarbeitung von Interrupts und Task-Wechseln besserals die Vorgängerversionen für Audioanwendungen. Zusätzlich existieren verschiedenePatches, die die Kernel-Latenzen weiter reduzieren können. Einer dieser Realtime-Patches wird auf den Kernel angewendet.

Um einen schnellen Bootvorgang und gute Reaktionszeiten zu erreichen, solltedas System auf das Nötigste reduziert werden. Neben dem Löschen nicht benötig-ter Programme und Bibliotheken bieten sich verschiedene Möglichkeiten an. Das

56

5.2 Embedded-PC

PCI-Treiber

MHA-Software

Berechnungskette

Berechnungskette

Adapter

Plugin Plugin Plugin

Plugin Adapter

Abbildung 5.4: MHA-Adapterkonzept für Hardwarebeschleunigung

System kann gegen die „uclibc“, gelinkt werden. Die uclibc ist eine weitgehendschnittstellen-, aber nicht binärkompatible Alternative zu der GNU C-Bibliothek.Das Open-Source-Projekt „Busybox“ stellt für viele Linux-Befehle eine platz- undspeichersparende Alternative zur Verfügung.

5.2.3 Module

Für eine Audio-Verarbeitung mit geringen Latenzen greift das MHA auf das JACKAudio Connection Kit zurück. Damit auch Benutzer außer root, Programme mithöchster Priorität (im Linux-Kontext sogenannter „Realtime-Priorität“) starten kön-nen, wird das Kernel-Modul realtime-lsm benötigt. Es ist in Form eines Patchesfür den Linux-Kernel von der Homepage des Autors [27] erhältlich.

5.2.4 Adapterkonzept für Plugins

Bei der Anbindung der Beschleuniger-Hardware können und sollen die bestehendenSchnittstellen des MHA nicht verändert werden. Aus diesem Grund wird ein Adapter-basiertes Konzept verwendet. Statt eines Plugins wird an dieser Stelle in einer Be-rechnungskette ein Adapter-Plugin eingebunden. Dieser Adapter nimmt selbst keineBerechnungen an den erhaltenen Daten vor. Stattdessen werden die Daten über einenBetriebssystem-Treiber an die Hardware weitergegeben.

57

5 Entwurf

5.2.5 PCI-Treiber

Ein Programm kann unter Linux nicht direkt auf die Systemhardware zugreifen. DerZugriff muss über einen Treiber erfolgen. Unter Linux stellen Hardware-Treiber ihreFunktionalität über Device-Nodes im Dateisystem zur Verfügung. Die Kommunika-tion mit einem Gerät funktioniert daher wie der Zugriff auf eine Datei.

Der Treiber des Geräts stellt für jede Plugin-Instanz einen hinreichend großen Puf-fer bereit, der beschrieben und ausgelesen werden kann. In den ersten Bytes dervirtuellen Datei wird vom MHA-Adapter-Plugin ein Header abgelegt, der die von derHardware benötigten Meta-Informationen enthält. Auf den Header folgen die Au-diodaten in einem zur Hardware-Implementierung des jeweiligen Plugins passendenFormat. Im Allgemeinen entspricht dies der internen Kodierung im MHA.

Um eine Berechnung anzustoßen, wird der ioctl-Befehl verwendet. Dieser Befehlsteht unter Linux Treibern und Anwendungen für die Umsetzung spezieller Opera-tionen zur Verfügung. Er wird beim Zugriff auf Dateien nicht verwendet. Der Befehlerwartet einen Befehlscode als Parameter, der vom Treiber nach Bedarf interpretiertwerden kann.Der Ablauf der Berechnung eines Datenpaketes könnte wie folgt aussehen:

• Das Adapter-Plugin schreibt Daten in die Device-Node des Treibers.

• Die Daten werden vom Treiber entgegengenommen und in einen Puffer geschrie-ben.

• Das Adapter-Plugin ruft ioctl auf.

• Der Treiber sendet die Daten im Puffer an die Hardware und legt den Threadschlafen.

• Der Treiber wartet auf einen Interrupt der Hardware, der die Fertigstellung derDaten signalisiert.

• Der Treiber liest die Daten von der Hardware und schreibt sie in den Puffer.Anschließend weckt der Treiber den ioctl-Thread wieder auf.

• Das Adapter-Plugin liest die Daten aus der Device-Node des Treibers. Indirektwerden die Daten dabei aus dem Puffer gelesen.

5.3 BenutzungsschnittstelleDie Bedienung des Gerätes soll über eine einfach zu verwendende Schnittstelle erfol-gen. Dazu wird das Gerät mit einer Anzeige und einigen Bedienelementen ausgestat-tet. Nach Möglichkeit sollen Symbole auf der Anzeige die Bedienung vereinfachen.Abbildung 5.5 zeigt die geplante Menü-Struktur. Dem ungeübten Nutzer stellt siedie wichtigsten Funktionen, wie die Auswahl einer Verarbeitungskette und eine Laut-stärkeanpassung, unmittelbar zur Verfügung. Über ein Untermenü stehen erfahrenenBenutzern und Entwicklern von Audioalgorithmen dagegen auch spezielle Operatio-nen zur Verfügung. Ein Beispiel dafür ist der Vergleich zwischen verarbeitetem undunverarbeitetem Ton über den rechten und den linken Kanal.

58

5.4 PCI-FPGA

MAIN

Volume up

Volume down

Chain up

Chain down

Mute on/off

Settings

SETTINGS

Volume

Balance

Output

About

Back

Halt

VOLUME

Select device

Volume up

Volume down

Default settings

Back

BALANCE

Select device

Balance left

Balance right

Default settings

Back

HALT

Yes

No

ABOUT

Back

Confirm

Chain up/downVolume up/down

Mute on/off

Default settings

Default settings

OUTPUT

Mute MHA on/off

Mute Monitor on/off

Back

Volume up

Cancel

About

Back

Balance

Back

Settings Back

Mute MHA

Mute Monitor

Back

Output

Volume

Back

Select device

Select device

Shutdown

Halt

Balance left

Balance right

Volume down

Abbildung 5.5: Entwurf der Menüstruktur

5.4 PCI-FPGA

Der PCI-FPGA übernimmt im Gesamtsystem die Rolle einer Vermittlungsstelle zwi-schen Industrie-PC und MHA-FPGA (siehe Abschnitt 5.5). Im Folgenden wird dieKommunikationsverbindung zwischen PCI-FPGA und Industrie-PC mit Inter- undjene zwischen PCI- und MHA-FPGA mit Intrakommunikationsverbindung bezeich-net.

59

5 Entwurf

Zur Erfüllung der Vermittlungsfunktion wird eine Konfiguration gewählt, wie sie inAbbildung 5.6 dargestellt ist. Zu sehen sind die Hauptkomponenten, bezeichnet mitPCI und Local-Bus-Controller zur Kommunikation mit dem Industrie-PC bzw. demMHA-FPGA, sowie ein Soft-Core-Prozessor mit angeschlossenem Speicher und UARTzur Ausführung eines Programmes, welches die Vermittlung der Pakete steuert. Ver-bunden sind die Komponenten mit einem Bussystem.

NIOS-ProzessorPCI Local BusController

Avalon-Bussystem

PC/104-Plus-Bus lokaler Bus

SpeicherUART

ext. Speicher

Abbildung 5.6: Entwurf der PCI-FPGA-Konfiguration

Eine Paketvermittlung findet auf die in Abbildung 5.7 dargestellte Weise statt. Zusehen sind dort über den PC/104-Plus-Bus [23] eintreffende Pakete, die von der mitPCI bezeichneten Komponente angenommen werden. Sie werden dort temporär zwi-schengespeichert und vom Soft-Core-Prozessor auf ihren Inhalt untersucht. Diese Un-tersuchung basiert auf dem Header des Paketes. Zeichnet dieser Header das Paket als

60

5.4 PCI-FPGA

NIOS-ProzessorPCI Local BusController

Avalon-Bussystem

PC/104-Plus-Bus lokaler Bus

SpeicherUART

vomIndustrie-PC

vomMHA-FPGA

ext. Speicher

Abbildung 5.7: Prinzip der Paketvermittlung im PCI-FPGA

„an den PCI-FPGA zu senden“ aus, so wird das Paket vom Soft-Core-Prozessor ent-gegengenommen und zur weiteren Verwendung in den externen Speicher kopiert. Isthingegen das Paket für den MHA-FPGA bestimmt, so wird der Local Bus Controllerdurch den Soft-Core-Prozessor damit beauftragt, das Paket aus der PCI-Komponentezu lesen und dem MHA-FPGA über den lokalen Bus zuzustellen. Während dieser Zeitkann kein anderer Zugriff auf den lokalen Bus stattfinden, weder durch den Soft-Core-Prozessor zur Programmausführung noch durch den MHA-FPGA zur Übertragungvon Paketen an den PCI-FPGA. Die Übertragung in Richtung des MHA-FPGA hateine in diesem FPGA eingebettete FIFO als Ziel. Läuft diese über, so wird der Daten-transfer vorzeitig abgebrochen und der Soft-Core-Prozessor mit einer Unterbrechungüber diesen Fehlerfall informiert. Bei einer erfolgreichen Übertragung findet auf diegleiche Weise eine positive Rückmeldung statt. Nach Beendigung kann der lokale Busbei Anforderung wieder dem Soft-Core-Prozessor sowie dem MHA-FPGA zugestan-den werden. Diese Übertragungsrichtung ist durch den roten Pfeil in Abbildung 5.7dargestellt.

Zur Übertragung von Paketen vom MHA-FPGA in Richtung PCI-FPGA muss derlokale Bus zuvor vom MHA-FPGA angefordert werden. Dies ist notwendig, da derPCI-FPGA den lokalen Bus zum Zugriff auf seinen lokalen Speicher benötigt undes auf physikalischen Gründen nicht erlaubt sein kann, simultan auf den Bus zu-zugreifen. Bei aktivierter Arbitrierung des lokalen Busses wird der lokale Bus demMHA-FPGA zugestanden und bleibt für die Dauer der Übertragung in seinem Besitz.

61

5 Entwurf

Nach Abschluss der Übertragung wird der PCI-FPGA über eine Unterbrechung überdie Ankunft neuer Daten informiert, welcher in Folge den Inhalt dieser Daten unter-suchen kann. Wird der PCI-FPGA als Ziel ausgezeichnet, werden die Daten (wie obenauch) in den externen Speicher zur weiteren Verwendung kopiert. Ist hingegen derIndustrie-PC bzw. das MHA als Ziel genannt, wird der Local Bus Controller damitbeauftragt, die Daten autonom in die PCI-Komponente zu übertragen. Der Soft-Core-Prozessor veranlasst im Anschluss die Übertragung der in der PCI-Komponente tem-porär gespeicherten Daten über den PC/104-Plus-Bus an den Industrie-PC. DieserInformationsfluss ist in Abbildung 5.7 durch den grünen Pfeil gekennzeichnet.

5.5 MHA-FPGA

Der MHA-FPGA beinhaltet die in Abbildung 5.8 dargestellten Komponenten undhat die Aufgabe, vom MHA ausgelagerte Plugins zu berechnen. Der Entwurf desGesamtsystems sowie die Einzelkomponenten werden im Folgenden beschrieben.

5.5.1 Gesamtsystem

Abbildung 5.8: Überblick über die Struktur des MHA-FPGAs

Der Controller steuert den Datenfluss und die übrigen gezeigten Komponenten. Diezu verarbeitenden Daten werden über die Externe Schnittstelle empfangen und ver-

62

5.5 MHA-FPGA

sendet. Nach Identifizierung des Datenziels werden die Daten an die Plugins, die alsSoftware-Plugin oder Hardware-Plugin zur Verfügung stehen können, übergeben oderim Speicher abgelegt. Im Speicher werden die Konfigurationen der Hardware-Pluginsund Software-Plugins abgelegt. Wird ein Datenpaket empfangen, so wird die aktu-elle Konfiguration der Zielkomponente überprüft und gegebenenfalls entsprechendrekonfiguriert. Die Kommunikation aller Komponenten mit Ausnahme der Software-Plugins erfolgt über den Bus.

In den folgenden Absätzen sind alle Komponenten sowie deren Funktionen undAufgaben ausführlich beschrieben.

5.5.2 Externe Schnittstelle

Die externe Schnittstelle hat einerseits die Aufgabe, Daten vom PCI-FPGA zuempfangen und diese dem Controller zur Verfügung zu stellen. Andererseits müssenberechnete Daten, die vom Controller an die externe Schnittstelle übertragen werden,an den PCI-FPGA gesendet werden. Diese Funktionen werden von den im weiterenbeschriebenen Automaten übernommen.

Abbildung 5.9: Daten vom PCI-FPGA empfangen

In Abbildung 5.9 ist der Automat dargestellt, der für den Datenempfang vom PCI-FPGA und das Bereitstellen der Daten für den Controller verantwortlich ist. Iminitialen Zustand wait on header wartet die Komponente bis das erste Datum einge-troffen ist, wodurch der Folgezustand wait on package betreten wird. Der Definitiondes Paketformates (dieses wird in Abschnitt 6.2 im Kapitel Implementierung be-handelt; an dieser Stelle ist die exakte Kodierung eines Paketes von untergeordneter

63

5 Entwurf

Rolle) nach handelt es sich bei dem ersten Datum um den Paket-Header. Der Zustandwait on package wird erst wieder verlassen, wenn das Paket vollständig eingetroffenist. Der nachfolgende Zustand transfer teilt dem Controller mit, dass Daten bereitstehen. Nachdem der Controller alle Daten von der externen Schnittstelle abgeholthat, befindet sich der Automat wieder im initialen Zustand wait on header und istfolglich wieder bereit, ein weiteres Datenpaket zu empfangen. Der PCI-FPGA darfnur Daten an die externe Schnittstelle senden, wenn diese sich im Zustand wait onheader befindet. Somit wird gewährleistet, dass ein Paket immer vollständig empfan-gen wird.

Das Empfangen von Ergebnisdaten und das Versenden dieser zum PCI-FPGA wirdin Abbildung 5.10 als Automat dargestellt. Die Zustände sind aus Sicht der externenSchnittstelle benannt. Gleichnamige Transitionen in den Abbildungen 5.9 und 5.10sind unabhängig voneinander.

Abbildung 5.10: Hauptautomat der externen Schnittstelle

Der Automat arbeitet wie folgt. Im initialen Zustand wait on header wartet dieKomponente auf das erste Datum vom Controller, welches nach vereinbartem Paket-format ein Paket-Header sein muss. In diesem Fall wird der Zustand wait on headerverlassen und wait on package betreten. Wenn das Paket vollständig in die externeSchnittstelle geschrieben worden ist, wird der Zustand wait on bus betreten, der aufdie Zuteilung des Busses durch den PCI-FPGA wartet. Sobald der Bus zugesichertworden ist, wird im folgenden Zustand send das Paket an den PCI-FPGA gesendet.Wenn die Daten vollständig an den PCI-FPGA verschickt wurden, wartet die Kompo-nente im Zustand wait on revoke grant auf das Zurücknehmen der Buszusicherung, sodass der Abschluss des Transfers garantiert ist und die Abarbeitung weiterer Paketeerfolgen kann. Dass der PCI-FPGA die Buszusicherung entfernen kann, wird diesemdurch den MHA-FPGA über eine Steuerleitung des Busses zwischen den FPGAs mit-geteilt. Das Protokoll verlangt, dass der PCI-FPGA die Zusicherung des Busses anden MHA-FPGA zurücksetzt. (Detailierter wird das Protokoll im Abschnitt 6.7.1 imKapitel Implementierung beschrieben.)

5.5.3 SpeicherDer Speicher dient der Zwischenspeicherung von Daten und Konfigurationen fürHardware- und Software-Plugins im MHA-FPGA. Insbesondere bei großen Daten-mengen ist eine Pufferung im FPGA auf Grund der geringen Speicherkapazität nicht

64

5.5 MHA-FPGA

möglich, weshalb diese zusätzliche Speicherkomponente nötig ist. Physikalisch ist die-se Komponente durch einen RAM-Baustein realisiert, der außerhalb des FPGA in-stalliert ist.

5.5.4 Controller

Der Controller ist die Kontrollinstanz des MHA-FPGAs. Seine Aufgabe besteht inder Steuerung der Plugins sowie der Verwaltung ein- und ausgehender Pakete. Ins-besondere betrifft dies die Speicherung und Zuteilung der Konfigurationen zu denentsprechenden Plugins.

Die Plugin-Verwaltung wird im Folgenden näher erläutert. Der Controller besitzteine eigene Schnittstelle zum Bus, die die Hardware-Komponenten miteinander ver-bindet. Des Weiteren besitzt er jeweils eine Schnittstelle zu jedem Software-Plugin.Der Controller besteht im Wesentlichen aus drei Bestandteilen: der Kontrollstruktur,die den Kontrollfluss übernimmt, dem Konfigurationsmanagement, das die dynami-sche Speicherung der Konfigurationen verwaltet und dem Pluginmanagement, das dieRegistrierung und Ansteuerung der Plugins übernimmt.

5.5.4.1 Kontrollstruktur

Die Kontrollstruktur sowie die Basisaufgaben des Controllers sollen in diesem Ab-schnitt veranschaulicht werden. Um den Zusammenhang der einzelnen Komponentenzu verdeutlichen, wird an dieser Stelle der Controller als Automat dargestellt. Da dieAnforderungen an das System möglichst geringe Latenzen beinhalten, ist die Verar-beitungszeit ein expliziter Entwurfsparameter. Es wurde ein Konzept entwickelt, dases ermöglicht, einzelne Verarbeitungsschritte nebenläufig zu behandeln. Im Folgendenwerden diese Automaten genauer beschrieben und ihre Synchronisierungsschnittstel-len verdeutlicht.

RahmenautomatIm Rahmenautomat sind alle weiteren Automaten eingebettet. Seine Aufgaben sinddie Initialisierung des Controllers und die Fehlerbehandlung. Wird von einem Au-tomaten ein Fehler erkannt, wird dieser dem Rahmenautomaten gemeldet. Er über-nimmt dann den Versand des Fehlerpaketes an das MHA.

65

5 Entwurf

Abbildung 5.11: Rahmen der Kontrollautomaten des MHA-FPGAs

Der Automat ist in Abbildung 5.11 dargestellt und erfüllt im System die folgendenAufgaben:

Initialisierung der externen Schnittstelle: Hier wird der Controller über die Exis-tenz der externen Schnittstelle informiert und seine Behandlungsroutinen gela-den.

Initialisierung der Plugins: In diesem Zustand werden sowohl die Hardware- als auchdie Software-Plugins initialisiert. Im einzelnen wird an dieser Stelle den Hardware-und Software-Plugins ihre Plugin-ID zur Identifikation zugewiesen. Ein eintref-fendes Paket wird über diese ID in Bezug zum entsprechenden Plugin gesetzt.Des Weiteren wird dem Konfigurationsmanagement die Anzahl der Parameter,die ein Plugin benötigt, mitgeteilt.

Aktivierung des Verarbeitungsprozesses: Nach der vollständigen Initialisierung dereinzelnen Plugins und der externen Schnittstelle, wird dieser signalisiert, dassder Controller bereit ist, Daten zu empfangen.

Verarbeitungsprozess: Der Verarbeitungsprozess terminiert nur im Fehlerfall. Die-ser Zustand repräsentiert die im Folgenden beschriebenen drei nebenläufigenAutomaten (Empfangsmodul, Versandmodul, Hardware-Modul).

Fehlerbehandlung Sollte eine der Komponenten einen Fehler melden, so ist dieserals derart schwerwiegend zu bewerten, dass der Controller terminieren muss. Indiesem Fall wird vor der endgültigen Terminierung ein Fehlerpaket mit einemFehler-Code und einer Fehlermeldung an den Treiber geschickt.

Empfangsmodul

Das Empfangsmodul hat die Aufgabe, eingehende Datenpakete zu identifizieren undder Verarbeitung zuzuführen. Insbesondere betrifft dies den Empfang und die Analysedes Paket-Headers. Die Header-Informationen werden benötigt, um das eintreffendePaket seinem Verarbeitungsstrang zuzuführen. Das Empfangsmodul wird aktiv, wenndie externe Schnittstelle den Empfang eines Datenpaketes signalisiert.

66

5.5 MHA-FPGA

Abbildung 5.12: Empfangsmodule des MHA-FPGAs

Das Empfangsmodul ist in Abbildung 5.12 dargestellt und erfüllt im System diefolgende Aufgaben:

warten: Dieser initiale Zustand wird vom Empfangsmodul immer dann betreten,wenn keine Pakete zur Verarbeitung anstehen. Meldet die externe Schnittstelleein eingetroffenes Paket, wird das Empfangsmodul aktiviert.

Paket-Header analysieren: In diesem Zustand wird der Paket-Header analysiert undfolgende Daten werden ausgelesen:• Plugin-ID• Instanz-ID• Konfigurations- oder Datenpaket• Länge des Pakets

Konfigurationsziel ermitteln: Überprüfung, ob das Plugin für das empfangene Kon-figurationspaket während der Initialisierungsphase registriert worden ist. Solltedies nicht der Fall sein, terminiert der Automat mit einem Fehler-Code. Trittkein Fehler auf, wird für die jeweilige Konfiguration eine Instanz angelegt bzw.eine Ersetzung signalisiert, falls die Instanz bereits existieren.

Konfigurationsdatensignal setzen: Ist das Plugin registriert, so wird der Verarbei-tungsprozess mittels Konfigurationsdatensignal über das Eintreffen eines Kon-figurationspaketes informiert.

Instanz-ID ermitteln: Es wird überprüft, ob zu dem eingetroffenen Datenpaket so-wohl ein Plugin als auch eine zu Ausführung notwendige Instanz registriertwurde. Sollte keine Instanz angelegt worden sein, terminiert der Automat miteinem Fehler-Code.

Ziel der Daten ermitteln: Während der Initialisierungsphase wurde das Plugin alsHardware- oder Software-Plugins registriert. An dieser Stelle wird die Zugehö-rigkeit überprüft, um den weiteren Kontrollfluss zu steuern.

67

5 Entwurf

Software-Datensignal: Wenn ein Plugin als Software-Plugin identifiziert worden ist,wird dieses Signal gesetzt, um dem Verarbeitungsprozess das Eintreffen einesDatenpaketes für ein Software-Plugin zu signalisieren.

Hardware-Plugin überprüfen: Ist das eingetroffene Datenpaket für ein Hardware-Plugin bestimmt, so muss überprüft werden, ob dieses momentan zur Verfügungsteht. Dies geschieht über eine direkte Abfrage der Hardware.

Hardware-Plugin starten: Wenn das Hardware-Plugin zur Verarbeitung bereit steht,wird das Plugin mit seiner instanzspezifischen Konfiguration geladen. Danachwerden die Daten des zuvor empfangenen Datenpaktes an das Plugin übertragenund die Verarbeitung gestartet.

Hardware-Datensignal setzen: Dieses Signal wird nur gesetzt, wenn die Hardwarezur Verarbeitung der Daten nicht bereit war. Mit diesem Signal wird dem Ver-arbeitungsprozess mitgeteilt, dass Daten für die entsprechende Hardware bereitstehen. Der Verarbeitungsprozess wird in regelmäßigen Abständen den Zustandder Komponente überprüfen, um sie so früh wie möglich mit der Verarbeitungder zwischengespeicherten Daten zu beauftragen.

VersandmodulDas Versandmodul dient ausschließlich den Hardware-Plugins. Um möglichst geringeWartezeiten zu garantieren, wird einer Hardware-Komponente die Möglichkeit gege-ben, die berechneten Daten direkt an die externe Schnittstelle zu übertragen, um vondort als Datenpaket zurück ans MHA geschickt zu werden.

Abbildung 5.13: Versandmodule des MHA-FPGAs

Der Versandautomat ist in Abbildung 5.13 beschrieben und besitzt folgende Funk-tionalität:

externe Schnittstelle überprüfen: Bei dieser Überprüfung wird sichergestellt, dassdie externe Schnittstelle zu diesem Zeitpunkt nicht vom Verarbeitungsprozessgenutzt wird. Da die Automaten nebenläufig sind, muss sichergestellt werden,dass nicht bereits ein Teil eines Datenpakets an die Schnittstelle geschickt wur-de. Dies würde zu einer Verschachtelung von Datenpaketen führen. Diese Fehler-situation wird durch das Konzept des gegenseitigen Ausschlusses unterbunden.

68

5.5 MHA-FPGA

Hardware-Modulsignal setzen: Sollte die externe Schnittstelle des Verarbeitungs-prozesses genutzt werden, wird diesem über ein Signal mitgeteilt, dass die Da-ten des Hardware-Plugins nach Abschluss der aktuellen Tätigkeit nachzureichensind.

Datenpaket senden Ist die externe Schnittstelle bereit für eine Datenaufnahme, ge-neriert der Controller einen Paket-Header und hängt die Signaldaten dem Paketan. Paket-Header und -Rumpf werden an die externe Schnittstelle übermittelt.

VerarbeitungsprozessDer Verarbeitungsprozess ist der Automat mit der geringsten Priorität. Seine Haupt-aufgabe besteht in der Verarbeitung von Software-Paketen. Dies betrifft sowohl dieBehandlung von Konfigurationspaketen als auch die Berechnung von Software-Plug-ins. Als zweite Aufgabe übernimmt der Verarbeitungsprozess die Abarbeitung anste-hender Tätigkeiten, die von den anderen Modulen nicht erledigt werden konnten. Diesbetrifft das Starten eines Hardware-Plugins sowie das Versenden bereits verarbeiteterDaten eines Hardware-Plugins.

Abbildung 5.14: Verarbeitungsprozess im MHA-FPGAs

Der Verarbeitungsprozess wird in Abbildung 5.14 schematisch dargestellt. Die Auf-gaben sind zyklisch um den Wartezustand angelegt und werden je nach anstehenderAufgabe abgearbeitet.

warten: In diesem Zustand verweilt der Automat, wenn kein Signal für den Verar-beitungsprozess gesetzt ist.

Konfiguration speichern: Das Konfigurationsdatensignal wird vom Empfangsmodulgesetzt. Dieses Signal teilt dem Verarbeitungsprozess mit, dass neue Konfigu-rationsdaten vorliegen. Der Verarbeitungsprozess überträgt die Daten von derexternen Schnittstelle und übergibt sie dem Konfigurationsmanagement. Hierwerden die Daten in einer dynamischen Speicherstruktur abgelegt. Die genaue

69

5 Entwurf

Funktionsweise des Konfigurationsmanagements wird in Abschnitt 5.5.4.2 be-schrieben.

externe Schnittstelle überprüfen: Wenn dieses Signal gesetzt ist, konnten Datenzu einen früheren Zeitpunkt nicht von einem Hardware-Plugin an die externeSchnittstelle übermittelt werden. Es wird wiederholt überprüft, ob die externeSchnittstelle bereit ist, Daten zu empfangen.

Hardware-Modul-Signal setzen: Es war nicht möglich, die Daten an die externeSchnittstelle zu übertragen. Der Verarbeitungsprozess wiederholt diese Aufgabespäter erneut.

Datenpaket senden: Nach der Berechnung eines Plugins wird von dem Verarbei-tungsprozess ein Header generiert und der externen Schnittstelle übergeben.Im Rumpf werden die berechneten Daten des Plugins untergebracht.

Software-Plugin starten: Wenn das Software-Datensignal vom Empfangsmodul ge-setzt worden ist, ist bereits sichergestellt, dass sowohl das Software-Plugin alsauch die Instanz registriert sind. An dieser Stelle wird vom Verarbeitungspro-zess die Konfiguration aus dem Speicher gelesen und zusammen mit den Datenaus der externen Schnittstelle an das Plugin übergeben.

Hardware-Plugin überprüfen: Bei Eintreffen des Hardware-Datensignals muss über-prüft werden, ob das Hardware-Plugin für die Aufnahme von Daten bereit steht.Dieses Signal wird vom Empfangsmodul nur dann gesetzt, wenn es dem Emp-fangsmodul nicht möglich war die Daten direkt an die Hardware zu übergeben.

Hardware-Plugin starten: Wenn das Hardware-Plugin zur Verarbeitung bereit steht,wird das Plugin mit seiner Konfiguration zu der entsprechenden Instanz geladen.Danach werden die Signaldaten in das Plugin übertragen und die Verarbeitunggestartet.

Hardware-Datensignal setzen: Sollte die Hardware erneut nicht für den Empfangvon Daten bereit stehen, so merkt sich der Verarbeitungsprozess diese Aufgabeund wiederholt sie zu einem späteren Zeitpunkt.

5.5.4.2 Konfigurationsmanagement

Im MHA-FPGA steht für die Ausführung eines Plugins eine Hardwarekomponen-te oder eine Softwareroutine zur Verfügung. Im MHA kann es mehrfach eingebun-den sein. Im Folgenden soll dies anhand eines Equalizer-Plugins verdeutlicht werden.Die Funktion eines Equalizers ist die Veränderung von Amplitudenwerte ausgewähl-ter Frequenzen. Ein Equalizer-Plugin kann dabei sowohl in unterschiedlichen Kettenals auch an unterschiedlichen Positionen innerhalb einer Kette vorkommen. Wenndieses Plugin als Komponente (Hardware oder Software) auf dem FPGA zur Ver-fügung steht, muss jede Instanz des Equalizers mit seinen spezifischen Parameternausgeführt werden. Im Folgenden werden die spezifischen Parameter eines Plugins alsKonfiguration desselben bezeichnet. Die Konfiguration eines Plugins wird entwederin der Initialisierungsphase des MHAs vor dem Senden des ersten Datenpakets oder

70

5.5 MHA-FPGA

während der Ausführung, wenn die Konfiguration dynamisch geändert wird, als Kon-figurationsdatenpaket an die (Hardware- / Software-) Komponente übergeben. DieKonfigurationsverwaltung teilt sich in zwei Phasen auf: die Initialisierungs- und dieBearbeitungsphase. In der Bearbeitungsphase spiegelt sich die eigentliche Aufgabedes Konfigurationsmanagements wieder, das Speichern und Aufrufen von Konfigura-tionen.

InitialisierungIn der Initialisierungsphase wird den im System vorhandenen Plugins eine Identifi-kation (ID) zugeordnet, die mit der Plugin-ID im MHA übereinstimmen muss. Hatbeispielsweise ein Filter im MHA die Plugin-ID 18, so muss der Pluginkomponenteim MHA-FPGA ebenfalls die ID 18 zugeordnet werden. Nach der Initialisierungs-phase erwartet der Controller ein Konfigurationsdatenpaket und befindet sich somitin der Berarbeitungsphase, in der das Speichern und Abrufen von Konfigurationendurchgeführt wird.

Speichern von KonfigurationenJede Plugin-Instanz ist mit einer eindeutigen Plugin-Instanz-ID versehen, die derjeweiligen Konfiguration zugeordnet ist. Trifft ein Konfigurationspaket mit einer un-bekannten Instanz-ID ein, so wird in einer verketteten Liste ein neuer Eintrag hinzu-gefügt. Im folgenden Schritt werden die Parameter ebenfalls in einer verketteten Listegespeichert. Ist die Plugin-Instanz-ID bereits vorhanden, so werden die Parameter inder verketteten Liste überschrieben.

Aufrufen von KonfigurationenTrifft ein Datenpaket ein, so wird die Instanz-ID des Paketes an das Konfigurati-onsmanagement übergeben. In der verketteten Liste wird der entsprechende Eintraggesucht. Wird die Instanz-ID identifiziert, so können die Parameter anschließend aus-gelesen werden. Wird die Instanz-ID nicht gefunden, wird ein Fehler an die aufrufendeFunktion zurückgegeben.

5.5.4.3 Plugin-Management

In diesem Anschnitt wird die Handhabung der Plugins aufgezeigt, welche sich inden Schnittstellen, deren Verwendung und deren Kontrolle manifestiert. Das Plugin-Management ist für Software- und Hardware-Plugins getrennt zu behandeln, da essich um zwei voneinander getrennte Konzepte und Technologien handelt. Die Abar-beitung von Software-Plugins wird für das Steuern der Hardwarekomponenten unter-brochen, so dass diese möglichst permanent mit Daten versorgt sind. Die Hardware-Plugins werden mit einer höheren Priorität behandelt, da diese über weitaus mehrPerformanz als die Software-Plugins verfügen, und somit die primäre Rolle überneh-men, nämlich den Industrie-PC zu entlasten.

Software-PluginSoftware-Plugins sind Algorithmen, die in ANSI-C geschrieben sind und auf einemProzessor ausgeführt werden können. Für die Ausführung im MHA-FPGA sind be-

71

5 Entwurf

stimmte Konventionen getroffen, die eine Verwendung von Software-Plugins verein-heitlichen und vereinfachen. Die Übergabeparameter für Software-Plugins sind diezu bearbeitenden Daten und die Konfiguration, mit denen das Plugin ausgeführtwerden soll. Des Weiteren steht eine Paketversandfunktion zur Verfügung, die nachAbarbeitung eines jeden Plugins ausgeführt werden muss, um die Daten an das MHAzurückzuschicken. Zusätzlich ist es möglich einen Fehler-Code zu senden.

Hardware-Plugin – allgemeine DefinitionenHardware-Plugins sind solche, die als Hardwarekomponente vorliegen. Diese sind miteiner einheitlichen Schnittstelle ausgestattet, welche einen minimalen Parametersatzanbietet, so dass Daten gesendet und empfangen werden können. Die nachstehendeListe zeigt die Parameter dieses minimalen Satzes.

1. Datenausgang

2. Dateneingang

3. Status

4. Kontrolle

5. Instanz-ID

6. Parameterwert

Über die Parameter Datenaus- und Dateneingang werden Daten empfangen und ge-sendet. Der Parameter Status zeigt den aktuellen Zustand also die Empfangsbereit-schaft, die Anzahl zu übertragender Werte sowie die aktuelle Konfiguration der Kom-ponente an. Über den Parameter Kontrolle kann die Komponente gestartet werden.Des Weiteren wird die aktuelle Konfiguration der Komponente über den ParameterInstanz-ID mit dem Plugin assoziiert. Die Konfigurationsdaten werden über den Pa-rameter Parameterwert zugewiesen. Die Anzahl des Parameters Parameterwert istfür jedes Plugin spezifisch.

5.5.5 Hardware-Plugins

72

5.5 MHA-FPGA

Dieser Abschnitt beschreibt den Entwurf der MHA-Plugins, die als Hardware-Plugins ausgelagert werden sollen. Wegen der Wichtigkeit der (i)FFT, was durchdie Ergebnisse des Abschnittes 4.2 bestätigt wird, wurden das wave2spec- und dasspec2wave-Plugin als Hardware-Plugins realisiert. Die Komponenten dieser Pluginsund die Verkettungen dieser werden in den folgenden Abschnitten näher erläutert.

5.5.5.1 wave2spec-Plugin

Zunächst wird das wave2spec-Plugin beschrieben. Es entspricht in seiner Funkti-onsweise seinem Software-Äquivalent [28], jedoch wurden die einzelnen Operatio-nen anders auf die Komponenten verteilt. So wurde die Applikation der Hanning-Fenster durch zwei separate Komponenten realisiert und das Zero-Padding in dieFFT -Komponente integriert.

Gesamtsystem

Das wave2spec-Plugin setzt sich aus den Komponenten Eingangspuffer, Windowing,Hanning-Funktion, FFT und Ausgangspuffer zusammen. Im Folgenden ist der Da-tenfluss und Kontrollfuss näher erläutert.

Datenfluss

Die zu bearbeitenden Daten werden vom MHA-Controller in den Eingangspuffer ge-schrieben. Von dort werden sie über die Windowing-Komponente zur Hanning-Funktionund dann an die FFT transferiert. Nachdem die Berechnung der FFT abgeschlossenist, werden die Daten an den Ausgangspuffer gesendet und müssen vom MHA-FPGA-Controller abgeholt werden. Der Datenfluss wird in Abbildung 5.15 durch die unidi-rektionalen Pfeile repräsentiert und wird durch den wave2spec-Controller gesteuert.Alle Komponenten, bis auf die Eingangs- und Ausgangspuffer, besitzen die Fähigkeit,aktiv die Folgekomponente zu beschreiben.

Kontrollfluss

Die Steuerung und Konfiguration erfolgt über die Schnittstelle des wave2spec-Pluginsund basiert auf der in Abschnitt 5.5.4.3 vorgestellten Schnittstelle.

SchnittstelleFolgende Parameter werden von der wave2spec-Komponente benötigt:

• Blockgröße

• FFT-Länge

• Fensterposition

• History-Länge

Die Parameter Blockgröße und History-Länge werden von der wave2spec-KomponenteWindowing benötigt. Der FFT-Komponente erfordert die Parametern FFT-Längeund Fensterposition.

73

5 Entwurf

Abbildung 5.15: Kontrollfluss des wave2spec-Plugins

AutomatDer wave2spec-Controller hat die Aufgabe, den Datenfluss zwischen den Komponen-ten des wave2spec-Plugins zu steuern. Die wesentliche Aufgabe besteht darin, einerKomponente die Bereitschaft der Folgekomponente zu signalisieren. Eine Außnah-me bildet die Eingangspuffer-Komponente, da diese aktiv gelesen werden muss. DieKontrollsignale sind durch die bidirektionalen Pfeile in Abbildung 5.15 repräsentiert.

Abbildung 5.16: wave2spec-Controller: Datentransfer von Eingangspuffer zu Win-dowing-Komponente

Der Automat, zuständig für den Datentransfer vom Eingangspuffer zur Windo-wing-Komponente, ist in Abbildung 5.16 abgebildet. Dieser liest die Daten aus demEingangspuffer und schreibt sie in die Windowing-Komponente. Im initialen Zustandinit wird so lange verharrt, bis das erste Datum am Eingangspuffer registriert wird.Die gelieferten Daten entstammen dem MHA. Des Weiteren sendet der Automat nachdem Senden aller Daten den Befehl go zum Starten der Komponente. Der Zustands-wechsel von wait on go zu wait on next component ist die Folge. Der Zustand wait onnext component stellt sicher, dass die Komponente windowing bereit ist, neue Datenentgegen zu nehmen. Ist dies der Fall, so wird der Zustand write to next componentbetreten, in dem alle Daten von dem Eingangspuffer in die Windowing-Komponente

74

5.5 MHA-FPGA

geschrieben werden. Dem MHA-Controller wird während dieses Vorgangs angezeigt,dass die wave2spec-Komponente nicht bereit ist, neue Daten anzunehmen. Auf dieseWeise wird sichergestellt, dass der Eingangspuffer nicht überläuft, falls neue Datenin den Eingangspuffer geschrieben werden. Sobald der Eingangspuffer wieder leer ist,kann der MHA-Controller wieder Daten an die wave2spec-Komponente übergeben.

Abbildung 5.17: wave2spec-Controller: Datentransfer von der Windowing-Kompo-nenten zur Hanning-Funktion

Im nächsten Schritt werden die Daten von der Windowing-Komponente in dieHanning-Funktion geschrieben. Der Automat in Abbildung 5.17 ist für die Aufgabeverantwortlich. Im initialen Zustand wartet der Controller auf einen schreibenden Zu-griff der Windowing-Komponente. Es ist davon auszugehen, dass die Folgekomponen-te FFT bei der ersten Aktivierung empfangsbereit ist. In diesem Fall muss nicht aufeine Bereitschaft der Hanning-Funktion gewartet werden. Weiterhin ist zu erwähnen,dass diese FFT -Komponenten pipeline-fähig ist und somit beschleunigt neue Datenempfangen kann. Erfolgt ein schreibender Zugriff, so wird der Zustand wait on holdbetreten. Dieser dient dazu, auf die Aktivität der FFT zu warten, da davon auszuge-hen ist, dass die Komponente erst nachdem die Hanning-Funktion einen schreibendenZugriff durchgeführt hat, anzeigen kann, dass sie für einen weiteren Datenempfangnicht bereit ist. Sobald die FFT signalisiert, dass eine Berechnung durchgeführt wird,d.h. nicht bereit für neue Daten ist, wird der Zustand wait on ready betreten. Dieserwird erst wieder verlassen, wenn die FFT die Berechnung abgeschlossen hat und dieBereitschaft für neue Daten anzeigt.

Abbildung 5.18: wave2spec-Controller: Datentransfer von FFT zum Ausgangspuffer

75

5 Entwurf

Der letzte Automat steuert den Datenfluss zwischen FFT - und der Ausgangspuffer-Komponente. Die Arbeitsweise ist in Abbildung 5.18 dargestellt. Im initialen Zustandwartet der Automat auf die Schreibanforderung der FFT. Ist der Ausgangspufferleer, so wird bei einer Schreibanforderung der Zustand wait on output buffer emptybetreten. Dem MHA Controller wird mitgeteilt, dass neue Daten bereitliegen undalle Daten der FFT werden in den Ausgangspuffer geschrieben. Erst wenn alle Datenvom MHA-Controller abgeholt wurden, wird wieder der Zustand init betreten. DiesesVerhalten stellt sicher, dass die FFT keinen Überlauf beim Ausgangspuffer erzeugt.

Windowing

Die Windowing-Funktion dient im Hardware-wave2spec dazu, aus aktuellen Blockda-ten und History-Daten ein Fenster zu erzeugen, auf das die Hanning-Funktion ange-wendet werden kann. Es übernimmt dabei ebenfalls die Aufgabe, die History-Dateneines Kanals zu speichern. Dies impliziert, dass jeweils eine Instanz der Funktion proKanal existieren muss, um eine entsprechende History zuzuweisen.

Schnittstelle

In Abbildung 5.19 ist das Blockschaltbild der Windowing-Funktion dargestellt. ImFolgenden werden die Ein- und Ausgänge dieser Komponente erläutert.

Über den Blocksamples-Eingang übernimmt die Komponente die neuen Blockdaten.Dieser Vorgang soll durch Setzen des Wertes am write-Eingang initialisiert werden.Dies kann jedoch nur in Abhängigkeit des Wertes am busy-Ausgang geschehen, daan diesem Ausgang die Verfügbarkeit der Komponente signalisiert wird. Zusätzlichwerden der Komponente die History-Länge und die Blockgröße übergeben, da die-se Informationen zur Fenstererzeugung mit korrekter Größe benötigt werden. Dieerzeugten Fenster werden über den Fenster-Samples-Ausgang aktiv an die Folge-komponente geschrieben. Dies wird über einen entsprechenden Wert am write out-Ausgang signalisiert. Die Information der Bereitschaft der Folgekomponente erfährtdie Windowing-Funktion über den ready-Eingang.

Abbildung 5.19: Blockschaltbild des Windowing

Automat

Bevor der Kontrollablauf näher erläutert wird, sollen zunächst der Datenfluss sche-matisch und die beteiligten Subkomponenten vorgestellt werden (Abbildung 5.20).

76

5.5 MHA-FPGA

Der Speicher ist als Ringspeicher konzipiert. Die eintreffenden Blöcke werden so ge-speichert, dass die zeitliche Reihenfolge erhalten bleibt und ein korrektes Fensterausgelesen werden kann. Der Controller koordiniert die Lese- und Schreibzugriffe aufden Speicher. Durch seine Adresszuweisungen wird das Konzept des Ringspeichersrealisiert. Er agiert in Abhängigkeit der Kontrolleingänge um die gewünschten Fens-ter zu erzeugen.

Abbildung 5.20: Schema des Windowing

Der grobe Kontrollablauf des Windowing ist in Abbildung 5.21 skizziert. Die Abbil-dung zeigt die Parallelkomposition zweier Automaten. Der Automat mit drei Zustän-den beschreibt das Schreiben der neuen Blöcke in den History-Speicher. Im ZustandWarten wird verblieben, bis ein neuer Block in die Komponente geschrieben wird.Liegt ein neuer Block an, wechselt der Automat in den Zustand Block schreiben. DieTransition in diesen Zustand löst zudem ein Ereignis aus, das anzeigt, dass neueDaten verfügbar sind. Der Zustand wird verlassen, wenn der komplette Block in denSpeicher geschrieben wurde. Im Folgezustand neue Daten in History wird verblieben,bis dem Automaten durch ein Ereignis signalisiert wurde, dass das aktuelle Fensterausgelesen wurde. Der Automat kehrt daraufhin in den Zustand Warten zurück.

Der zweite Automat beschreibt den Auslesevorgang. Der Zustand Warten2 wirdnicht verlassen, bis das Ereignis eingetreten ist, dass ein neuer Block anliegt. DieTransition beschreibt das Initialisieren des Auslesens. Im zweiten Zustand Fensterauslesen wird verblieben, bis das Fenster vollständig ausgelesen wurde. Auf der Tran-sition zurück in Warte2 wird dann das Ereignis ausgelöst, das signalisiert, dass dieaktuellen Daten ausgelesen wurden.

77

5 Entwurf

Abbildung 5.21: Kontrollautomat des Windowing

Hanning-Funktion

Die Komponente der Hanning-Funktion dient der Anwendung der Funktion auf dieFenster, die von der Windowing-Komponente erzeugt werden. Das Ergebnis der An-wendung ist der gewünschte Fensterinhalt. Die Von-Hann-Funktion H(n) ist durchdie folgende Gleichung definiert:

H(n) =12− 1

2· cos

2π · nN

Dabei bezeichnet N die Länge des Fensters. Abbildung 5.22 zeigt den Graphen füreine Von-Hann-Funktion mit N = 512.

Abbildung 5.22: Beispiel einer Hanning-Kurve mit N = 512

78

5.5 MHA-FPGA

Schnittstelle

Die Schnittstelle der Hanning-Komponente ist in Abbildung 5.23 dargestellt. ÜberData IN -Eingang werden die Daten des Windowing in die Komponente geschrieben.Dieser Schreibvorgang und die Aktivierung der Komponente werden über einen ent-sprechenden Wert am GO-Eingang signalisiert. Die Aktivierung kann nur stattfinden,wenn am Ready-Ausgang die Bereitschaft der Komponente angezeigt wird. Um dieHanninng-Funktion mit der korrekten Länge anzuwenden, wird am Window-Length-Eingang die Fensterlänge übergeben. Am Data OUT -Ausgang werden schließlich dieWerte des fertigen Fensters ausgegeben.

Abbildung 5.23: Schnittstelle der Hanning-Komponente

Automat

Zunächst wird auf die Subkomponenten der Hanning-Funktion eingegangen. Ein Spei-cher nimmt die Funktionswerte H(n) zu verschiedenen Größen von N auf. So müssendie Funktionswerte nicht zur Laufzeit berechnet werden. Dies macht die Kompo-nente zwar unflexibler, jedoch werden zeit- und flächenintensive, arithmetische Ope-rationen eingespart. Zur Anwendung der Hanning-Funktion auf die Eingangsdaten,wird ein Fließkommamultiplizierer als arithmetische Einheit benutzt. Ein Control-ler übernimmt die Koordination der Speicherzugriffe und des Multiplizierers, so dassdie Eingangswerte mit den korrellierenden Funktionswerten im Speicher multipliziertwerden.

Abbildung 5.24 zeigt den Kontrollautomaten der Hanning-Funktion. Es wird inWait verweilt, bis mit GO-Eingang eine Berechnung initialisiert wird. Daraufhin wirdin Abhängigkeit der Fensterlänge die Speicheradressierung angepasst. Der ZustandCompute Data repräsentiert, dass die Daten am Data IN mit den korrellierendenFunktionswerten aus dem Speicher an den Multiplizierer übertragen werden. Sobalddas erste Ergebnis vorliegt, wird am Ready-Ausgang dies der Folgekomponente si-gnalisiert(Write Data). Sobald alle Berechnungen abgeschlossen sind, wird wiederder Zustand wait betreten.

79

5 Entwurf

Abbildung 5.24: Zustandsautomat der Hanning-Komponente

FFT/iFFT

Die Fast-Fourier-Transformation arbeitet nun auf den Datenfenstern, auf denen dasHanning-Fenster angewendet wurde. Dabei findet die Transformation der Abtast-werte aus dem Zeitbereich in den Frequenzbereich statt. Die Komponente realisiertzudem ebenfalls die inverse Fast-Fourier-Transformation.

Entwurfsentscheidung

Die Grundlage des FFT-Entwurfs bildet eine Butterfly zur Zahlenbasis 2 (Radix-2). Auf die Realisierung von FFTs zu anderen Basen (Radix-4, Radix-8, usw.) undentsprechender Kombinationen wurde im Rahmen der Projektlaufzeit abgesehen. DasSchema der Radix-2-Butterfly ist in Abbildung 5.25 dargestellt. Entsprechend erhältman das Blockschaltbild in Abbildung 5.26.

Abbildung 5.25: Butterfly-Schema

80

5.5 MHA-FPGA

Abbildung 5.26: Blockschaltbild der Butterfly

Auf Grund der Serialität der Daten war es notwendig, die Butterfly pipeline-fähigzu entwerfen. Diese Aufgabe erfüllt ein Automat zur Ansteuerung der arithmetischenKomponenten, dessen Verhalten in Abbildung 5.27 dargestellt ist.

Abbildung 5.27: Zustände einer pipeline-fähigen Butterfly

Durch die Verwendung der Butterfly erhält man eine komplexe FFT. Auf Grundder reellen Abtastwerte wird auf dieser Struktur eine kompakte reelle FFT durchge-führt. Dabei werden die Eingänge für die imaginären Werte für weitere reelle Werteverwendet, womit eine FFT doppelter Länge berechnet werden kann. Die Alternati-ve, zwei reelle FFTs mit einer komplexen Komponente zu berechnen, kann nicht ge-nutzt werden, da die Eingangsdaten sequenziell eintreffen, was unnötige Wartezeitender Komponente nach sich zöge. Der Einsatz als kompakte, reelle FFT bedingt eineUmordnung des Eingansdatensatz. Dies geschieht mittels Interlaced Decomposition,welches die Abtastwerte mit ungeradem Index auf den Imaginärteil des vorhergehen-den Abtastwertes mit geradem Index abbildet. Es wird dazu ein Speicher benötigt,der Worte doppelter Länge(64 Bit) aufnimmt. Dabei beschreiben die ersten 32 Bits

81

5 Entwurf

den Real-, die zweiten den Imaginärteil. Die FFT wird mit diesem Datensatz bis zurvorletzten Stufe durchgeführt. Anschließend werden die resultierenden Werte durchEven-Odd Decomposition umsortiert und mit dieser Ordnung die letzte Stufe der FFTdurchlaufen.

Abbildung 5.28: Beispiel Interlaced DecompositionEin weiterer Entwurfsschritt war es, die Drehfaktoren im Vorraus zu berechnen und

in einem Speicher abzulegen. Dies erspart zeit- und ressourcenintensive, arithmetischeOperationen. Die Funktion ωjk

N für die Drehfaktoren der FFT ist wie folgt definiert:

ωjkN = cos(k · 2π

N) + i · cos(k · 2π

N).

Die Drehfaktoren haben die Eigenschaft, dass sie in einem Einheitskreis wie in Abb. 5.29darstellbar sind. Durch seine Definition ist der Einheitskreis in N Werte aufgeteilt.Da der 4. Drehfaktor einer 8-Punkte-FFT den gleichen Wert repräsentiert wie der256. Wert einer 512-Punkte-FFT, muss man nur noch die Drehfaktoren der 512-Punkte-FFT in einem Speicher ablegen. Fourier-Transformationen mit weniger Punk-ten können aus diesen Werten die benötigten Drehfaktoren auslesen. Analog wurdediese Methode für die inverse Transformation genutzt.

Abbildung 5.29: Darstellung der Drehfaktoren auf dem Einheitskreis [29]Auch wurde die FFT -Komponente so entworfen, dass das Zero-Padding integriert

wurde. Im folgenden Abschnitt über die Schnittstelle der Komponente wird näher aufdie Integration eingegangen.

82

5.5 MHA-FPGA

SchnittstelleDie Schnittstelle der FFT/iFFT -Komponente ist in Abbildung 5.30 zu sehen. Zu-nächst soll ergänzend zum vorigen Abschnitt auf das Zero-Padding eingegangen wer-den. Die Eingänge Left Window und Right Window übergeben die Indizes für denersten bzw. letzten Abtastwert des Datenfensters aus der Hanning-Funktion innerhalbdes FFT-Fensters. Liegt nun ein Wert außerhalb eines Fensters, wird der Butterflyals Wert eine Null übergeben. Die Daten der Hanning-Funktion werden über denData IN -Eingang an die Komponente übertragen. Eine Aktivierung der Komponenteerfolgt über den Load-Eingang. Diese Aktivierung kann jedoch nur erfolgen, wennam Ready-Ausgang die Bereitschaft der Komponente signalisiert wird. Die Werte amHold-Eingang zeigen die Bereitschaft der Folgekomponente bzw. eines Ausgangspuf-fers an. Zur korrekten Durchführung wird der Komponente am FFT Size-Eingang dieLänge der FFT übergeben. Der Complete-Ausgang signalisiert, dass die Berechnungabgeschlossen ist und Werte am Data OUT -Ausgang verfügbar sind. Der Wert amInverse FFT -Eingang bestimmt, welche Transformations durchgeführt werden soll.

Abbildung 5.30: Schnittstellenerweiterung der FFT-Komponente um die iFFT-Fähigkeit.

AutomatDie Fast-Fourier-Transformation enthält mehrere Automaten. Der Automat zur Steue-rung des Verhaltens der FFT-Komponente, ist in der Abbildung 5.32 zu sehen. DerAutomat zur Steuerung der FFT besitzt vier Hauptzustände: Wait for Data, LoadData, Compute Data und Write Data. Die Zustände Interlaced Decomposition undZero-Padding sind der Vollständigkeit halber eingefügt worden, um Information dar-über zu geben, in welchen Zuständen die Berücksichtigung dieser beiden Fälle erfolgt.

In Abbildung 5.33 ist der Automat zu sehen, der für die Berechnung der FFT zu-ständig ist. Das Entscheidende in diesem Automaten ist das korrekte Umsetzen derZustandsübergänge zwischen den Zuständen 000 bis 007 . Es muss in Abhängigkeit

83

5 Entwurf

der aktuellen FFT-Größe mitgezählt werden, wie viele Werte bereits an die Butterflyübertragen und zurück in den Speicher geschrieben worden sind. Das bedeutet, dassdieser Automat doppelt vorhanden sein muss. Der erste Automat ist für die Daten,die gerade aus dem Speicher gelesen und an die Butterfly zur Berechnung geschriebenwerden zuständig, während der andere für die Werte verantwortlich ist, die bei derButterfly-Komponente am Ausgang anliegen und im Speicher wieder abgelegt werdensollen. Diese Problematik entsteht dadurch, dass die Butterfly pipeline-fähig ist unddie zu schreibenden und wieder zu lesenden Werte durch die Latenz des Bausteins ei-nige Takte auseinander liegen. Ein anderes Problem entsteht dadurch, dass bei kleinenFFT-Größen die Werte bereits an die Butterfly geschickt, die Berechnungen jedochnoch nicht vollständig abgeschlossen worden sind. Die nachfolgende Verarbeitungs-schritt muss also bei den FFT-Größen von 32 und 64 Punkten erst das Beenden desschreibenden Zustands abwarten, bevor weitere Aktionen getätigt werden können. Indiesen Fällen ist zum Zeitpunkt des Abschließens eines Verarbeitungsschrittes (Stage)noch keine Daten für den nächsten Schritt vorhanden.

Abbildung 5.31: Überblick über den Datenfluss der kompletten FFT.

Da die iFFT auf die gleiche Weise wie die FFT berechnet werden kann, ist es nichtnotwendig den Zustandsautomaten der FFT anzupassen. Das Register für die iFFTist jedoch beim Eintritt in den Load-Zustand zu berücksichtigen und die Adressenfür die Drehwerte anzupassen.

84

5.5 MHA-FPGA

Abbildung 5.32: Zustandsautomat der FFT/iFFT

Abbildung 5.33: Compute Data-Zustand der FFT/iFFT-Komponente

5.5.5.2 spec2wave-Plugin

Das zweite realisierte Plugin ist das spec2wave-Plugin. Auch dieses entspricht funktio-nal seinem Software-Äquivalent [28]. Im Gegensatz zum wave2spec-Plugin entsprichtdie Aufteilung der Einzeloperationen auch der Aufteilung auf die Einzelkomponenten.

Gesamtsystem

Das spec2wave-Plugin besteht aus den Komponenten Eingangspuffer, iFFT, Hanning-Rampen, Overlap-Add und Ausgangspuffer und sind in der Abbildung 5.34 schema-tisch dargestellt.

85

5 Entwurf

Abbildung 5.34: spec2wave-Plugin Daten- und Kontrollfluss

Datenfluss

Die Daten für das spec2wave-Plugin werden von dem MHA-Controller in den Ein-gangspuffer geschrieben. Anschließend gelangen die Daten über die iFFT -Komponentean die Hanning-Rampen-Komponente. Von dort aus werden die Daten anschließendan die Overlap-Add-Komponente transferiert und gelangen schließlich in den Aus-gangspuffer. Der Datenfluss ist in Abbildung 5.34 durch die unidirektionalen Pfeilerepräsentiert.

Kontrollfluss

Der Kontrollfluss der spec2wave-Komponente ist in Abbildung 5.34 durch die bidi-rektionalen Pfeile dargestellt. Der spec2wave-Controller steuert mit Außnahme derHanning-Rampen alle Komponenten. Die zentrale Aufgabe des spec2wave-Controllersist, Komponenten in Abhängigkeit der Bereitschaft der Folgekomponente zu steu-ern. Wie auch im wave2spec-Plugin besitzen alle Komponenten mit Ausnahme derEingans- und Ausgangspuffer-Komponente die Funktion, in eine FolgekomponenteDaten zu schreiben. Ein Signal zeigt der Komponente an, ob die Folgekomponentebereit ist Daten zu empfangen. Lediglich der Eingangspuffer muss aktiv von demspec2wave-Controller gelesen werden. Auf Grund der Pipelinefähigkeit der Hanning-Rampen-Komponente, muss diese nicht speziell mit Kontrollsignalen werden.

SchnittstelleDie Schnittstelle des spec2wave-Plugins basiert auf der in Abschnitt 5.5.4.3 vorge-stellten Schnittstelle. Folgende Parameter werden von der Komponente zusätzlichbenötigt.

• Blockgröße

• FFT-Länge

Der Parameter Blockgröße wird von der Komponente Overlap-Add benötigt. DieiFFT -Komponente bedarf den Parameter FFT-Länge.

86

5.5 MHA-FPGA

AutomatDie Funktionsweise des spec2wave-Controllers teilt sich in drei Teilaufgaben. Die ers-te Aufgabe besteht darin, die Daten aus dem Eingangspuffer abzuholen und an dieiFFT zu übergeben. Die Funktionsweise des verantwortlichen Automaten ist in Abbil-dung 5.35 dargestellt. Der Automat ist identisch mit dem des wave2spec-Controllers,der ebenfalls die Daten aus dem Einganspuffer zur Folgekomponete transferiert. Indiesem Kontext liest der Automat die Daten aus dem Eingangspuffer und schreibtdiese dann an die IFFT -Komponente. Für eine detaillierte Beschreibung der Auto-matenzustände sei an dieser Stelle auf den Abschnitt 5.5.5.1 verwiesen.

Abbildung 5.35: spec2wave-Controller: Datentransfer Eingangspuffer zu iFFT

Die zweite Aufgabe besteht darin, den Datenfluss von der iFFT über die Hanning-Rampen- an die Overlap-Add-Komponente zu steuern. Der Automat ist in Abbil-dung 5.36 dargestellt. Die Funktionsweise ist identisch mit dem Automaten der inAbbildung 5.17 zu sehen und im Abschnitt 5.5.5.1 erklärt ist. An dieser Stelle wirdauf eine detaillierte Erläuterung verzichtet und auf den genannten Abschnitt verwie-sen.

Abbildung 5.36: spec2wave-Controller: Datentransfer iFFT zu Overlap-Add

Letztendlich besteht die dritte Aufgabe des spec2wave-Controllers darin, die Datenvon der Overlap-Add-Komponente an den Ausgangspuffer zu schreiben. Der entspre-chende Automat ist in Abbildung 5.37 dargestellt. Die Funktionsweise entspricht dem

87

5 Entwurf

im Abschnitt 5.5.5.1 vorgestellten Automaten 5.18. Für eine detaillierte Beschreibungdes Automaten sei auf den genannten Abschnitt verwiesen.

Abbildung 5.37: spec2wave-Controller: Datentransfer Overlap-Add zu Ausgangspuf-fer

Overlap-AddDie Overlap-Add-Methode stellt die finale Operation im spec2wave-Plugin dar. Durchihre Funktionalität reduziert sie die iFFT-rücktransformierten Daten wieder auf dieursprüngliche Blockgröße. Prinzipiell geschieht dies durch Addition überlappenderDatenblöcke.

SchnittstelleZur Schnittstelle(Abbildung 5.38) der Overlap-Add gehören, neben einem EingangiFFT-Daten für die Daten aus der iFFT, ein Eingang write zum aktiven Beschrei-ben und ein busy-Ausgang. Letzterer signalisiert die Verfügbarkeit der Komponente.Zudem werden durch die Eingänge FFT-Länge und Blockgröße die entsprechendenGrößen übergeben. Der Ausgang Blockdaten dient der Ausgabe der finalen Blöcke,welche durch den write_out-Ausgang initialisiert wird. Der ready-Eingang liefert In-formationen über die Verfügbarkeit des Ausgangspuffers, in den die finalen Blöckegeschrieben werden.

Abbildung 5.38: Blockschaltbild der Overlap-Add

AutomatDie Subkomponenten der Overlap-Add sind in Abbildung 5.39 dargestellt. Der Spei-cher ist analog zur Windowing-Komponente als Ringspeicher angelegt. Die neuen Da-ten werden sequenziell mit den korrellierenden Daten aus dem Speicher addiert. Der

88

5.5 MHA-FPGA

Controller steuert den Ablauf in Abhängigkeit der externen Kontroll- und Konfigura-tionssignale. Er koordiniert die Adressierung des Speichers und Schreib-/Lesezugriffe,wodurch die korrekten Überlappungen erzeugt werden.

Abbildung 5.39: Schema der Overlap-AddAbbildung 5.40 beschreibt den Kontrollfluss der Komponente. Im Zustand Warten

wird verblieben bis neue Daten von der iFFT geschrieben werden. Im FolgezustandFensteraddition werden die eintreffenden Daten mit den Korrelierenden im Speicheraddiert und somit die entsprechenden Fenster erzeugt. Ist dieser Vorgang beendet,wird der Zustand Block ausgeben betreten, in dem der finale Block ausgegeben undin den Ausgangspuffer geschrieben wird. Zudem wird der Speicherbereich des finalenBlockes nach dem Auslesen zurückgesetzt (mit Nullen beschrieben). Wurde der Blockaus dem Ausgangspuffer geholt, ist die Komponente wieder bereit und kehrt in denWartezustand zurück.

Abbildung 5.40: Kontrollautomat der Overlap-Add

89

5 Entwurf

90

6 Implementierung

In diesem Kapitel wird die Implementierung des Gesamtsystems beschrieben. AufBasis der Analyse in Kapitel 4 und des Entwurfs in Kapitel 5 werden hier konkreteAuswahlentscheidungen für jede der im System vorhandenen Komponenten getroffenund begründet. Darüber hinaus werden funktionale Zusammenhänge der Komponen-ten auf untersten Ebenen beschrieben, so dass die Funktionsweisen und Interaktionender Komponenten verständlich werden.

Dazu wird zu Beginn ein Überblick über das Gesamtsystem auf einer Abstrak-tionsebene gegeben, welche jede der Komponenten durch ausgewählte Baugruppenbeschreibt. Im Anschluss wird das Kommunikationsprotokoll vorgestellt, indem Pa-kete und deren Inhalte diskutiert werden. Anschließend wird der Schaltungsentwurfdes Gesamtsystems vorgestellt. Es folgt eine Beschreibung der Soft- und Hardwa-re des Industrie-PCs, sowie eine detaillierte Funktionsbeschreibung von PCI- undMHA-FPGA. Die Beschreibung des PCI-FPGA zielt auf eine Beschreibung seinerRolle im Gesamtsystem und seiner internen Konfiguration ab. Die des MHA-FPGAgeht darüber hinaus auf das dort umgesetzte Konzept für die Auslagerung und Verar-beitung von Bestandteilen des MHA ein. Das Kapitel schließt mit der Beschreibungder Konstruktion des Gehäuses.

6.1 GesamtsystemAuf Basis des Entwurfs in Kapitel 5 und der dortigen Skizze des Gesamtsystems inAbbildung 5.1 auf Seite 53, wird in diesem Abschnitt diese Zeichnung konkretisiert.Abbildung 6.1 zeigt diese konkretisierte Umsetzung.

In der Abbildung sind die beiden Hauptkomponenten Industrie-PC und Beschleu-niger zu sehen. Weiterhin sind die Ein- und Ausgabekomponenten Tastatur, Anzeige-und Anzeigesteuerung eingezeichnet. Die gestrichelten Linien repräsentieren die Kom-munikatinsverbindungen zwischen diesen Komponenten. So kommunizieren Tastaturund Industrie-PC über die PS/2-Schnittstelle, die Anzeigensteuerung hingegen über-trägt die Daten über die RS-232-Schnittstelle zum Industrie-PC. Ebenso besteht zwi-schen Industrie-PC und Beschleuniger eine RS-232-Verbindung die zur Fehlersuchein der Entwicklungsphase verwendet wird. Zudem wird sie vom MYGERMS-Monitor(siehe Abschnitt 6.6, S. 112 ff) benutzt.

Weitere wichtige Kommunikationsverbindungen sind jene zwischen Industrie-PCund Beschleuniger und zwischen PCI-FPGA und MHA-FPGA. Erstere wird dabeimit Interkommunikation und Letztere mit Intrakommunikation bezeichnet. Die In-terkommunikationsverbindung dient der Übertragung von Daten des MHA zum undvom Beschleuniger, wo sie vom PCI-FPGA entgegegenommen bzw. versendet wer-den. Die Vermittlung der Daten innerhalb des Beschleunigers zum MHA-FPGA zureigentlichen Verarbeitung und vom MHA-FPGA zur Rücksendung an den Industrie-PC, wird durch die Intrakommunikationsverbindung geleistet.

91

6 Implementierung

Die einzelnen Komponenten werden im Folgenden genauer betrachtet, wobei zu-nächst auf die Kommunikation und dann auf die Komponenten selbst eingegangenwird.

Cyclo

neII

()

PCI-F

PGA

Paralla

x-Modul:

Stratix

()

MHA-FP

GA

PC/10

4-Plus

1MBS

RAM

JTAG

PC/10

4-Plus

IntelC

eleron

733M

HzRS

232

Tastatu

r

PS/2

Anzei

gesteu

erung

Anzei

gemodul

Indust

rie-PC

Besch

leunig

er

Daten

fluss

Ethern

etRS

-232

Komm

unikat

ionmi

tEntw

icklun

gs-um

gebung

1MBS

RAM

Sound-K

arte

RS232

Konfi

guratio

ns-spe

icher

+5VS

pannungsve

rsorgu

ng

Abbildung 6.1: Übersicht über das Gesamtsystem

92

6.2 Kommunikationsprotokoll

6.2 Kommunikationsprotokoll

Wie bereits aus dem Entwurf bekannt ist, werden Daten in Form von einzelnen Pa-keten versendet. Ein Paket, das in Richtung des Beschleunigers gesendet wird, istals Daten- oder Konfigurationspaket kodiert. Pakete, die vom Beschleuniger an dasMHA zurückgesendet werden, sind als Daten- oder Fehlerpakete gekennzeichnet. Diebit-genaue Spezifikation des Paketformats wird im Folgenden näher erläutert.

6.2.1 Datenpaket

In Tabelle 6.1 ist der Aufbau des Datenpakets grafisch dargestellt. Datenpakete wer-den von der MHA-Software an den Beschleuniger gesendet. Das Ziel wird hierbeieindeutig durch die Plugin-ID definiert.

01631

Plugin-ID Instanz-ID 0 Paketlänge

Datenfeldhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

hh

hh

hh

hhh

hhh

hhh

hhh

hh

hhh

hhh

hhh

hh

Tabelle 6.1: Aufbau des Datenpakets

Plugin-ID Über die Plugin-ID wird ein Datenpaket identifiziert und dem entspre-chenden Plugin zugeordnet. Dies gilt für Hardware- als auch Software-Plugins.

Instanz-ID Die Instanz-ID gibt an, mit welcher Konfiguration das Plugin auszuführenist. Dies ist notwendig, da ein MHA-Plugin mehrfach mit unterschiedlichenParametern instanziiert werden kann.

Konfigurationsbit/Fehlerbit Das Konfigurations-, bzw. Fehlerbit ist im Datenpaketnicht gesetzt und identifiziert das Paket damit eindeutig als Datenpaket.

Paketlänge Der Wert gibt die Anzahl der im Paket enthaltenen 32-Bit-Worte an.Die maximale Länge eines Pakets besteht aus 510 Worten. Pakete mit mehr als510 Wörtern werden in mehrere Pakete aufgeteilt.

Datenfeld Im Datenfeld sind die zu übermittelnden Daten enthalten. Die maximaleGröße des Datenfeldes beträgt 510 * 32 Bit.

6.2.2 Konfigurationspaket

In Tabelle 6.2 ist der Aufbau des Konfigurationspakets dargestellt. Konfigurationspa-kete können nur von der MHA-Software in Richtung des Beschleunigers übermitteltwerden. Sie enthalten die Konfiguration des Ziel-Plugins.

93

6 Implementierung

01631

Plugin-ID Instanz-ID 1 Paketlänge

Konfigurationsfeldhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

hh

hh

hhh

hhh

hhh

hh

hhh

hhh

hhh

hhh

hhhh

Tabelle 6.2: Aufbau des Konfigurationspakets

Plugin-ID Über die Plugin-ID wird das Ziel des Pakets identifiziert und der entspre-chenden Plugin-Konfiguration zugeordnet. Dies gilt für Hardware-, als auch fürSoftware-Plugins.

Instanz-ID Die Instanz-ID gibt an, für welche Konfiguration des Ziel-Plugins dieDaten im Paketrumpf zu speichern sind.

Konfigurationsbit/Fehlerbit Für ein Konfigurationspaket ist dieses Bit gesetzt.

Paketlänge Der Wert gibt die Anzahl der im Paket enthaltenen 32-Bit-Worte an.Die maximale Länge eines Pakets besteht aus 510 Worten. Pakete mit mehr als510 Wörtern werden in mehrere Pakete aufgeteilt.

Datenfeld Im Datenfeld sind die zu übermittelnden Parameter enthalten. Die maxi-male Größe des Datenfeldes beträgt 510 * 32 Bit.

6.2.3 Fehlerpaket

In Tabelle 6.3 ist der Aufbau des Fehlerpakets dargestellt. Fehlerpakete können nurin Richtung des MHA verschickt werden. Fehlerpakete vereinfachen die Identifikati-on eines Fehlers während der Entwicklungsphase. Ein mögliches Szenario wäre dasStarten eines Hardware-Plugins, bevor dessen Konfiguration übertragen wurde.

01631

Plugin-ID Instanz 1 Paketlänge

Fehlernummer... 3rd char 2nd char 1st char... ... ... ...

n-th char (n-1)-th char ... ...

Tabelle 6.3: Aufbau des Fehlerpakets zur Versendung an das MHA

Plugin-ID Die Plugin-ID gibt die ID des Plugins wieder, das das Fehlverhalten ver-ursacht hat.

94

6.3 Schaltungsentwurf

Instanz-ID Die Instanz-ID gibt die Instanz des Plugins wieder, die im Fehlerfall ge-setzt war.

Konfigurationsbit/Fehlerbit Dieses Bit ist bei einem Fehlerpaket gesetzt.

Paketlänge Die maximale Länge des Fehlerpakets beträgt 510 * 32 Bit. Dies ent-spricht dem 32 Bit Fehlercode zuzüglich 2036 Zeichen Fehlermeldung. Ein Zei-chen wird durch ein Byte repräsentiert.

Fehlernummer Die Fehlernummer wird als 32-Bit Integer-Wert übertragen. Sie iden-tifiziert die Art des aufgetreten Fehlers anhand einer Fehlertabelle.

Fehlermeldung Die Fehlermeldung wird in einem Char-Array kodiert. Ein 32-BitWort enthält 4 Zeichen, die byte-weise nach ASCI II-Standard codiert werden.


Der Schaltungsentwurf des Gesamtsystems betrifft die Komponenten

• Anzeige mit LCD-Modul,

• Anzeigesteuerung,

• Beschleuniger und

• Spannungsversorgung.

Diese Komponenten und deren Verbindungen untereinander sind, mit Ausnahme derSpannungsversorgung, in der Abbildung 6.1 auf Seite 92 zu sehen.

In diesem Abschnitt soll deren Konstruktion genauer betrachtet werden. Die Dis-kussionsgrundlage soll das in Abbildung 6.2 gezeigte Blockschaltbild sein. Gezeigtsind in diesem Bild die einzelnen Leiterplatinen, sowie deren Verbindungen mit denentsprechenden Steckern und Buchsen. Des Weiteren sind die Spannungsversorgungender Komponenten aufgezeigt.

95

6 Implementierung

PCI-FPGA(IC2-[A-D]) MHA-FPGA

(IC4-[A-E])lokaler Bus

RS-232(IC9)

1MBSRAM(IC5,6)

17

32

1MBSRAM(IC7,8)

3217

3

3

SteuerbusAdressbus

DatenbusSteuerbus

Adressbus

Datenbus

1,2V-Regler

3,3V-Regler(LM317) 5V-Regler

(LT 1083)7,2V (Batterie)

CONN1 Beschleunigerplatine

5V

Industrie-PCJ8 X5 J14

AnzeigeAnzeigesteuerung

J13

AT89C4051MAX232

CONN2

CONN1

CONN1EADIP122B-5NLW MAX1044

TastaturJ12

5VCONN3 CONN4 CONN2

Abbildung 6.2: Blockschaltbild des Gesamtsystems

6.3.1 Ein- und Ausgabekomponenten

Zur Interaktion mit dem Benuzter dienen die Ein- und Ausgabeelemente. Zur Eingabewird eine 6-Tasten-Tastatur angeboten, deren Tasten wahlfrei durch entsprechendeProgrammierung mit verschiedenen Funktionen zur Bedienung des Systems belegtwerden können. Die Komponente ist in Abbildung 6.2 als Tastatur beszeichnet. DieAusgabe wird über ein LC-Display realisiert. Die Anzeigesteuerung befindet sich aufeiner separaten Leiterplatte und bildet eine Brücke zwischen Industrie-PC und grafi-scher Anzeige.

Die 6-Tasten-Tastatur wird mittels eines integrierten Schaltkreises (IC) aus einerhandelsüblichen 105-Tasten-PC-Tastatur realisiert. Dabei werden lediglich die Tastenmit den Ziffern 1 bis 6 am IC belegt, so dass Programme auf dem Industrie-PCnach gelieferten Wert identifizieren können, welche Taste gedrückt wurde und welcheFunktion auszuführen ist. Es orientiert sich an der Verschaltung der PC-Tastatur,aus welcher der verwendete IC stammt. Das Schaltbild wurde lediglich hinsichtlichder Tastenanzahl abgeändert.

96


Die Ausgabe wird über zwei separate Komponenten realisiert. Die KomponenteAnzeigesteuerung bildet eine Brücke zwischen dem Industrie-PC und der Anzeige,welche das LCD-Modul EADIP122B-5NLW [30] des Unternehmens Electronic As-sembly [31] und einen Negativ-Spannungswandler MAX1044CPA [32] des Unterneh-mens Maxim [33] beherbergt. Auf der Komponente Anzeige sind die für das LC-Display notwendigen Komponenten angebracht. Diese Komponente stellt außerdemdie Schnittstelle für die Anzeigesteuerung bereit.

Die Anzeigesteuerung macht eine Vorverarbeitung der vom Industrie-PC gesende-ten Daten, so dass diese durch das LCD-Modul auf der Komponente Anzeigeplatinedargestellt werden können. Für diesen Zweck befindet sich auf der Leiterplatte derAnzeigesteuerung ein 8051-Mikrocontroller des Typs AT89C4051 [34] des Unterneh-mens Atmel [35], welcher über einen weiteren RS-232-Konverter-IC [36] Daten überdie serielle Schnittstelle vom Industrie-PC empfängt und überarbeitet an das LCD-Modul sendet. Die Schaltbilder der Tastatur, der Anzeige und der Anzeigesteuerungsind im Anhand in Abschnitt A.2 zu finden.

Die Kommunikation zwischen Industrie-PC und Anzeigesteuerung wird über diefolgenden Programme abgehandelt:

display.exe Dieses Programm ist als Hauptprogramm zur Kommunikation mit derAnzeige zu verstehen. Es kann über die Kommandozeile benutzt werden undbietet Möglichkeiten zur Wahl der COM-Schnittstelle, der Positionierung derAusgabe und zur Übertragung von Befehlen, Text- oder Bilddaten. MöglicheBefehle sind

• CLEAR, zum Löschen des Bildschirminhaltes,• TRIGGERBACKLIGHT, zur Aktivierung der Hintergrundbeleuchtung und• SETBACKLIGHTDELAY, zur Einstellung der automatischen Abschalt-

zeit der Hintergrundbeleuchtung.

bmp2array.exe Dieses Hilfsprogramm konvertiert BMP-Bilddaten in die Form einerFelddefinition der Programmiersprache C/C++. Das Ergebnis kann vom obenerläuterten Programm zur Anzeigesteuerung gesendet werden, welche so in derLage ist, das konvertierte Bild auf der Anzeige darzustellen. Das BMP-Bildmuss zur erfolgreichen Konversion im 24Bit-RGB-Format gespeichert werdenund darf maximal 122x32 Pixel groß sein.

Das Übertragungsprotokoll zwischen Anzeigesteuerung und Industrie-PC sieht da-bei die Bestätigung eines jeden vom Industrie-PC übertragenen Bytes vor. Diese Be-stätigung gibt Auskunft über den korrekten Empfang bzw. über einen festgestelltenFehler in der Übertragung. Nach der Identifikation eines Fehlers wird das Programmabgebrochen und der Benutzer darüber informiert.

6.3.2 Beschleuniger

Auf dem Beschleuniger übernehmen zwei FPGAs die Verarbeitung der Daten. DasBlockschaltbild 6.3 zeigt beide FPGAs als Hauptbestandteile des Beschleunigers. ImFolgenden seien diese FPGAs als PCI-FPGA und MHA-FPGA bezeichnet.

97

6 Implementierung

PCI-F

PGA

(IC2-[

A-D]

)MH

A-FP

GA(IC

4-[A-

E])lok

alerB

us

RS-23

2(IC

9)

1MB

SRAM

(IC5,6

)

17

32

1MB

SRAM

(IC7,8

)32

17

3

3

S teuer

busAd

ressbu

s

Daten

busSte

uerbus

Adres

sbus

Daten

bus

1,2V-R

egler

3,3V-R

egler

(LM317)

5V-Re

gler

(LT108

3)7,2

V(Ba

tterie)

CONN

1Be

schleu

nigerp

latine

5V

Hallo

PCI-F

PGA

(IC2-[

A-D]

)

lokale

rDate

nbus

D[31.

.0]

MhaFpga

WrRq

MhaFpga

WrClk

MhaFpga

WrFu

llPci

FpgaW

rRqPci

FpgaW

rClk

PciFp

gaWrFu

llLo

calBu

sGran

tLo

calBu

sRequ

est

MHA-

FPGA

Paral

lax-M

odul

(IC4-[

A-E])

CONN

1 Bank

1,3

1MB

SRAM

(IC5,6

)1M

BSR

AM(IC

7,8)

17 Adre

ssbus

3Ste

uerbus

32Da

tenbus

17 Adre

ssbus

3Ste

uerbus

32Da

tenbus

Konfi

gurat

ions-

speich

er(IC

1,EPC

S4)

Data

ASDO

nCSO

DCLK

JTAG

(CONN

2)TM

STC

KTD

ITD

OLE

DsOs

zillato

r(IC

10)Ba

nkN,

E

1,2V-R

egler

(IC3,U

C382-A

dj)Be

schleu

niger

RS-23

2-Konver

ter(IC

9,MAX

3225C

UP)

3,3V,

5V

5V

Abbildung 6.3: Blockschaltbild des BeschleunigersDer PCI-FPGA übernimmt die Kommunikation mit dem Industrie PC. Des Weite-

ren werden die vom Industrie PC empfangenen Daten zum MHA-FPGA transferiert,Daten vom MHA-FPGA werden zum Industrie-PC transferiert. Für diese Aufga-be wurde ein CycloneIITM FPGA des Typs EP2C8Q208C7 [37] des UnternehmensAltera [2] gewählt. Als Entscheidungsgrundlage für diesen FPGA galten folgende Ar-gumente.

Bekannter Entwurfsfluss Einige Beteiligte der Projektgruppe waren bereits mit ähn-

98


lichen FPGAs und der Altera-Entwicklungsumgebung Quartus II [7] vertraut,so dass eine längere Einarbeitungszeit nicht notwendig war.

Montage FPGAs des gewählten Typs werden auch in einem PQFP-Gehäuse [37,S. 15-7] vertrieben. Dieser Gehäusetyp kann mit den zur Verfügung stehendenWerkzeugen auf einer Platine montiert werde.

FPGA-Ressourcen Der FPGA bietet die notwendigen Ressourcen an, wie z.B. I/O-Standard 3,3 V-PCI und LVTTL sowie hinreichend viele Logikeinheiten zurImplementierung der entworfenen VHDL-Programme.

Kosten Der FPGA kostete zum Zeitpunkt der Anschaffung 25e . Die Kosten für denKonfigurationsspeicher belaufen sich auf 15,80e . Somit steht ein kostengüns-tiges FPGA-System zur Verfügung.

Des Weiteren zeigt Abbildung 6.3, dass der PCI-FPGA über die Ein-, Ausgabebän-ke 1 und 3 [37, S. IV-1ff] mit dem PC/104-Plus-Bus [23] und über die Bänke 2 und4 mit dem lokalen Bus verbunden ist. Diese Verschaltung ist durch die Verfügbarkeitder I/O-Standards in den jeweiligen Bänken des FPGA bedingt. Der PC/104-Plus-Bus wurde bereits im Abschnitt 4.3.2 beschrieben. Der lokale Bus zwischen PCI- undMHA-FPGA wird eingehend im Abschnitt 6.7.1 ab Seite 114 erläutert.

Zur Konfiguration des PCI-FPGA stehen eine JTAG-Schnittstelle [38, S. 4-52ff,Vol. 1] und ein Konfigurationsspeicher EPCS4 (Bez. IC1) [38, Kapitel 4, Vol. 2] zurAuswahl. Die JTAG-Schnittstelle ist über den Wannenstecker CONN2 erreichbar undermöglicht die Programmierung des FPGA und des Konfigurationsspeichers. Dieserdient zur nicht-flüchtigen Speicherung von Konfigurationen des FPGA, die nach demEinschalten des Systems automatisch in den PCI-FPGA geladen werden.

Weiterhin ist zu Testzwecken ein 11 MHz-Oszillator (Bez. IC10) auf der Leiterplatteinstalliert. Dieser kann verwendet werden, wenn der Industrie-PC nicht mit demBeschleuniger verbunden ist und somit kein Taktsignal über den PC/104-Plus-Bus zurVerfügung steht. Über die interne PLL des PCI-FPGA [37, S. 7-1, Vol. 1] kann dieserTakt auf 33 MHz umgesetzt werden, so dass die Funktionalität des Beschleunigers beider Zielfrequenz getestet werden kann.

Zur flüchtigen Speicherung von Daten und Programmen besitzen PCI- und MHA-FPGA je einen 1 MB-SRAM-Speicher, die aus jeweils zwei 16 Bit-SRAM-Speicherndes Typs CY7C1041CV33-10ZC [39] des Unternehmes Cypress [40] aufgebaut sind.Sie besitzen eine Zugriffszeit von 11ns(siehe auch Abschnitt 6.7, S. 113ff). Die RS-232-Schnittstelle ist über das IC9 und den Stecker CONN6 ansprechbar und dient derKommunikation mit dem Industrie-PC. Diese kann während der Entwicklungsphasezusätzlich zur Fehlersuche und außerdem zum Transfer von Programmen und Datenfür die in den FPGAs eingebetteten Soft-Core-Prozessoren genutzt werden.

Der MHA-FPGA ist ein eigenständiges Modul mit der Bezeichnung Stratix 672SmartPack Rev B/C [41] des Unternehmens Parallax [42]. Dieses Modul beherbergteinen EP1S25F672-FPGA [43] der Stratix-Familie von Altera und wird mittels Pfos-tenstecker auf den Beschleuniger aufgesteckt. Dadurch wird die Erweiterbarkeit undÄnderbarkeit des Systems gewährleistet. Die Argumentation für die Auswahl des Mo-duls ist wie folgt:

99

6 Implementierung

DSP-Resourcen FPGAs der Stratix-Familie verfügen über dedizierte Ressourcen,die von Algorithmen für die digitale Signalverarbeitung verwendet werden, wiez.B. Rechenwerke für Multiplikation und Akkumulation. Diese sind speziell fürden Einsatz in DSP-Anwendungen nützlich. Weiterhin sind hinreichend vieleLogikeinheiten vorhanden, um weitere Logik unterzubringen, wie z.B. NIOSII-Prozessor, DMA-Controller oder eine Schnittstelle zum lokalen Bus (siehe auchAbschnitt 6.8).

Verfügbare Alternativen Ein Problem stellt die Montage vergleichbarer FPGAs dar.Diese werden oft nur in Gehäusen vertrieben, die nicht durch die zur Verfügungstehenden Werkzeuge verarbeitet werden können. Somit fiel die Wahl auf eineModulbauweise, die den FPGA sowie nötige Spannungswandler und Konfigu-rationslogik bereits beinhaltet.

Kosten Der EP1S25 FPGA hätte in einer Einzelbestellung deutlich mehr gekostetals das erworbene Modul von Parallax. Weiterhin sind bei diesem Modul Ent-wicklungsprogramme, Verbindungskabel (ByteBlaster II [44]) und ein Netzteilbeigelegt, so dass das Modul eine kostengünstige Alternative zum Kauf eineseinzelnen FPGA darstellt.

Im Anhang finden sich die folgenden Schaltbilder des Beschleunigers.

1. PC/104-Plus-Anbindung

2. Beschaltung der PCI-FPGA-Bänke

3. lokaler SRAM-Speicher des PCI-FPGA

4. Steckverbindungen zum Parallax-Modul Stratix 672 SmartPack (MHA-FPGA)

5. lokaler SRAM-Speicher des MHA-FPGA

6. Netzteil

6.3.3 Spannungsversorgung

Die Spannungsversorgung des Gesamtsystems ist in Abbildung 6.4 schematisch dar-gestellt. Die Energieversorgung wird durch eine 7,2 V-Spannungsquelle geleistet. Immobilen Einsatz wird diese durch eine NiMH-Batterie ersetzt, mit der das System biszu einer Stunde betrieben werden kann. Im stationären Betrieb wird ein Netzteil fürdie 7,2 V-Spannungsquelle verwendet.

Die Komponenten des Beschleunigers benötigen drei unterschiedliche Spannungen.Eine Versorung mit 3,3 V wird durch ein abgesetztes Netzeil mit einem LinearreglerLM317 hergestellt, das durch die 7,2 V-Spannungsquelle gespeist wird. Die weiter-hin benötigten 1,2 V werden auf dem Beschleuniger mit dem Bauteil UC384-ADJ(IC3) aus den Spannungen 3,3 V und 5 V abgeleitet. Die Spannung von 5 V wirddem PC/104-Plus-Bus entnommen und vom Industrie-PC geliefert. Dieser, sowie dieAnzeige und ihre Steuerung, benötigen ebenso 5 V für ihren Betrieb. Diese Span-nung wird durch einen abgsetzten Linearregler LT1083 abgeleitet, welcher von der7,2 V-Spannungsquelle gespeist wird.

100

6.4 PC-Hardware

1,2V-Regler(IC3, UC382-Adj)

3,3V-Regler(LM317) 5V-Regler

(LT 1083)7,2V (Batterie)

Beschleuniger5V

1,2V3,3V

J18

CONN1

X5

Anzeigesteuerung

5VCONN3

AnzeigeCONN4 CONN2

Industrie-PC

Abbildung 6.4: Blockschaltbild der Spannungsversorgung des Gesamtsystems

6.4 PC-HardwareAuf Basis der Abschnitte 4.1.1, 5.1 und 5.2.1, in denen eine Analyse der möglichenIndustrie-PCs, ein Entwurf des Gesamtsystems sowie eine Skizzierung der Plattformdes MHA durchgeführt wurden, soll hier die ausgewählte Plattform für das MHAvorgestellt werden.

Es wurde bereits in den genannten Abschnitten darauf hingewiesen, dass als Plattform-Alternative für das MHA ein Industrie-PC ausgewählt wurde. Dies ergab sich aus denAnalyseergebnissen über das MHA, welche im Abschnitt 4.2 zusammengefasst sind.Daher fiel die Wahl auf einen Industrie-PC des Typs speedMOPSlcdCE [45] des Un-ternehmes Kontron [46]. Dieser PC hat u.a. folgende Eigenschaften:

• Intel Celeron 733 MHz Prozessor,

• PC/104-Plus-Bus [47],

• 2 x USB2.0,

• 10/100BaseT Ethernet,

• 147mm x 96mm Baugröße,

• einfache +5V-Spannungsversorgung und ca. 14W Leistung,

• Gewicht von 195g,

• großer zul. Temperaturbereich und

• integrierte Sound- und Grafikkarte.

101

6 Implementierung

Anhand der folgenden Punkte sei die Auswahl des Industrie-PCs nochmals präziservor dem Hintergrund der Analyseergebnisse erläutert.

Schnittstellen Der PC verfügt über eine für den Embedded-Bereich entwickelte PC/104-Plus-Schnittstelle [23]. Diese entspricht einer Kombination aus PCI und ISAmit speziellem, verkleinerten Sockel. Die Analyse in Abschnitt 4.2 ergab, dassdie Bandbreite einer PCI-Schnittstelle zur Übertragung der Daten zwischenIndustie-PC und Beschleuniger benötigt wird. Die Vielzahl weiterer Schnitt-stellen des Industrie-PCs, wie RS232, Ethernet und PS/2, ermöglicht die ein-fache Anbindung des Beschleunigers und externer Entwicklungsumgebungenauf anderen PCs. Keine andere untersuchte Plattformalternative verfügt übervergleichbar schnelle und echtzeitfähige Schnittstellen oder über eine ähnlicheAuswahl verschiedener Schnittstellen.

Entwicklungsumgebung Der Industrie-PC ist weitestgehend kompatibel mit her-kömmlichen PCs und ermöglicht somit die Programmentwicklung mit bereitsverwendeten Techniken. Andere Plattformalternativen verlangen hingegen nachspeziellen Entwicklungsumgebungen, die eine weitere Einarbeitung und spezi-elle Entwicklungstechniken erfordern. Ebenso wird durch die Architektur desIndustrie-PCs die Portierung des MHA und benötigter Programme vereinfacht.

Leistungsfähigkeit Der 733 MHz-Intel-Celeron-Prozessor des Industrie-PCs ist eineleistungsfähige Recheneinheit zur Verarbeitung der Algorithmen des MHA. Ins-besondere unterstützt der Prozessor Fließkommaberechnungen, was bei keineranderen der untersuchten Plattformalternativen der Fall ist. Diese Unterstüt-zung ist fundamental, da die Verarbeitung der Audiodaten im MHA auf Fließ-kommaarithmetik basiert. Eine Emulation der Fließkommaarithmetik in Soft-ware wäre zu rechenaufwendig, eine einfache Auslagerung auf extern angeschlos-sene Hardware ist aufgrund der hohen benötigten Bandbreite nicht möglich.

Preis Das Preis/Leistungs-Verhältnis ist bei dem gewählten Industrie-PC besser, alsbei anderen Plattformalternativen. Dies resultiert aus den oben genannten Ar-gumenten und dem Preis des PCs. Keine andere untersuchte Plattform bietetein vergleichbares Spektrum an Schnittstellen, Leistungsfähigkeit, Vielseitig-keit und Konformität mit bekannten Entwicklungstechniken, so dass dadurchder Industrie-PC als beste Plattformalternative ausgezeichnet wird.

Für den Einsatz des PCs als Plattform des MHA wurde dieser mit jeweils 256 MBHaupt- und Massenspeicher ausgestattet. Als Massenspeichermedium wurde eineCompact Flash (CF) Speicherkarte verwendet, da diese Speichermedien weniger Ener-gie benötigt, als Festplatten herkömmlicher Bauweise. Gleichzeitig sind CF-Kartenmechanisch unempfindlich.

6.5 PC-SoftwareDas Zielsystem wurde auf der CF-Speicherkarte mit 256 MB Speicherplatz (siehe Ka-pitel 6.4) untergebracht. Um dieses Zielsystem zu erzeugen, wird zunächst ein Ent-wicklungssystem benötigt, das die notwendigen Werkzeuge wie die Paketverwaltung

102

6.5 PC-Software

und einen Compiler enthält. Das Paketverwaltungssystem der Gentoo-Distributionnennt sich Portage und wird für die Installation und Deinstallation von Programm-paketen benötigt. Im Anschluss wird beschrieben, wie aus dem Entwicklungssystemdas Zielsystem generiert wird.

6.5.1 Entwicklungssystem für die Zielplattform

Bei dem Entwicklungssystem handelt es sich um ein manuell eingerichtetes Gentoo Li-nux. Die Installation wurde wie nachfolgend beschrieben durchgeführt.

Booten von der Setup-CD: Version 2006.0 der Gentoo-Installations-CD.

Temporäre Einrichtung des Netzwerks: Laden der Netzwerktreiber für das Herun-terladen der Installationsdateien.

Partitionierung und Formatierung der Festplatte: Aufteilung der Festplatte in Boot-, Swap- und Root-Partition.

Download und Installation des Grundsystems (stage3): Das Grundsystem basiertauf dem Stage-Archiv Intel x86 stage3-x86-2006.0.tar.bz2. Zusätzlich wurde derPortage-Snapshot in das Dateisystem entpackt und aktualisiert.

Auswahl, Konfiguration und Kompilieren des Kernels: Für das Entwicklungssystemwurde ein Gentoo-Kernel 2.6.15. verwendet.

Netzwerkeinrichtung Die Netzwerkeinrichtung ist für das Herunterladen und Instal-lieren der auf dem Zielsystem benötigten Programme notwendig. Mit Hilfe desNetzwerks kann außerdem nach Abschluss der Installation auf das Zielsystemzugegriffen werden.

Zudem wurde für die Softwareentwicklung die grafische Oberfläche Xfce [48] unddie Entwicklungsumgebung Kdevelop [10] installiert. Unter dieser Umgebung wurdespäter die Entwicklung der MHA-Software-Plugins realisiert.

6.5.2 Erstellung des Zielsystems

Durch die oben aufgeführten Maßnahmen stehen alle notwendigen Werkzeuge, wie derGNU C-Compiler und die Paketdatenbank des Gentoo-Betriebssytems (Portage) zurVerfügung, so dass sämtliche für das Zielsystem benötigten Anwendungen zugänglichsind.Es folgt die schematische Darstellung der Erstellung des Zielsystems. Für eine ge-nauere Beschreibung einzelner Punkte wird auf die offizielle Gentoo-Dokumentationverwiesen [49].

Erstellung des Dateisystems Herunterladen des Stage 1-Archivs stage1-x86-2006.-0.tar.bz2 und Entpacken im Ordner /target/ auf dem Entwicklungssystem.Dieses Verzeichnis stellt das Dateisystem für die spätere Installation auf demZielsystem dar.

103

6 Implementierung

Compiler-Optionen Des Weiteren kamen folgende Compiler-Optionen bei jedem wei-teren Compilieren zum Einsatz und wurden global in der Datei /etc/make.confangegeben:

USE="minimal −X"CFLAGS="−march=i686 −pipe −O2"MAKEOPTS="− j 2 "

Diese Optionen vermeiden, dass unnötige Dinge, wie Assembler-Quellen für al-le Architekturen, sowie X-Windows-Server spezifischer Code compiliert werden.Die Compilerflags optimieren den Code außerdem für die verwendete Architek-tur.

Bootstrapping cd /target && bash scripts/bootstrap.sh startet das Bootstrap-ping . Dies ist nötig, um eine „cross-compilation“ Umgebung zu erzeugen, in deraus dem Entwicklungssystem heraus Programme für das Zielsystem compiliertwerden können.

Basispakete Mit folgenden Befehlen werden Basispakete mit der Grundfunktionalitäteines Gentoo-Linux Systems installiert.

ROOT=/ta r g e t emerge systemROOT=/ta r g e t emerge base layout

Mit ROOT=/target wird dabei das Dateisystem des Zielsystems als Ziel ange-geben.

Kernel Mit emerge vanilla-sources wurde der Quellcode des für das Zielsystembestimmten Kernels in das Entwicklungssystem heruntergeladen. Erst nach An-wendung der nachfolgend beschriebenen Patches wurde dieser in einem zweitenSchritt in das Zielverzeichnis kopiert.Der realtime-preempt-Patch von Ingo Molnár [50] wurde auf den Kernel ange-wendet. Dieser Patch verringert die maximale Reaktionszeit von Systemaufru-fen, wodurch eine geringe Audio-Gesamtlatenz des Zielsystems erreicht werdenkann.Für das JACK Audio Connection Kit wurde der Patch realtime-lsm [27] be-nötigt. Er ermöglicht es, anderen Benutzern außer root das Recht zu geben,Prozesse mit Echtzeitpriorität zu starten.Nach Anwendung der Patches fand die Konfiguration des Kernels mit makemenuconfig statt. Alle wirklich benötigten Treiber wurden fest in den Kernelkompiliert. Dies beschleunigt den Systemstart und vereinfacht die Konfigurati-on.Zur Erstellung des Kernels wurde make all ausgeführt. Der Kernel wurde mitseinen Bestandteilen schließlich in das Zielverzeichnis kopiert.

Weitere Pakete Folgende Pakete wurden mit emerge -B zunächst auf dem Entwick-lungssystem heruntergeladen und kompiliert, in einem zweiten Schritt dann mitROOT=/target emerge -k binär ins Zielverzeichnis kopiert.

104

6.5 PC-Software

• JACK Audio Connection Kit [51]

• netkit-telnetd

• OpenSSH

• TCL Skriptsprache [52]

• TCL expect-Bibliothek

MHA und Anwendungen Abschließend wurde die MHA-Software mit der akusbdAuthentifizierungssoftware für den Dongle-Kopierschutz in das Zielverzeichniskopiert.

Folgende Tabelle listet von der Projektgruppe entwickelte Software auf, die auf demZielsystem verwendet wird.

Anwendung Zweck Zielverzeichnis

display Anwendung zur Ansteuerung des LC Dis-plays

/usr/local/bin

Menu TCL Anwendung zur Darstellung auf demDisplay und Bedienung über die Tasten

/usr/local/bin

Treiber Anwendung zur Kommunikation mit derBeschleunigerhardware

/usr/lib/modules/2.6.15und /dev/mha2-pci

Plugins MHA-Adapter-Plugins, die die Umleitungder Daten über den PCI-Treiber ermögli-chen

/opt/mha/bin

6.5.3 Kommunikationschema

Abbildung 6.5 zeigt in vereinfachter Form die Kommunikation über den PCI-Treiber.

In einem ersten Schritt ist der Bootvorgang des Linux-Kernels dargestellt. Es folgtdas Laden des Treibers, die Initialisierung desselben und das Reservieren der Res-sourcen. Anschließend findet eine Berechnung eines Datenpaketes mit Hilfe der Be-schleunigerhardware statt. Hierzu wird der Device-Node geöffnet, die Konfigurationgeschrieben und es kommt zu einem Austausch der Daten. Nach Fertigstellung wirdder Device-Node wieder geschlossen.

105

6 Implementierung

Beschleuinigerhardware:<type>MHA-PCI-Treiber: Linux-Kernel:<type>Adapter-Plugin:MHA:<type>

sd: Sequenzdiagramm_2

.boot

1) .driver_init

1)

2) .register_chr_dev

2)

3) .register_pci_module

3)

4) .pci-probe

4)

5) .read_ressources

5) ressources

6) .input

6)

7) .request_io

7)

8) .request_memory

8)

9) .request_irq

9)

10) .start_mha

10)

13) .process_data

13)

14) .write_config

14)

15) .process

15)

11) .init_plugin

11)

12) .open

12)

23) .free_plugin

23)

24) .close

24)

16) .memcpy_toio

16) pci_isr

17) .output

17) interrupt

.plugin_init

18) .write_data

18)

19) .process

19) data_ready

20) .memcpy_io

20) pci_isr

21) .output

21) interrupt

.process

22) .read_data

22) data

Erstellt mit Poseidon for UML Community Edition. Nicht zur kommerziellen Nutzung. Abbildung 6.5: Sequenzdiagramm Software-Kommunikation

106

6.5 PC-Software

6.5.4 PCI-Treiber

Der PCI-Treiber dient der Kommunikation zwischen MHA-Adapter-Plugin und demPCI-FPGA. Er stellt im wesentlichen folgende Funktionalität zur Verfügung:

Funktionalität Beschreibung FunktionsnameÖffnen desTreiber-Device

Der Treiber reserviert einen Puffer und legteinen Pointer auf diesen Puffer im File-Descriptor der Verbindung ab. Eine für dasverwendete Plugin eindeutige ID wird ge-neriert und gespeichert.

file_dev_open

Schreiben in dasTreiber-Device

Die zu schreibenden Daten werden durchden Treiber angenommen und in dem un-ter 1 reservierten Puffer abgelegt.

file_dev_write

Berechnung an-fordern

Der Treiber sendet die Daten aus dem Puf-fer an den PCI-FPGA der Beschleuniger-hardware und wartet auf eine Fertigstel-lung der Berechnung. Der Header der Da-tenpakete wird mit der oben generiertenID versehen. Bei Benachrichtigung durchdie Beschleunigerhardware werden die be-rechneten Daten ausgelesen und abermalsin dem reservierten Puffer abgelegt. An-hand der ID können die Daten dem ent-sprechenden Puffer zugeordnet werden.

file_dev_ioctl

Lesen aus demTreiber-Device

Die berechneten Daten werden durch denTreiber aus dem Puffer gelesen und derAnwendung zur Verfügung gestellt.

Schliessen desTreiber-Device

Der reservierte Puffer wird freigegeben. file_dev_close

Des Weiteren implementiert der Treiber folgende weitere für eine PCI-Kommunikationnotwendigen Kernel-Schnittstellen:

pc i_dr iver . namepc i_dr iver . id_tablepc i_dr iver . probepc i_dr iver . remove

Auf die genaue Funktionalität dieser Schnittstellen soll nicht weiter eingegangenwerden. Es handelt sich um Standardschnittstellen des Linux-Betriebssystems. Einegenaue Beschreibung kann [53] entnommen werden.

Im Folgenden wird die Funktionsweise an einem Beispiel erläutert. In der Praxisfinden Zugriffe nicht streng sequentiell, sondern oft parallel statt, da mehrere Pluginsgleichzeitig über den Treiber kommunizieren. Der Klarheit halber wird in diesemBeispiel nur eine einfache Verbindung eines einzelnen Plugins betrachtet.

Über ein MHA-Adapter-Plugin werden Berechnungen auf den Beschleuniger aus-gelagert (siehe: 6.5.5). Die Daten werden dazu durch das Plugin in den Datei-Node/dev/mha-pci geschrieben. Der Treiber nimmt die Daten entgegen und schreibt sie in

107

6 Implementierung

einen Puffer. Dieser Puffer ist groß genug, um die Samples eines MHA-Datenpaketesaller Kanäle aufzunehmen.

Nach dem Schreiben der Daten fordert das Plugin mit ioctl eine Berechnung beimPCI-Treiber an. Der PCI-Treiber reicht die Daten im Puffer in kleineren Paketen vonje 512 Wörtern an den PCI-Bus weiter. Dies entspricht der Kapazität der FIFO, dieim PCI-FPGA verwendet wird. Nun erfolgt die in Abschnitt 6.8.7 beschriebene Be-rechnung durch die Beschleunigerhardware. Nach Abschluss der Berechnung werdendie Daten in Teilpaketen (entsprechend der FIFO-Länge) aus der Hardware wiederin den Puffer geschrieben und dadurch zu einem vollständigen MHA-Datenpaket zu-sammengesetzt. Die Verfügbarkeit eines Teilpaketes wird durch die Hardware übereinen Hardware-Interrupt signalisiert. Während der Wartezeit können weitere Plugin-Instanzen Daten mit dem PCI-Treiber austauschen. Erst nach Abschluss des Rück-transfers an den PCI-Treiber terminiert die ioctl-Prozedur. Im Anschluss kann dasPlugin die Daten über die read-Prozedur aus dem Datei-Node und somit indirektaus dem Puffer auslesen.

6.5.5 MHA-Adapter-Plugins

Aufgabe des Adapter-Plugins ist es, vom MHA gelieferte Daten über den PCI-Treibermit der Beschleuniger-Hardware auszutauschen. Aus Sicht des MHA verhält es sichdabei wie ein gewöhnliches Software-Plugin und kann ebenso in eine normale Berech-nungskette integriert werden.

Für jedes ausgelagerte Plugin muss ein spezifisches Adapter-Plugin implemen-tiert werden, das die benötigte Konfigurationsschnittstelle bereitstellt. Jedem MHA-Adapter-Plugin liegt das gleiche Grundgerüst zu Grunde.

Im Wesentlichen muss folgende Funktionalität implementiert werden:

• plugin-spezifische Konfigurationsparameter

• Kommunikation mit dem PCI-Treiber

Die Daten gelangen auf dem üblichen Weg zum Adapter-Plugin [28]. Um die Be-rechnung der Daten anzufordern, ruft das MHA die process-Methode des Pluginsauf. Eine vereinfachte Implementierung dieser Methode:

mha_spec_t∗ mha2fft_t : : p roce s s (mha_wave_t∗ wave ) {po l l_con f i g ( ) ;

i f ( config_changed ) {send_conf ig (wave−>num_frames ) ;

}exchange_data (wave , wave−>num_frames ∗ s izeof ( mha_real_t ) ) ;

return (mha_spec_t∗) wave ;}

Bei jeder Änderung der Plugin-Konfiguration, also z.B. in der Methode update_cfg()des Plugins, muss die Variable config_changed auf 1 gesetzt werden. Dadurch wird

108

6.5 PC-Software

der process-Methode signalisiert, dass zunächst die neue Konfiguration an die Hard-ware übertragen werden muss. Dies ist die Aufgabe der send_config-Methode, welchefolgendermaßen implementiert wurde:

void mha2fft_t : : send_conf ig ( unsigned short num_frames ) {stat ic struct mha2_packet_header header ;stat ic struct mha2_config {

unsigned short f f t l e n ;unsigned short wndlen ;unsigned short wndpos ;unsigned short wndtype ;unsigned short h i s t l e n ;

} c o n f i g ;

header . plugin_id = MHA2_PLUGIN_ID;header . type = MHA2_HEADER_TYPE_CONFIG;header . l ength = s izeof ( c o n f i g ) ;

c o n f i g . f f t l e n = f f t l e n . data ;c o n f i g . wndlen = wndlen . data ;c o n f i g . wndpos = f l o o r ( wndpos . data ∗ ( f f t l e n . data

− wndlen . data ) ) ;c o n f i g . wndtype = wndtype . get_index ( ) ;c o n f i g . h i s t l e n = c o n f i g . wndlen − num_frames ;

f s e e k ( driver_fd , 0 , SEEK_SET) ;f w r i t e (&header , s izeof ( header ) , 1 , dr iver_fd ) ;f w r i t e (&con f ig , s izeof ( c o n f i g ) , 1 , dr iver_fd ) ;

i o c t l ( dr iver_fd , MHA2_IOCTL_PROCESS, NULL) ;config_changed = 0 ;

}

Konfigurationspakete entsprechen in ihrem Aufbau normalen Datenpaketen gemäßder Definition in Abschnitt 5.1.1. Den Datenteil bilden die Plugin-Konfigurations-parameter. In der send_config-Methode werden zunächst Header und Datenteil de-finiert und an den PCI-Treiber übermittelt.

Der Datenaustausch mit dem Treiber wird in der process-Methode über die Me-thode exchange_data realisiert:

void mha2fft_t : : exchange_data ( mha2_packet_bigdata∗ wave ,unsigned int num_bytes ) {

struct mha2_packet_header header ;

header . plugin_id = MHA2_PLUGIN_ID;header . type = MHA2_HEADER_TYPE_DATA;header . l ength = num_bytes ;

f w r i t e (&header , s izeof ( header ) , 1 , dr iver_fd ) ;

109

6 Implementierung

f w r i t e (&wave , s izeof (∗wave ) , 1 , dr iver_fd ) ;

i o c t l ( dr iver_fd , MHA2_IOCTL_PROCESS, NULL) ;

f s e e k ( driver_fd , s izeof ( header ) , SEEK_SET) ;f r ead (wave , num_bytes , 1 , dr iver_fd ) ;

}

Die Methode entspricht überwiegend der send_config-Methode. In einem erstenSchritt wird ein Paket-Header definiert, der die Plugin-ID und die Länge der fol-genden Daten enthält. Header und Daten werden gemeinsam an den Treiber über-tragen (fwrite). Es folgt die Anforderung einer Berechnung (ioctl), nach derenAbschluss die Daten aus PCI-Device ausgelesen werden (fread).

6.5.5.1 Plugin MHA2-FFT

Dieses Adapter-Plugin stellt eine MHA-Schnittstelle für die Hardware-Implementierungdes FFT-Plugins dar. Mit den folgenden Konfigurationsparametern ist es an Stelledes MHA-eigenen wave2spec-Plugins nutzbar.

• fftlen

• wndlen

• wndpos

• wndtype

6.5.5.2 Plugin MHA2-iFFT

Das Adapter-Plugin iFFT bietet eine Schnittstelle für die Hardware-Implementierungder inversen Fourier-Transformation. Das Plugin kann anstelle des MHA-eigenenspec2wave Plugin verwendet werden. Entsprechend dem MHA-Plugin spec2wavebesitzt es nur den Parameter postwnd. Bei Änderung der Konfiguration wird dieserWert über den Treiber an die Hardware gesendet.

6.5.6 Menüsystem

6.5.6.1 Struktur und grafische Gestaltung

Die grafische Gestaltung des Menüsystems erfolgte mit der Grafikbearbeitungs-Soft-ware Gimp in Version 2.2.13. Diverse unterschiedliche Designs wurden für das LC-Display implementiert und von verschiedenen Testpersonen sehr unterschiedlichenAlters auf ihre Bedienbarkeit überprüft (siehe: 7.3). Es wurde Wert darauf gelegt,möglichst große, leicht erkennbare Bedienelemente übersichtlich und intuitiv bedien-bar anzuordnen.

110

6.5 PC-Software

Abbildung 6.6: Implementierung des Menüsystems

6.5.6.2 Technische Realisierung

Die unter Abschnitt 5.3 vorgestellte technische Realisierung der Menüführung wur-de mit der Skriptsprache TCL in der Version 8.4 implementiert. Die Grafikausga-be auf dem LC-Display wurde mit Hilfe des selbstentwickelten, bereits unter 6.3vorgestellten display-Programms umgesetzt. Mit Hilfe dieses Programms könnenBMP-Rastergrafiken direkt auf dem Display ausgegeben werden. Die Ansteuerung derDisplay-Software, sowie die für die Nutzung des MHA notwendige Telnet-Kommunikationwurde mit der TCL-Bibliothek Expect 5.44 realisiert.

Um Ein- und Ausgabeparameter der Soundkarte, wie Lautstärke, Balance undMonitoring direkt an die Hardware senden zu können, wurden diese Konfigurations-parameter ebenfalls über die Expect-Bibliothek gesetzt.

Der Quellcode soll an dieser Stelle nicht weiter erläutert werden. Stattdessen wirdauf den Quellcode direkt verwiesen, welcher sich auf der Projektgruppen-CD-ROMbefindet.

Zu Debugging-Zwecken (siehe: 7.3) wurde das Menü-Skript zudem nicht nur fürdie Ausgabe auf dem LC-Display implementiert, sondern wird bei Anschluss einesBildschirms an den Industrie-PC auch hier dargestellt.

111

6 Implementierung

6.6 MYGERMS-Monitor

Das MYGERMS-Monitorprogramm basiert auf dem GERMS-Monitorprogramm [3,S. 16ff] von Altera. Dieses Monitorprogramm dient dazu, Software für den NIOS-Soft-Core-Prozessor in den externen Speicher zu laden. Dazu muss der FPGA bereits sokonfiguriert sein, dass alle Hardwarekomponenten, wie NIOS, BOOT-RAM, RS-232Schnittstelle und selbsterstellte Komponenten, vorhanden sind. Das MYGERMS Pro-gramm ist im BOOT-RAM abgelegt, welches ein FPGA-interner Speicher ist. BeimStart des Systems führt der NIOS das MYGERMS Monitorprogramm aus, so dassüber ein Terminalfenster auf dem Zweitrechner die Bereitschaft, Programmcode zuempfangen, angezeigt wird. Das MYGERMS Programm führt alle nötigen Aktionenaus, um Programmcode zu empfangen. Dieser wird im externen Speicher abgelegt undanschließend ausgeführt. Mit dem Zweitrechner wird unter anderem die Aufgabe, denProgrammcode zu kompilieren und den FPGA zu programmieren, übernommen. DesWeiteren können Ausgaben über das Terminalfenster auf dem Zweitrechner angezeigtwerden.

MYGERMS ist eine abgewandelte Version des GERMS-Monitorprogramms. DieAbwandlung bestand in der Spezialisierung des Funktionsumfangs auf das Beschleu-nigersystem. Hierdurch wurde der Funktionsumfang des GERMS-Monitorprogram-ms stark eingeschränkt, so dass lediglich die Funktionalität zum Herunterladen einerS-Record-Datei bestehen blieb. Diese Funktion wird nach dem Systemstart benö-tigt, wenn der FPGA konfiguriert wurde und der eingebettete NIOS-Prozessor denMYGERMS-Monitor ausführt. Nach einem Test des externen SRAM-Speichers wirdauf die Kontaktaufnahme des Industrie-PCs gewartet. Dieser sendet sodann ein Pro-gramm über die serielle Schnittstelle (RS-232), das durch Ausführung durch denNIOS-Prozessor die eigentliche Funktionalität des FPGAs – was die Programmper-spektive angeht – realisiert. Im PCI-FPGA ist dies die Vermittlung von Paketenzwischen MHA-FPGA und Industrie-PC. Im MHA-FPGA hingegen ist es die Funk-tionalität, die der Controller übernimmt, der im Abschnitt 5.5.4 beschrieben ist.

Konfiguration desFPGA

Starten vonMYGERMS

Testen desSRAM

Warten aufIndustrie-PC

Laden desProgrammes

Programmausführen

Fehler beimSpeichern

SRAMfehlerhaft

PC kontaktierteNIOS

Abbildung 6.7: Ablaufdiagramm des MYGERMS-Monitorprogramms

Zur Verdeutlichung ist in Abbildung 6.7 ein Ablaufdiagramm gezeigt. Gestartetwird mit der FPGA-Konfiguration. Hierdurch wird ein interner Speicher (Boot-RAM

112

6.7 PCI-FPGA

in Abb. 6.8, S. 113, ) erforderlich, der mit dem MYGERMS-Monitorprogramm ge-laden wird und nach Zurückstellung des NIOS-Prozessors gelesen wird. Dies startetdie Ausführung des enthaltenden Programmcodes. Begonnen wird mit einem Testdes externen SRAM-Speichers. Ist dieser Test erfolgreich, wird auf eine Kontaktauf-nahme des Industrie-PCs gewartet. Es wird sodann mit dem Herunterladen einesProgrammes fortgefahren, wobei nach jedem Datum festgestellt wird, ob das Datumkorrekt im externen SRAM-Speicher abgelegt wurde. Nach erfolgreichem Abschlusswird das Programm gestartet oder im Falle einer fehlerhaften Speicherung ein Fehlergemeldet.

6.7 PCI-FPGA

Der PCI-FPGA schlägt eine Kommunikationsbrücke zwischen dem Industrie-PC unddem MHA-FPGA. Wie bereits im Abschnitt 5.4 erwähnt worden ist, ist der PCI-FPGA für die Abwicklung der Inter- und Intrakommunikation verantwortlich. Fürdiesen Zweck ergibt sich die in Abbildung 6.8 gezeigte Konfiguration des FPGA.

NIOS

Local-Bus-Controller

Loop-Device

Boot-RAM

PCI-Core

UART

Datamaster

Instructionmaster

PCI-FPGAlokaler Bus

PC/104-Plus-BusTxRx

(Intrakommunikation)

(Interkommunikation)

ext. SRAM(1MB)

Abbildung 6.8: Blockschaltbild der PCI-FPGA-Konfiguration

Die gezeigten Komponenten sind in der folgenden Auflistung kurz erläutert. Einenähere Beschreibung folgt in folgenden Abschnitten weiter unten.

Local-Bus-Controller Der Local-Bus-Controller bietet eine Schnittstelle zum exter-nen Speicher des PCI-FPGA sowie eine Datenverbindung zum MHA-FPGA an.Diese Zusammenfassung von Speicher- und MHA-FPGA-Schnittstelle ist nötig,da der lokale Bus am PCI-FPGA sowohl für den Zugriff auf den Speicher,als auch zur Datenübertragung zum MHA-FPGA verwendet wird. Die Arbi-trierung dieses Busses unterliegt dem PCI-FPGA. Eine genauere Beschreibungdieser Komponente und des lokalen Busses findet sich im Abschnitt 6.7.1.

Loop-Device Das Loop-Device wird wegen der eingeschränkten Verbindungsmöglich-keiten des SOPC Builder [7, Vol. 4] notwendig, um Automaten des Local-Bus-Controllers Zugriff auf den externen SRAM-Speicher des PCI-FPGA zu ermög-lichen. Es ergibt sich somit die Situation, dass der LocalBusController auf sich

113

6 Implementierung

selbst zugreift. Dies ist insbesondere für das Kommando FIFOTransfer inter-essant, welches vom MHA-FPGA empfangene Daten über das Loop-Device inden externen SRAM-Speicher schreiben kann. Das Loop-Device maskiert in ei-nem solchen Transfer die Quelle des Zugriffs, so dass der Local-Bus-Controllerauf sich selbst zugreifen kann. Die Maskierung erfolgt dabei durch einfache Ab-bildung des Adressraums des Loop-Device auf den des Local-Bus-Controllersund Weiterleitung der empfangenden Bustransaktionen an den Local-Bus-Con-troller.

Boot-RAM Dieser ist ein im FPGA angesiedelter interner Speicher, der für den Sys-temstart notwendig ist. Hier ist nach der Konfiguration des FPGA das Pro-gramm MYGERMS gespeichert und wird dann vom NIOS-Prozessor [4] aus-geführt (siehe auch Abschnitt 6.6). Dieses Programm dient dem Laden einesweiteren Programms in den externen Speicher des PCI-FPGA, welches die ei-gentliche Funktionalität des PCI-FPGA implementiert. Das Laden des Pro-gramms erfolgt durch den Industrie-PC über die serielle RS-232-Schnittstelle(UART).

PCI-Core Der PCI-Core ist für die Abwicklung der PCI-Kommunikation über denPC/104-Plus-Bus zuständig. Diese Komponente wird eingehend im Abschnitt6.7.2 erläutert.

UART Diese Komponente bietet eine serielle RS-232-konforme Schnittstelle zur Kom-munikation mit dem Industrie-PC an. Diese Kommunikationsverbindung wirdbenötigt, um Programme und Daten zu laden sowie zur Fehlersuche währendder Entwicklungsphase.

Alle gezeigten Komponenten verfügen über Avalon-Schnittstellen [54], so dass siedurch den SOPC Builder von Altera in ein System eingebunden werden können. Die-ses Werkzeug generiert die nötige Verschaltung der Komponenten untereinander undermöglicht dem NIOS-Prozessor den Zugriff auf die Komponenten. Die Verschaltungvon Daten- und Befehlsbus (mit Datamaster bzw. Instructionmaster bezeichnet) istdurch die Bussegmente in der Abbildung 6.8 angedeutet. Durch diese Segmentie-rung des Avalon-Busses können Komponenten aufeinander nur zugreifen, wenn sieauf dem gleichen Bussegment angeordnet sind. Dadurch wird eine Parallelisierungder Busaktivitäten in verschiedenen Bussegmenten erreicht, wovon insbesondere dieautonom arbeitenden Automaten im Local-Bus-Controller profitieren. Diese könnenbei Abarbeitung der Befehle MHATransfer und FIFOTransfer unbeeinflusst auf ihrenBussegmenten arbeiten (siehe auch Abschnitt 6.7.1)

6.7.1 Lokaler Bus

Der lokale Bus stellt die Kommunikationsverbindung zwischen dem PCI- und MHA-FPGA her. Die Kommunikation über diese Verbindung wird als Intrakommunikationbezeichnet, da sie innerhalb des Beschleunigers stattfindet (siehe auch Abb. 6.1 aufS. 92).

In der Abbildung 6.3 auf Seite 98 (Blockschaltbild des Beschleunigers) sind die Si-gnale des lokalen Busses eingezeichnet. Sie bestehen je Übertragungsrichtung aus drei

114

6.7 PCI-FPGA

Signalen, die zur Übertragung des Schreibtakts und einer Schreibanforderung sowieder Signalisierung eines Überlaufs der FIFO dienen. Diese sind mit (MHA|PCI)FPGAWR-CLK, (MHA|PCI)FPGAWRRQ und (MHA|PCI)FPGAWRFULL bezeichnet. Weiter existierenSignale zur Anforderung (LocalBusReq) und zur Zusicherung (LocalBusGrant) deslokalen Busses.

Im Abschnitt 6.7 wurde bereits erwähnt, dass die Arbitrierung und Steuerung deslokalen Busses dem PCI-FPGA unterliegt. Daher ist innerhalb dieses FPGAs dasSteuerwerk des lokalen Busses (engl. Local Bus Controller und im Folgenden LBCabgekürzt) untergebracht. In Abbildung 6.8 auf Seite 113 ist ersichtlich, dass durchden LBC eine Brücke zwischen internen Avalon und externen lokalen Bus geschlagenwird. Diese Brücke ermöglicht dem NIOS-Prozessor im PCI-FPGA den Zugriff aufden externen SRAM-Speicher (des PCI-FPGAs) sowie den Datentransfer zum undvom MHA-FPGA.

Aus der Sicht des erwähnten NIOS-Prozessors erscheint der LBC im Adressraumwie in Abbildung 6.9 dargestellt. Der LBC belegt die ersten 1024 KB des Adressraums,wobei Zugriffe auf Adressen A mit 0x0 ≤ A ≤ 0xFFFEF, direkt auf den externenSRAM-Speicher abgebildet werden. Zugriffe auf den Bereicht 0xFFFF0 – 0xFFFFFwerden auf die Register des LBC umgelenkt und initiieren keine Zugriffe auf denSRAM-Speicher. Die Register des LBC sind dabei die folgenden:

031

B+0xFFFF8 FIFO-Peek-Register

B+0xFFFF4 Statusregister

B+0xFFFF0 Befehlsregister

B+0xFFFEF SRAM Endehhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

hhh

hhh

hhh

hhh

hhh

hh

hhh

hhh

hhh

hhh

hh

B+0x00000 SRAM Anfang

Abbildung 6.9: Registersatz des Steuerwerkes des lokalen Busses (LBC).

Befehlsregister Das Befehlsregister ist ein 32 Bit breites, les- und beschreibbares Re-gister. Es dient dem Auslösen von spezifischen Befehlen. Dabei sind folgendeBefehle definiert:FIFOTransfer Dieser Befehl transferiert den Inhalt der Eingangs-FIFO, welche

für den Datenempfang vom MHA-FPGA dient, zu einer beliebigen Adresseauf dem Avalon Bus. Die Kodierung des FIFOTransfer-Befehles ist

11 A · · ·A︸︷︷︸30 mal

,

wobei die obersten beiden Bits den Befehl und die unteren 30 A-Bits dieZieladresse kodieren, an die der Inhalt der FIFO transferiert werden soll.

115

6 Implementierung

Die Anzahl der zu übertragenden Worte wird über das Statusregister fest-gelegt und muss kleiner oder gleich der in der FIFO enthaltenden Wortesein, anderenfalls wird mit FIFOTErr = 1 ein fehlerhafter Transfer signa-lisiert, nachdem sämtlicher Inhalt aus der FIFO transferiert worden ist.Über das Statusregister kann ferner festgelegt werden, ob die Zieladres-se während des Transfers inkrementiert werden soll. Diese Funktion kanninsbesondere dann sinnvoll sein, falls die Zieladresse einen Speicher adres-siert, bei dem die Adressen inkrementiert werden müssen. Ist hingegen eineandere FIFO-ähnliche Struktur adressiert, so darf die Zieladresse nicht in-krementiert werden, um die FIFO-Struktur über die gesamte Dauer desTransfers zu selektieren. Nach Abschluss des Transfers kann eine Unter-brechung ausgelöst werden, wenn das Bit INTEN im Statusregister auf 1gesetzt ist. Über die gesamte Dauer der Abarbeitung des Befehls ist dasBit MHAT im Statusregister 1 sonst ist es 0. Hiermit kann somit alternativdas Ende der Abarbeitung festgestellt werden.

MHATransfer Mit diesem Befehl können Daten zum MHA-FPGA transferiertwerden. Die Kodierung des Befehl ist

10 A · · ·A︸︷︷︸30 mal

,

dabei dienen die oberen beiden Bits der Kodierung des Befehls und dieunteren 30 A-Bits der Kodierung der Quelladresse. Von dieser Quelladres-se werden 32Bit-Worte gelesen und in gleicher Größe zum MHA-FPGAtransferiert. Auch bei diesem Befehl kann über das Statusregister festge-legt werden, ob die Quelladresse je 32 Bit-Wort inkrementiert werden solloder nicht. Im Falle einer vollen FIFO im MHA-FPGA wird der Transferabgebrochen und das Fehlerbit MHATErr auf 1 gesetzt. Im Anschluss aneinen Transfers, obgleich fehlerfrei oder fehlerhalft, wird eine Unterbre-chung ausgelöst, falls das INTEN Bit auf 1 gesetzt ist.

MHATransferAbort Mit diesem Befehl kann ein MHA-Transfer abgebrochenwerden. Der Zustand der Datenquelle und -senke sind dabei unbestimmt.Der Zustand der internen FIFO kann durch den Befehl FIFOClear aufden Initialzustand zurückgestellt werden. Die Datensenke bedarf speziellerBehandlung zur Beseitigung der Zustandsunbestimmtheit. Diese ist vonder Art der Senke abhängig. Die Kodierung ist: 0x00000001.

FIFOTransferAbort Dieser Befehl dient dem Abbruch eines gerade laufendenFIFOTransfer-Befehls. Nach Abbruch sind der Inhalt der FIFO und derZustand der Datensenke unbestimmt. Diese Unbestimmtheit des FIFO-Inhalts kann durch den Befehl FIFOClear aufgehoben werden. Die Kodie-rung ist 0x00000003.

FIFOClear Mit diesem Befehl kann der FIFO-Inhalt gelöscht werden. Die Ko-dierung ist 0x00000002.

Statusregister Das Statusregister gibt Aufschluss über den aktuellen Zustand desLBC und dient der Einstellung spezifischer Optionen. Es besitzt folgende Ele-mente:

116

6.7 PCI-FPGA

Nr. Name Bedeutung31 MHAT Dieses Bit ist 1 genau dann, wenn zur Zeit ein MHA-

Transfer Kommando abgearbeitet wird.

30 FIFOT Dieses Bit ist 1 genau dann, wenn zur Zeit in FIFOTrans-fer Kommando abgearbeitet wird.

29 LETY Dieses Bit ist 1 genau dann, wenn die lokale FIFO (desLBC) leer ist.

28 RFUL Dieses Bit ist 1 genau dann, wenn die Empfangs-FIFO(im MHA-FPGA) voll ist.

27 INC Ist dieses Bit 1, so wird die Quell- bzw. Zieladressebei den FIFOTransfer- bzw. MHATransfer- Komman-dos nach jedem Zugriff um vier inkrementiert (es werdenstets 32Bit-Wörter transferiert).

26 INTEN Wird dieses Bit auf 1 gesetzt, so können Unterbrechun-gen auf dem Avalon Bus ausgelöst werden. Ist es 0, soist die Funktion abgeschaltet. Unterbrechungen auf demAvalon Bus werden stets dann ausgelöst, wenn das BitINT gleich 1 ist.

25 INT Dieses Bit zeigt an, ob eine Unterbrechung ausgelöstwurde. Dies ist genau dann der Fall, wenn es 1 ist. An-derenfalls wurden keine Unterbrechungen ausgelöst. Un-terbrechungen werden signalisiert, falls• die Befehle MHATransfer und FIFOTransfer been-

det wurden oder• falls ein Fehler bei Abarbeitung dieser Befehle auf-

getreten ist.

24 MHATErr Dieses Bit zeigt mit dem Wert 1 an, ob bei der Ab-arbeitung des letzten MHATransfer-Befehls ein Fehleraufgetreten ist. Dies ist dann der Fall, falls die Daten-senke (MHA-FPGA) einen Überlauf meldet oder fallsmehr Worte transportiert werden sollten, als zu Beginnin der FIFO waren.

23 FIFOTErr Dieses Bit zeigt mit dem Wert 1 an, ob bei der Ab-arbeitung des letzten FIFOTransfer-Befehls, ein Fehleraufgetreten ist. Dies ist z.B. dann der Fall, falls mehrWörter transportiert werden sollten, als bei Beginn inder FIFO waren.

Tabelle 6.4: Aufbau des Statusregisters des LBC

117

6 Implementierung

Nr. Name Bedeutung

22 ARBEN Dieses Bit aktiviert die Arbitrierung des lokalen Busses.Ist es 1, so kann der MHA-FPGA den lokalen Bus anfra-gen und bekommt ihn nach Beendigung aller Zugriffe desPCI-FPGA auf den lokalen Bus zugestanden. Ist es hin-gegen 0, so bleiben Busanforderungen des MHA-FPGAunbeachtet.

21 LBRQ Dieses Bit zeigt an, ob der lokale Bus vom MHA-FPGAangefordert wird. Es ist 1 bei einer Anforderung, sonstist es 0. Es ist eine Verzögerung von vier Taktzyklen zwi-schen der Anforderung des MHA-FPGA und der Wer-tänderung dieses Bits zu beachten.

20 LBGNT Dieses Bit zeigt bei 1 an, dass der lokale Bus dem MHA-FPGA zugestanden wurde. Zugriffe des PCI-FPGA aufden lokalen Bus sind nun nicht möglich. Es ist 0, fallsder lokale Bus dem PCI-FPGA zur Verfügung steht.

19 NEWDATARCV Dieses Bit ist 1, falls neue Daten vom MHA-FPGA emp-fangen wurden. Es bleibt solange 1, bis der FIFO-Inhaltexplizit gelöscht oder die FIFO (leer-)gelesen wurde.

10-0 WrdCnt Dieses Feld gibt die Anzahl der 32Bit-Worte an, diewährend eines Transfers übertragen werden sollen. EinTransfer wird dabei mit den Befehlen FIFOTransfer undMHATransfer eingeleitet.

Tabelle 6.4: Aufbau des Statusregisters des LBC

FIFO-Peek-Register Dieses Register wird bei jedem Datentransfer vom MHA- zumPCI-FPGA aktualisiert und enthält das erste 32Bit-Wort, das innerhalb desTransfers übertragen wurde. Dieses Wort kann dazu genutzt werden, die Be-deutung des transferierten Paketes zu bestimmen.

Die Kommunikation zwischen den FPGAs des Beschleunigers ist in Abbildung 6.10nochmals genauer dargestellt. Zu sehen ist dort im oberen Diagramm ein Transfervom PCI- zum MHA-FPGA, initiiert durch den Befehl MHATransfer. Wird dieserBefehl durch den LBC verarbeitet, so wird ein Schreibtakt mhaFPGAWRCLK an denMHA-FPGA angelegt und eine Schreibanforderung mhaFPGAWRRQ gestellt. Bei jedersteigenden Taktflanke werden nun Daten zum MHA-FPGA übertagen. Dieser kannüber das Signal mhaFPGAWRFULL das Erreichen des maximalen Füllstands melden, wo-durch der Transfer sofort abgebrochen wird. In einem solchen Fall wird das FehlerbitMHATErr im Statusregister gesetzt. Sind hingegen alle Daten übertragen worden, sowerden noch vier weitere Takte zum MHA-FPGA geschickt, um die Verwaltungsin-formationen der FIFO im MHA-FPGA (siehe auch [55, S. 2-23ff]) zu aktualisieren.Danach wird das Taktsignal „abgeschaltet“ und das Bit MHAT im Statusregister auf0 und das Bit INT auf 1 gesetzt, um anzuzeigen, dass ein Transfer vervollständigtwurde.

118

6.7 PCI-FPGA

Dn

pciFPGAWRCLK

pciFPGAWRRQ

pciFPGAWRFULL

4 weitere Taktzyklen

mhaFPGAWRCLK

mhaFPGAWRRQ

mahRPGAWRFULL

localBusRequest

localBusGrant

Busanforderung ignoriert, PCI-FPGA nutzt Bus momentan

Datentransfer in Richtung MHA-FPGA

pciFPGACLK

pciFPGAWRCLK

pciFPGAWRRQ

pciFPGAWRFULL

mhaFPGAWRCLK

mhaFPGAWRRQ

mahRPGAWRFULL

localBusRequest

localBusGrant

Datentransfer in Richtung PCI-FPGA

4 weitere Taktzyklen

localBusData[31..0] D1 D2 ... Dn

Datentransfer auf steigender Taktflanke

falls FIFO im PCI-FPGA voll wird

localBusData[31..0] D1 D2 ...

Datentransfer auf steigender Taktflanke

falls FIFO im MHA-FPGA voll wird

Takt KANN geliefert werdenfalls FIFO voll kann Takt abgeschaltet werden

falls FIFO voll, wird Takt nichtmehr geliefert

Abbildung 6.10: Zeitdiagramm von Transfers über den lokalen Bus zwischen PCI-und MHA-FPGA

Im unteren Diagramm ist ein Datentransfer vom MHA- zum PCI-FPGA darge-stellt. Für einen solchen Transfer muss der MHA-FPGA den lokalen Bus zunächstmit localBusRequest anfordern und darf erst nachdem localBusGrant durch denPCI-FPGA signalisiert wurde, auf den lokalen Bus zugreifen. Dies ist notwendig,da der PCI-FPGA den lokalen Bus ebenfalls für den Zugriff auf den lokalen SRAM-Speicher verwendet und eine gleichzeitige Verwendung des Busses durch beide FPGAsphysikalisch nicht möglich ist. Nachdem der Bus dem MHA-FPGA zugestandenwurde, überträgt der MHA-FPGA analog zum oben geschilderten Transfer die Da-ten zum PCI-FPGA. Über die gesamte Dauer des Transfers muss die Anforderung

119

6 Implementierung

localBusRequest bestehen bleiben und nach Vervollständigung des Transfers zu-rückgenommen werden. Der LBC signalisiert über das Bit NEWDATARCV, dassneue Daten empfangen wurden. Somit ist das erste 32 Bit-Wort des letzten Trans-fers über das FIFO-Peek-Register einsehbar. Über die Bits LBRQ und LBGNT kannermittelt werden, ob der Bus z.Z. angefordert wird und ob er zugestanden ist.

6.7.2 PCI-Kern

Der PCI-Kern bildet die Schnittstelle zwischen dem PCI-Bus und dem Beschleunigerund ermöglicht somit den Empfang von Daten über den PCI-Bus. Ein eigenständigesSenden von Daten ist mit dem implementierten PCI-Kern zur Zeit noch nicht möglich.Dies erfordert, dass der Industrie-PC bzw. der Treiber aktiv Daten in den Beschleuni-ger überträgt. Nach Verarbeitung der Daten im Beschleuniger wird der Treiber übereine Unterbrechung darüber informiert, dass Daten zur Abholung bereitgestellt sind,so dass dieser abermals aktiv diese Daten aus dem Beschleuniger lesen muss. Fernerwurde der PCI-Kern für die Version 2.2 des PCI-Standards [20] konzipiert, da dieseVersion im ausgewählten Industrie-PC (siehe Abschnitt 6.4) verwendet wird. Ebensowar ein hohes Maß an Autonomie angestrebt, um das Ausmaß der Steuerung vonaußen gering zu halten. Dies, sowie der Aufbau und die Funktionen des PCI-Kerns,werden in den nächsten Unterabschnitten vorgestellt.

6.7.2.1 Aufbau des PCI-Kerns

parityErrPCIParityChecker

PCI FSM

PCIConfigMem

PCIBusBuffer

AD[3

1:0]

C/B

E[3:

0]#

PAR

FRAM

E#TR

DY#

IRD

Y#ST

OP#

DEV

SEL#

IDSE

L

REQ

#G

NT#

PER

R#

INTA

#IN

TB#

INTC

#IN

TD#

FromPCIFIFO(512 x 32Bit)

ToPCIFIFO(512 x 32Bit)

PCIMux

Cm

d[3:

0]Fr

ame#

TRD

Y#IR

DY#

STO

P#D

EVSE

L#ID

SEL

REQ

#G

NT#

PER

R#

INT#

Avalon Interface

rdReqempty

wrReq

wrReq

full

rdReq

BackOff + LatchCntrl + S/T/S-Control-Signals

sel[x:0]

CnfMemDataIn[31:0]

CnfMemDataOut[31:0]

wrEn

Set/Read specific cmd/status bits

PCIAddrDecoder

BAR0 BAR1

IOAddressed

MemAddressedPCIAddr[31:0]

PCIA

ddrD

ata[

31:0

]

Innenleben des PCI-FPGAs

CMemDataOut[31:0]

clr

clr

PCIParityGenerator

SER

R#

SER

R#

calculatedParity

A[31

:0]

D[3

1:0]

Cnf

Mem

Addr

[5:0

]

PAR

ToC

heck

er

PCID

ata[

31:0

]

PCIA

ddr[3

1:0]

PCIA

Dat

a[31

:0]

calculatedParity

PAR

ToC

heck

er

parityErr

CnfMemAddr[5:0]

PCIB

yteE

n[3:

0]

Abbildung 6.11: Aufbau des PCI-Kerns.

120

6.7 PCI-FPGA

Der schematische Aufbau des PCI-Kerns ist in der Abbildung 6.11 gezeigt. Diegezeigten Komponenten erfüllen die folgenden Aufgaben:

PCI Parity Generator generiert eine gerade Paritätsinformation für die Inhalte desDaten/Adress- und Steuerbusses [20, S. 200].

PCI Parity Checker vergleicht die gelieferte Paritätsinformationen mit der eigen-ständig errechneten Parität. Bei Ungleichheit wird ein Fehler an das Steuerwerkgemeldet, welches sodann je nach Einstellung den Fehler auf dem PCI-Bus mel-den oder ignorieren kann.

PCI Bus Buffer dient der elektr. Ankopplung der restlichen Logik des PCI-Kernesan den PCI-Bus. Dabei muss insbesondere auf die Art und Weise geachtetwerden, wie und wann Signale getrieben bzw. abgeschaltet werden. Im BusBuffer wird jedoch nicht die Information der Signale festgelegt, sondern nurderen Weiterleitung an den PCI-Bus koordiniert.

PCI Mux koordiniert den Fluss der Daten zum und vom PCI- und Avalon Bus.

PCI Config Memory ist der PCI-Konfigurationsspeicher. Auf diesen kann vom PCI-als auch vom Avalon-Bus zugegriffen werden.

PCI Address Controller erkennt, ob das Gerät in der gegenwärtigen PCI-Transaktionausgewählt ist.

From PCI FIFO ist der Datenspeicher, in dem die vom PCI-Bus angekommene Da-ten gepuffert werden.

To PCI FIFO ist der Datenspeicher, in dem die zum PCI-Bus gehende Daten gepuf-fert werden. Diese werden jedoch nicht eigenständig durch den PCI-Kern überden PCI-Bus übertragen, sondern müssen aktiv von einem anderen Initiator(z.B. dem Industrie-PC) gelesen werden.

Avalon Interface gewährleistet die Kommunikation über den Avalon-Bus.

PCI FSM ist das Steuerwerk, das die Aktionen der einzelnen Komponenten des Kernswährend eines PCI- oder Avalonzugriffs aufeinander abstimmt.

PCI Retry FSM übernimmt die Kontrolle, falls das Steuerwerk PCI FSM z.Z. mitder Abwicklung von Zugriffen über den Avalon Bus beschäftigt ist. Durch dieRetry FSM wird dem Initiator einer PCI-Transaktion der Wunsch nach einemsofortigen Abbruch sowie späteren Wiederaufnahme der laufenden Transaktionmitgeteilt. Dies wird im PCI-Standard als Target Abort [20, Kap. 12] bezeich-net.

6.7.2.2 Ansteuerung von der PCI-Seite

Der PCI-Kern implementiert Konfigurations- und Targetfunktionen eines PCI-Geräts.Der Begriff „Target“ bezeichnet in der PCI-Spezifikation [20] das bei einer PCI-Transaktion adressierte Gerät. Durch die Realisierung der Targetfunktionen kanndas Gerät PCI-Transaktionen annehmen, selbst aber keine auslösen.

121

6 Implementierung

Für die PCI-Konfiguration werden die PCI-Kommandos Configuration Read undConfiguration Write benutzt. Für die Datenübertragung können sowohl Memory Readund Memory Write als auch IO Read und IO Write benutzt werden, wobei der Da-tentransfer über Memory Read und Memory Write nicht über fortlaufenden Spei-cheradressen geschieht, sondern immer an die selbe Adresse gerichtet werden müssen.

Der PCI-Kern behandelt Paritäts- und Systemfehler der PCI-Spezifikation [20]entsprechend. Falls der Kern zu Beginn einer PCI-Transaktion bereits mit der Ab-arbeitung eines Befehls beschäftigt ist, wird die Transaktion mit einem TransactionAbort abgebrochen und nicht angenommen. Aufgrund der kurzen Abarbeitungsdau-er eines solchen Befehls kann aber die selbe Transaktion gleich nach einem solchenErgebnis erneut ausgeführt werden.

6.7.2.3 Ansteuerung von der Avalon-Seite

Die Komponente Avalon Interface dient der Übertragung der Daten von und zum PCI-Kern einerseits und der Steuerbefehle andererseits. In der Abbildung 6.12 wird derPCI-Kern aus der Sicht des Avalon-Busses dargestellt. Beide Übertragungsverfahrensollen in den nachfolgenden Abschnitten erläutert werden.

031

B+0x4 Steuerung

B+0x0 Daten

Abbildung 6.12: Registersatz des PCI-Kerns.

Datenübertragung über Avalon-Bus

Die über den PCI-Bus zu übertragenen Daten werden über den Avalon-Bus an die Ba-sisadresse des PCI-Kerns geschrieben. Vorhandene Daten können von der Basisadressedes PCI-Kerns gelesen werden. Dies sind Standardoperationen für den Transfer überden Avalon-Bus. Zur näheren Information darüber vgl. [56].

Übertragung von Steuerbefehlen und Status des PCI-Kernes über Avalon-Bus

Der Kontrolltransfer über den Avalon-Bus wird über die Basisadresse mit einem Off-set von +0x4 durchgeführt. Beim Lesen von dieser Adresse wird das Statusregisterausgelesen (siehe 6.7.2.3), beim Schreiben wird das Befehlsregister(siehe 6.7.2.3) be-schrieben.

Statusregister

Das Statusregister des PCI-Kerns wird mit dem Lesezugriff auf der Basisadresse miteinem Offset von +0x4 gelesen. Es folgt die Auflistung der Bedeutung der einzelnenBits:

122

6.7 PCI-FPGA

0123412132122232425293031

BS

PI Reserviert P

KFF

ND ToPCIElements FromPCIElements I

WIR

IF

IE

Abbildung 6.13: Bits im StatusregisterAnmerkungen zum Diagramm sowie zur nachfolgenden Erklärung der einzelnen

Bitwerte im Statusregister: Zwecks besserer Lesbarkeit des Diagramms wurden dieBitnamen abgekürzt, in der Erklärung werden die Namen der entsprechenden Signalein runden Klammern angegeben. Mit „gesetzt“ ist der Wert 1 eines Bits gemeint, mit„gelöscht“ der Wert 0.

Nr. Name Bedeutung31 BS (newCommandNotYetProcessed, BS als Abkürzung für

busy) Wenn gesetzt, liegt ein neues über den Avalon-Busgeschicktes Kommando vor, das durch den PCI-Kernnoch nicht abgearbeitet wurde. Wenn gelöscht, darf einneues Kommando über den Avalon-Bus an den Kern ge-schickt werden.

30 PI (pciIRQ) Bildet den Zustand des IRQ-Pins [20] auf demPCI-Bus ab.

29–25 Reserviert Diese Bits sind für künftige Erweiterungen reserviert.

24 PK (peeked) Wenn gesetzt, ist die FIFO vom PCI- zumAvalon-Bus (FromPCIFIFO) mit dem Peek-Kommandovorausgelesen worden, um so den undefinierten Wert amAnfang des Lesevorgangs aus der besagten FIFO zu un-terdrücken. Der undefinierte Wert tritt beim Lesen ausder FIFO-Megafunction auf, welche im Legacy-Mode[55]betrieben wird. Dieser Bit beim Lesen der vorhandenenDaten aus dem PCI-Kern automatisch gelöscht.

23 FF (fromPCIFIFOFull) Wenn gesetzt, ist die FIFO vomPCI- zum Avalon-Bus bei der letzten PCI-Transaktionüberfüllt worden. Das Bit muss mit dem Clear FromPCI-FIFOFull flag-Kommando gelöscht werden.

22 ND (newData) Wenn gesetzt, sind seit dem letzten Lesevor-gang aus dem PCI-Kern neue Daten vom PCI-Bus ange-kommen. Das Bit muss mit dem Clear NewDataReceivedflag-Kommando gelöscht werden.

21–13 ToPCIFIFOElements (ToPCIFIFOElements) Dieser Adressbereich gibt denFüllstand der FromPCIFIFO (siehe Abbildung 6.11) an.

12–4 FromPCIFIFOElements (FromPCIFIFOElements) Dieser Adressbereich gibt denFüllstand der ToPCIFIFO (siehe Abbildung 6.11) an.

Tabelle 6.5: Aufbau des Statusregisters des PCI-Kernes

123

6 Implementierung

Nr. Name Bedeutung

3 IW (isWritten) Wenn gesetzt, wird der PCI-Kern gerade vonder PCI-Seite beschrieben.

2 IR (isRead) Wenn gesetzt, wird der PCI-Kern gerade vonder PCI-Seite belesen.

1 IF (interruptFired) Wenn gesetzt, ist von dem PCI-Kernauf der Avalon-Seite ein Interrupt ausgelöst worden. Die-ses Bit muss mit dem Kommando Clear Interrupt gelöschtwerden.

0 IE (interruptEnabled) Wenn gesetzt, darf der PCI-Kernauf der Avalon-Seite Interrupts auslösen. Wird mit demKommando Enable Interrupts gesetzt und mit dem Kom-mando Disable Interrupts gelöscht.

Tabelle 6.5: Aufbau des Statusregisters des PCI-Kernes

BefehlsregisterDas Befehlsregister des PCI-Kerns nimmt über den Avalon-Bus Kommandos entge-gen. Dies geschieht beim Schreiben auf die Steuerungadresse des PCI-Kernes (vgl.Abbildung 6.12). Der Befehlsregister ist auf dem Avalon-Bus an der Adresse BaseAddress des PCI-Kerns + 0x4 erreichbar. Ein neues Kommando wird aber nur entge-gengenommen, wenn im Statusregister (vgl. vorheriger Abschnitt) das BS-Bit gelöschtist.

In der folgenden Liste stehen die möglichen Kommandos. In den runden Klam-mern ist der interne Name und dessen Codierung vermerkt. Mit Ausnahme der Be-fehle für den PCI-Konfigurationsspeicher dauert die Ausführung bei 33 MHz jeweilseinen Takt. Der Befehlsregister ist 32 Bits breit. Zur Codierung der Befehle wer-den die niederwertigsten Bits benutzt. Eine Ausnahme stellen wieder die Befehle zurSteuerung des PCI-Konfigurationsspeichers dar, weil da die Adresse des Werts imKonfigurationsspeicher mitcodiert werden muss. Daher werden diese Befehle mit denhöchstwertigen Bits dargestellt und die niederwertigsten Bits beinhalten die Konfi-gurationsspeicheradresse. Bei den restlichen Befehlen sind die höchstwertigen Bitsgelöscht.

Enable Interrupts (ENABLEIRQSCMD, 0x1) Erlaubt dem PCI-Kern Interrupts aufder Avalon-Seite auszulösen. Dabei wird der IE-Bit im Statusregister gesetzt.

Disable Interrupts (DISABLEIRQSCMD, 0x2) Verbietet dem PCI-Kern Interruptsauf der Avalon-Seite auszulösen. Dabei wird der IE-Bit im Statusregister ge-löscht.

Clear Interrupts (CLEARIRQCMD, 0x3) Löscht den IF-Bit im Status-Register.

Clear ToPCIFIFO (CLEARTOPCIFIFOCMD, 0x4) Löscht die FIFO ToPCIFIFO.

Clear FromPCIFIFO (CLEARFROMPCIFIFOCMD, 0x5) Löscht die FIFO vom PCI-zum Avalon-Bus.

124

6.8 MHA-FPGA (Signalprozessor)

Trigger PCI Interrupt (TRIGGERPCIIRQCMD, 0x6) Löst einen Interrupt auf derPCI-Seite aus.

Clear NewDataReceived flag (CLEARNEWDATARECEIVEDCMD, 0x7) Löscht dasND-Bit im Statusregister.

Clear FromPCIFIFOFull flag (CLEARFROMPCIFIFOFULLCMD, 0x8) Löscht dasFF-Bit im Statusregister.

Peek (FROMPCIFIFOPEEK, 0x9) Die vom PCI-Bus führende FIFO vorauslesen,um so den undefinierten Wert am Anfang des Lesevorgangs aus der besag-ten FIFO zu unterdrücken. Das Kommando setzt den PK-Bit im Statusregis-ter. Für die Ursache dieser Operation vgl. Beschreibung des Bits PK im Ab-schnitt 6.5(Statusregister).

Read Configuration Memory Space (READCONFIGMEMCMD) Die Kodierung desKommandowertes sieht folgendermaßen aus:

056293031

1 0 Reserviert Adresse

Der PCI-Konfigurationsspeicher ist 256 Bytes groß und in 32 Bit breiten Wortenorganisiert, was zu Folge hat, dass z.B. das zweite Wort im Speicher nicht mit0x4, sondern mit 0x1 adressiert wird. Der gelesene Wert wird in die entspre-chende FIFO geschrieben.

Write Configuration Memory Space (WRITECONFIGMEMCMD) Die Kodierungdes Kommandowertes sieht folgendermaßen aus:

056293031

1 1 Reserviert Adresse

Es gelten dieselben Bedingungen wie beim Kommando Read Configuration Me-mory Space. Der zu schreibende Wert muss als erstes in die ToPCIFIFO ge-schrieben werden.


Dieses Kapitel beschreibt die Implementierung des MHA-FPGAs, der die Aufgabe hatdas Ziel eingehender Datenpakete zu bestimmen und anschießend die entstprechendenBerechnungen vorzunehmen. Im Folgenden wird mit einer Beschreibung des Gesamt-systems begonnen, in der die Komponenten vorgestellt werden, die im MHA-FPGAzum Einsatz kommen. Anschließend werden die Komponenten und ihre Implementie-rung genauer betrachtet.

125

6 Implementierung

6.8.1 Gesamtsystem

Im Kapitel 5.5.1 ist der Überblick über das Gesamtsystem schematisch dargestellt. Indiesem Abschnitt wird die konkrete Umsetzung beschrieben. Der verwendete AlteraFPGA ist vom Typ EP1S25F672C6 und gehört zur Stratix Familie. Wie schon imKapitel 6.3.2 erwähnt, kommt eine komplett vormontiertes Modul der Firma Paral-lax [42] mit Bezeichnung Stratix 672 SmartPack Rev B/C [41] zum Einsatz. Dieserübernimmt Aufgaben wie die Anbindung über den LocalBus an den PCI-FPGA, dieAnbindung an den externen Speicher, die Ausführung von Plugins und das Steuerndes Datenflusses. Der Controller wird durch ein NIOS II Soft-Core-Prozessor im-plementiert, der alle übrigen Komponenten steuert. Die kommenden Textpassagenbeschreiben diese Komponenten genau.

6.8.2 externe Schnittstelle

Die externe Schnittstelle dient der Kommunikation mit dem PCI-FPGA und bestehtaus drei Komponenten. Die erste Komponente, das Interface übernimmt die Kommu-nikation mit dem NIOS II als auch mit dem PCI-FPGA. Eine zweite Komponente,das Register File, speichert die Daten, die vom NIOS II an die externe Schnittstelle ge-schrieben werden. Im Register File werden auch die Daten, die der PCI-FPGA sendetgespeichert. Die dritte Komponente übernimmt die eigentliche Kontrolle der Steuer-signale und ist als Task Logic bezeichnet. Für das Interface zum Avalon Bus stehenstandardisierte Signale zur Verfügung. Diese sind in der folgenden Liste aufgezeigt.

• clk

• reset

• chipselect

• read

• write

• address

• readdata

• writedata

• irq

• waitrequest

Für eine genaue Beschreibung der Signale sei auf die Avalon-Interface-Spezifikation [54]verwiesen. Die Kommunikation zum PCI-FPGA wird über die Signale

• localbus_pci_fpga_wr_full

• localbus_req

• localbus_grant

126


• localbus_mha_fpga_wr_req

• localbus_wr_clk

• localbus

• input_fifo_clk_from_pci

• input_fifo_wr_full_to_pci

• input_fifo_wr_req_from_pci

bewerkstelligt. Die Beschreibung der Signale aus Sicht des PCI-FPGAs wurde bereitsin Kapitel 6.7.1 vorgenommen. Hier folgt eine Beschreibung aus Sicht der externenSchnittstelle.

Das Signal localbus_pci_fpga_wr_full zeigt der externen Schnittstelle an, ob dieFIFO des PCI-FPGAs voll ist. Wenn Daten für den PCI-FPGA bereit liegen, setztder Controller in der Task Logic das localbus_req Signal. Das localbus_grant Flag si-gnalisert, dass die Daten an den PCI-FPGA gesendet werden können. Mit Setzen deslocalbus_mha_fpga_wr_req Signals, wird ein Datum in die FIFO des PCI-FPGAsgeschrieben. Dieser Vorgang erfolgt synchron zum localbus_wr_clk Taktsignal. DerPCI-FPGA schreibt synchron mit dem Taktsignal input_fifo_clk_from_pci durchSetzen des input_fifo_wr_req_from_pci Signals an der Eingangs-FIFO der externenSchnittstelle. Ist die Eingangs-FIFO voll, so wird das Signal input_fifo_wr_full_to_pcigesetzt. Das Blockschaltbild des Interfaces ist in Abbildung 6.14 zu sehen.

Abbildung 6.14: Interface Blockschaltbild der externen SchittstelleDas Register File speichert die Kontollsignale des NIOS II, den Status der exter-

nen Schnittstelle, die an den PCI-FPGA zu sendenen Daten und die vom PCI-FPGAempfangenen Daten. Kontroll- und Statussignale werden in einem Register gespei-chert, der Datentransfer wird von zwei FIFOs, einer Eingangs- und einer Ausgangs-FIFO übernommen. Die Eingangs-FIFO nimmt die Daten des PCI-FPGAs auf, dieAusgangs-FIFO die des NIOS II. Beide FIFOs sind mit einer Kapazität von 512 32-Bit Wörtern instantiiert. Die Kontrollsignale und Statussignale der FIFOs werdenim Registerfile als Ausgänge zur Verfügung gestellt, so dass die Task Logic diese In-formationen verwenden kann. Abbildung 6.15 zeigt das Blockschaltbild der RegisterFile-Komponente.

127

6 Implementierung

Abbildung 6.15: Register File-Blockschaltbild der externen SchnittstelleFolgende in Tabelle 6.6 dargestellten Statusignale der FIFOs wurden verwendet:

Port Typ Beschreibungrdempty OUT STD_LOGIC Zeigt an, dass die FIFO leer istrdusedw OUT STD_LOGIC_VECTOR(8:0) zeigt den Füllstand der FIFO anwrfull OUT STD_LOGIC Zeigt an, dass die FIFO keine

weiteren Daten mehr aufnehmenkann

Tabelle 6.6: Verwendete Statussignale der FIFOsDas rdempty-Signal der Eingangs-FIFO wird verwendet, um den Controller in derTask Logic zu signalisieren, dass ein Datum eingetroffen ist. Der Automat (siehe auchEntwurf 5.5.2) wartet nun auf das vollständige Eintreffen des Pakets mit der angege-benen Größe. Ist das Paket eingetroffen, so wird der IRQ für den NIOS II gesetzt. Dasrdempty-Signal der Ausgangs-FIFO wird verwendet um den Controller der Task Logiczu signalisieren, dass Daten für den PCI-FPGA transferiert werden sollen. Der Con-troller in der Task Logic wartet so lange bis das Paket vollständig vom NIOS II in dieAusgangs-FIFO geschrieben wurde. Um die Vollständigkeit des Pakets zu überprüfenwird jeweils der rdusedw-Ausgang der entsprechenden FIFO verwendet. Das wrfullSignal der Ausgangs-FIFO wird direkt mit dem Ausgang waitrequest der Avalon In-terface-Komponente verbunden. Diese Verschaltung gewährleistet, dass der NIOS IInicht auf eine volle Ausgangs-FIFO schreibt und dass keine Daten verloren gehen. Daswrfull-Signal der Eingangs-FIFO ist direkt als Ausgang für den PCI-FPGA abgreif-bar. Die FIFO-Komponente steht in der verwendeten Entwicklungsumgebung AlteraQuartus als Standardbibliothekskomponente zur Verfügung. Weitere Informationenzu der FIFO-Komponente sind in Single- & Dual-Clock FIFO Megafunction UserGuide [55] zu finden. Wie oben bereits erwähnt generiert die Task Logic-Komponenteden Interrupt für den NIOS II(siehe Tabelle 6.7). Des Weiteren steuert die Task Lo-gic die Signale für die Buskommunikation (Tabelle 6.8). Dies ist insbesondere das

128


Signal localbus_req, welches den Bus beim PCI-FPGA anfordert. Das Signal wirdgesetzt, wenn ein Paket vollständig in die Ausgangs-FIFO geschrieben wurde. Teiltder PCI-FPGA dem MHA-FPGA den Bus zu, indem er das localbus_grant-Signalsetzt, so wird der Transfer vom Controller in der Task Logic-Komponente initiiert.Der Transfer zeichnet sich durch ein Lesen der Ausgangs-FIFO und durch ein schrei-ben der PCI-FPGA Eingangs-FIFO aus. Dieser Vorgang ist bereits in Abschnitt 6.7.1detailliert beschrieben. Das Blockschaltbild der Task Logic-Komponente ist in Abbil-dung 6.16 dargestellt.

Port Typ Beschreibungavalon_irq OUT STD_LOGIC informiert den NIOS II über das Vorhan-

densein eines Datenpakets

Tabelle 6.7: Task Logic generierte Signale für den NIOS II

Port Typ Beschreibunglocalbus_req OUT STD_LOGIC Busanfrage an den PCI-

FPGAlocalbus OUT STD_LOGIC_VECTOR(8:0) Localbusschnittstelleinput_fifo_full OUT STD_LOGIC Signaliert dem PCI-

FPGA, dass dieEingangs-FIFO vollist

Tabelle 6.8: Task Logic generierte Signale für die PCI-FPGA Kommunikation

Abbildung 6.16: Task Logic Blockschaltbild der externen Schnittstelle

6.8.3 SRAM-ControllerFür den Zugriff auf den lokalen Speicher des MHA-FPGA ist im System ein SRAM-Controller installiert. Dieser ist die Schnittstelle zwischen dem Avalon-Bus und dem

129

6 Implementierung

externen SRAM-Speicher, so dass Schreib- und Lesezugriffe von der Avalon-Seite desSRAM-Controller in entsprechende Schreib- und Lesezugriffe auf den SRAM-Speicherübersetzt werden. Das Blocksymbol des SRAM-Controller mit einer Auflistung derEin- und Ausgangssignale ist in Abbildung 6.17 dargestellt.

Avalon

SRAM

clkreadData[31..0]writeData[31..0]

readwrite

waitrequestbyteenable[3..0]

data[31..0]sram_oesram_wrsram_csaddr[17..0]

Abbildung 6.17: Blockschaltbild des SRAM-Controllers

Die zeitliche Abfolge und Relation der Signale des SRAM-Speichers ist von be-sonderem Interesse. Eine Missachtung dieser Randbedingungen führt zu fehlerhaftenVerhalten des SRAM-Speichers. Aus diesem Grund wird der vom Avalon-Bus geliefer-te 100MHz Systemtakt derart geteilt, dass sich effektiv eine Zugriffsrate von 25MHzauf den SRAM-Speicher einstellt. Mit dieser Zugriffsrate können Operationen mitdem SRAM-Speicher korrekt ausgeführt werden.

Weiterhin zu bemerken ist die Abhandlung von Schreibzugriffen auf Teile eines32Bit-Wortes. In einem solchen Fall wird das adressierte Wort aus dem Speicher ge-lesen, der zu überschreibenden Teil mit den Daten des Avalon-Busses ersetzt und an-schließend in den SRAM-Speicher zurückgeschrieben. Dies wird vom SRAM-Controllerautonom durchgeführt, so dass sich aus der Avalon-Perspektive ein einheitliches Zu-griffsverhalten ergibt.

6.8.4 Plugin-SchnittstellenDieser Abschnitt beschreibt die implementierten Schnittstellen für die Softwareplug-ins, wie auch für die Hardwareplugins. Die Definition dient der Vereinheitlichung vonimplementierten Plugins.

6.8.4.1 Software-Schnittstelle (Spezifikation)

Bei der Softwareschnittstelle handelt es sich um einen Funktionsaufruf mit genau zweispezifizierten Parametern. Beide Paramameter sind vom Typ float. Der erste Parame-ter übergibt ein Array mit den zu berechnenden Daten, der zweite übergibt ein Arraymit den Konfigurationsparametern. Die Arraygröße ist auf 1530 Werte beschränkt.Der Rückgabewert ist ein Fehlercode. Die Fehlercodes „0“–„10“ sind reserviert. “0“wird zurückgegeben, wenn kein Fehler aufgetreten ist. Die vergebenen Fehlercodessind in Tabelle 6.12 definiert. Des Weiteren muss vor Verlassen der Softwarerouti-ne die Funktion sendSoftwareData aufgerufen werden, die in Tabelle 6.8.5.3 genauerbeschrieben ist. Die Funktion sendet die Ergebnisse der Berechnung an das MHA.

130


6.8.4.2 Hardware-Schnittstelle (Spezifikation)

Die Hardware-Plugin-Komponente teilt sich in drei Komponenten auf. Diese sind dasAvalon Interface, Register File und die Task Logic. Die Avalon Interface-Komponenteimplementiert das Interface zum NIOS II. Es werden die für die Kommunikation benö-tigten Signale, die im Blockschaltbild 6.18 dargestellt und in [1] näher erläutert sind,mit den Komponenten Register File und Task Logic verbunden. Die Register File-Komponente speichert alle Kontrollbefehle, die vom den NIOS II empfangen werdenund stellt des Weiteren die Statusinformationen der Gesamtkomponente bereit. DieTask Logic-Komponente implementiert die Berechnung des Plugins.

Abbildung 6.18: Hardwareplugin: Blockschaltbild Avalon Interface

Für den Adresseingang gelten die in Tabelle 6.8.4.2 zusammengefassten Konventio-nen. Tabelle 6.8.4.2 zeigt die Definition des Statusregisters und Tabelle 6.8.4.2 zeigtdie Konventionen für das Kontrollregister.

Adresse Name Bedeutung0 Datenausgang Spricht den Datenausgang der Komponente an.

1 Dateneingang Spricht den Dateneingang der Komponente an.

2 Statusregister Spricht den Ausgang zum Lesen der Statusinforma-tion an.

3 Kontrollregister Spricht den Eingang zur Kontrolle des Plugins an.

4 Instanz-ID Spricht den Eingang zum Speichern der konfigura-tionsspezifischen Instanz-ID an.

> 5 Parameter oder freieVerfügung

Über diesen Adressraum werden die Paramterein-gänge des Plugins angesprochen.

Tabelle 6.9: Hardware-Plugin – Konventionen des Adresseingangs

131

6 Implementierung

Bit Name Bedeutung31–23 nicht vergeben Dieser Bereich steht zur freien Verfügung.

22 IRQ Status Zeigt an ob ein Interrupt aktiv ist.

21 IRQ Bereitschaft Zeigt an, ob Interrupts aktiviert sind.

20 Komponentenstatus Zeitgt an, ob Komponente bereit für neue Berech-nung ist

19–8 Datenanzahl Zeigt an , wie viele Ergebnisdaten bereitliegen

7–0 Instanz-ID Zeigt die aktuelle, konfigurationsspezifischeInstanz-ID an.

Tabelle 6.10: Hardware-Plugin – Konventionen des Statusregisters

Bit Name Bedeutung31–3 nicht vergeben Dieser Bereich steht zur freien Verfügung.

2 Start Komponente beginnt Berechnung

1 IRQ Aktivierung Nach Fertigstellung des Berechnungsprozesses wirdein Interrupt erzeugt. Wenn deaktiviert, wird dieFertigstellung nur über das Statusregister ange-zeigt.

0 IRQ reset Setzt den Interrupt der Komponente zurück.

Tabelle 6.11: Hardware-Plugin – Konventionen des Kontrollregisters

6.8.5 Controller

Dieser Abschnitt beschäftigt sich mit der Implementierung des Controllers, des-sen Aufgabe es ist ankommende Datenpakete von der externen Schnittstelle abzu-holen und deren Ziel zu bestimmen. Des Weiteren werden alle Komponenten desMHA-FPGAs durch den Controller gesteuert. Die Aufgaben des Controllers werdendurch einen Softcore implemtiert. Die Firma Altera stellt mit dem NIOS II-Softcore-Prozessor und der NIOS II IDE die Möglichkeit zur Verfügung, das gewünschteVerhalten in ANSI-C zu implementieren. Dieser Abschnitt wurde in drei Abstrak-tionsebenen unterteilt. Die oberste Ebene ist die Kontrollstruktur. Hier wird dieKommunikation der einzelnen Kontrollautomaten und deren Steuerung beschrieben.Die mittlere Ebene beinhaltet die Kontrollkomponenten, die die aus dem Entwurfbekannten Kontrollautomaten umsetzt. Die Basiskomponenten bilden die untersteEbene, sie stellen den Kontrollkomponenten die Grundfunktionalität des Controllerszur Verfügung. Die Beschreibung findet also als TOP-DOWN Vorgehensweise statt.

6.8.5.1 Kontrollstruktur

Die Kontrollstruktur steuert das Verhalten der einzelnen Kontrollkomponenten. Dader NIOS II Aufgaben lediglich sequentiell abarbeiten kann, ist die parallele Ausfüh-

132


rung der im Entwurf vorgestellten Automaten nicht möglich. Um dennoch möglichsteffektiv auf den entwickelten Hardware-Komponenten arbeiten zu können, werdenInterrupt-Service-Routinen(ISR) benutzt. Diese ermöglichen es, das laufende Pro-gramm an jeder beliebigen Stelle zu unterbrechen, damit höher priorisierte Aufgabenvorrangig abgearbeitet werden. Um ein Fehlverhalten des Controllers zu verhindern,ist eine Kommunikation der einzelnen Software-Komponenten untereinander notwen-dig. Dies geschieht mittels Kommunikationssignale. In Abbildung 6.19 wird dieseStruktur grafisch dargestellt.

Die Basis der Grafik bilden die Kontrollkomponenten (Hauptroutine, Empfangsmo-dul, Versandmodul, Verarbeitungseinheit). In der Abbildung wurden diese auf das fürdie Kontrollstruktur wesentliche Verhalten reduziert. Die Transitionen der Automa-ten sind mit den Kommunikationssignalen für die Softwarekomponenten beschriftet.Hierbei wird unterschieden, ob auf ein Signal gewartet, oder ob es gesetzt wird. Diesist mit unterschiedlichen Farben gekennzeichnet. Schwarze Transitionsbeschriftungengeben an, welches Signal gesetzt sein muss, damit die Transition vollzogen wird. RoteTransitionsbeschriftungen geben das Signal an, das beim Durchlaufen gesetzt wird.Die in der Grafik gestrichelt dargestellten Pfeile zeigen an welcher Stelle das Setzeneines Signals eine Beeinflussung der Kontrollkomponente zur Folge hat. Zur besserenÜbersicht wurden die beeinflussten Komponenten durch die Farbe der Pfeile vonein-ander getrennt (siehe Legende der Grafik).

Nachfolgend wird die Bedeutung aller Signale beschrieben.

FIFO_IRQ: Dieser Interrupt wird von der externen Schnittstelle außerhalb des Con-trollers gesetzt. Er signalisiert, dass ein neues Datenpaket eingetroffen ist.

HW-Plugin_IRQ: Ein Hardware-Plugin signalisiert mit diesem Interrupt, dass dieBerechnung abgeschlossen ist und Daten zur Abholung bereit liegen. DiesesSignal stammt somit ebenfalls von einer Komponente außerhalb des Controllers.

fifo_IRQ_enable / fifo_IRQ_disable: Ist das Eintreffen eines Pakets signalisiertworden, wird der Interrupt der externen Schnittstelle abgeschaltet. Erst wenndas Paket vollständig vom Controller eingelesen worden ist, wird der Inter-rupt wieder aktiviert. Dieses Signal wird vom Empfangsmodul selbst und derVerarbeitungseinheit beeinflusst.

HW-Plugin_IRQ_enable / HW-Plugin_IRQ_disable: Es ist möglich den Interrupteines Hardware-Plugins zu aktivieren bzw. zu deaktivieren. Wird ein Hardware-Plugin gestartet, so wird auch der Interrupt aktiviert, so dass das Ende derBerechnung signalisiert werden kann. Tritt dieses Signal auf, wird der Interruptwieder deaktiviert und die entsprechende ISR initialisiert. Auf diese Weise ist dieUnterbrechung des Controllers nur zur Laufzeit des Hardware-Plugins möglich.

Softcore-Signal: Erkennt das Empfangsmodul, dass ein Paket für den NIOS II be-stimmt ist, wird dies der Verarbeitungseinheit mittels des Softcore-Signals kennt-lich gemacht. Dies betrifft sowohl Datenpakete, die für Software-Plugins be-stimmt sind, als auch alle Konfigurationspakete.

Hardware-Signal: Erkennt das Empfangsmodul, dass ein eingetroffenes Datenpaketfür ein Hardware-Plugin bestimmt ist, wird dies in der Regel sofort an die

133

6 Implementierung

Abbildung 6.19: Grafik zur Erläuterung der Kontrollstruktur

134


Hardware übertragen und das Plugin aktiviert. Sollte das Hardware-Plugin zudiesem Zeitpunkt mit der Berechnung eines anderen Datenpakets beschäftigtsein, wird mit dem Hardware-Signal der Verarbeitungseinheit gemeldet, dassdie Übertragung und das Starten des Plugins noch ansteht und durchgeführtwerden muss.

kritischer Abschnitt betreten / verlassen: Dies ist das Signal des gegenseitigen Aus-schlusses. Es wird benutzt um zu verhindern, dass die Übertragung von Datenan die externe Schnittstelle unterbrochen wird und Ergebnisdaten einer ande-ren Komponente, wie z.B. eines Softwareplugins, an die externe Schnittstellegesendet werden. Datenpakete würden verschachtelt werden, was zu verhin-dern ist. Überträgt beispielsweise die Verarbeitungseinheit ein Datenpaket ei-nes Software-Plugins an die externe Schnittstelle, signalisiert sie, dass sie sichim kritischen Abschnitt befindet. Fordert ein Hardware-Plugin eine Unterbre-chung an, erkennt das Versandmodul die Belegung des kritischen Abschnitts,und wartet mit der Behandlung des Hardware-Interrupts.

Hardware-Plugin-Signal: Befindet sich die Verarbeitungseinheit im kritischen Ab-schnitt, so kann mittels dieses Signals das Versandmodul mitteilen, dass es einDatenpaket nicht übertragen konnte. Es beauftragt die Verarbeitungseinheitdies nachzuholen sobald der kritische Abschnitt verlassen wurde.

Fehlercode Sollte eine Softwarekomponente einen Fehler erkennen, teilt sie dies mit-tels eines Fehlercodes mit. Dies führt zur Terminierung der betreffenden Softwa-rekomponente und somit des gesamten Controllers. Ein Fehler tritt bei einemfehlerhaften Paketziel auf und liegt somit in der Verantwortung des Entwickler.Des Weiteren wird eine Fehler erzeugt, wenn eine Speicheranforderung nichterfüllt werden konnte. Die korrekte Ausführung eines Plugins wäre in diesemFall nicht möglich. (siehe auch 6.8.5.3)

6.8.5.2 Kontrollkomponenten

In den folgenden Abschnitten wird die Umsetzung der aus dem Entwurf bekanntenAutomaten (Abschnitt 5.5.4.1) beschrieben. Zum besseren Verständnis werden dieAutomatengrafiken aus dem Entwurf wieder eingeführt und um Implementierungs-informationen erweitert. Die aus dem vorhergehenden Abschnitt bekannten Kom-munikationssignale werden an dieser Stelle noch einmal aufgegriffen und in ihrerimplementierten Form vorgestellt. Dies dient dem Verständnis der Umsetzung dernachfolgenden Automaten.Softcore-Signal: Das Softcore-Signal ist als Variable dataAvailable im Controller rea-

lisiert. Es wird immer in Verbindung mit der Variable confBit aus dem Paket-Header verwendet. Mittels dieser Variable wird unterschieden, ob ein Paket anden Softcore für das Konfigurationsmangement, oder ein Software-Plugin be-stimmt ist.

Software-Signal: Das Software-Signal ist eine Verknüpfung zweier Variablen. Es istgesetzt, wenn gilt: dataAvailable == 1 && confBit == 0. Damit wird daseingetroffene Paket eindeutig als ein Datenpaket für ein Software-Plugin iden-tifiziert

135

6 Implementierung

Konfigurationssignal: Das Konfigurationssignal ist eine Verknüpfung zweier Varia-blen. Es ist gesetzt, wenn gilt: dataAvailable == 1 &&. confBit == 1. Somitist das Konfigurationspaket als solches eindeutig identifiziert.

Hardware-Signal: Das Hardware-Signal ist als Variable hardwareDataAvailable imController umgesetzt. Trägt es den Wert ’1’, ist das Signal gesetzt.

Hardware-Plugin-Signal: Das Hardware-Plugin-Signal besitzt einen zusätzlichen In-formationsgehalt. Trägt es den Wert ’0’, ist es nicht gesetzt. Wird es von einemHardware-Plugin gesetzt, so trägt es den Wert der Basisadresse des Plugins, sodass die Verarbeitungseinheit die Anfrage der entsprechenden Hardwarekompo-nente behandeln kann. In Anlehnung an den Quellcode wird es im Folgendenmit toFifoTransferBase bezeichnet, da die Aufgabe darin besteht Ergebnisseeiner Hardwarekomponente an die Ausgangs-FIFO der externen Schnittstellezu transferieren.

Fehlercode: Ist der Wert ’0’, ist aktuell kein Fehler bekannt. Im Fehlerfall trägt dererrorCode die Fehlernummer als zusätzliche Information. (siehe auch 6.8.5.3)

kritischer Abschnitt betreten / verlassen: Die Variable criticalSection übernimmtdie Aufgabe den Zustand des kritischen Abschnitts zu signalisieren. Sie trägtden Wert ’1’ wenn der kritische Abschnitt betreten wurde, ’0’ wenn der kritischeAbschnitt akutell frei ist.

<Hardware-Name>_IRQ_<enable / disable>: Dieses Signal steht an dieser Stel-le stellvertretend für ein Signal an eine beliebige Hardware-Komponente. DiesesSignal bietet die Möglichkeit den Interrupt direkt in einer Hardware-Komponentezu aktivieren bzw. deaktivieren.

<Hardware-Name>_IRQ: Dieses Signal steht für das Auftreten des Interrupts einesHardware-Plugins oder der externen Schnittstelle.

Hauptroutine (Rahmenautomat)

Die Hauptroutine ist der aus dem Entwurf bekannte Rahmenautomat (Abschnitt 5.5.4.1).Diese Routine wird mit Start des Controllers ausgeführt. Seine Hauptaufgaben sinddie Initialisierung der Software-Routinen für die externen Schnitttstelle und der im-plementierten Plugins, die Initialisierung des Konfigurationsmanagement, das Startendes Verarbeitungsprozesses, sowie der Fehlerroutine im Fehlerfall.

136


Abbildung 6.20: Implementierung des MHA-FPGA-Rahmenautomaten

Zuerst werden alle Interrupts der entwickelten Hardware-Komponenten deakti-viert. Dieser Vorgang ist notwendig, um zu verhindern, dass von einer Hardware-Komponente ein Interrupt ausgelöst wird, bevor der Controller die entsprechendenServiceroutinen geladen und registriert hat. Des Weiteren wird in dieser Initialisie-rungsphase das Konfigurationsmanagement geladen. Nach dieser Initialisierungsphasestartet die Verarbeitungseinheit. Wird die Verarbeitungseinheit beendet, terminiertder Rahmenautomat, also der Controller, nachdem noch ein Fehlerpaket versendetwird. Der Kontrollfluss des Rahmenautomats wird in Abbildung 6.20 aufgezeigt. Diedazu verwendeten Basiskomponenten und Signale sind rot dargestellt.

handle_FIFO_isr (Empfangsmodul)

Das Empfangsmodul, beschrieben in Abschnitt 5.5.4.1 des Entwurfs, ist innerhalb desControllers als ISR realisiert. Wenn die externe Schnittstelle ein Datenpaket empfan-gen hat, fordert sie beim NIOS II eine Unterbrechung an. Der Prozessor lädt dieUnterbrechungroutine handle_FIFO_isr().

Abbildung 6.21: Implementierung des MHA-FPGA-Empfangsmoduls

137

6 Implementierung

Die Abarbeitung des Empfangsmoduls wird in Abbildung 6.21 aufgezeigt. Die dazuverwendeten Basiskomponenten und Signale sind rot dargestellt.

handle_FFT_isr (Versandautomat)

Der Versandautomat ist ebenfalls eine ISR. Allerdings muss jedes Hardware-Plugineine eigene ISR besitzen und somit auch eine eigene Instanz dieses Versandautomats.Dies ist darin begründet, dass jede Hardware-Komponente einen eigenen Interruptzugewiesen bekommt. Des Weiteren ermöglicht es dem Controller die Interrupts mitunterschiedlichen Prioritäten zu behandeln. An dieser Stelle wird die Standardverar-beitung geschildert.

Abbildung 6.22: Implementierung des MHA-FPGA-Versandmodule

Die genaue Abarbeitung des Versandmoduls wird in Abbildung 6.22 aufgezeigt. Diedazu verwendeten Basiskomponenten und Signale sind rot dargestellt. Durch Auftre-ten des Interrupts wird das entsprechende Versandmodul ausgeführt. Grundsätzlichwird zuerst der Interrupt der Komponente deaktiviert. Ist der kritische Abschnittnicht belegt, wird mit der Funktion hardwareToFifoTransfer() das Datenpaket andie externe Schnittstelle versendet. Sollte sich der Automat im kritischen Abschnittbefinden, wird die Variable toFifoTransferBase mit der Adresse der entsprechendenHardwarekomponente gesetzt.

Verarbeitungseinheit

Die Verarbeitungseinheit ist eine Routine, die als Endlosschleife implementiert ist(mainOperatingSystemLoop()). Sie terminiert nur im Fehlerfall und führt damitzur Beendigung des Controllers. Die Hauptaufgaben sind das Speichern von Konfi-gurationen, das Verarbeiten von Software-Plugins und das Abarbeiten anstehenderAufgaben, die von der handle_FIFO_isr() oder handle_<HW-Plugin>_isr() nichtdirekt bearbeitet werden konnten.

138


Abbildung 6.23: Implementierung der MHA-FPGA-Verarbeitungseinheit

Die genaue Funktionsweise der Verarbeitungseinheit wird in Abbildung 6.21 aufge-zeigt. Die dazu verwendeten Basiskomponenten und Signale sind rot dargestellt.

6.8.5.3 Basiskomponenten

Die hier vorgestellten Komponenten sind Subsysteme des Controllers. Sie überneh-men eine oder mehrere Funktionen, die zu Funktionssammlungen zusammen gefasstwurden.

Analyse des Paket-HeadersDie Interpretation des Paket-Headers wird vom Empfangsmodul mit der FunktionparseHeader durchgeführt.

Name: parseHeader

Beschreibung: Extraktion der aufgelisteten Informationen aus dem Paket-Header

Parameter: Der aus der externen Schnittstelle gelesene Paket-Header imFormat: unsigned int.

Rückgabewert: struct header

Definition der Header-Strukturheader.pluginID (Format: unsigned int)header.instanceID (Format: unsigned int)header.confBit (Format: unsigned short)header.packageLength (Format: unsigned int)

KonfigurationsmanagementDas Konfigurationsmanagement ist in einer C-Datei, der pluginStorage zusammen-gefasst. Es stellt alle Funktionen bereit, die zur Verwaltung der Konfigurationen be-nötigt werden. Im Folgenden wird die Arbeitsweise der Funktionen dargestellt. Als

139

6 Implementierung

Speicherstruktur werden verkettete Listen verwendet, die dynamisch erweiterbar sind.Um das Suchen von Einträgen zu optimieren, werden globale Zeiger verwendet, dieimmer auf das zuletzt aufgerufene Objekt zeigen. Wie im Entwurf 5.5.4.2 beschrie-ben, muss initial jedem im System vorhandenen Plugin eine Plugin-ID zugewiesenwerden. Dies erfolgt über die Funktion addPlugin, deren Funktion in Tabelle 6.8.5.3und im anschießenden Text näher erläutert ist.

Name: addPlugin

Beschreibung: Registrierung einer Plugin-ID und Zuweisung zu einem Pluginmit baseAddress

Parameter: pluginID, baseAddress, numberOfParameters: unsigned int.Rückgabewert: Fehlercode

Die Basisadresse baseAddress wird vom SOPC Builder generiert und ist einer im Sys-tem vorhandenen Hardwarekomponente wie z.B. dem wave2spec-Plugins zugewiesen.Soll das Ziel ein Software-Plugin sein, so muss die Basisadresse ’0’ verwendet werden.Konflikte mit einer Hardware-Plugin-Komponente können nicht auftreten, da der imSystem verwendete Speicher die Adresse ’0’ beansprucht. Wird die Funktion mit einerPlugin-ID aufgerufen, die bereits vorhanden ist, so wird ein Fehlercode zurückgeben.Desweiteren wird ein Fehlercode auch zurückgegeben, wenn nicht genügend Speicherzur Verfügung steht. Die addPlugin-Funktion erwartet des Weiteren die Anzahl derParamater des Plugins. Da sich die Anzahl der Parameter während des laufendenBetriebs nicht ändert, wird diese in der Initialisierungsphase festgelegt.Nach der initialen Phase erfolgt die eigentliche Abarbeitung. Diese besteht darin Kon-figurationen zu speichern und abzurufen. Zum Speichern einer Konfiguration wird dieFunktion callInstance aufgerufen. Für die korrekte Funktionsweise muss jedoch sicher-gestellt sein, dass der globale Plugin-ID-Zeiger auf das richtige Plugin zeigt. Dies wirddurch die Funktion pluginExists sichergestellt, deren Funktionsweise vorangehend er-läutert wird.

Name: pluginExists

Beschreibung: Setzt den Plugin-ID-ZeigerParameter: Plugin-IDRückgabewert: Fehlercodeunsigned short

Der Funktionsaufruf bewirkt, dass in der verketten Liste die entsprechende Plugin-ID gesucht wird. Ist die Plugin-ID vorhanden, so bleibt der globale Plugin-ID-Zeigerfür die nachfolgende Funktion gesetzt. Ist die Plugin-ID nicht vorhanden, so wirdein Fehlercode zurück gegeben. Nach dem erfogreichen Ausführen der pluginExistsFunktion ist die Vorbedingung für die Funktion callInstance erfüllt.

Name: callInstance

Beschreibung: Fügt der aktuellen Plugin-ID eine Instanz-ID zuParameter: instanceIDRückgabewert: Fehlercode: unsigned short

callInstance fügt der aktuellen Plugin-ID eine Instanz-ID hinzu, wenn diese nochnicht registriert wurde. Andernfalls wird der globale Plugin Zeiger für nachfolgende

140


Funktionen gesetzt. Die Funktion gibt einen Fehlercode zurück, wenn nicht genügendSpeicher zur Verfügung steht. Die Funktion callPugin erfüllt die Vorbedingung fürdie Funktion writeConfig, die im Folgenden erklärt wird. writeConfig speichert dieParameterwerte für die aktuelle Instanz-ID.

Name: writeConfig

Beschreibung: Speichert die Parameterwerte für die aktuelle Plugin-IDParameter: value floatRückgabewert: Fehlercode unsigned short

Die Funktion erwartet immer, dass sie genau für die Anzahl an Parametern aufge-rufen wird, die das aktuelle Plugin hat, da die Speicherstruktur der Parameter alsRingpuffer organisiert ist. Beim erstmaligen Aufruf wird der Speicher für die entspre-chende Anzahl an Parametern angelegt. Sie gibt einen Fehlercode zurück, wenn nichtgenügend Speicher zur Verfügung steht. Werden die Parameterwerte ein weiteres malgeändert, so werden die alten Werte überschrieben.

Die folgenden Funktionen dienen zum Abrufen von Konfigurationen. Tritt ein Da-tenpaket ein, so wird zunächst getestet, ob das Ziel-Plugin existiert. Dies wird durchdie Funktion plugInstExists bereitgestellt. Diese Funktion überprüft auch, ob die ge-suchte Instanz-ID existiert. Durch den Test zeigen nach dem erfolgreichen Aufruf dieglobalen Zeiger auf die Zielkonfiguration.

Name: plugInstExists

Beschreibung: Setzen der globalen Zeiger auf die gesuchte Konfiguration.Parameter: Paket-HeaderRückgabewert: Fehlercode unsigned short

Die Funktion getParameter_ptr, die zum Abrufen eines Parameters dient, kann nachdem erfolgreichen Ausführen der plugInstExists Funktion ausgeführt werden. DieseFunktion erwartet, dass sie genau für die Anzahl an Parametern aufgerufen wird. Sieliefert beim erstmaligen Aufruf den Zeiger auf den ersten Parameterwert. Der zweiteAufruf liefert den Zeiger auf den zweiten Parameterwert. Nach dem letzten Aufrufzeigt der Zeiger wieder auf den ersten Wert.

Name: getParameter_ptr

Beschreibung: Liefert Zeiger auf ParameterwertParameter: keinerRückgabewert: Parameterwert* float

Makro-Funktionen

Die Makro-Funktionen sind eine Sammlung von Funktionen, die häufig auftretendeProgrammsequenzen zusammenfassen sollen. Dies soll hauptsächlich die Entwicklungvon Plugins vereinfachen und mögliche Fehlerquellen ausschließen.

141

6 Implementierung

Name: readStatus_reg

Beschreibung: Mit diesem Befehl kann der aktuelle Status aus dem Statusre-gister eines Hardware-Plugins ausgelesen werden.

Vorbedingung: Ausführung der Funktion plugInstExistsParameter: keineRückgabewert: Wert des Statusregisters als unsigned int

Name: startHardware

Beschreibung: Weist ein Hardware-Plugin an, mit der Berechnung zu beginnen.Vorbedingung: Laden der Konfiguration,

Laden der Berechnungsdaten,Ausführen der Funktion plugInstExists

Parameter: keineRückgabewert: keine

Name: clearInterrupt

Beschreibung: Weist das Hardware-Plugin an, den Interrupt zurückzusetzenund abzuschalten

Vorbedingung: keineParameter: Basisadresse des Hardware-PluginsRückgabewert: keine

Name: hardwareBusy

Beschreibung: Überprüft anhand des Statusregisters eines Hardware-Plugins,ob es zum gegenwärtigen Zeitpunkt beschäftigt ist

Vorbedingung: Ausführung der Funktion plugInstExistsParameter: keineRückgabewert: ’1’ falls beschäftigt, ’0’ sonst

Name: sendConfiguration

Beschreibung: Überprüft, ob ein Hardware-Plugin mit einer anderen Konfigu-ration geladen werden muss, lädt dann die Konfiguration einerInstanz in die Komponente und trägt die Instanz-ID im Status-register ein

Vorbedingung: Ausführung der Funktion plugInstExistsParameter: Struktur des Paket-HeadersRückgabewert: keine

FehlerbehandlungDer Controller besitzt eine globale Variable errorCode. Im normalen Betrieb gilterrorCode=0. Im Fehlerfall kann eine Softwarekomponente diesen Wert auf einenspezifischen Fehlercode setzten. In der Fehlerbehandlung wird dieser Code aufgegrif-fen und innerhalb einer Tabelle die entsprechende Fehlermeldung gesucht. Mit diesenInformationen wird ein Fehlerpaket verschickt.

142


Name: sendException

Beschreibung: Versendet das Fehlerpaket inklusive der FehlermeldungParameter: Fehlercode (Format: unsigned int)

Nachfolgend werden die vom System benutzen Fehlercodes und ihre Bedeutung inTabelle 6.12 geschildert.

Fehlercode Fehlerbeschreibung1 Initialisierungsfehler. Das Anlegen eines Plugins ist nicht mög-

lich. Kein freier Speicher zur VerfügungQuelle: addHardwarePlugin

2 Es wurde versucht ein Plugin mit einer ID zu initialisieren, diebereits vergeben istQuelle: addHardwarePlugin

3 Zu einer abgefragten Plugin-ID ist kein Plugin registriertQuelle: pluginExist

4 Nicht genügend Speicherplatz verfügbar, um eine Plugin-Konfiguration zu speichernQuelle: addInstance

5 Nicht genügend Speicherplatz verfügbar, um einen Plugin-Parameter zu speichernQuelle: writeConfig

6 zur Zeit nicht vergeben7 Zu einer abgefragten Plugin-ID ist kein Plugin registriert

Quelle: plugInstExists8 Zu einer abgefragten Instanz-ID ist keine Plugininstanz regis-

triertQuelle: plugInstExists

9 Der Aufruf eines Software-Plugins ist gescheitertQuelle: callPlugin

10 unerwarteter Fehlerab 11 frei verwendbar vom Plugin-Entwickler

Tabelle 6.12: Auflistung der Fehlercodes des MHA-FPGA

Plugin-Steuerung

Die Basiskomponenten die die Plugin-Steuerung betreffen, wurden implementiert,um dem Plugin-Entwickler eine komfortable Entwicklungsplattform zur Verfügung zustellen. Des Weiteren dienen sie der Stabilität des Controllers, da diese Funktionendie entwickelten Sicherheitskonzepte berücksichtigen.

143

6 Implementierung

Name: initPlugins

Beschreibung: Initialisierung der Plugins.Zu registrierende Angaben eines Plugins:Plugin-IDAnzahl der KonfigurationsparameterBasisadresse falls Hardware-Plugins’0’ falls Software-Plugin

Rückgabewert: Fehlercode, wenn die Registrierung fehlschlägt. ’0’ sonst

Name: callPlugin

Beschreibung: Aufruf der Software-Plugins mittels einer case-AnweisungParameter: Konfiguration der aufzurufenden Plugin-Instanz (Format:

float[])Daten des aufzurufenden Plugins (Format: float[])

Rückgabewert: Fehlercode der Funktion, oder der eines Software-Plugins. ’0’sonst

Name: sendSoftwareData

Beschreibung: Mit dieser Funktion werden die Ergebnisse eines Software-Plugins verschickt. Diese Funktion ist in einem Software-Pluginzu benutzen, da in dieser Versandroutine Sicherheitsaspekte wiez.B. der kritische Abschnitt Anwendung finden.

Vorbedingung: keineParameter: Paket-Header (Format: struct header),

Datenpaket (Format: float[]),Paketlänge (Format: unsigned int)

Rückgabewert: keine

Name: hardwareToFifoTransfer

Beschreibung: Mit dieser Funktion werden Daten aus einem Hardware-Pluginabgeholt, in ein Datenpaket mit Paket-Header verpackt und un-ter Berücksichtigung des kritischen Abschnittes an die externeSchnittstelle übertragen.

Vorbedingung: Hardware-Plugin hat die Beendigung seiner Berechnung gemel-det

Parameter: Basisadresse des Hardware-PluginsRückgabewert: keine

6.8.6 Bootloader

Um den kompilierten C-Code des Controllers auf den MHA-FPGA zu laden und des-sen Ausführung zu starten, wird ein Bootloader verwendet. Dies geschieht ausschließ-lich aus Platz- und Komfortgründen. Der Quellcode des Controllers ist in kompilierterForm bereits ca. 50 kB groß. Addiert werden muss die Größe jedes implementierten

144


Software-Plugins. Um ohne Bootloader auszukommen, müsste dieser Programmcodeinnerhalb eines ROMs mit mindesten 50 kB Kapazität auf dem FPGA untergebrachtwerden. ROMs benötigen Ressourcen des FPGAs, die durch die implementiertenHardwareplugins und des Controllers als quantitativ kritisch zu betrachten sind. Dererste Vorteil ist, dass man die benötigte ROM-Größe durch Verwendung des Bootloa-ders auf ca. 5 kB verringern kann. Der Bootloader transferiert das Programm über dieserielle Schnittstelle vom Industrie-PC in den Hauptspeicher. Der zweite Vorteil in derVerwendung eines Bootloaders liegt in der einfachen Handhabung für einen Plugin-Entwickler. Wird ein Software-Plugin entwickelt, so kann das Programm direkt aufdem Entwicklungsystem kompiliert werden und im Dateisystem des Industrie-PC er-setzt werden. Bei Neustart des Industrie-PCs wird das Software-Plugin automatischin den MHA-FPGA geladen. Die genaue Funktionsweise des Bootloaders ist in Ab-schnitt 6.6 beschrieben.

6.8.7 Hardware-PluginsDieser Abschnitt beschreibt die Implementierung der unter 5.5.5 entworfenen Hardware-Plugins „spec2wave“ und „wave2spec“.

6.8.7.1 Gesamtsystem wave2spec/spec2wave

Einleitend wird in Abbildung 6.24 der Datenfluss durch die implementierten Ein-zelkomponenten des wave2spec- bzw. spec2wave-Plugins aufgezeigt. Die vorgestellteKomponente kann wahlweise eine wave2spec-Berechnung oder eine spec2wave-Berech-nung durchführen. Die in Abbildung 6.24 aufgezeigte Komponente HANNING/HRAMPSimplementiert die im Entwurf vorgestellten Funktionen Hanningfunktion und Han-ningrampenfunktion. Nähere Informationen werden im Abschnitt 6.8.7.3 vorgestellt.Die Komponente FFT/iFFT implementiert die Fast Fourier Transformation und des-sen Inverse. Der Eingangspuffer und Ausgangspuffer wird jeweils durch eine FIFOimplementiert, die hier als INPUT FIFO und OUTPUT FIFO bezeichnet ist. DesWeiteren sind die im Entwurf vorgestellten Funktionen Windowing und Overlap-Add, die in der Abbildung als WINDOWING und ADD dargestellt sind, zu sehen.Die verwendeten Multiplexer (MUX) und Demultiplexer (DMUX) werden durch denParameter ifft gesteuert, welcher die durchzuführende Funktion innerhalb der Kom-ponente bestimmt. Die Addresszuweisung der Parameter ist in Tabelle 6.13 dargestelltund im nachfolgenden Text näher erörtert.In dem in Abbildung 6.24 dargestellten Datenfluss repräsentieren die roten Pfeile denDatenfluss bei Durchführung einer iFFT, die schwarzen Pfeile den bei einer FFT.

Adresse Name Bedeutung5 fftlen Anzahl der Punkte mit der die Komponente ausgeführt

wird6 wndlen Breite des Fensters7 wndpos_l linke Positionsangabe des Fenstrs8 wndpos_r rechte Positionsangabe des Fensters

Tabelle 6.13: wave2spec- / spec2wave-Parameteradressierung

145

6 Implementierung

Adresse Name Bedeutung9 hstlen Anzahl der aus der History zu verwendenden Daten10 blksz Blockgröße11 ifft Art der Berechnung (wave2spec oder spec2wave)

Tabelle 6.13: wave2spec- / spec2wave-Parameteradressierung

Abbildung 6.24: Datenfluss für FFT und iFFT

Alle Parameter der Schnittstelle wurden laut Spezifikation (Abschnitt 6.8.4.2) im-plementiert. Des Weiteren sind die im Entwurf vorgestellten Parameter entsprechendder Tabelle 6.13 adressierbar. Ein weiterer Parameter ifft wurde für die durchzufüh-rende Funktion der Komponente eingeführt.

146


6.8.7.2 Windowing

Dieser Abschnitt stellt die Implementierung der Windowing-Komponente vor. Ein-leitend wird der Aufbau beschrieben, gefolgt von dessen expliziten Umsetzung. DerAbschnitt schließt mit der Integration in das wave2spec-Plugin ab.

Aufbau der Komponente

Die einzelnen Subkomponenten werden im Folgenden beschrieben.

WD_Ctrl ist der Controller, der die Lese- und Schreibzugriffe auf den History-Speicher und die Adressierung koordiniert. Er kommuniziert über die Steue-rungsignale der Komponente mit dem Controller des wave2spec-Plugins.

WRAddrCounter inkrementiert sukzessiv die Schreibadresse des Speichers.

RDAddrCounter inkrementiert die Leseadresse. Geladen wird die erste Adresse deszu erzeugenden Fensters.

HistoryRAM ist der als Ringspeicher konzipierte RAM, der die History-Daten auf-nimmt.

Implementierung der Subkomponenten

Für die Realisierung der einzelnen Subkomponenten wurde, mit Ausnahme des Con-trollers, auf Megafunctions der Altera Quartus Software zurückgegriffen. Tabelle 6.14zeigt, welche Megafunction für welche Subkomponente verwendet wurde.

Subkomponente Altera Megafunction BeschreibungWRAddrCounter LPM_COUNTER 9-Bit Zähler, nur Inkrement, Clock enable,

asynchrones clearRDAddrCounter LPM_COUNTER wie WRAddrCounter + Load-Fkt.

HistoryRAM LPM_RAM_DP Dual-Port RAM mit einem Lese- und ei-nem Schreib-Port, Kapazität 512 x 32 Bit,asynchrones clear

Tabelle 6.14: Altera Megafunctions in der Windowing-Komponente

Der Controller WD_Ctrl wurde in VHDL realisiert und enthält die Beschreibungender in 5.21 vorgestellen Kontrollautomaten. Es finden sich zusätzliche Zustände in derImplementierung, um das Zeitverhalten an die Eigenschaften der anderen Subkom-ponenten anzupassen. Des Weiteren wird das Verhalten bei einem Reset beschrieben.

Implementierte Schnittstelle

Neben den in 5.5.5.1 erläuterten Ein- und Ausgängen verfügt die implementierte Kom-ponente über weitere Eingänge für des Taktsignal und das Resetsignal. Tabelle 6.15zeigt die vollständige Übersicht über alle Ein- und Ausgänge der finalen VHDL-Komponente.

147

6 Implementierung

Port Typ Beschreibungclk IN STD_LOGIC Eingang für das Taktsignalrst IN STD_LOGIC Eingang für das Resetsignalwrite IN STD_LOGIC Schreibanfrage an die Komponen-

tefft_ready IN STD_LOGIC Verfügbarkeit der Folgekompo-

nentedata_in IN STD_LOGIC_VECTOR(31:0) Dateneingang für Blockdatenfrsize IN STD_LOGIC_VECTOR(7:0) Eingang für die Blockgrößehistory IN STD_LOGIC_VECTOR(8:0) Eingang für die Länge der Historybusy OUT STD_LOGIC Verfügbarkeit der Komponentewrite_out OUT STD_LOGIC Schreibanfrage an die Folgekom-

ponenteq OUT STD_LOGIC_VECTOR(31:0) Datenausgang der Komponente

Tabelle 6.15: Implementierte Schnittstelle der Windowing-Komponente

Integraton in das wave2spec-PluginDie Windowing-Komponente muss für jeden Kanal einmal instanziiert sein. Werdenbeispielsweise zwei wave2spec-Plugins im MHA verwendet, so müssen zwei mal ’An-zahl der Kanäle’ Windowing-Komponenten instanziiert sein. Die Verschaltung derWindowing-Instanzen erfolgt über Multiplexer und Demultiplexer, welche über denParameter Instanz-ID gesteuert werden. Abbildung 6.25 zeigt den Aufbau der mitMultiplexer und Demultiplexer verschalteten Windowing-Komponente.

Abbildung 6.25: Datenfluss der Windowing-Komponente

6.8.7.3 Hanning-Funktion

Die im Entwurf beschriebene Umsetzung der Hanningfunktion verlangt eine Spei-cherung der Funktionswerte in einem ROM. Die Hanning-Komponente multipliziertdie Eingangsdaten mit einem bestimmten Wert aus diesem ROM. Auch hier wur-den Megafunctions von Altera verwendet, die instanziiert und miteinander verschal-

148


tet wurden. Die im Entwurf aufgezeigte Skizze des Hanning-Blocks wurde zu einemBlockschaltbild komplettiert (siehe: Abbildung 6.26).

Abbildung 6.26: Blockschaltbild der Hanning-Komponente

Megafunctions von Altera

In Tabelle 6.16 sind alle Instanzen der Megafunctions der Hanning-Komponente auf-geführt.Die Adressen für den Speicher werden durch die Counter-Komponente erzeugt. Diesemuss zum Startzeitpunkt der Berechnungen einen initialen Wert bekommen, der ab-hängig von dem Parameter wndlen der Komponente ist. Da die Fenstergröße M vonder Fragmentgröße P abhängt (M = 2P oder M = 4P ) und die Fragmentgröße Pgrundsätzlich die Werte 16, 32, 64 oder 128 annimmt, sind im ROM die Werte fürfolgenden Fenstergrößen abgelegt: 32, 64, 128, 256 und 512.

Das ROM der Hanning-Komponente ist somit wie in Abbildung 6.27 aufgebaut.

Subkomponente Altera Megafunction Beschreibungcounter_0 LPM_COUNTER 9-Bit Zähler, nur Inkrement,

Load-EingangROM_0 LPM_ROM ROM mit einer Kapazität von

992x32BitFP_MULT_0 ALTFP_MULT Fließkomma-Multiplizierer, single

Precision, dedizierte HW, einfacheFunktionalität

Tabelle 6.16: In der Hanning-Komponente verwendete Altera Megafunctions

149

6 Implementierung

Abbildung 6.27: ROM-Aufbau der Hanning-Komponente

Prozesse in der Hanning-KomponenteDie Hanning-Komponente besitzt drei Prozesse, die an Abbildung 6.28 dargestelltsind. Der im linken Teil dargestellte Prozess ist für das Setzen des Counters zuständig.Im zweiten Prozess wird der benötigte Wert aus dem ROM an den Eingang desMultiplizierers gelegt. Der im rechten Teil dargestellte Prozess setzt das ready-Signalund zeigt damit das Anliegen des Ergebnisses am Ausgang an. Die Komponente istpipeline-fähig. Sobald am Ausgang ready der Wert Null anliegt, ist die Berechnungabgeschlossen.

Abbildung 6.28: Aufbau der Prozesse innerhalb der Hanning-Komponente

150


Hanning-Rampen

Die Funktionswerte der Hanning-Rampenfunktion liegen oberhalb der Hanning-Funktionswertedes bereits beschriebenen ROMS.

6.8.7.4 FFT/iFFT

Nachfolgend wird die Implementierung der für die FFT benötigten Komponenten be-schrieben. Begonnen wird mit der Butterfly-Komponente, die als elementare Einheitder FFT/iFFT zu bezeichnen ist.

Butterfly-Komponente

Abbildung 6.29: Blockschaltbild der Butterfly-Komponente

Das Blockschaltbild der Butterfly-Komponente ist in Abbildung 6.29 dargestellt.Die Eingänge dataa_imag und datab_imag nehmen die imaginären Anteile der Be-rechnung entgegen, die Eingänge dataa_real und datab_real deren realen Anteile.Des Weiteren stehen Eingänge für die zu verwendenden Drehfaktoren zur Verfügung.Diese sind mit dataw_imag und dataw_real bezeichnet. Über den Eingang functionwird die Durchführung einer even/odd-Dekomposition bestimmt. Das enable signa-lisiert den Start der Berechnung. Die Ausgänge dataa_new_real, datab_new_real,dataa_new_imag und datab_new_imag liefern die Ergebnisse der Berechnung. Kom-plexe Operationen werden in der Butterfly aufgeteilt, so dass jeweils eine Operationfür den realen Anteil und eine Operation für der imaginären Anteil durchgeführtwird. Dies gilt für Multiplikationen als auch für Additionen. Bei Durchführung einereven/odd Dekomposition müssen die geraden Werte an den dataa-Eingängen und dieungeraden Werte an den datab-Eingängen angelegt werden. Die erzielte Gesamtver-zögerung der Komponente beträgt 15 Takte.Die Prozesse der Butterfly-Komponente sind in Abbildung 6.30 dargestellt. Der ers-te Prozess führt die Multiplikation der Eingangsdaten datab mit den entsprechendangelegten Drehfaktoren an den Eingängen dataw durch. Der zweite Prozess führt

151

6 Implementierung

die Addition und Subtraktion mit den Produkten der von Prozess Eins berechnetenDaten durch. Diese beiden Prozesse sind in der linken Spalte der Abbildung darge-stellt. Der dritte, in der Mitte des Bildes gezeigte Prozess führt die letzte Additionder Butterfly-Komponente durch. Dieser addiert bzw. subtrahiert die Werte der da-taa Eingänge und die Ergebnisse aus Prozess zwei. Der im rechten Teil des Bildesdargestellte Prozess ist für das Anlegen der Werte an den Ausgängen verantwortlich.

Abbildung 6.30: Aufbau der Prozesse innerhalb der Butterfly-Komponente

Zur Realisierung der Butterfly-Komponente wurden Megacores von Altera benutzt.Die verwendeten Komponenten sind der Tabelle 6.17 zu entnehmen.

Subkomponente Altera Megafunction BeschreibungFP_MULT_0 ALTFP_MULT Fließkomma-Multiplizierer, single

Precision, dedizierte HW, einfacheFunktionalität

FP_ADDER ALTFP_ADD_SUB Fließkomma-Addierer, single Pre-cision, nicht auf dedizierter Hard-ware möglich, einfache Funktiona-lität

FP_MIN ALTFP_ADD_SUB Fließkomma-Subtrahierer, singlePrecision, nicht auf dedizierterHardware möglich, einfache Funk-tionalität

Tabelle 6.17: In der Butterfly-Komponente verwendete Altera Megafunctions

152


Implementierung der FFT

Im Folgenden wir die konkrete Implementierung der FFT Komponente beschrieben,die auch für die IFFT maßgeblich ist. Abbildung 6.31 zeigt das Blockschaltbild derFFT/iFFT -Komponente. Über den Eingang enable wird die Ausführung der Kom-ponente gesteuert. Der load-Eingang dient dazu die am Dateneingang data_in anlie-genden Werte zu übernehmen. Die Eingänge left_window und right_window werdenfür das Zero Padding benötigt. Der fft_size-Eingang spezifiziert die Anzahl an Punk-ten mit der die FFT/iFFT ausgeführt werden soll. Über den Eingang hold wird dasSchreiben der Ergebnisse verhindert. Dieses wird für den Fall das die Folgekompo-nente im wave2spec/spec2wave Plugin nicht bereit ist benötigt. Des Weiteren stehtnoch der Eingang ifft bereit, um eine FFT- oder iFFT-Berechnung zu spezifizieren.Über dem Ausgang complete wird der Abschluss der Berechnung signalisiert. Derready-Ausgang zeigt an, ob die Komponente gerade eine Berechnung durchführt odernicht. Die Ergebnisse der Transformation liegen am data_out-Ausgang an.

Abbildung 6.31: Blockschaltbild der FFT-Komponente

Prozesse der FFT

Dieser Abschnitt beschreibt die Prozesse der FFT/iFFT -Komponente, die in Ab-bildung 6.32 dargestellt sind. Der in der linken Hälfte dargestellte Prozess ist fürdas Laden der zu berechnenden Werte zuständig, so wie auch für die Ausgabe derErgebnisse. Der andere Prozess steuert die Berechnungen in Abhängigkeit der durch-zuführenden Punkte-FFT/iFFT.

Zwei weitere Prozesse steuern den Zugriff auf die RAM-Bausteine und die Counter.In Abbildung 6.33 ist die Funktionsweise der Prozesse dargestellt.

153

6 Implementierung

Abbildung 6.32: Kontrollprozesse der FFT-Komponente

Abbildung 6.33: Prozesse für die Ansteuerung der Counter und der RAM-Bausteineder FFT-Komponente

Im Zustand 01 (compute data) wechselt der Schreib- und Lese-Vorgang auf denRAM-Bausteinen von Stage zur Stage. Zunächst wird aus RAM1 gelesen und in

154


RAM2 geschrieben. In der folgenden Stage ist dieser Prozess umgekehrt. Wie imEntwurf bereits angedeutet, müssen innerhalb eines Taktes gleichzeitig vier Zugriffeauf die Speicher möglich sein, je zwei Lese- und zwei Schreib-Operationen. Dies konntedurch die Verwendung eines zweiten Dual-Port-RAMs erreicht werden.

Zwei Prozesse sind dafür zuständig die Butterfly-Komponente zu steuern. Die imfolgenden beschriebenen Prozesse führen das Anlegen der Daten an die Butterfly-Eingänge aus. Sie sind nur dann aktiv, wenn der interne Zustand compute data er-reicht ist. Der erste Prozess legt die Werte von DATA_B und DATA_W an denEingang. Der zweite Prozess wird genau 15 Takte später aktiv um Werte an denDATA_A-Eingang der Butterfly-Komponente anzulegen.Wird der Zustand transport data erreicht, so werden die Daten aus dem Speicher anden Ausgang der FFT gelegt. Falls am hold-Eingang eine Eins anliegt, wartet dieFFT mit dem Anlegen der Ergebnisse an den Ausgang. Sobald hold auf den WertNull gesetzt wird, werden alle Ergebnisse Takt für Takt an den Ausgang gelegt.

Tabelle 6.18 zeigt alle Komponenten, die bei der Implementierung der FFT ver-wendet wurden.

Subkomponente Altera Megafunction BeschreibungButterfly - Die im Abschnitt 6.8.7.4 vorge-

stellte Lösung für eine pipeline-fähige Butterfly

RAM Dual-port RAM 2x Dual-Port RAM mit einer Ka-pazität von 512x64 bit,

Counter LPM_COUNTER 4x 12-Bit Zähler, nur Inkrement,Load-Eingang

ROM LPM_ROM ROM mit einer Kapazität von256x64 bit (Enthält vorausberech-nete Werte für einen 256-Punkte-Einheitskreis)

ADRESS_ROM_W LPM_ROM ROM mit einer Kapazität von4092x8 bit (Adressen für dasROM mit den Drehfaktoren)

ADRESS_ROM LPM_ROM 2x ROM mit einer Kapazität von4092x8 bit (Adressen für die jewei-ligen FFTs für den Wert A)

ADRESS_ROM_B LPM_ROM 2x ROM mit einer Kapazität von4092x8 bit (Adressen für die jewei-ligen FFTs für den Wert B)

Tabelle 6.18: In der Instanzen in der FFT-Komponente

Aufbau der ROMs der FFTDie FFT beinhaltet insgesamt 6 ROMs. IM ersten ROM sind die 256 Drehfaktoren ab-gelegt. Vier ROMs beinhalten die Adressen für die Ansteuerung der RAM-Bausteine.Das übrige ROM beinhaltet die notwendigen Adressen der im ersten ROM abgelegtenDrehfaktoren. Es können folgende FFT/iFFT-Berechnungen durchgeführt werden:

155

6 Implementierung

• 32-Punkte FFT

• 64-Punkte FFT

• 128-Punkte FFT

• 256-Punkte FFT

• 512-Punkte FFT

Dadurch dass eine Speicherzelle eines RAMs sowohl die reellen als auch die imaginärenBestandteile eines komplexen Wertes speichern, ist es möglich, durch drei Leseopera-tionen die notwendigen Werte für die Butterfly-Operation auszulesen. Weitere zweiSchreibvorgänge schließen die Butterfly-Operation ab. Wie die Hanning-Komponente,arbeitet auch die FFT mit Offsets. Ab einem bestimmten Speicherbereich sind sequen-tiell die Adressen aller Stages für eine 512-Punkte FFT abgelegt, danach die Wertefür eine 256-Punkte FFT usw.. Die Operation für die Even-/Odd-Dekomposition istbereits im ROM berücksichtigt und muss nicht durch eine spezielle Logik beeinflusstwerden.

Implementierung der inversen FFTDie Berechnung der inversen FFT ist analog zur Berechnung einer FFT. Es werdenlediglich andere Werte für die Drehfaktoren verwendet. Eine Beschreibung diesesVerfahrens kann [57] entnommen werden.

6.8.7.5 Overlap-Add

Aufbau der KomponenteEs folgt eine Kurzbeschreibung der Elemente, wie sie in der Implementierung ver-wendet wurden.

OLA_Ctrl ist der Controller, der die Lese- und Schreibzugriffe auf den Fensterspei-cher und die Adressierung koordiniert. Er kommuniziert über die Steuerungsi-gnale der Komponente mit dem Controller des spec2wave-Plugins.

WRAddrCounter inkrementiert die Schreibadresse und wird mit der Startadresse desaktuellen Fensters initialisiert.

RDAddrCounter inkrementiert die Leseadresse und wird mit der Startadresse desaktuellen Blocks initialisiert.

WindowRAM ist der als Ringspeicher konzipierte RAM, der die aufaddierten Fens-terdaten speichert.

Implementierung der SubkomponentenTabelle 6.19 beschreibt, mit welchen Altera Megafunctions die jeweiligen Subkompo-nenten implementiert wurden. Ähnlich wie bei der Windowing-Komponente beinhal-tet auch die VHDL-Beschreibung des Controllers OLA_Ctrl die Kontrollautomaten,wie sie in 5.40 dargestellt sind. Analog zur Windowing-Implementierung musstenZustände auf Grund des Zeitverhaltens hinzugefügt werden. Ebenfalls wurde dasReset-Verhalten implementiert.

156


Subkomponente Altera Megafunction BeschreibungWRAddrCounter LPM_COUNTER 9-Bit-Zähler, nur Inkrement, Clock enable,

asynchrones clear, Load-Fkt.RDAddrCounter LPM_COUNTER wie WRAddrCounter

WindowRAM LPM_RAM_DP Dual-Port-RAM mit einem Lese- und ei-nem Schreib-Port, Kapazität 512x32Bit,asynchrones clear

FP_ADD ALTFP_ADD_SUB 32-Bit-Fließkommaaddierer

Tabelle 6.19: Altera Megafunctions in der Overlap-Add-Komponente

Implementierte Schnittstelle

In der Implementierung wurde das in 5.5.5.2 vorgestelle Schnittstellenmodell um dieEingänge clk für das Takt- und rst für das Reset-Signal erweitert. Die vollständigeÜbersicht über die Ein- und Ausgänge zeigt Tabelle 6.20.

Port Typ Beschreibungclk IN STD_LOGIC Eingang für Taktsignalrst IN STD_LOGIC Eingang für Resetwrite IN STD_LOGIC Schreibanfrage an die Komponen-

tefifo_busy IN STD_LOGIC Verfügbarkeit des Ausgangspuf-

fersdata_in IN STD_LOGIC_VECTOR(31:0) Eingang für iFFT-Datenfft_len IN STD_LOGIC_VECTOR(8:0) FFT-Längefrsize IN STD_LOGIC_VECTOR(7:0) Blockgrößebusy OUT STD_LOGIC Verfügbarkeit der Komponentewrite_out OUT STD_LOGIC Schreibanfrage an den Ausgangs-

pufferq OUT STD_LOGIC_VECTOR(31:0) Datenausgang

Tabelle 6.20: Implementierte Schnittstelle der Overlap-Add-Komponente

Integraton in das spec2wave-Plugin

Die Overlap-Add-Komponente wird analog zu der Windowing-Komponente verwen-det. Es muss für die Anzahl an spec2wave-Instanzen im MHA multipliziert mitden verwendeten Kanälen Overlap-Add-Komponenten im spec2wave-Plugin existie-ren. Die Auswahl der Overlap-Add-Komponente erfolgt über Multiplexer und Demul-tiplexer, und ist abhängig von dem Parameter Instanz-ID. Abbildung 6.34 zeigt denDatenfluss der Overlap-Add-Komponente.

157

6 Implementierung

Abbildung 6.34: Datenfluss der Overlap-Add-Komponenten

6.9 GehäuseDas Gehäuse wurde mit der 3D-Software SketchUp der Firma @Last Software entwor-fen. Alle Hardwarekomponenten wurden sehr detailiert anhand der Datenblätter undder geplanten Platinenlayouts dreidimensional nachmodelliert und mit ihren Texturenversehen. Die als Texturen verwendeten Bilder stammen ebenfalls aus Datenblätternund Fotographien.

Wärend dieser Designstudie ging es vorerst darum die einzelnen Komponentenso platzsparend wie möglich anzuordnen, um ein kompaktes Endgerät entwerfen zukönnen. Dabei wurde auf die Bedienbarkeit des Geräts Rücksicht genommen.

Aussparungen für Schnittstellen wurden zu diesem Zeitpunkt bereits ebenfalls mo-delliert.

Abbildung 6.35 zeigt die Einzelkomponenten in einer dreidimensionalen Ansicht.Oben links in der Abbildung sind die sechs Akkus dargestellt. Im Uhrzeigersinn folgtals nächste Komponente das LC-Display und daraufhin dessen Controller-Platine.Die nächste zu sehende Komponente ist der Industrie-PC, gefolgt von einem Adapter,der als Verlängerung der Busanbindung dient. Bei den beiden letzten Teilen handeltes sich um die Tastatur und um die Beschleunigerplatine, die sich aus dem SmartPack und der eigens hergestellten Platine mit dem PCI-FPGA zusammensetzt.

Für die technische Umsetzung des Designs mussten noch einige Änderungen vor-genommen werden. Als alle Komponenten tatsächlich verfügbar waren, wurden dieAbmessungen auf 1mm dicke Aluminiumplatten übertragen. Diese wurden gefrästund schließlich über Verbindungsschienen verschraubt. Die endgültige Anordnungder Komponenten ist in Abbildung 6.36 und 6.37 dargestellt. Abbildung 6.38 zeigtdas tatsächlich umgesetzte Gehäusedesign.

158

6.9 Gehäuse

Abbildung 6.35: 3D Modelle der einzelnen Komponenten

Abbildung 6.36: 3D Gehäuseentwurf

159

6 Implementierung

Abbildung 6.37: 3D Gehäuseentwurf mit Texturen

Abbildung 6.38: Fertiges Gehäuse

160

7 Komponenten- und Integrationstests

In diesem Kapitel werden die Hardware- und Software-Tests für die Komponentendes Gesamtsystems vorgestellt werden. Dabei unterbleiben detailierte Diskussionendes jeweiligen Tests, und es wird vielmehr die allgemeine Intention und das Ergeb-nis genannt. Die Details der Tests können den begefügten Quelldateien entnommenwerden.

Die durchgeführten Tests betreffen die Konfigurationen und Software der FPGAsdes Beschleunigers sowie die Software des Industrie-PC. Diese umfasst MHA-Erwei-terungen und PCI-Treiber.

7.1 MHA-FPGAIn diesem Abschnitt sollen die durchgeführten Komponenten-, als auch die Intrakom-munikationstest kurz vorgestellt werden. Die Tests sollen eventuelles Fehlverhaltendurch inkorrekten Quellcode, als auch strukturelles Fehler aufzeigen. Die durchge-führten Tests und ihre Ergebnisse werden protokollarisch dargestellt.

7.1.1 Test der externen SchnittstelleDie externe Schnittstelle musste hinsichtlich zweier Gesichtspunkte überprüft werden.Zum einen der korrekten Kommunikation mit dem NIOS II Softcore über den Avalon-Bus und zum anderen der Kommunikation mit dem PCI-FPGA über den Localbus.

7.1.1.1 Komponententest durch Simulation des PCI-FPGA

Um die Kommunikation zwischen NIOS II Softcore und externer Schnittstelle zuüberprüfen, war es nötig mögliche weitere Fehlerquellen zu eleminieren. Aus diesemGrund wurde eine Hardware-Komponente entwickelt, die den Localbus-Controllersimulierte. Es wurden über den NIOS II Softcore Daten in die externe Schnittstellegeschrieben. Der Ausgang der externe Schnittstelle zum Localbus wurde mit der Test-Hardware direkt zurück an den Eingang geschliffen. Von dort wurden sie wieder vomNIOS II Softcore entgegengenommen und verglichen. Mit dieser Simulations-Softwarewurden elektrische Fehler auf der Platine und Fehler im PCI-FPGA nicht überprüft.Der Test verlief erfolgreich.

7.1.1.2 Intrakommunikationstest zwischen PCI- und MHA-FPGA

Nachdem die externe Schnittstelle hinreichend überprüft wurde, wurde die Kommuni-kation zwischen PCI- und MHA-FPGA getestet. Es wurden zwei Loop-back-Geräteentwickelt, die einen Satz von Datenpaketen in einer Endlosschleife zwischen denFPGAs rotierten. Da nach 40 min Laufzeit keine Veränderung der Datenpakete fest-gestellt werden konnte, wird die Verbindung als hinreichend stabil angenommen.

161


7.1.2 Controllertest

Alle Controller-Tests wurden in Verbindung mit der NIOS-II-IDE von Altera durch-geführt. Durch die Integration einer JTag-Debug-Schnittstelle in das FPGA-Design,war es möglich Ausgaben des MHA-FPGA in textueller Form an das Entwicklungs-system zu übertragen. Auf diese Weise wurde Zwischenergebnisse überprüft. Dieswar notwendig, da der PCI-FPGA grundsätzlich als Initiator des Tests fungierte undzwischenzeitlich überprüft werden musste, ob alle Daten vom MHA-FPGA korrektempfangen und verarbeitet wurden. Der Quellcode der Testsystem ist auf der CD zufinden und dort auch näher erläutert. In diesem Kapitel werden lediglich die durch-geführten Tests kurz vorgestellt.

7.1.2.1 Intrakommunikationstests

Als Intrakommunikationstests werden hier die Tests verstanden, die ausschließlich dieKommunikation zwischen PCI-FPGA und MHA-FPGA verifizieren.

Schritt 1: Übertragung kleinster und durchschnittlicher Pakete

In diesem Test sendete der PCI-FPGA Daten- und Konfigurationspakete an denMHA-FPGA. Die Paketgröße belief sich zwischen einem und 509 Datenworten zuzüg-lich des Paket-Headers. Die versendeten Datenworte wurden ohne Manipulation überden Bus direkt an den PCI-FPGA übertragen. Versendete und empfangene Paketewurden auf Abweichungen überprüft. Es wurden keine Abweichungen festgestellt.

Schritt 2: Übertragung übergroßer Pakete

Die logische Folgerung des ersten Übertragungstest war das Verifizieren übergroßerDatenpakete. Übergroße Datenpakete bieten Fehlerpotential innerhalb der externenSchnittstelle und zu kleinen Teilen auch innerhalb des Controllers. Es wurden Über-große Pakete bis zur Gesamtlänge von drei Einzelpaketen getestet. Dies bedeutet,dass drei aufeinander folgenden Pakete an den MHA-FPGA geschickt wurden, vomController in einen Werteblock zusammengeführt worden sind und schließlich wiederin drei Einzelpakten verpackt an den PCI-FPGA zurück übertragen wurden. Der Testwurde erfolgreich abgeschlossen.

7.1.2.2 Komponententests

Auch alle folgend aufgeführten Tests wurden in Zusammenarbeit mit dem PCI-FPGAdurchgeführt. Da das Ziel nicht die Überprüfung der Kommunikation, sondern dieÜberprüfung einzelner Funktionen des Controllers und dessen Komponenten war,werden sie hier als Komponententests beschrieben.

Hardware-Interface-Test

Der Hardware-Interface-Test diente maßgeblich der Überprüfung der Kontrollstruk-tur des MHA-Controllers. Mit diesem Test wurde überprüft, ob ein Hardware-Pluginmittels der Makro-Funktionen und der Kontrollstruktur des Controllers korrekt ver-arbeitet wird. Dies betrifft das Laden von Konfigurationen und Daten in ein Plugin,

162

7.1 MHA-FPGA

das Aktivieren und Deaktivieren von Interrupts, das Überprüfen der Statussigna-le eines Hardware-Plugins und den Versand berechneter Daten an den PCI-FPGA.Als Hardware-Plugin wurde eine Testkomponente benutzt, die zum verifizieren derSchnittstelle entwickelt worden ist. Es wurden zwei Datenpakete an den MHA-FPGAgeschickt. Das erste Paket enthielt die Konfiguration des entsprechenden Hardware-Plugins, das zweite die Datenwerte. Mit diesen Eingaben wurde das Plugin gestartetund das Ergebnis in Form eines Datenpakets an den PCI-FPGA zurückgeschickt. DerTest wurde erfolgreich abgeschlossen.

Software-Plugin-TestSoftware-Plugins sind Funktionen die zwei Eingabe- und einen Ausgabeparameterbesitzen. Des Weiteren benutzen sie die Funktion sendSoftwareData(), um ein be-rechnetes Datenpaket zu verschicken. Bei diesem Test war nicht zu überprüfen, obein Software-Plugin seine Werte korrekt berechnet, sondern, ob es die zu berechnen-den Informationen erhält und ob das Ergebnis korrekt an den PCI-FPGA übertragenwird. Es wurden Konfigurations- und Datenpaket für ein Software-Plugin an denMHA-FPGA geschickt und das Ergebnispaket innerhalb des PCI-FPGAs überprüft.Der Test verlief erfolgreich.

Kobinierter Plugin-TestDieser Test stellt die Verbindung von Hardware- und Software-Plugin-Tests dar. Eswurden vom PCI-FPGA in zufälliger Reihenfolge Pakete für Soft- und Hardware-Plugins geschickt. Die Ergebnispakete wurden im PCI-FPGA auf Fehler überprüft.Das Verhalten des Controllers wurde mit zusätzlichen Debug-Ausgaben überwacht.Dies diente dazu, die Kommunikationssignale zu überprüfen, da zur Aufgabenbewäl-tigung in den meisten Fällen mehr als ein Pfad durch den Controller führt. Es wurdekein Fehlverhalten erkannt. Da dieser Test auf zufällig ausgewählten Daten beruht,kann die Fehlerfreiheit des Controllers in diesem Punkt nur angenommen werden.

Test möglicher FehlercodesEs sind grundsätzlich zwei Gruppen von Fehlern im System verarbeitbar. Zum einensind dies Fehler, die durch einen Speichermangel ausgelöst werden und zum anderenFehler, die durch den Versand fehlerhafter Pakete entstehen. Speicherallokation wirddurch die Funktion malloc() in der Bibliothek stdlib zur Verfügung gestellt. Da dieseFunktion ein Bestandteil der Standard-Bibliothek ist, wurde von der Fehlerfreiheitder Funktion ausgegangen. Die übrigen Fehlercodes wurden durch bewusstes Auslösengetestet. Der Test wurde erfolgreich abgeschlossen.

KontrollstrukturtestsDer Kontrollstrukturtest zwang den Controller alle Code-Segmente mindestens ein-mal zu durchlaufen, um sie auf ihre Funktionalität hin zu überprüfen. Dies wurdedurch geschickte Vergabe der gesendeten Pakete und die Manipulation des Control-lers durch das Setzen von Kommunikationssignalen erzielt. Dieser Test bewies nichtdie vollständige Korrektheit der Kontrollstruktur, sondern die Korrektheit der einzel-nen Code-Segmente. Da kein Fehler auftrat, wird weiterhin von der Korrektheit derKontrollstruktur ausgegangen.

163


7.2 PCI-FPGA-TestsIn den folgenden Unterabschnitten werden die Tests der Komponenten des PCI-FPGAs vorgestellt werden. Die Vorstellung der Tests von VHDL-Komponenten be-schränkte sich dabei auf eine Erläuterung der getesteten Eigenschaften, da die Simu-lationsergebnisse in unzureichender Qualität dargeboten werden könnten. Deshalbwerden die Quelldateien zur Wiederholung der Tests mitgeliefert, so dass diese mitder Quartus II-Entwicklungsumgebung nachvollzogen werden können.

7.2.1 Test des Local Bus ControllerDer Local Bus Controller ist im Abschnitt 6.7.1 auf funktionaler Ebene beschrieben.Die Testdateien der Quartus II-Entwicklungsumgebung sind die Folgenden.

localBusController_0.vwf Mit diesem Test wird der Zugriff auf den externene SRAM-Speicher getestet. Dabei sind Adressumsetzung und Zugriffprotokoll des SRAM-IC interessant. Weiterhin der Schreib-, Lesezugriff auf das Statusregister getes-tet.

localBusController_1.vwf Der Befehl FIFOTransfer des Local Bus Controllers wirdgetestet. Dabei ist insbesondere der simultane SRAM-Zugriff, die Adressbe-rechnung und das Verhalten bei (nicht-)verzögerten Zugriffen auf den AvalonBus, die Meldung von Fehlern und Stati der Befehlsausführung mittels Un-terbrechnungen und die Entsagung des Zugriffes auf den lokalen Busses durchden MHA-FPGA bei nicht leerer Empfangs-FIFO des Local Bus Controller vonInteresse. Ebenso werden Zugriffe auf das FIFO-Peek-Register getestet.

localBusController_2.vwf Hier wird die Übertragung von Daten vom MHA- zumPCI-FPGA sowie Arbitriertung des lokalen Busses getestet. Die Befehle imZusammenhang mit dem Befehl MHATransfer des Local Bus Controllers wer-den ebenso ihre Funktion hin untersucht. Dabei ist insbesondere der simultaneSRAM-Zugriff, das Verhalten des Local Bus Controller bei überfüllter FIFO imMHA-FPGA, die Meldung von Fehlern bzw. Stati der Befehlsausführung überUnterbrechungen, das Nachlaufen des Schreibtaktes für den MHA-FPGA sowiedie Arbitrierung des lokalen Busses von Interesse.

LBCAddressRegister.vwf Mit dieser Datei wird die korrekte Funktion der Adress-zähler geprüft. Diese Zähler dienen zur Berechnung der Adresse des nächstesZugriffes auf den Avalon-Bus.

LBCWordCounter.vwf Hier wird die korrekte Funktion des Wortzähler geprüft. Die-se zählen bei den Befehlen MHA- und FIFOTransfer die Menge der zu übertra-genen 32Bit-Wörter.

7.2.2 Test des PCI-KernesDir Funktionsweise des PCI-Kerns wird im Abschnitt 6.7.2 erläutert. Einzelne Kom-ponenten sind in der Quartus II-Entwicklungsumgebung getestet worden. Die Testswerden im Unterordner waveforms mitgeliefert. Der Zweck der einzelnen Tests wirdweiter unten erläutert.

164

7.2 PCI-FPGA-Tests

PCIAddrDecoder_0.vwf Die Komponente PCIAddrDecoder wird auf die Erkennungder angegebenen Adresse 0xCAFEBABE getestet.

PCIAvalonInterface.vwf Das Setzen und Zurücksetzen der einzelnen Bits im Sta-tusregister der Komponente AvalonInterface über den Befehlsregister sowie dasLesen und das Schreiben der Kommandos wird getestet.

PCIBusBuffer_0.vwf Für die Komponente PCIBusBuffer wird eine PCI-Transaktionsimuliert. Die Weiterleitung der Daten vom PCI-Bus an andere Komponentendes PCI-Kerns wird geprüft.

PCIConfigMem_0.vwf In diesem Test werden zuerst einzelne von der Komponen-te PCI FSM zu setzende Bits (z.B. Parity Error) getestet. Weiterhin werdenfolgende Register (bzw. Teilregister) des PCI-Konfigurationsspeichers testweisebeschrieben und belesen: Status register, Base Address Register 0, Base AddressRegister 1, Interrupt Line, Latency, Device-Id/Vendor-Id.

PCICore_0.vwf Integrationstest des PCI-Kerns. Getestet werden folgende PCI-Ko-mmandos: Configuration Read, Memory Read mit Ergebnis Target Abort (weildas entprechende FIFO im PCI-Kern zu diesem Zeitpunkt leer ist), MemoryRead mit Daten aus dem FIFO als Ergebnis, Memory Write mit falscher Parität.Ferner wird der Kern über den Avalon-Bus mit Daten beschrieben.

PCICore_1.vwf Backup-Kopie des vorherigen Tests.

PCICore_2.vwf Vorlage für weitere Integrationstests für den PCI-Kern.

PCICore_pciBurstRead.vwf Der PCI-Kern wird über den Avalon-Bus mit vier Wer-ten beschrieben. Danach werden vom PCI-Kern mit dem PCI-Kommand Me-mory Read vier Werte gelesen.

PCICore_pciBurstReadTooMany.vwf Der PCI-Kern wird über den Avalon-Bus mitvier Werten beschrieben. Danach werden fünf Werte über den PCI-Bus gelesen,worauf der PCI-Kern mit einem Target Abort reagiert.

PCICore_pciBurstReadWithWaitStates.vwf Der PCI-Kern wird über den Avalon-Bus mit vier Werten beschrieben. Danach werden über den PCI-Bus vier Wertegelesen, wobei die aktive Seite mit Pausen liest.

PCICore_pciBurstWrite.vwf Über den PCI-Bus werden vier Werte in den PCI-Kerngeschrieben. Dabei wird über den Avalon-Bus der Status-Register gelesen. Nachden PCI-Transaktion werden die Werte über den Avalon-Bus gelesen.

PCICore_pciReadConfig.vwf Dieser Test basiert auf dem Test PCICore_pciBurst-Read.vwf. Zusätzlich wird der Register Device-Id/Vendor-Id des PCI-Konfigura-tionsspeichers über den Avalon-Bus ausgelesen. Danach wird der oberste (an derAdresse 0xF) Wert des PCI-Konfigurationspeichers über den PCI-Bus ausgele-sen.

PCICore_pciWriteConfig.vwf In diesem Test wird die PCI- sowie Avalon-Operati-onen geprüft, bei denen der PCI-Konfigurationsspeicher beschrieben wird. Erst

165


werden über den Avalon-Bus die Bits des Konfigurationsspeichers gesetzt, diedie Fähigkeit des PCI-Kerns zur Auswertung der Parität anzeigen. Dann wirddas Schreiben in den PCI-Konfigurationsspeicher mit falscher Parität simu-liert. Die Meldung über die falsche Parität bei der Transaktion wird danachüber den Avalon-Bus durch das Zurücksetzen des Status-Registers im PCI-Konfigurationsspeicher gelöscht. Gleichzeitig wird eine Configuration Write-Transaktion über den PCI-Bus versucht, welche jedoch durch den AutomatRetry FSM abgeblockt wird, welcher bei einer Transaktion über den Avalon-Busdie Kontrolle über den PCI-Bus übernimmt.

PCICore_template.vwf Der Test ist eine Vorlage für den Integrationstest des PCI-Kerns. Erst wird der PCI-Kern mit vier Werten über den Avalon-Bus beschrie-ben, dann werden vier Werte über den PCI-Bus mit einer Memory Read PCI-Transaktion gelesen.

PCIFSM_0.vwf Bei diesem Test wird die Funktionsfähigkeit des Steuerautomatenim PCI-Kern getestet.

PCIFSMRetryFSM_0.vwf In diesem Test wird die Übernahme der Kontrolle überPCI-Transaktionen durch die Komponente Retry FSM überprüft.

PCIMux_0.vwf Hier wird die Weiterleitung der Daten durch die Komponente PCIMux getestet.

PCIParityChecker_0.vwf Bei diesem Test wird die Komponente Parity Checker aufErkennung falscher even-Parität getestet.

PCIParityGenerator_0.vwf Bei diesem Test wird die Komponente Parity Checker aufGenerierung der even-Parität über 32-Bit Werte getestet.

Sowohl die funktionale Simulation als auch die Timing-Simulation zeigten das stan-dardkonforme Verhalten des PCI-Kernes. Da aber der Industrie-PC sich nicht startenließ als der PCI-Kern eingesetzt worden ist, wurde der Einsatz des PCI-Kernes vonAltera[58] in Betracht gezogen.

7.3 Testen des Softwarekommunikation

Da die Entwicklung der Hardwareseitigen PCI-Kommunikation bei Fertigstellung desPCI-Treibers noch nicht abgeschlossen war, konnte der implementierte Treiber vorerstnicht vollends getestet werden. Aus diesem Grund wurde eine hardwareunabhängigeVersion des Treibers entwickelt, deren Funktionalität getestet werden konnte. Nichtnur Treiberfunktionen wurden mit dieser, im Folgenden als „Loopback-Treiber“ be-zeichnet Treiber-Version getestet, auch die Funktionalität des MHA-Adapter-Pluginskonnte überprüft werden. Daten einer Verarbeitungskette wurden über das MHA-Adapter-Plugin an den Loopback-Treiber gereicht. Dieser schrieb die Daten dannjedoch lediglich in den Zwischenspeicher des Industrie-PC. Bis auf die fehlende Über-tragung an die Hardware blieben alle weiteren Verarbeitungsschritte unverändert. Die

166

7.4 Testen der Menüführung

Daten wurden durch den Loopback-Treiber wieder eingelesen und konnten schließ-lich über das Adapter-Plugin wieder in die Verarbeitungskette integriert werden (sie-he: 6.5.5. Anschließend wurden die Daten auf ihre Korrektheit überprüft. Es wurdeneinige kleinere Fehler entdeckt und behoben.

7.4 Testen der MenüführungDas Testen der Menüführung diente zwei Zwecken. Zum einen sollte die Funktionalitätüberprüft werden und eventuelle Fehler ausfindig gemacht werden. Zum anderen soll-te jedoch auch das grafische Menü-Design auf intuitive Bedienbarkeit getestet werden.Insbesondere sollte sichergestellt werden, dass die Menü-Symbole eindeutig verständ-lich sind und eine Bedienung des Endsystems ohne eine größere Einarbeitungszeitmöglich ist. Zum Testen der Skript-basierten Menüführung war das Menü nicht nurfür die Ausgabe auf dem LC-Display implementiert worden. Eine text-basierte Aus-gabe kann über einen an den Industrie-PC angeschlossen Bildschirm verfolgt werden.Vor der eigentlichen grafischen Implementierung konnte die Menüführung auf diesemWege ausgiebig getestet werden. Alle Statusparameter wurden ständig überprüft.

Nach vollständiger Implementierung der grafischen Menüführung wurde das Menümit mehreren Testpersonen unterschiedlichen Alters getestet. Sie sollten die einfa-che Bedienbarkeit bestätigen. Einige kleine Veränderungen an grafischen Symbolenwurden anhand dieser Tests im nachhinein verbessert.

167


168

8 Fazit

Im Rahmen der Projektgruppe MHA2 wurde ein tragbarer Rechner gebaut, dessenRecheneinheit aus einer PC/104-Platine und einer selbsthergestellten FPGA-Platine(s.u.) besteht. Des Weiteren sind von der Gruppe das Bedienpanel, die Stromversor-gung und das Gehäuse entworfen und erstellt worden.

Die PC/104-Platine besitzt genügend Rechenleistung, um die Software MHA zustarten und ausführen zu können. Es wird eine abgespeckte Version der Gentoo-Distribution des Betriebssystems Linux verwendet. Durch Anpassungen wird dieRealtime-Ausführung der Software MHA ermöglicht. Um eine Verbindung mit derFPGA-Platine aufzubauen sind dedizierte Linux-Treiber geschrieben worden.

Die FPGA-Platine ist mit Hinblick auf Hochfrequenzbetrieb entworfen worden.Diese Platine enthält zwei FPGA-Bausteine der Fa. Altera Corporation. Im größerenBaustein werden die Berechnungen durchgeführt. Der verwendete FPGA ist speziellauf Anwendungen im Bereich der digitalen Signalverarbeitung optimiert. Der kleinereBaustein bewerkstelligt die Kommunikation mit der Host-Platine. Die Kommunika-tion geschieht über den PCI-Bus. Für die Kommunikation zwischen den Bausteinenist eine spezielle Schnittstelle Localbus entworfen und implementiert worden.

Das Bedienpanel ermöglicht die menügeführte Bedienung des Geräts mit grafischerAusgabe. Viel Beachtung wurde hier der Bequemlichkeit der Menüführung geschenkt.

Um das Gerät vor äußeren Einflüssen zu schützen wurde ein Gehäuse entworfenund hergestellt. Zusammen mit der Stromversorgung wird hier die Kernanforderungerfüllt – eine mobile Plattform zur Ausführung von Hörgeräte-Algorithmen.

Abschließend werden Ideen aufgezeigt, wie nach Ende des Projekts mit dem Pro-totypen und den Ergebnissen verfahren werden könnte. Einerseits besteht die Mög-lichkeit, den entwickelten Prototypen weiterzuentwickeln und seine Komponenten zuoptimieren. Zunächst soll die Weiterentwicklung des entwickelten Prototypen betrach-tet werden. Die Hardware des Prototypen ist direkt lediglich in Bezug auf den FPGAerweiterbar. Die Beschleunigerplatine wurde so konzipiert, dass auch weitere StratixSmartPacks gestapelt werden können. Allerdings wird das Stratix SmartPack vonParallax nicht mehr produziert.

Im Rahmen der Entwicklung wäre eine weitere Konsequenz, weitere Plugins desMHAs in Hardware zu realisieren. Dazu gehöhren vorwiegend Filterfunktionen, wieMultibandfilter. Auch die Auslagerung kompletter Ketten wäre ein Schritt, der zu-dem den Datentransfer auf dem PCI-Bus reduzieren kann. Eine weitere Möglichkeit,besonderes im Hinblick auf die verfügbaren Ressourcen im FPGA ist die Optimie-rung der FFT-Implementierung. Speziell eine „Verkleinerung“ der Butterfly würdeden Ressourcenbedarf der Komponente senken. Desweiteren wäre die Implementie-rung der FFT zu anderen Zahlenbasen oder eine Kombination dieser denkbar.

Ein anderer Lösungsweg wäre, einen weiteren Prototypen zu entwickeln. Währendder Laufzeit des Projektes sind verschiedene neue Technologien zur Marktreife gekom-men, die Verwendung in einem neuen Prototypen finden könnten. Mehrkernprozesso-

169

8 Fazit

ren sind dem Normalverbraucher zugänglich und werden auch in neueren Industrie-PCs integriert. Diese neuen Prozessorgenerationen sind deutlich leistungsfähiger undkönnten den Einsatz eines Beschleunigers verzichtbar machen.

Das Beschleunigerkonzept könnte jedoch durch neue Busstandards wie PCI-Express(PCI-E) profitieren. PCI-E bietet Übertragungsraten bis zu 2,5 GB/s, was insbeson-dere die Erweiterbarkeit der Eingangskanäle fördert. Auch neue Generationen vonFPGAs können die Leistungsfähigkeit des Beschleunigers steigern. Diese FPGAs sol-len mit Taktfrequenzen bis 800 MHz betrieben werden können und würden somit dieBerechnungszeiten auf dem Beschleuniger wesentlich verkürzen.

Auch die neuen Co-Prozessorkonzepte von AMD und Intel legen neue Wege of-fen. So entwickeln diese Chiphersteller Protokolle für Co-Prozessoren von Drittanbie-tern. So sollen Physik-, Grafik oder Signalprozessoren in Sockeln platz finden, auchFPGAs wären denkbar. Findet auch diese Architektur den Einzug in den Bereich derIndustrie-PCs, wäre es eine leistungsfähige Alternative.

170

A Anhang

A.1 Testsysteme

Im folgenden Abschnitt werden die verwendeten Testsysteme beschrieben.

A.1.1 Betriebssystem

Bei dem verwendeten Linux-Kernel handelt es sich um den Kernel 2.6 mit Gentoo [59]-spezifischen Patches. Der Kernel wurde selbst kompiliert. Mit make menuconfig kön-nen dabei viele Einstellungen vorgenommen werden. Abweichend von den Standard-einstellungen vor der Kompilierung wurden folgende Einstellungen vorgenommen.

Konfiguration des Kernels• Processor type and features → Processor family → 586

• Processor type and features → Generic x86 support → *

• Processor type and features → Math emulation → *

• Bus options → PCCARD → PCCard support → *

• Security options → enable different security models → *

– Default Linux capabilities → M

Zusätzliche Patches• realtime-lsm [27]

• perfctr 2.6.19 für Kernel 2.6.14[60]

TreibermoduleAußer den Standard-Treibermodulen wurde noch ein Treiber für die vorhandene Netz-werkkarte und die verwendete Soundkarte (ALSA-Treiber) [61] installiert.

weitere Anwendungen• JACK Audio Connection Kit, Version 0.100.0 [51]

• Master Hearing Aid (MHA), Version 4.2

171

A Anhang

A.1.2 TesthardwareFolgende Hardware stand uns für die Tests zur Verfügung:

1. Intel Pentium II, 233 MHz256 MB SD-RAM, Infineon 3rd, 133 MHz Asus P2B-B, Intel 440BX Chipsatz,FSB 66 MHz Taktfrequenz

2. Intel Pentium III, 500 MHz256 MB SD-RAM, Infineon 3rd, 133 MHz MSI 6163 Ver. 2 , Intel 82443BX/PI-IX4E Chipsatz, FSB 100 MHz Taktfrequenz

3. AMD Athlon 64 3000+, 1800 MHz512 MB DDR-Speicherbausteine, Infineon, 400 MHz, CL3, Dual Channel-KonfigurationAsus A8V, V2.0, VIA K8T800 Pro Chipsatz, FSB 200 MHz

Bei allen durchzuführenden Tests wurde eine 6-Kanal-Soundkarte mit dem Chipsatz„8738“ von C-Media Electronics Inc. genutzt.

A.1.3 Testwerkzeuge

„perfctr“Das „perfctr“-Paket [60] für Linux ermöglicht es, die „Performance Monitor Coun-ters“ (PMCs) moderner Prozessoren der x86er-Familie auszulesen. Als PMCs werdenprozessoreigene Register bezeichnet, in denen, je nach Microarchitektur, unterschied-liche Messwerte abgelegt werden. So können mit Hilfe von Programmen wie perfctrWerte wie die Anzahl ausgeführter Instruktionen, Cache-Überläufe etc. ausgelesenwerden.

Diese Messungen sind besonders für die Behebung von „low-level“-Performance-Problemen hilfreich.

Für die Arbeit mit „perfctr“ bedarf es jedoch einiger Veränderungen am Kerneldes Linux-Betriebssystems, die durch das Einspielen des für die Kernel-Version spezi-fischen perfctr-Patches vorgenommen werden können. Durch Aufspielen des Patcheswird eine neue Schnittstelle innerhalb des Betriebssystems angelegt, die im Datei-system als Gerät unter /dev/perfctr anzusprechen ist und den Zugriff auf die PMC-Register erlaubt.

Jeder Linux-Prozess erhält ein eigenes Set von „virtuellen“ PMCs, was bedeutet,dass die PMCs von einem Prozess aus als privat und unabhängig von anderen Pro-zessen erscheinen. Virtuelle PMCs haben eine theoretische Präzision von 64 Bit, diepraktisch jedoch nicht erreicht wird, da aktuelle Prozessoren nur 32, 40 oder 48-BitPMCs aufweisen.

„global“Im „perfctr“-Paket sind kleine Anwendungsprogramme enthalten, die die von perfc-tr eingerichtete Schnittstelle nutzen. Für die unterschiedlichen Messungen wurdenunterschiedlich Modifikationen des Programms „global“ benutzt. Dabei wurde auchberücksichtigt, nur die von Anwendungsprogrammen erzeugte Rechenlast zu messen.Die dafür benötigten Daten wurden den Datenblättern der verwendeten Prozessorenentnommen [62] [63].

172

A.1 Testsysteme

Abbildung A.1: Bitbelegung der PerfEvtSel0 und PerfEvtSel1 MSRs der Intel IA-32-Architektur

Die beschriebenen Messungen erfolgten mit folgenden Modifikationen von „global“in der Quelltextdatei „x86.c“.

Original

Zeile 31, für AMD K8:evntsel0 = 0xCB | (0x01 << 8) | (3 << 16) | (1 << 22);Zeile 46, für Intel Pentium:evntsel0 = 0xC1 | (3 << 16) | (1 << 22);

MINS

Zeile 31, für AMD K8:evntsel0 = 0xC0 | (1 << 16) | (1 << 22);Zeile 46, für Intel Pentium:evntsel0 = 0xC0 | (1 << 16) | (1 << 22);

MOPS

Zeile 31, für AMD K8:evntsel0 = 0xC1 | (1 << 16) | (1 << 22);Zeile 46, für Intel Pentium:evntsel0 = 0xC2 | (1 << 16) | (1 << 22);

FLOPS

Zeile 31, für AMD K8:evntsel0 = 0xCB | (0x01 << 8) | (1 << 16) | (1 << 22);Zeile 46, für Intel Pentium:evntsel0 = 0xC1 | (1 << 16) | (1 << 22);

173

A Anhang

A.1.4 MHA-Konfigurationen

Unbelastetes SystemDas unbelastete System ist hier definiert als das für das MHA notwendige Grund-system. Dies umfaßt das Betriebssystem mit den notwendigen Prozessen, sowie denJACK-Soundserver und das MHA. Das MHA wird hierbei mit der Identitätskette be-trieben. Diese Kette schleust lediglich das Audiosignal durch das MHA, ohne daraufBerechnungen durchzuführen.

Der entsprechende Quelltext kann auf der Projektgruppen-CD-ROM eingesehenwerden.

Belastung durch FFT/iFFTIn dieser Konfiguration wird das MHA mit der FFT und der iFFT belastet. Dieserfolgt, in dem in einer Kette sowohl das Plugin wave2spec als auch spec2wave einge-bunden wird.


Belastetes SystemIn dieser MHA-Konfiguration wird das System durch die komplette Referenzkettebelastet. Diese besteht aus folgenden Plugins:

• wave2spec

• equalize

• fader

• fftfilterbank

• spec2wave

• rmslevel

• matrixmixer


174

A.2 Schaltpläne

A.2 Schaltpläne

Im Folgenden sind die Schaltpläne zu den Komponenten aus den Abschnitten 6.3.1und 6.3.2 abgebildet.

Abbildung A.2: Schaltbild der 6-Tasten-Tastatur

175

A Anhang

Abbildung A.3: Schaltbild der Anzeige

176

A.2 Schaltpläne

Abbildung A.4: Schaltbild der Anzeigesteuerung

177

A Anhang

Abbildung A.5: Schaltbild der PC/104-Plus-Anbindung des Beschleunigers

178

A.2 Schaltpläne

Abbildung A.6: Schaltbild der Beschaltung der Bank I des PCI-FPGA

179

A Anhang

Abbildung A.7: Schaltbild der Beschaltung der Bank II des PCI-FPGA

180

A.2 Schaltpläne

Abbildung A.8: Schaltbild der Beschaltung der Bank III des PCI-FPGA

181

A Anhang

Abbildung A.9: Schaltbild der Beschaltung der Bank IV des PCI-FPGA

182

A.2 Schaltpläne

Abbildung A.10: Schaltbild des lokalen SRAM-Speichers des PCI-FPGA

183

A Anhang

Abbildung A.11: Schaltbild der Steckverbindung zum Parallax-Modul Startix 672SmartPack (MHA-FPGA)

184

A.2 Schaltpläne

Abbildung A.12: Schaltbild des lokalen SRAM-Speichers des MHA-FPGA

185

A Anhang

Abbildung A.13: Schaltbild des Netzteiles des Beschleunigers

186

A.3 Projektplan

A.3 Projektplan

187

A Anhang

188

Literaturverzeichnis

[1] Altera Corporation: Avalon Bus Specification Reference Manual Version2.3, Juli 2003

[2] Altera Corporation. http://www.altera.com, Abruf: März 2006

[3] Altera Corporation: NIOS Embedded Processor Software Development Re-ference Manual Vers. 3.2, März 2003

[4] Altera Corporation: Nios 3.0 CPU Data Sheet Vers. 2.0, März 2003

[5] Altera Corporation: SOPC Builder Data Sheet Vers. 2.0, Januar 2003

[6] Compaq Computer Corporation, Hewlett-Packard Company, IntelCorporation, Lucent Technologies Inc, Microsoft Corporation,NEC Corporation, Koninklĳke Philips Electronics N.V.: UniversalSerial Bus Specificaiton Revision 2.0, April 2000

[7] Altera Corporation: Quartus II Handbook, Vol. 1: Design & Synthesis,Vol. 2: Design Implementation and Optimization, Vol. 3: Verification, Vol. 4:SOPC Builder, December 2005

[8] Mentor Graphics: ModelSim. http://www.model.com/default.asp, Abruf:Okt. 2006

[9] Mentor Graphics Corporation: Mentor Graphics. http://www.mentor.com/, Abruf: 15.10.2006

[10] KDevelop Team: KDevelop KDE Development Environment. http://www.kdevelop.org/, Abruf: Okt. 2006

[11] Sandeep Dutta: SDCC 2.4.0 Compiler User Guide, Rev. 1.88, Februar 2004

[12] Altera Corporation: NIOS II Software Developer’s Handbook, Rev.: NII5V2-6.0, 2005

[13] Zuken Limited: CadStar User’s Guide, Part No.: 202559/12, 2004

[14] Limited, Zuken: Zuken Limited. http://www.zuken.com/, Abruf: 15.10.2006

[15] Collins-Sussman, Ben ; Fitzpatrick, Brian W. ; Pilato, C. Michael: VersionControl with Subversion 1.2, 2006. http://subversion.tigris.org/

[16] LaTeX Project Group: LaTeX – A Document Preparation System. http://www.latex-project.org/, Abruf: 15.10.2006

[17] CompactFlash Association. http://www.compactflash.org/, Abruf: Dez. 2005

189

http://www.altera.com

http://www.model.com/default.asp

http://www.mentor.com/

http://www.mentor.com/

http://www.kdevelop.org/

http://www.kdevelop.org/

http://www.zuken.com/

http://subversion.tigris.org/

http://www.latex-project.org/

http://www.latex-project.org/

http://www.compactflash.org/


[18] CompactFlash Association: CF+ and CompactFlash Specification Revision3.0. Palo Alto, CA 94303, Dezember 2004

[19] Shanley, Tom ; Anderson, Don: PCMCIA System Architecture: 16-Bit PCCards. 2. 75 Arlington Street, Suite 300, Boston, MA 02116 : Addison-Wesley,1995. – ISBN 0–201–40991–7

[20] Shanley, Tom ; Anderson, Don: PCI System Architecture. 4. 75 ArlingtonStreet, Suite 300, Boston, MA 02116 : Addison-Wesley, 1999. – ISBN 0–201–30974–2

[21] Intel Corporation. http://www.intel.com, Abruf: Dez. 2005

[22] PCI Special Interest Group. http://www.pcisig.com/home, Abruf: Dez. 2005

[23] PC/104 Embedded Consortium: PC/104-Plus Specification Version 2.0. SanFrancisco, CA 94107-8008, November 2003

[24] T13 Kommitee. http://www.t13.org/, Abruf: Dez. 2005

[25] T13-Kommittee: Information Technology – AT Attachment with Packet Inter-face 7, Revision 4b, Vol. 1: Register Delivered Command Set, Logical RegisterSet; Vol. 2: Parallel Transport Protocols and Physical Interconnect; Vol. 3: SerialTransport Protocols and Physical Interconnect. ANSI INCTS, April 2004

[26] Fraunhofer Gesellschaft: Batterie-Glossar. http://www.ict.fhg.de/deutsch/scope/ae/bg.html, Abruf: Dez. 2005

[27] O’Quin, Jack: Realtime Linux Security Module. http://sourceforge.net/projects/realtime-lsm/, Abruf: 20.03.2006

[28] HörTech gGmbH: MHA Developers Reference Handbook. Version: 2005. http://www.hoertech.de/

[29] Butz, Tilman: Fouriertransfromation für Fußgänger. 1. Stuttgart; Leipzig :B.G. Teubner, 1998. – ISBN 3–519–00202–7

[30] Electronic Assembly: Datasheet LCD-Module EA DIP122-5, Dezember 2004

[31] Electronic Assembly GmbH: Electronic Assembly, Lochhammer Schlag 17,D-82166 Gräfelfing. http://www.lcd-module.de, Abruf: Aug. 2006

[32] Maxim Integrated Products: Switched-Capacitor Voltage Converters, 19-4667; Rev 1; 7/94. 120 San Gabriel Drive, Sunnyvale, CA 94086, 2004

[33] Maxim Integrated Products: Dallas Semiconductor / Maxim. http://www.maxim-ic.com/, Abruf: 02.10.2006

[34] Atmel Corp.: 8-Bit Microcontroller with 4k Bytes Flash AT89C4051, Doc.-Nr.: 1001E-MICRO-6/05. 2325 Orchard Parkway, San Jose, CA 95131, USA,2005

190

http://www.intel.com

http://www.pcisig.com/home

http://www.t13.org/

http://www.ict.fhg.de/deutsch/scope/ae/bg.html

http://www.ict.fhg.de/deutsch/scope/ae/bg.html

http://sourceforge.net/projects/realtime-lsm/

http://sourceforge.net/projects/realtime-lsm/

http://www.hoertech.de/

http://www.hoertech.de/

http://www.lcd-module.de

http://www.maxim-ic.com/

http://www.maxim-ic.com/


[35] Atmel Corp.: Atmel, 2325 Orchard Parkway, San Jose, CA 95131, USA.http://atmel.com, Abruf: Aug. 2006

[36] Maxim Integrated Products: +5V-Powered, Multichannel RS-232 DriversReceivers; 19-4323, Rev.: 14, 8/04. 120 San Gabriel Drive, Sunnyvale, CA 94086,2004

[37] Altera Corporation: CycloneII Device Handbook Vol. 1, 2005. – Dok.-Nr.:CII5V1-2.2

[38] Altera Corporation: Configuration Handbook Vers. 2.0, Volume 1,2, 2004

[39] Cypress Semiconductor Corporation: 4-MBit (256k x 16Bit) SRAM,Doc.-Nr.: 38-05134 Rev.*G, 2006

[40] Cypress Semiconductor Corporation: Cypress Semiconductor Corporati-on. http://www.cypress.com, Abruf: Okt. 2006

[41] Parallax Inc.: Stratix 672 Smart Pack, Juni 2003. – Dok.-Nr.: 60001

[42] Parallax Inc. http://www.parallxinc.com, Abruf: Mär. 2006

[43] Altera Corporation: Stratix Device Handbook Vol. 1, 2005. – Dok.-Nr.:S5V1-3.2

[44] Altera Corporation: ByteBlaster II Download Cable User Guide, Vers.: 1.1,2004. – Dok.-Nr.: UG-BBII81204-1.1

[45] Kontron Embedded Modules AG: speedMOPSlcdCE User’s Guide Revision1.0, 2005

[46] Kontron Embedded Modules AG. http://www.kontron.de, Abruf: Jan. 2006

[47] PC/104 Embedded Consortium: PC/104 Specification Version 2.5. SanFrancisco, CA 94107-8008, November 2003

[48] xfce Team: xfce Desktop Environment. http://www.xfce.org/, Abruf:Okt. 2006

[49] Gentoo Foundation: http://www.gentoo.org/doc/de/, Abruf: Okt. 2006

[50] Molnár, Ingo: Homepage von Ingo Molnár. http://people.redhat.com/mingo/, Abruf: Nov. 2006

[51] JACK Project. http://jackit.sourceforge.net/, Abruf: Dez. 2005

[52] The Tcl Core Team. http://www.tcl.tk/, Abruf: Okt. 2006

[53] Bovet, Daniel P. ; Cesati, Marco: Understanding the Linux Kernel. 3. Berlin,Heidelberg : O’Reilly, 2005. – ISBN 0–5960–0565–2

[54] Altera Corporation: Avalon Interface Specification Reference ManualVers. 2.4, Januar 2004

191

http://atmel.com

http://www.cypress.com

http://www.parallxinc.com

http://www.kontron.de

http://www.xfce.org/

http://www.gentoo.org/doc/de/

http://people.redhat.com/mingo/

http://people.redhat.com/mingo/

http://jackit.sourceforge.net/

http://www.tcl.tk/


[55] Altera Corporation: Single- & Dual-Clock FIFO Megafunction User Guide,September 2005. – Dok.-Nr.: 3.2

[56] Altera (Hrsg.): Avalon Intervace Specification. Version: 2005. http://www.altera.com/literature/manual/mnl_avalon_spec.pdf, Abruf: 10.12.2005

[57] Smith, Steven W.: The Scientist and Engineer’s Guide to Digital Signal Pro-cessing. 1. P.O. Box 502407, San Diego, CA 92150-2407 : California TechnicalPublishing, 1997. – ISBN 0–9660176–3–3

[58] Altera: PCI Compiler: 32-Bit Master/Target MegaCore Function.http://www.altera.com/products/ip/iup/pci/m-alt-pci_mt32.html, Ab-ruf: 01.10.2006

[59] Gentoo Foundation, Inc.: Gentoo. http://www.gentoo.org/, Abruf:20.03.2006

[60] Pettersson, M.: Perfctr manual. http://user.it.uu.se/~mikpe/linux/perfctr/, Abruf: 20.03.2006

[61] ALSA Project. http://www.alsa-project.org/, Abruf: Dez. 2005

[62] Intel Corporation: IA-32 Intel Architecture Software Developer’s Manual,Volume 3B, Part 2. http://www.intel.de/, Abruf: 20.03.2006

[63] AMD Corporation: AMD64 Architecture Programmer’s Manual Volume 2.http://www.amd.de/, Abruf: 20.03.2006

192

http://www.altera.com/literature/manual/mnl_avalon_spec.pdf

http://www.altera.com/literature/manual/mnl_avalon_spec.pdf

http://www.altera.com/products/ip/iup/pci/m-alt-pci_mt32.html

http://www.gentoo.org/

http://user.it.uu.se/~mikpe/linux/perfctr/

http://user.it.uu.se/~mikpe/linux/perfctr/

http://www.alsa-project.org/

http://www.intel.de/

http://www.amd.de/

Index

AAkkumulator . . . . . . . . . . . . . . . . . . . . . . . . 48

Blei-Gel . . . . . . . . . . . . . . . . . . . . . . . . . 49Blei-Säure . . . . . . . . . . . . . . . . . . . . . . . 49Lithium-Ion . . . . . . . . . . . . . . . . . . . . . 49Nickel-Kadmium . . . . . . . . . . . . . . . . 49Nickel-Metall-Hydrid . . . . . . . . . . . . 49

Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Anzeigesteuerung . . . . . . . . . . . . . . . . 91, 97ASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47ATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Auslagerungsstrategie . . . . . . . . . . . . . . . 36

BBefehlsregister . . . . . . . . . . . . . . . . . . . . . 115Beschleuniger . . . . . . . . . . . . . . . . . . . . 91, 97bmp2array.exe . . . . . . . . . . . . . . . . . . . . . . 97Boot-RAM . . . . . . . . . . . . . . . . . . . . . . . . . 114Bootstrapping . . . . . . . . . . . . . . . . . . . . . 104Busbelastung . . . . . . . . . . . . . . . . . . . . . . . 40Busstandards . . . . . . . . . . . . . . . . . . . . . . . 43

CCompact Flash (CF) . . . . . . . . . . . 44, 102Compiler-Optionen . . . . . . . . . . . . . . . . . 104

DDatenpaket . . . . . . . . . . . . . . . . . . . . . . . . . 93Datenpakete . . . . . . . . . . . . . . . . . . . . . . . . 55display.exe . . . . . . . . . . . . . . . . . . . . . . . . . . 97DSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

EEntladestrom . . . . . . . . . . . . . . . . . . . . . . . 48Entwicklungssystem . . . . . . . . . . . . . . . . 102Entwicklungsumgebung . . . . . . . . . . . . 102equalize . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Ffader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Fast-Fourier-Transformation . . . . . . . . . 36Fehlerbit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Fehlernummer . . . . . . . . . . . . . . . . . . . . . . . 95Fehlerpaket . . . . . . . . . . . . . . . . . . . . . . . . . 94

FFT siehe Fast-Fourier-Transformation,174

fftfilterbank . . . . . . . . . . . . . . . . . . . . . . . . 174FIFO-Peek-Register . . . . . . . . . . . . . . . . 118Fließkommaoperation . . . . . . . . . . . . 36, 40Fließkommazahl . . . . . . . . . . . . . . . . . . . . . 40FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

GGentoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Gesamtsystems . . . . . . . . . . . . . . . . . . . . . . 91global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

IIdentitätskette . . . . . . . . . . . . . . . . . . . . . 174iFFT . . . . . . . . . . . . . . . . . . . . . siehe inverse

Fast-Fourier-Transformation, 174Industrie-PC . . . . . . . . . . . . . . . 30, 91, 101Instanz-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 93Interkommunikation . . . . . . . . . . . . . . . . . 59Intrakommunikation . . . . . . . . . . . . 59, 114inverse Fast-Fourier-Transformation . 36

KKernel . . . . . . . . . . . . . . . . . . . . . . . . 104, 171Kette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Kommunikationsprotokoll . . . . . . . . . . . 93Konfigurationsbit . . . . . . . . . . . . . . . . . . . 93Konfigurationspaket . . . . . . . . . . . . . . . . . 93Konfigurationspakete . . . . . . . . . . . . . . . . 55

LLocal-Bus-Controller . . . . . . 61, 113, 115Loop-Device . . . . . . . . . . . . . . . . . . . . . . . 113low-level . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Mmatrixmixer . . . . . . . . . . . . . . . . . . . . . . . 174Memory-Effekt . . . . . . . . . . . . . . . . . . . . . . 49MHA-Adapter-Plugins . . . . . . . . . . . . . 108MYGERMS . . . . . . . . . . . . . . . . . . . . . . . . 112

PPaketlänge . . . . . . . . . . . . . . . . . . . . . . . . . . 93Plus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

193

Index

PCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44PCI-Core . . . . . . . . . . . . . . . . . . . . . . . . . . 114PCI-FPGA . . . . . . . . . . . . . . . . . . . . . . . . 113PCI-Kern . . . . . . . . . . . . . . . . . . . . . 120, 121PCISIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44PDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31perfctr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172Performance Monitor Counters . . . . . 172Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Plugin-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Prozessorlast . . . . . . . . . . . . . . . . . . . . . . . . 37

RReferenzkette . . . . . . . . . . . . . . . . . . . . . . 174Referenzsystem . . . . . . . . . . . . . . . . . . . . . 37relative Auslastung . . . . . . . . . . . . . . . . . . 39rmslevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

SSchaltungsentwurf . . . . . . . . . . . . . . . . . . . 95Schnittstellen . . . . . . . . . . . . . . . . . . . . . . 102Soundkarte . . . . . . . . . . . . . . . . . . . . . . . . 172Spannungsversorgung . . . . . . . . . . . . . . 100spec2wave . . . . . . . . . . . . . . . . . . . . . . 37, 174Spielekonsole . . . . . . . . . . . . . . . . . . . . . . . . 31Statusregister . . . . . . . . . . . . . . . . . 116, 122

TTastatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96TCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Testergebnisse . . . . . . . . . . . . . . . . . . . . . . . 37Testhardware . . . . . . . . . . . . . . . . . . . . . . 172Tiefentladung . . . . . . . . . . . . . . . . . . . . . . . 48Transferart . . . . . . . . . . . . . . . . . . . . . . . . . . 44

UÜbertragungsprotokoll . . . . . . . . . . . . . . 97Übertragungsrate . . . . . . . . . . . . . . . . . . . 42Universal Serial Bus . . . . . . . . . . . . . . . . . 45USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45USB-Host . . . . . . . . . . . . . . . . . . . . . . . 45

VVESA VL . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Wwave2spec . . . . . . . . . . . . . . . . . . . . . . 37, 174

Xx86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

194

Documents

Abschlussbericht - boles.de · 2.5 Anforderungen an die Infrastruktur ... 5.8 Überblick über die Struktur des MHA-FPGAs ... 5.24 Zustandsautomat der Hanning-Komponente