Entwicklung von Ansteuerungs- und Datenerfassungssoftware für

Transcription

Entwicklung von
Ansteuerungs- und Datenerfassungssoftware
für das akustische
Navigationssystem des Enceladus Explorer
Projekts
von
Stefan Wickmann
Bachelorarbeit in P H Y S I K
vorgelegt der
Fakultät für Mathematik, Informatik und
Naturwissenschaften
der Rheinisch-Westfälischen Technischen Hochschule Aachen
im
August 2013
angefertigt am
III. Physikalischen Institut B
Prof. Dr. Christopher Wiebusch
Inhaltsverzeichnis
Inhaltsverzeichnis
Abkürzungen
3
1. Einleitung
5
2. Akustische Umfelderkundung (ARS)
2.1. Konzept des Phasenarrays . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Konzept des Datenerfassungssystems . . . . . . . . . . . . . . . . . . . .
7
7
7
3. Technologie
3.1. PCI Express . . . . . . . . . . . . . . . . .
3.1.1. Protokoll der Transaktionsschicht &
3.1.2. Speicherleseanfrage/Antwort . . . .
3.1.3. Speicherschreibanfrage . . . . . . .
3.2. Linux-Gerätetreiber . . . . . . . . . . . . .
3.3. FPGA & VHDL . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
10
11
13
13
14
4. Testsystem zur Datenerfassung
4.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1. Xilinx Spartan 6 . . . . . . . . . . . . . . . . .
4.1.2. Avnet Spartan 6 LX75T PCIe Entwicklungskit .
4.1.3. Adlink nanoX-TC . . . . . . . . . . . . . . . . .
4.1.4. Adlink nanoX Starter Kit . . . . . . . . . . . .
4.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1. Fedora 18 . . . . . . . . . . . . . . . . . . . . .
4.2.2. Xilinx ISE Design Suite . . . . . . . . . . . . .
4.3. Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1. Inbetriebnahme Spartan 6 Entwicklungskit . . .
4.3.2. Entwicklungs- & Testsystem . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
15
15
15
16
17
17
17
17
17
18
5. Ansteuerungs- und Datenerfassungssoftware für ARS
5.1. FPGA . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1. Module . . . . . . . . . . . . . . . . . . . .
5.2. Linux-Gerätetreiber . . . . . . . . . . . . . . . . . .
5.2.1. Datenstrukturen . . . . . . . . . . . . . . .
5.2.2. Funktionen . . . . . . . . . . . . . . . . . .
5.3. Messung der Übertragungsgeschwindigkeit . . . . .
5.3.1. Durchführung . . . . . . . . . . . . . . . . .
5.3.2. Diskussion . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
20
20
26
26
27
28
28
29
6. Fazit und Ausblick
. . . .
TLPs
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
1
Inhaltsverzeichnis
A. Literatur
32
B. Abbildungsverzeichnis
34
C. Tabellenverzeichnis
35
D. Signaltabellen
36
2
Abkürzungen
Abkürzungen
ADC Analog to Digital Converter (Analog-Digital-Umsetzer)
APS Acoustic Positioning System (akustisches Positionierungssystem)
ARS Acoustic Reconnaissance System (akustisches Umfelderkundungssystem)
ATX Advanced Technology Extended (Norm für Platinen im Computerbereich)
COM Computer-on-module
CplD Completion with Data Packet (Antwortdatenpaket mit Daten)
CRC Cyclic Redundancy Check (zyklische Redundanzprüfung)
DLLP Data Link Layer Packet (Datenpaket der PCIe-Verbindungsschicht)
DMA Direct Memory Access (Speicherdirektzugriff)
DW Double Word (32 Bit breites Datenwort)
EnEx Enceladus Explorer
FPGA Field Programmable Gate Array (im Anwendungsfeld konfigurierbare
Logikschaltung)
FTP File Transfer Protocol (Netzwerkprotokoll zum Übertragen von Dateien)
CLB Configurable Logic Block (konfigurierbarer logischer Block)
GPS Global Positioning System (globales Satelitennavigationssystem)
JTAG Joint Test Action Group (Schnittstelle um Hardware zu testen und zu
konfigurieren)
LED Light Emitting Diode (Leuchtdiode)
LUT Lookup table (Umsetzungstabelle)
MRd Memory Read Request Packet (Datenpaket einer Speicherleseanfrage)
MWr Memory Write Request Packet (Datenpaket einer Speicherschreibanfrage)
PICMG PCI Industrial Computer Manufacturers Group
PCIe Peripheral Component Interconnect Express
PCI-SIG Peripheral Component Interconnect Special Interest Group
PLP Physical Layer Packet (Datenpaket der physikalischen PCIe-Schicht)
RAM Random Access Memory (Speicher mit wahlfreiem Zugriff)
3
Abkürzungen
SBC Single Board Computer (Einplatinencomputer)
TLP Transaction Layer Packet (Datenpaket der PCIe-Transaktionschicht)
USB Universal Serial Bus (serielles Bussystem)
VHDL Very High Speed Integrated Circuit Hardware Description Language
(Hardwarebeschreibungssprache)
VNC Virtual Network Computing (Fernwartungssoftware)
XPIO Xilinx PCIe Programmed Input/Output Example Design (PCIe Beispieldesign
von Xilinx
4
1. Einleitung
1. Einleitung
Im Jahr 2009 entdeckte die Sonde Cassini während eines nahen Vorbeiflugs am SaturnEismond Enceladus in den von Enceladus ausgestoßenen Wassereisfontänen salzhaltige
Eispartikel und Ammoniak [9].
Diese Eispartikel können nicht aus der Eiskruste des Eismondes stammen, da in der Regel während des Gefrierprozesses von Salzwasser das Salz aus dem Eis heraus gedrückt
wird. Daher liegt die Vermutung nahe, dass flüssiges Salzwasser aus Wasserreservoiren unterhalb der Eiskruste durch die Aktivität von Eisvulkanen an die Oberfläche des
Enceladus geschleudert werden. [10]
Die Verifizierung der Vermutung von vorhandenen Wasserreservoiren, die eine Annahme
der Existenz von organischem Leben auf Enceladus impliziert, war die Motivation für
das Projekt Enceladus Explorer“ (EnEx), das von dem Forschungszentrum der Bundes”
republik Deutschland für Luft- und Raumfahrt (DLR) ins Leben gerufen wurde. Dabei
geht es um die Entwicklung eines neuen Sondenkonzepts, mit dessen Hilfe man in der
Lage sein wird, in die vermuteten Wasserreservoire vorzudringen und verschiedene Arten
von Proben zu entnehmen. [6]
Das Projekt EnEx hat zum Ziel, die Realisierung einer möglichen Exploration der Wasservorkommen auf Enceladus in terrestrischen Testszenarien zu untersuchen.
Teil des EnEx-Projekts ist der an der FH Aachen entwickelte Eisroboter IceMole“.
”
Dieser ist in der Lage, sich sowohl durch das Eis zu schmelzen, als auch zu ziehen.
Das Schmelzen erfolgt durch am Roboterkopf angebrachte Heizelemente, der Zug wird
mittels einer mittig im Roboterkopf eingebrachten Schraube erreicht. Somit ist es ihm
möglich, sich im Eis auch entgegen der Schwerkraft fortzubewegen. Heizelemente an den
Seiten des IceMoles ermöglichen zusätzlich Kurvenfahrten. [11]
Da auf Enceladus keine externen Navigationssysteme, wie GPS o.ä. vorhanden sind,
müssen Navigationssysteme bereitgestellt werden, um den IceMole sinnvoll einsetzen zu
können.
Neben geplanten inertialen Navigationssystemen existiert schon ein an der RWTH Aachen entwickeltes, akustische Positionierungssystem (APS). Dieses misst im IceMole die
Laufzeiten von Schallpulsen, die von an der Eisoberfläche sitzenden Schallsendern ausgestrahlt werden. Durch Triangulation ist somit eine Positionierung des IceMoles möglich.
Zudem soll ein Umfelderkundungssystem basierend auf Phasenarrays (ähnlich Ultraschallphasenarrays in der Medizin) eingesetzt werden. Ein solches Umfelderkundungssystem sichert sowohl die Sondierung der Umgebungsbeschaffenheit zur geeigneten Probenahme, als auch die Gewährleistung der ständigen Manövrierfähigkeit des IceMoles,
indem es Hindernisse, wie z.B. Spalten und Fremdkörper rechtzeitig erkennt.
5
1. Einleitung
Zielsetzung der vorliegenden Arbeit ist, basierend auf der Inbetriebnahme eines Testsystems eine Ansteuerungs- und Datenerfassungssoftware für ein solches Umfelderkundungssystem zu entwickeln. Hierbei muss besonderes Augenmerk auf die sich ergebenden Anforderungen bezüglich der anfallenden Datenmenge und der daraus folgenden
Datenübertragungsgeschwindigkeit gelegt werden.
6
Die akustische Umfelderkundung (ARS, Acoustic Reconnaissance System) im IceMole
besteht im Wesentlichen aus mehreren, im Kopf des IceMoles untergebrachten Phasenarrays und einem Kontroll- und Datenerfassungssystem im Rumpf des IceMoles.
2.1. Konzept des Phasenarrays
Die im Kopf des IceMoles verbauten Schallphasenarrays bestehen aus 16 piezokeramischen, linear angeordneten Elementen aus Blei-Zirkonat-Titanat (PZT) mit einer Resonanzfrequenz von ca. 750 kHz. Diese Elemente können phasengesteuert mit elektrischen
Pulsen angeregt werden, sodass durch Interferenz eine gerichtete Schallwelle entsteht.
Diese Welle wird reflektiert und von den Elementen des Schallphasenarrays detektiert.
Die Elemente des Phasenarrays werden also sowohl zur Erzeugung, als auch zur Detektierung von Schallwellen eingesetzt.
Aus der Laufzeit zwischen Aussenden und Empfangen der Pulse und der Schallgeschwindigkeit in Eis kann so die Entfernung zwischen dem Schallphasenarray und dem Reflektionspunkt der Schallwelle bestimmt werden.
Mithilfe dieser Methode ist es möglich, ein Winkelspektrum auszumessen und einen
Schnitt durch die Umgebung zu erhalten. Im Kopf des IceMoles ist für vier Schallphasenarrays Platz vorgesehen, die kreuzförmig angeordnet sind (siehe Abbildung 1). Somit
existieren 64 Einzelelemente, also 64 Kanäle, die angesteuert und ausgelesen werden
müssen. Bei einer Digitalisierungsauflösung von 12 Bit und eine Digitalisierungsrate von
10 MSamples/s ergibt sich eine Datenrate von ca. 229 MB/s pro Phasenarray. Daher
bedarf es einer schnellen Datenverbindung zwischen Ausleselektronik und dem datenverarbeitenden Computermodul um diese Datenmengen zu übertragen. (vgl. [8])
2.2. Konzept des Datenerfassungssystems
Im IceMole sind die einzelnen Subsysteme modular in separaten Boxen untergebracht.
Durch die kompakte Bauweise des IceMoles steht für diese Subsysteme nur ein begrenzter
Raum zur Verfügung. Daher müssen die einzelnen Subsysteme platzsparend aufgebaut
sein (siehe Abbildung 2). Dies stellt hohe Anforderungen an die Komponenten der Akustikbox, da diese trotz ihrer kleinen Bauform genug Leistung benötigen, um die Daten
des ARS zu verarbeiten.
Wie in Abbildung 3 zu sehen ist, befindet sich in der Akustikbox neben dem ARS (rot)
zusätzlich das APS (grün) und eine Versorgungsplatine (gelb), die die Systeme mit Strom
versorgt und für das APS ein Synchronisationssignal bereitstellt.
7
Abbildung 1: Schallphasenarrays im IceMolekopf [8].
Das ARS ist modular aus mehreren Platinen aufgebaut. Auf der ARS-Hauptplatine
(ARS-Mainboard) befindet sich als zentrales Bauteil ein FPGA, der das ARS-System
steuert. Er veranlasst die Generierung von Pulsen auf der MOSFET-Array-Platine, die
dann über die ARS-Relay-Platine zu den Schallphasenarrays im Kopf des IceMoles gesendet werden. Die Steuerung, d.h. die Auswahl des jeweiligen Schallphasenarrays, der
ARS-Relais-Platine, die sich im Kopf des IceMoles befindet, übernimmt ebenfalls der
FPGA. Über die Analog-Digital-Umsetzer-Arrays (ADCs Array) werden die Daten dann
in einen Zwischenspeicher (RAM) geschrieben, um danach zur Platine des Embedded
PC transferiert zu werden.
Die Platinen des ARS-Systems befinden sich zu dem Zeitpunkt dieser Arbeit noch in
der Entwicklung.
8
9,7 cm
28,4 cm
Abbildung 2: Aufsicht in die offene Akustikbox mit eingebautem APS, die Tiefe der
Akustikbox beträgt ca. 10 cm.
Abbildung 3: Schema der Platinen in der Akustikbox (links) und Ankopplung der Sensorplatinen im IceMolekopf (rechts). Gelb: Versorgungsplatine, Grün: APS,
Rot: ARS [7].
9
3. Technologie
3. Technologie
3.1. PCI Express
Der Peripheral Component Interconnect Express Standard (PCIe) ist ein Busstandard,
um Peripheriegeräte mit dem Chipssatz eines Prozessors zu verbinden. Er wird von
der Peripheral Component Interconnect Special Interest Group (PCI-SIG) verwaltet und
weiterentwickelt. Im Gegensatz zu seinen Vorgängern PCI und PCI-X, bei denen sich
viele Geräte einen parallelen Bus teilen, ist der PCIe Bus ein paketbasierter serieller Bus
mit Sterntopologie.
Dabei werden die einzelnen Geräte über Verteiler (Switches) miteinander verbunden.
Diese Punkt-zu-Punkt Verbindungen nennt man Links. Sie bestehen, je nach Anwendung, aus bis zu 32 differentiellen Signalpaaren, genannt Lanes. Die Daten werden pro
Signalpaar und Richtung mit einer Geschwindigkeit von 2,5 Gbit/s übertragen.
Da kein dediziertes Taktsignal übertragen wird, muss es aus den übertragenen Daten
gewonnen werden. Um diese Taktrückgewinnung robust zu gestalten, werden die zu
übertragenen Daten mit der 8b/10b Codierung codiert. Dabei werden alle 8 Bit Zeichen
durch 10 Bit Codewörter ersetzt, sodass eine genügende Anzahl von 1 zu 0“ und 0 zu 1“
”
”
Übergängen im Signal vorhanden ist, um das Taktsignal sicher rückgewinnen zu können.
Aufgrund dieser Codierung reduziert sich die Datenübertragungsrate der Nutzdaten auf
250 MB/s, da für jedes Byte 10 Bit übertragen werden müssen. (vgl. [5], Kapitel 1)
PCI Express besteht aus drei Schichten und ihren dazugehörigen Datenpaketen: Physikalische Schicht & Physical Layer Packets (PLPs), Verbindungsschicht & Data Link Layer
Packets (DLLPs) und Transaktionschicht & Transaction Layer Packets (TLPs). PLPs
und DLLPs werden für die PCIe Energieverwaltung und den Austausch von Flusskontrollinformationen benutzt. Des Weiteren bestätigen DLLPs über das sog. ACK/NAKProtokoll den Erhalt oder Nicht-Erhalt von TLPs. Auf diese Pakettypen wird im folgenden nicht mehr eingegangen (weiterführende Informationen siehe [5] Kapitel 4, 11).
3.1.1. Protokoll der Transaktionsschicht & TLPs
Mithilfe des Protokolls der Transaktionsschicht werden über TLPs PCIe-Transaktionen
übertragen. Wie in Abbildung 4 zu sehen, startet die Generierung der TLPs in der
Transaktionsschicht. Hier wird der Kern des TLP, bestehend aus Header und/oder Daten, erstellt und anschließend in der Verbindungsschicht eine Sequenznummer, sowie eine
CRC-Prüfsumme hinzugefügt.
Vor seiner Übertragung wird das TLP von der physikalischen Schicht außerdem mit
Start- und Endzeichen ausgestattet. Die PCIe-Transaktionen unterteilen sich in die Kate-
10
3. Technologie
gorien Speicher-, Eingabe und Ausgabe-, Konfigurations- und Nachrichtentransaktionen.
Es existieren dabei quittierte (Non-Posted ) und nicht quittierte (Posted ) Transaktionen.
Bei Erhalt eines TLPs einer Non-Posted -Transaktion, quittiert der Empfänger den Erhalt mit einem TLP. Posted -Transaktionen werden dagegen nicht quittiert. Dies kann
sich positiv auf die Geschwindigkeit der Datenübertragung auswirken. (vgl. [5], Kapitel
2)
In der PCIe Spezifikation sind zwei Klassen von Speichertransaktionen definiert: Speicherleseanfrage in Verbindung mit einer Antworttransaktion und Speicherschreibanfrage.
Diese Transaktionen und ihre dazugehörigen TLPs werden nachfolgend näher erläutert.
Transaktionsschicht
Verbindungsschicht
Physikalische Schicht
Start
Header
Daten
Sequenznr.
Header
Daten
LCRC
Sequenznr.
Header
Daten
LCRC Ende
Abbildung 4: Schichtweiser Aufbau (von oben nach unten) von TLPs durch die verschiedenen PCIe-Schichten. Erläuterungen siehe Abschnitt 3.1.1 (vgl. [5],
S.73).
3.1.2. Speicherleseanfrage/Antwort
Eine Speicherleseanfrage besteht aus einem TLP mit einem drei oder vier Doppeldatenwörter (DW) großem Header, je nachdem ob eine 32 Bit Addressierung oder 64 Bit
Addressierung gewählt wird.
Der Sender (Requester ) sendet ein Speicherleseanfrage-TLP (MRd), der Empfänger
(Completer ) empfängt das Paket, verarbeitet es, d.h. er stellt die angeforderten Daten bereit, generiert im Normalfall, d.h. wenn das empfangene TLP nicht fehlerhaft ist,
ein Antwort-TLP (CplD) und sendet dieses zurück an den Sender.
Der Header eines MRd ist wie in Abbildung 5 aufgebaut. Das Requester ID Feld identifiziert den Sender eindeutig, sodass ein CplD an ihn zurück gesendet werden kann. Das
Requester ID Feld besteht aus der PCIe Busnummer, Gerätenummer und Funktionsnummer der PCIe-Hardware. Das FMT - und Type-Feld definiert die Art des TLP, also
in diesem Fall eine Speicheranfrage mit entweder 3 DWs oder 4 DWs. Die im Feld Lenght angegebene Zahl beschreibt die angeforderte Anzahl an DWs ab der im Feld Address
angegebenen Adresse. Die Adresse bestimmt auch den Empfänger des MRd, indem das
Gerät im PCIe-Subsystem ermittelt wird, das den Adressbereich, in dem diese Adresse
liegt, zugewiesen bekommen hat.
11
3. Technologie
Bitpos.
DW1
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
FMT
Type
DW2
TC
Requester ID
Tag
DW3
Bitpos.
DW1
DW2
TD EP Attr
Length
Last DW BE
1st DW BE
Address [31:2]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
FMT
Type
TC
TD EP Attr
Requester ID
Tag
DW3
Address [63:32]
DW4
Address [31:2]
Length
Last DW BE
1st DW BE
Abbildung 5: Headerstruktur einer 3 DWs (oben) bzw. 4 DWs (unten) Speicheranfrage,
erste Spalte: Bitposition, weitere Spalten: DWs (vgl. [5], S.175).
Abbildung 6 zeigt die Struktur eines Headers des vom Empfänger zurückgesendeten
CplD. Er ist ähnlich aufgebaut wie der Header eines MRd und hat stets die Größe von
drei DWs. Das Requester ID-Feld hat hierbei denselben Wert wie das Requester ID-Feld
im MRd.
Das Feld Completer ID identifiziert den Empfänger des MRd und damit den Sender des
CplD. Das Length-Feld gibt die Anzahl der nach dem Header folgenden DWs an, also
die Anzahl der eigentlichen Daten-DWs. Die Anzahl der noch zu übermittelnden Bytes
wird im Feld Byte Count angegeben. Wenn eine Speicherleseanfrage auf mehrere CplD
aufgeteilt wird, ist dieses Feld nicht Null. Information zu allen nicht erwähnten Feldern
finden sich in [5] Kapitel 4, S. 174 ff., Tabellen 4-7 und 4-9.
12
3. Technologie
Bitpos.
DW1
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
FMT
Type
TC
DW2
Completer ID
DW3
Requester ID
TD EP Attr
B
Cpl Status C
M
Tag
Length
Byte Count
Lower Address
Abbildung 6: Headerstruktur eines CplD (erste Spalte: Bitposition, weitere Spalten:
DWs vgl. [5], S.184).
3.1.3. Speicherschreibanfrage
Eine Speicherschreibanfrage besteht wie die Speicherleseanfrage aus einem TLP mit einem drei oder vier DWs großem Header mit der gleichen Struktur (Abbildung 5). Darauf
folgen Daten-DWs, in der in dem Length-Feld angegebenen Anzahl. Der Empfänger eines
Speicherschreibanfrage-TLPs (MWr) sendet kein Antwortpaket an den Sender zurück,
da es sich hier, laut PCIe Spezifikation, um eine nicht quittierte (Posted ) Transaktion
handelt.
3.2. Linux-Gerätetreiber
Gerätetreiber werden unter Linux üblicherweise als Kernelmodul erstellt. Ein Kernel Modul erweitert den Linuxkernel, dies ist der Hauptteil des Linux Betriebssystems, indem
es in den Kernel geladen wird. Dadurch wird der Programmcode des Moduls im Kernelspeicherbereich ausgeführt und hat somit direkten Zugriff auf das Eingabe/AusgabeSubsystem, dies ist für einen mit Hardware interagierenden Treiber zwingend erforderlich.
Durch die Anmeldung des Kernelmoduls bei dem Linux-Treibersystem und die Erstellung einer Gerätedatei (Inode) im Dateisystem, wird das Linux-Kernelmodul erst zu
einen Linux-Gerätetreiber. Die Gerätedatei ermöglicht Programmen, die im Nutzerbereich des Speichers ausgeführt werden, auf die Hardware mittels den Standard Unix
Systemaufrufen zuzugreifen. Das Kernelmodul transferiert dann die Daten vom Nutzerzum Kernelspeicherbereich und umgekehrt. Das Implementieren der Standard Unix Systemaufrufe durch das Kernelmodul ist bei diesem Vorgang essentiell. (vgl. [13], Kapitel
5.2)
13
3. Technologie
3.3. FPGA & VHDL
VHDL (Very High Speed Integrated Circuit Hardware Description Language) ist eine
abstrakte Hardwarebeschreibungssprache. Die Hardware wird dabei in Funktionsblöcke
(engl. entity) unterteilt. Innerhalb dieser Blöcke werden die Schnittstellen (engl. port)Deklarationen nach außen beschrieben.
Jeder Funktionsblock besitzt mindestens eine Funktionsbeschreibung (engl. architecture), in der die Funktionalität des Blocks beschrieben wird.
Vergleicht man einen VHDL-Entwurf mit herkömmlicher Hardware, so stellt der Funktionsblock das Chipgehäuse mit den einzelnen Pins und die Funktionsbeschreibung das Innenleben, also den Chip selbst dar. VHDL unterstützt auch das Zusammenschalten durch
Signale solcher Blöcke in einem anderen Block. So entsteht nach und nach eine abstrakte
logische Schaltung, die dann von einem VHDL-Simulator simuliert und getestet werden
kann. Anhand dieser abstrakten Beschreibung wird dann von einem VHDL-Syntheziser
ein konkretes Hardwaredesign synthetisiert und gleichzeitig optimiert. Dies bedeutet
die Erstellung einer Netzliste, nach deren Schema anschließend integrierte Schaltungen
gefertigt werden können. Alternativ ist es auch möglich und zur Verifikation des Schaltungsdesigns üblich, einen Konfigurationsdatenstrom zu generieren, der in der Folge
direkt in einen FPGA (Field Programmable Gate Array) geladen werden kann.
Ein FPGA ist ein RAM-basierter Schaltkreis, der im wesentlichen aus Wahrheitstabellen
(LUTs, Look-up-Tables) besteht, die gemäß eines Konfigurationsdatenstroms verschaltet
werden, sodass zusammen mit den Ein-/Ausgängen des FPGA eine Logikschaltung entsteht. FPGAs sind, wie der Name schon sagt, im Feld konfigurierbar, und damit flexibel.
Sie eignen sich daher gut für die Entwicklung und das Testen von Systemen, vergleicht
man sie mit integrierten Schaltkreisen (engl. integrated circuit, IC), die aufwändig und
effektiv nur in großen Stückzahlen gefertigt werden können.
FPGAs verlieren ihre Konfiguration bei Stromausfall, es ist nicht möglich, einen FPGA
dauerhaft zu konfigurieren. Aus diesem Grund werden in FPGA-Systemen oft Speicherbausteine verbaut, die der Speicherung des Konfigurationdatenstroms dienen. Beim Einschalten des FPGA Systems wird die Konfiguration aus dem Speicher in den FPGA
geladen und so ein manuelles Konfigurieren umgangen. (vgl. [14])
14
4.1. Hardware
4.1.1. Xilinx Spartan 6
Der Xilinx Spartan 6 (XC6SLX75T) Chip ist ein FPGA mit integriertem PCIe-Block,
d.h. neben den für FPGAs üblichen Elementen verfügt er über einen dedizierten Block,
der die PCIe Kommunikation übernimmt. Er besteht aus 11662 logischen Zellen mit
jeweils vier Umsetzungstabellen LUT und acht Flip-Flops, die in konfigurierbaren logischen Blöcken (engl. configurable logic block, CLB) zusammengefasst sind. Dabei werden
immer zwei Zellen zu einem CLB zusammengefasst.
Es existieren 3 verschieden Arten von Zellen, die aus vier LUTs und acht Flip-Flops
bestehen. Dabei können bei zwei der verschiedenen Zellenarten die LUTs auch als Distributed RAM oder als Schieberegister genutzt werden. Außerdem besitzt der FPGA
noch weitere dedizierte Blöcke, wie einen Taktsteuerungsblock (engl. clock managment
block), BlockRAM Blöcke (Speicherblöcke), sowie diverse Blöcke, um schnelle, differentielle Signale zu verarbeiten.
Der integrierte 1-Lane PCIe-Block ist kompatibel mit der PCIe Base 1.1 -Spezifikation
und implementiert die physikalische, die Verbindungs- und Transaktionsschicht des PCIe
Protokolls. (vgl. [17])
4.1.2. Avnet Spartan 6 LX75T PCIe Entwicklungskit
Der Avnet Spartan 6 LX75T PCIe Entwicklungskit ist als PCIe-Karte ausgelegt. Auf
der Platine befinden sich neben einem Xilinx Spartan 6 (xc6slx75t) diverse Bausteine
und Schnittstellen, die für den Betrieb des FPGA nötig sind, sowie Speicherbausteine,
Ethernet Anschluss u.a.. Der FPGA wird über eine auf der Karte verfügbare JTAGSchnittstelle konfiguriert. Die Stromversorgung der Karte ist auf zwei verschiedene Arten
möglich: über den PCIe-Steckplatz oder über ein seperates Netzgerät an einem Molex
8981 Stecker. (vgl. [4])
4.1.3. Adlink nanoX-TC
Der Adlink nanoX-TC Computer ist ein Computer-on-module (COM). Ein COM ist ein
lauffähiger Computer, bei dem sich alle Komponenten auf einer einzigen Leiterplatine
befinden, ein Einplatinencomputer (SBC). Im Gegensatz zu den meisten SBC benötigt
ein COM eine Trägerplatine (engl. carrier board), auf dem die Steckverbindungen und
15
Peripherieanschlüsse ausgeführt sind. Der nanoX-TC ist als Mini COM Express Type
10 -Modul ausgeführt und ist dementsprechend 55 mm breit und 84 mm lang.
COM Express ist ein Standard der PCI Industrial Computer Manufacturers Group
(PICMG), er definiert sowohl die mechanischen Abmessungen der COM Express Module
und der elektrischen Schnittstellen, als auch deren elektrischen Ausführungen. (vgl. [3],
[2])
Abbildung 7: Ober-/Unterseite des nanoX-TC COM, Abmessungen: 55 mm x 84 mm.
4.1.4. Adlink nanoX Starter Kit
Das Adlink nanoX Starter Kit enthält die Trägerplatine nanoX-Base im Standard ATXFormat (engl. Advanced Technology Extended), ein 10 Zoll Display (Hersteller: Hannstar), ein ATX Netzteil, sowie diverse Kabel und Steckverbinder, um den nanoX-TC
in Betrieb nehmen zu können. Auf dem nanoX-Base befinden sich neben diversen Anschlüssen, Switches und Diagnose-LEDs auch ein SDCard Steckplatz für das Betriebsystem und mehrere PCIe-Steckplätze. (vgl. [2])
16
4.2. Software
4.2.1. Fedora 18
Der nanoX-TC Computer wird mit dem Linux Betriebssystem Fedora 18 betrieben, da
die Treiberentwicklung unter Linux sehr gut dokumentiert und viele Beispiele quelloffen
zugänglich sind. Fedora ist aus Red Hat Linux entstanden und wird von einer weltweiten
Gemeinschaft zusammen mit der Firma Red Hat, die das Fedora Project koordiniert,
weiterentwickelt (vgl. [12]).
Die Wahl fiel unter den Linux-Betriebssystemen auf Fedora, da es im Gegensatz zu
z.B. Ubuntu den integrierten Chipsatz Intel PCH EG20T des Intel Atom Prozessors des
nanoX-TC unterstützt. Außerdem sind Treiber und Testsoftware laut Hersteller unter
Fedora getestet worden [1].
4.2.2. Xilinx ISE Design Suite
Die Xilinx ISE Design Suite ist eine integrierte Entwicklungsumgebung zur Entwicklung
von FPGA Designs. Sie stellt Programme bereit, um FPGA Designs in den Sprachen
VHDL (vgl. Abschnitt 3.3) und Verilog zu erstellen, zu editieren, zu synthetisieren, zu
simulieren und einen Konfigurationsdatenstrom zu generieren, mit denen anschließend
die Konfiguration des FPGA erfolgen kann. Es ist möglich, diese Programme ohne die
grafische Benutzeroberfläche via Kommandozeile zu bedienen. Diese Anwendungsweise
wurde in der vorliegenden Arbeit zum Teil eingesetzt.
Die Xilinx ISE Design Suite existiert u.a. mit einer kostenlosen, sog. WebPack Lizenz.
Sie unterstützt alle Low Cost FPGAs von Xilinx, ebenso wie den in dieser Arbeit verwendeten Xilinx Spartan 6 LX75T. (vgl. [18]
4.3. Aufbau
4.3.1. Inbetriebnahme Spartan 6 Entwicklungskit
Um sich mit dem Spartan 6 Entwicklungskit und der Erzeugung von VHDL-basierten
Hardwaredesign vertraut zu machen, sowie die Grundfunktionalität des Kits zu testen,
wurde der Molexstecker der Enwicklunsplatine über ein eigens dafür angefertigtes Kabel
mit einem externen Netzgerät verbunden (siehe Abbildung 8). Dies ermöglichte einen
guten Zugriff auf die auf dem Board befindlichen LEDs und Schalter.
Über einen USB-JTAG-Adapter (Xilinx USB II Cable) wurde der FPGA mithilfe der
Xilinx ISE mit kleinen, in VHDL geschriebenen Anwendungen konfiguriert. Diese An-
17
wendungen dienen dazu, sich mit der Hardwarebeschreibungssprache VHDL und insbesondere dem FPGA und dem Enwicklungskit vertraut zu machen und die erforderlichen
Abläufe bei der Hardwarentwicklung zu lernen.
Anschließend wurde die PCIe-Karte in einen PC mit Windows XP Betriebssystem verbaut, um das Xilinx Programmed Input/Output Beispieldesign (XPIO) und damit die
PCIe Funktion des Spartan 6 Entwicklungskit mittels der dem Beispiel beiligenden Windowssoftware zu testen. Mit Hilfe dieser Software ist es möglich, über PCIe die LEDs
auf dem Entwicklungskit zu steuern, sowie die Schalter auf dem Kit auszulesen.
Abbildung 8: Spartan 6 Entwicklungskit mit angeschlossenem USB-JTAG-Adapter und
externer Stromversorgung.
4.3.2. Entwicklungs- & Testsystem
Das System zum Entwickeln und Testen sowohl des FPGA-Designs, als auch des LinuxGerätetreibers, ist folgendermaßen aufgebaut: Das nanoX-Base wird zur sicheren Handhabung in ein ATX-Gehäuse eingeschraubt und mit dem ATX-Netzteil verbunden (siehe
Abbildung 9). Der NanoX-TC wird, nachdem ein Kühlkörper angefertigt, angebracht
und ein Lüfter auf diesen montiert wurde, über die COM-Express Schnittstelle auf die
nanoX-Base Platine gesteckt. Die Spartan 6 Entwicklungskit PCIe-Karte wird in einen
der PCIe-Steckplätze der nanoX-Base-Platine eingebracht, hierüber erfolgt auch gleichzeitig die Stromversorgung der Karte. Der FPGA wird über die JTAG Schnittstelle mit-
18
tels des Xilinx USB II Cable konfiguriert, bzw. es wird ein Konfigurationsdatenstrom in
den auf dem Spartan 6 Entwicklungskit vorhandenen Flashspeicher geladen.
Auf dem Computer, der zur Konfiguration des FPGA dient, ist ein FTP-Server und
ein VNC-Server installiert, somit kann die Konfiguration von einem beliebigen System
im Netzwerk erfolgen. Der nanoX-TC kann über das Secure-Shell-Netzwerkprotokoll
(SSH) konfiguriert und verwaltet werden und ermöglicht auf diese Weise das Editieren,
Kompilieren, Laden und Entladen des PCIe-Treibers von einem beliebigen Computer im
Netzwerk.
Abbildung 9: Aufbau des Entwicklungs- & Testsystems.
19
Das Datenerfassungssystem besteht aus zwei Teilen: einem Softwareteil (Linux-Kernelmodul) und einem Firmwareteil (FPGA-Design). Dabei fungiert das Linux-Kernelmodul
als Treiber für das FPGA-Design. Mit dessen Hilfe wird die Hardware im Computersystem verfügbar gemacht. Danach ist es möglich, Befehle in ein Befehlsregister in dem
FPGA zu schreiben und das FPGA-Design zur Ausführung der Befehle über das Setzen
eines Ausführungsregisters zu veranlassen.
Des Weiteren können Daten von dem Speicherbereich der Hardware gelesen und in diesen
geschrieben werden. Das FPGA-Design verarbeitet die Befehle des Treibers, z.B. den
Befehl der Datennahme. Die Datennahme wird durchgeführt, indem der Analog-DigitalUmsetzer (ADC) zur Datennahme veranlasst wird und eine Zwischenspeicherung der
Daten erfolgt. Außerdem stellt das FPGA-Design die Infrastruktur zur Kommunikation
mit dem Computersystem bereit.
5.1. FPGA
Das FPGA-Design lehnt sich an das Xilinx-PCIe-Programmed-Input/Output-Beispieldesign (XPIO) an (siehe [16]). Dieses ist ein PCIe-Basisdesign und stellt die PCIe Grundfunktionen bereit, um Speicherschreib- & Speicherlese-TLPs abzuarbeiten und generieren zu können. Das Beispieldesign bietet die Möglichkeit, Daten von dem Computer,
mittels eines speziellen Treibers, in den dafür vorgesehenen Speicherbereich auf dem
FPGA zu schreiben und wieder zu lesen. Das Beispieldesign wurde an die Anforderungen der oben genannten Funktionsweise angepasst. Hierzu wurden vorhandene Module
des XPIO genutzt, zum Teil modifiziert, und auch komplett neue Module erstellt. Diese
werden im Folgenden beschrieben.
5.1.1. Module
Wie in Abbildung 10 zu sehen, besteht das FPGA-Design aus mehreren, in der Hardwarebeschreibungssprache VHDL geschriebenen Modulen, die über Steuer- und Datenleitungen (Signale) miteinander kommunizieren.
Im Zentrum des Designs steht das ARS Memory Controller -Modul, es regelt Speicheranfragen von dem ARS DAQ Controller -Modul und von dem RX/TX Engine-Modul zu
den beiden Speicherbereichen, die von den Modulen BAR0 und BAR1 gesteuert werden. Das Modul RX/TX Engine steuert den im FPGA integrierten PCIe-Block, der die
Schnittstelle zum PCIe-Bus darstellt.
20
Das ARS DAQ Controller -Modul ist die Steuereinheit des Designs. Es steuert den
Schreibzugriff des ARS Memory Controller -Moduls, veranlasst das ARS ADC AccessModul, das die ADCs steuert, zur Datennahme und regelt das Speichern der Daten.
Die digitalen Ein- und Ausgänge (Signale) werden im weiteren Text wie folgt angegeben:
signal[hohes Bit:niedriges Bit] dabei bezeichnet die Differenz aus hohes Bit und niedriges
Bit und anschließende Addition von eins die Bitbreite des Signals. Wird der Ausdruck
mit den eckigen Klammer weggelassen, ist das Signal ein Bit breit.
Alle Module besitzen einen globalen Reset Eingang rst n und ein globales Taktsignal clk.
Wird im folgenden vom Setzen“ eines Signals gesprochen, ist damit der Übergang des
”
Signals von einem logischen Falsch zu einem logischen Wahr gemeint. Das Zurückset”
zen“ eines Signals meint entsprechend das Gegenteil. Detaillierte Informationen zu allen
Signalen der Module sind den Tabellen im Anhang D zu finden.
5.1.1.1. ARS ADC Access Das ARS ADC Access-Modul bildet die Schnittstelle zu
den ADCs, steuert diese und reicht die digitalen Daten an das ARS DAQ Controller Modul weiter. In diesem Testdesign dient das ARS ADC Access-Modul lediglich zur
Simulation der ADC-Hardware, die zum jetzigen Zeitpunkt noch nicht verfügbar ist.
Es liefert beim Setzen des daq adc capture i-Signals den konstanten, 32 Bit breiten Datenwert ’0xcafebabe’ am daq adc data o[31:0]-Datenbus und ansonsten den konstanten
Wert ’0xdeadbeef’.
5.1.1.2. ARS DAQ Controller Das ARS DAQ Controller -Modul ist die Kontrolleinheit des FPGA-Designs. Es regelt die Datennahme und das Speichern der Daten. Es
besteht im Wesentlichen aus einem Zustandsautomaten, dargestellt in Abbildung 11.
Im DAQ RST-Zustand setzt der Automat alle Werte auf ihre Anfangswerte zurück und
überwacht das Ausführungsregister des BAR0 -Moduls. Wird das Register vom Treiber
gesetzt, wird entsprechend dem Wert des Befehlsregisters (daq commad i[3:0]) der nächste Zustand ausgewählt. Im Fall der Datennahme wird der DAQ CAPTURE1-Zustand
ausgewählt. In diesem Zustand wird das ARS ADC Access-Modul zur Datennahme veranlasst und über das daq mem wr select o-Signal das ARS Memory Controller -Modul
angewiesen, den Speicherzugriff zum ARS DAQ Controller -Modul zu schalten.
Im nächsten Zustand (DAQ CAPTURE2) werden die Speicheradresse sowie die zu speichernden Daten bestimmt und im darauffolgendem Zustand (DAQ CAPTURE3) in den
Speicher geschrieben. Anschließend springt der Automat in den DAQ WAIT-Zustand,
in dem er verbleibt, bis der Speicher die Daten geschrieben hat. Danach wird Anhand des Werts der Speicheradresse der nächste Zustand ausgewählt. Ist der Wert
der Adresse kleiner als der maximale Wert, wird die Adresse inkrementiert und in
den DAQ CAPTURE2-Zustand gesprungen. Wird der maximale Wert der Adresse er-
21
reicht, wird das Ausführungsregister zurückgesetzt und der Speicherzugriff mittels des
daq mem wr select o-Signals wieder zum RX/TX Engine-Modul geschaltet. Im Folgenden wird dann in den DAQ RST-Zustand gesprungen, in dem erneut alle Signale auf den
Anfangswert gesetzt werden.
Enthält das Befehlsregister den Befehl zum Zurücksetzen des Ausführungsregisters, springt der Automat in den DAQ REGRST-Zustand. Hier wird das Befehlsregister zurückgesetzt, bevor der Automat wieder in den DAQ RST-Zustand springt.
5.1.1.3. BAR0 Das BAR0 -Modul besteht aus zwei Teilen: dem BAR0 Devices-Modul
und dem BAR0 Registers-Modul. Diese beiden Module sind dem XPIO-Beispiel (vgl.
[16]) entnommen. Das BAR0 Registers-Modul enthält das Ausführungs- und das Befehlsregister, und steuert das Setzen dieser beiden Register. Das BAR0 Devices-Modul zeigt
den Inhalt des Ausführungs- und des Befehlsregisters über LEDs an. Dies ermöglicht eine schnelle visuelle Erfassung des Zustands der Register. Die LEDs sind auf der Spartan
6 PCIe Karte angebracht.
Das BAR0 -Modul ist nach außen wie ein Speichermodul aufgebaut, d.h. es besitzt die
gleiche Schnittstelle wie das BAR1 -Modul. Um also das Ausführungs- bzw. Befehlsregister zu ändern, wird an die Speicheradresse ’0x00’ bzw. ’0x04’ des BAR0 Speicherbereichs
geschrieben.
5.1.1.4. BAR1 Das BAR1 -Modul besteht aus dem BRAM Controller -Modul des XPIOBeispiels. Es instantiiert einen 8 KB großen BlockRAM innerhalb des FPGA und stellt
die Steuer- und Datensignale für diesen bereit.
5.1.1.5. PCIe TX/RX Engine Das PCIe TX/RX Engine-Modul steuert den im FPGA
integrierten PCIe-Block. Die Generierung von zu sendenden TLPs sowie die Verarbeitung empfangener TLPs wird von diesem Modul getätigt. Außerdem ist es für die Bereitstellung über PCIe angeforderte Daten bzw. das Schreiben empfangener Daten in
die Register und den Speicher zuständig. Das Modul beinhaltet die beiden, dem XPIOBeispiel entnommenen Module 32 Bit RX Engine und 32 Bit TX Engine. Dabei ist
das 32 Bit RX Engine-Modul für das Verarbeiten vom PCIe-Block empfangener TLPs
zuständig.
In Abbildung 12 (links) sind die Signalzustände für einen solchen Vorgang dargestellt.
Dabei ist die zeitliche Entwicklung der Signale unterhalb des globalen Taktsignals clk
aufgetragen. Es ist darauf zu achten, dass bis auf dieses alle anderen Signale eine negative Logik benutzen, d.h. der niedere Zustand des Signals bezeichnet ein logisch Wahr
und der hohe Zustand ein logisch Falsch. Das Setzen bzw. Rücksetzen eines Signals ist
synchron zur steigenden Taktflanke des globalen Taktsignals clk. Ist das PCIe TX/RX
22
Engine-Modul bereit, TLPs zu verarbeiten, setzt es das trn dst rdy n-Signal. Anschließend setzt der PCIe-Block gleichzeitig die Signale trn rsof n und trn rsrc rdy n. Ebenfalls
gleichzeitig steht auf dem trn rd[31:0]-Datenbus das erste DW bereit. Der PCIe-Block
setzt im nächsten Takt das trn rsof n-Signal zurück und stellt zu jedem neuen Takt ein
weiteres DW zur Verfügung. Geichzeitig mit dem letzten DW setzt der PCIe-Block das
trn reof n-Signal, bevor er es im nächsten Takt zusammen mit dem trn rscr rdy n-Signal
wieder zurück setzt.
Das 32 Bit TX Engine-Modul ist für die Generierung von zu sendenden TLPs zuständig.
Wie in Abbildung 12 zu sehen, signalisiert das vom PCIe-Block gesetzte trn tdst rdy nSignal dem Modul, dass es mit der Datenübertragung beginnen kann. Durch gleichzeitiges Setzen der Signale trn tsof n und trn tsrc rdy n wird am trn td[31:0]-Datenbus
das erste DW des TLPs zum PCIe-Block übertragen. Im nächsten Takt setzt das Modul das trn tsof n-Signal zurück, und stellt nun mit jedem Takt ein neues DW am
trn td[31:0]-Datenbus zur Verfügung. Mit dem letzten zu übertragenden DW setzt das
Modul das trn teof n-Signal und schließt im nächsten Takt mit dem Zurücksetzen der
Signale trn tsrc rdy n und trn teof n die Übertragung ab. (vgl. [15])
5.1.1.6. ARS Memory Controller Das ARS Memory Controller Modul ist die zentrale
Schnittstelle im FPGA-Design. Es ermöglicht dem RX/TX Engine-Modul das Ansteuern
der BAR0 - und BAR1 -Module über nur eine Schnittstelle, indem die obersten zwei Bits
des rxtx rd addr i[12:0]- bzw. rxtx wd addr i[12:0]-Signals über die Ansteuerung des einen
oder anderen Moduls entscheiden.
Eine weitere Funktion des ARS Memory Controller -Moduls ist das Schalten des Schreibzugriffs auf den im BAR1 -Modul befindlichen BlockRAM. Ist das daq mem wr select iSignal gesetzt, werden die Steuer- und Datenleitungen des ARS DAQ Controller -Moduls
durgeschaltet, andernfalls die Leitungen des RX/TX Engine-Moduls.
23
BAR0
BAR0 Devices
BAR0 Registers
ARS ADC Access
ARS DAQ Controller
BAR1
BRAM Controller
BRAM
ARS Memory Controller
RX/TX Engine
32 Bit RX Engine
32 Bit TX Engine
PCIe Endpoint Block
Abbildung 10: Modulstruktur mit Schnittstellen des ARS FPGA-Designs, gelb: Module
des XPIO-Beispieldesigns, blau: selbst erstellte Module, rot: integrierter
Block im FPGA. Die Module werden im Abschnitt 5.1.1 näher erläutert.
24
DAQ_CAPTURE1
DAQ_CAPTURE2
2
3
DAQ_RST
4
1
DAQ_WAIT
DAQ_CAPTURE3
DAQ_REGRST
1: daq_run_i = '1' & daq_command_i[3:0] = "0000"
2: daq_run_i = '1' & daq_command_i[3:0] = "0001"
3: daq_wr_busy_i = '0' & Speicheradresse < MAX
4: daq_wr_busy_i = '0' & Speicheradresse = MAX
Abbildung 11: Zustandsdiagramm des ARS DAQ Controller -Moduls, Erläuterungen siehe Abschnitt 5.1.1.2.
Zeit
Zeit
1
clk
trn_rd [31:0]
0
trn_td [31:0]
HDW1 HDW2 HDW3
1
clk
trn_rsof_n
trn_tsof_n
trn_reof_n
trn_teof_n
trn_rsrc_rdy_n
trn_tsrc_rdy_n
trn_rdst_rdy_n
trn_tdst_rdy_n
0
HDW1 HDW2 HDW3 DDW1
Abbildung 12: Signalzustände bei der Verarbeitung (links) bzw. Generierung (rechts)
von 3 DW großen TLPs ohne bzw. mit Nutzdaten innerhalb des RX/TX
Engine-Moduls, Erläuterungen siehe Abschnitt 5.1.1.5 (vgl. [15]).
25
5.2. Linux-Gerätetreiber
Der Treiber für das FPGA-Design ist als Linux-Kernelmodul ausgeführt. Der Einsprungspunkt des Treibers, d.h. die Funktion, die aufgerufen wird, wenn das Modul geladen
wird, ist die Treiberladefunktion sp6 init. Sie registriert das Modul als Treiber im LinuxTreibersystem, erstellt einen Eintrag im Linux-Geräteverzeichnis und meldet den Treiber
im PCI/PCIe-Subsystem (PCIe und PCI unterscheiden sich in ihren Grundfunktionen
auf der Treiberseite nicht voneinander) an.
Wird ein PCIe-Gerät am PCIe-Bus erkannt, wird anhand der PCIe Hersteller- und
Gerätenummer der passende Treiber vom PCI/PCIe-Subsystem ausgewählt und im
Treiber die Geräteinitialisierungsfunktion (sp6 device init) aufgerufen. In der Geräteinitialisierungsfunktion sp6 device init wird Speicherplatz für das Gerät reserviert, das
PCIe-Gerät aktiviert und die Speicherbereiche der Hardware auf den Systemspeicher des
Computers abgebildet. Danach ist die Hardware über eine Gerätedatei ansprechbar.
Öffnet ein Programm diese Gerätedatei über den Standard-Systemaufruf open, wird im
Treiber die Funktion sp6 open aufgerufen. Nun kann auf die Hardware mittels der Linux
Systemaufrufe ioctl, read und write zugegriffen werden. Dabei werden im Treiber jeweils
die Funktionen sp6 ioctl, sp6 read und sp6 write aufgerufen. Über den ioctl -Systemaufruf
kann der Treiber gesteuert werden. Mithilfe des Systemaufrufs read bzw. write können
Daten von der Hardware gelesen bzw. auf sie geschrieben werden.
Die Funktion sp6 release wird ausgeführt, wenn der Systemaufruf close aufgerufen wird.
Wird das PCIe-Gerät aus dem System entfernt, regelt die Gerätedeinitialisierungsfunktion sp6 device deinit das Freigeben des abgebildeten Systemspeichers und deaktiviert das
PCIe-Gerät. Das Kernelmodul wird über die Treiberentladefunktion sp6 exit entladen,
dabei werden alle in der Funktion sp6 init reservierten Speicherbereiche freigegeben, der
Eintrag im Geräteverzeichnis gelöscht und der Treiber im PCI/PCIe-Subsystem und im
Linuxtreibersystem abgemeldet.
Die einzelnen Funktionen werden im Folgenden erläutert.
5.2.1. Datenstrukturen
5.2.1.1. Dateioperationen (fops) In der Datenstruktur der Dateioperationen sind die
Zuordnungen zwischen Linux-Systemaufrufen und den einzelnen Funktionen im Treiber
hinterlegt. Die Datenstruktur wird in der Funktion zum Laden des Treibers (siehe Abschnitt 5.2.2.1) dem Linux-Treibersystem übergegeben.
5.2.1.2. Geräteinformationen (sp6 driver struct) Hier werden Informationen zum
PCIe-Gerät gespeichert, die dem Treiber in der Initialisierungsfunktion (sp6 device init)
26
vom PCIe-Subsystem übergeben werden. Außerdem sind hier die die Adressen und die
Längen der in den Speicherbereich des Computers abgebildeten Speicherbereiche der
Hardware hinterlegt.
5.2.1.3. PCIe-Treiberinformationen (sp6 pci driver) Bestandteil dieser Datenstruktur ist eine Tabelle, in der alle vom Treiber unterstützten PCIe-Geräte anhand ihrer
Hersteller- und Gerätenummer verzeichnet sind. Außerdem erfolgt hier die Spezifikation
derjenigen Treiberfunktionen, die bei einer physikalischen Verbindung bzw. Trennung
eines PCIe-Geräts mit, dem bzw. von dem System aufgerufen werden (siehe Abschnitt
5.2.2.3 und 5.2.2.4).
5.2.2. Funktionen
5.2.2.1. Laden des Treibers (sp6 init) Diese Funktion wird vom Treibersubsystem
aufgerufen, wenn der Treiber in den Kernel geladen wird. Man nennt diese Funktion auch
den Einsprungspunkt des Treibers. In dieser Funktion wird der Treiber im Treibersystem
angemeldet und ein Eintrag im Linux-Geräteverzeichnis erstellt, d.h. der Treiber bekommt dynamisch eine eindeutige Gerätenummer zugewiesen, die ihn im System identifiziert. Gleichzeitig wird dem Treibersubsystem die Datenstruktur der Dateioperationen
(fops) übergeben, anhand derer eine Zuordnung der Linux-Systemaufrufe zu den Treiberfunktionen möglich ist. Anschließend wird der Treiber im PCIe-Subssystem angemeldet. Dabei wird dem PCIe-Subsystem die Datenstruktur der PCIe-Treiberinformationen
übergeben, mittels derer das PCIe-Subsystem die PCIe-Geräte dem Treiber zuordnen
kann.
5.2.2.2. Entladen des Treibers (sp6 exit) Wird der Treiber entladen, d.h. aus dem
Kernel geladen, wird diese Funktion aufgerufen. Sie meldet den Treiber im PCIe- und
Treibersystem ab. Werden zu diesem Zeitpunkt noch PCIe-Geräte von diesem Treiber
verwaltet, so wird erst die Funktion zur Deinitialisierung des Gerätes aufgerufen.
5.2.2.3. Initialisierung des Geräts (sp6 device init) Bei der Initialisierung wird das
PCIe-Gerät aktiviert, d.h. es wird im Geräteverzeichnis angezeigt. Gleichzeitig wird Speicherplatz im Kernelspeicher reserviert, in den dann die Speicherbereiche des Gerätes abgebildet werden. Anschließend werden die Speicheradressen und die Länge des Speicherbereichs in der Geräteinformationsdatenstruktur gespeichert, um sie den anderen Funktionen des Treibers verfügbar zu machen. Diese Funktion wird automatisch aufgerufen,
wenn das PCIe-Subsystem ein auf diesen Treiber passendes PCIe-Gerät detektiert.
27
5.2.2.4. Deinitialisierung des Geräts (sp6 device deinit) Hier wird das PCIe-Gerät
deaktiviert, d.h. der Eintrag im Geräteverzeichnis deaktiviert. Anschließend werden die
abgebildeten Speicherbereiche freigegeben und die Informationen in der Geräteinformationendatenstruktur gelöscht.
5.2.2.5. Öffnen des Geräts (sp6 open) Beim Öffnen des Geräts wird ein Dateideskriptor erstellt und dem Benutzerprogramm übergeben, über den das Benutzerprogramm dann auf die Daten des Gerätes über die Schreib- und Lesefunktionen zugreifen
kann.
5.2.2.6. Schließen des Geräts (sp6 release) In dieser Funktion wird der in der Funktion zum Öffnen des Gerätes erstellte Dateideskriptor gelöscht.
5.2.2.7. Lesen des Geräts (sp6 read) Wenn ein Benutzerprogramm Daten des PCIeGerätes anfordert, wird diese Funktion aufgerufen. Sie kopiert die angeforderten Daten
vom Kernelspeicher in den Benutzerspeicher und macht so dem Benutzerprogramm die
Daten zugänglich. So können die in der Hardware erfassten Daten gelesen werden.
5.2.2.8. Schreiben des Geräts (sp6 write) Möchte ein Benutzerprogramm Daten in
das PCIe-Gerät schreiben, so wird diese Funktion aufgerufen, die die zu schreibenden Daten vom Benutzerspeicher in den Kernelspeicher, und damit in das PCIe-Gerät, schreibt.
Diese Funktion ist für das Datenerfassungssystem nicht notwendig, da die Daten nur
ausgelesen werden sollen, allerdings ist sie für Testzwecke und die Entwicklung von Bedeutung.
5.2.2.9. Steuern des Geräts (sp6 ioctl) Über diese Funktion kann der Treiber sowie das PCIe-Gerät gesteuert werden. In dieser Arbeit wird die Funktion genutzt, um
einerseits den Status des Befehls- und Ausführungsregisters (siehe Abschnitt 5.1.1.3)
anzuzeigen und andererseits Befehle an das FPGA-Design zu senden und auszuführen,
d.h. das Befehlsregister und das Ausführungsregister zu setzen und somit die Hardware
zu steuern.
5.3. Messung der Übertragungsgeschwindigkeit
5.3.1. Durchführung
Um die Übertragungsgeschwindigkeit von der PCIe-Karte zum nanoX-TC zu bestimmen,
wird der Linuxbefehl dd benutzt, der Daten von einer Datei in eine andere Datei kopiert.
28
Der vollständige Aufruf des Befehls lautet:
$ dd if=/dev/sp6lx75t of=/dev/zero bs=8192
Der Parameter if gibt die Datei an, von der gelesen werden soll, in diesem Fall die
Gerätedatei der PCIe-Karte. Der Parameter of definiert dementsprechend die Datei, in
die die Daten geschrieben werden sollen. In diesem Fall werden die Daten in ein virtuelles
Gerät geschrieben, das alle Daten verwirft. So wird sichergestellt, dass die gemessene Geschwindigkeit der Datenübertragung der PCIe-Übertragungsgeschwindigkeit entspricht
und nicht durch eventuelle langsamere Festplattenzugriffe beinflusst wird.
Der Parameter bs gibt die Größe in Byte der geschriebenen und gelesenen Blöcke an. Hier
werden 8192 Bytes gelesen bzw. geschrieben, dies entspricht der Grösse des Speichers im
FPGA. Diese Messung wurde 1000 mal durchgeführt und anschließend der Mittelwert
gebildet.
Um einen Einfluss von etwaigen Initalisierungsprozessen beim Datentransfer, die bei
der geringen Auslesezeit der kleinen Speichergröße stark ins Gewicht fallen würden, zu
vermeiden, wurde eine zweite Messung durchgeführt, bei der ein größerer Speicherbereich
(128 MB) in der Hardware emuliert wurde. Dabei entspricht der Speicherbereich keinem
realen Speicher in der Hardware, sondern einem Modul, das an jeder Adresse immer den
selben Datenwert liefert und zu schreibende Daten verwirft. Diese Messung wurde jeweils
zehn mal durchgeführt und anschließend wieder der Mittelwert gebildet. Die Ergebnisse
sind in Tabelle 1 zu sehen.
Speicher
8 KB Blockram
128 MB emuliert
Lesen [MB/s] Schreiben [MB/s]
1, 30 ± 0, 41
1, 58 ± 0, 04
3, 71 ± 1, 37
26, 54 ± 0, 07
Tabelle 1: Übertragungsgeschwindigkeiten.
5.3.2. Diskussion
Die für die Datenerfassung relevante Datenlesegeschwindigkeit von (1, 30 ± 0, 41) MB/s
bleibt deutlich hinter der Erwartung (max. erreichbare PCIe Bandbreite: 250 MB/s)
zurück. Auch streuen die Werte sehr stark, was wahrscheinlich, wie schon vermutet, an
etwaigen Initialisierungsprozessen im Linux-Treiber- oder PCIe-Subsystem liegen könnte, da beim emulierten, großen Speicher die Werte um zwei Größenordnungen weniger
streuen. Hierbei fallen diese Prozesse nicht ins Gewicht, da sie nur einen Bruchteil der
Übertragung ausmachen.
29
Die größere Datenschreibgeschwindigkeit von (3, 71 ± 1, 37) MB/s kann daraus resultieren, dass Speicherschreibanfragen nicht mit einem Antwortpaket abgeschlossen werden
(siehe Kapitel 3.1.1). Die signifikant höhere Datenschreibgeschwindigkeit von (26, 54 ±
0, 07) MB/s bei dem emulierten, größeren Speicher weist darauf hin, dass der Speicher
im FPGA zusätzlich eine limitierende Größe ist.
Der bedeutendste Einfluss auf die Übertragungsgeschwindigkeit resultiert allerdings daraus, dass die Speicherleseanfrage (MRd) auf mehrere Speicherleseanfragen aufgeteilt
wird, die nur ein DW an Nutzdaten zulassen, da das RX/TX Engine-Modul nur Speicherleseanfragen mit einem DW Nutzdaten verarbeiten kann. Daher werden auch nur
Antwortpakete (CplD) mit einem DW Nutzdaten zurückgesendet. Somit werden für ein
DW Nutzdaten je nach Adressierung acht oder neun DWs übertragen. Um Daten effizient übertragen zu können, müssten Pakete mit mehreren DWs Nutzlast angefragt,
verarbeitet und zurückgesendet werden.
Die beste Lösung stellt jedoch die Methode des Speicherdirektzugriffs (Direct Memory Access, DMA) dar. Dabei werden die Daten direkt vom FPGA-Design in den Arbeitsspeicher des Computers geschrieben, d.h. es werden nur Speicherschreibanfragen
gesendet. Hierbei sollte dann die Nutzdatenlast pro Paket die maximal unterstützte
Nutzdatenlast des integrierten PCIe Blocks von 512 Bytes (vgl. [15]) betragen.
Der Vorteil besteht neben der effizienteren Nutzung des PCIe-Protokolls auch darin,
dass die Datenübertragung direkt in den Speicher geschrieben wird, ohne vom Prozessor
des Computers verarbeitet, d.h. vom Kernelspeicher in den Nutzerspeicher kopiert zu
werden. Um diese Lösung umsetzen zu können, ist allerdings eine Erweiterung des LinuxGerätetreibers und eine Abänderung des FPGA-Designs nötig.
30
In der vorliegenden Arbeit wurde ein Testsystem zur Datenerfassung in Betrieb genommen und eine Ansteuerungs- und Datenerfassungssoftware für ARS entwickelt.
Mit Hilfe dieser Software besteht die Möglichkeit, mit einem Computer (COM) über
die PCIe-Schnittstelle ein FPGA-Design zu steuern und in der Hardware digitalisierte
Daten zum Computer zu übertragen, wobei die Ergebnisse im Hinblick auf die anfallende
Datenmenge und die daraus resultierende Datenübertragungsgeschwindigkeit von großer
Bedeutung sind, um eine sinnvolle Umfelderkundung bei einer Exploration in einem
adäquaten Zeitrahmen durchführen zu können.
Wie schon im vorigen Kapitel diskutiert, muss hierzu bemerkt werden, dass bei dem
in dieser Arbeit entwickelten und getesteten System die Übertragungsgeschwindigkeit
zum Lesen der Daten mit (1, 58 ± 0, 04) MB/s weit hinter den Erwartungen an den
PCIe-Standard zurück bleibt.
Das Potenzial der PCIe-Schnittstelle in dieser Anwendung kann allerdings basierend auf
der vorliegenden Arbeit und den darin aufgezeigten Optimierungsmöglichkeiten durch
eine Änderung des PCIe-Übertragungskonzepts (DMA) weiter ausgebaut werden.
31
A. Literatur
A. Literatur
[1] ADLINK Technology Inc. (Hrsg.): nanoX-TC BSP for Linux Version 1.0 Release Notes. Taipei, Taiwan: ADLINK Technology Inc., 2011
[2] ADLINK Technology Inc. (Hrsg.): nanoX-BASE User’s Manual. Taipei, Taiwan: ADLINK Technology Inc., 2012
[3] ADLINK Technology Inc. (Hrsg.): nanoX-TC Datasheet. Taipei, Taiwan:
ADLINK Technology Inc., 2013
[4] Avnet Electronics Marketing (Hrsg.): Xilinx® Spartan® - 6 LX75T
Development Kit User Guide. Phoenix (AZ), USA: Avnet Electronics Marketing, 2012. https://www.em.avnet.com/Support%20And%20Downloads/xlx_s6_
lx75t_dev-ug_reva_v1_2_031327.pdf
[5] Budruk, R. ; Anderson, D. ; Shanley, T.: Pci Express System Architecture.
Addison Wesley Professional, 2004 (Mindshare PC System Architecture). http:
//books.google.de/books?id=sBtKutWpVh8C. – ISBN 978–0–321–15630–3
[6] Forschungszentrum der Bundesrepublik Deutschland für Luft- und Raumfahrt (DLR):
Saturnmond Enceladus: Dem Leben im Wasser auf der
Spur.
http://www.dlr.de/dlr/desktopdefault.aspx/tabid-10664/1151_
read-4597/#gallery/4874. Version: August 2012
[7] Eliseev, Dmitry: Persönliche Mitteilung. 2013
[8] Enex Collaboration (Hrsg.): Enceladus Explorer System Design - Navigation.
Aachen: Enex Collaboration, 2012
[9] Europäische Weltraumorganisation (ESA): Saturn’s moon shows evidence of Ammonia. http://www.esa.int/Our_Activities/Space_Science/Cassini-Huygens/
Saturn_s_moon_shows_evidence_of_ammonia. Version: Juli 2009
[10] Europäische Weltraumorganisation (ESA): Cassini samples the ice spray of Enceladus’ water plumes. http://www.esa.int/Our_Activities/Space_Science/
Cassini-Huygens/Cassini_samples_the_icy_spray_of_Enceladus_water_
plumes. Version: Juni 2011
[11] Enex-Team, FH Aachen: Persönliche Mitteilung. 2013
[12] Inc., Red H.: About Fedora. https://fedoraproject.org/de/about-fedora.
Version: 2013
[13] Quade, Jürgen ; Kunst, Eva-Katharina: Linux-Treiber entwickeln. 3., aktualisierte
und erw. Aufl. Heidelberg : dpunkt-Verlag, 2011. – 587 S. – ISBN 978–3–89864–
696–3
32
A. Literatur
[14] Reichardt, J. ; Schwarz, B.: VHDL-Synthese: Entwurf digitaler Schaltungen
und Systeme. Oldenbourg Wissenschaftsverlag, 2012 http://books.google.de/
books?id=nYyaDD7UvpYC. – ISBN 978–3–486–71677–1
[15] Xilinx® (Hrsg.): Spartan-6 FPGA Integrated Endpoint Block for PCI Express
- User Guide. San Jose (CA), USA: Xilinx® , 2010. http://www.xilinx.com/
support/documentation/user_guides/s6_pcie_ug654.pdf
[16] Xilinx® (Hrsg.): PCIe Programmed I/O Example Design. San Jose (CA), USA:
Xilinx® , 2011
[17] Xilinx® (Hrsg.): Spartan-6 Family Overview. San Jose (CA), USA: Xilinx® , 2011.
http://www.xilinx.com/support/documentation/data_sheets/ds160.pdf
[18] Xilinx® : Xilinx Licensing FAQ.
Version: 2013
http://www.xilinx.com/tools/faq.htm.
33
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Schallphasenarrays im IceMolekopf [8]. . . . . . . . . . . . . . . . . . . .
Aufsicht in die offene Akustikbox mit eingebautem APS, die Tiefe der
Akustikbox beträgt ca. 10 cm. . . . . . . . . . . . . . . . . . . . . . . . .
Schema der Platinen in der Akustikbox (links) und Ankopplung der Sensorplatinen im IceMolekopf (rechts). Gelb: Versorgungsplatine, Grün: APS,
Rot: ARS [7]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schichtweiser Aufbau (von oben nach unten) von TLPs durch die verschiedenen PCIe-Schichten. Erläuterungen siehe Abschnitt 3.1.1 (vgl. [5],
S.73). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Headerstruktur einer 3 DWs (oben) bzw. 4 DWs (unten) Speicheranfrage,
erste Spalte: Bitposition, weitere Spalten: DWs (vgl. [5], S.175). . . . . .
Headerstruktur eines CplD (erste Spalte: Bitposition, weitere Spalten:
DWs vgl. [5], S.184). . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ober-/Unterseite des nanoX-TC COM, Abmessungen: 55 mm x 84 mm. .
Spartan 6 Entwicklungskit mit angeschlossenem USB-JTAG-Adapter und
externer Stromversorgung. . . . . . . . . . . . . . . . . . . . . . . . . . .
Aufbau des Entwicklungs- & Testsystems. . . . . . . . . . . . . . . . . .
Modulstruktur mit Schnittstellen des ARS FPGA-Designs, gelb: Module
des XPIO-Beispieldesigns, blau: selbst erstellte Module, rot: integrierter
Block im FPGA. Die Module werden im Abschnitt 5.1.1 näher erläutert.
Zustandsdiagramm des ARS DAQ Controller -Moduls, Erläuterungen siehe Abschnitt 5.1.1.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Signalzustände bei der Verarbeitung (links) bzw. Generierung (rechts)
von 3 DW großen TLPs ohne bzw. mit Nutzdaten innerhalb des RX/TX
Engine-Moduls, Erläuterungen siehe Abschnitt 5.1.1.5 (vgl. [15]). . . . .
34
8
9
9
11
12
13
16
18
19
24
25
25
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Übertragungsgeschwindigkeiten. . . . . . . . . . . . . . . . . . . . .
Signale des ARS ADC Access-Moduls. . . . . . . . . . . . . . . . .
Signale des ARS DAQ Controller -Moduls. . . . . . . . . . . . . . .
BAR0 Signale des ARS Memory Controller -Moduls. . . . . . . . .
BAR1 Signale des ARS Memory Controller -Moduls. . . . . . . . .
RX/TX Engine Signale des ARS Memory Controller -Moduls. . . .
ARS DAQ Controller Signale des ARS Memory Controller -Moduls.
Signale des BAR0 -Moduls. . . . . . . . . . . . . . . . . . . . . . . .
Signale des BAR1 -Moduls. . . . . . . . . . . . . . . . . . . . . . . .
ARS Memory Controller Signale des RX/TX Engine-Moduls. . . .
PCIe Signale des RX/TX Engine-Moduls (vgl. [15]). . . . . . . . .
35
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
36
36
37
37
38
39
40
40
41
42
D. Signaltabellen
D. Signaltabellen
Signal
Typ
Beschreibung
daq adc capture i
Eingang startet die Datennahme
daq adc data o[31:0] Ausgang Daten der Datennahme, liefert 0xcafebabe bei
gesetztem daq adc capture i Signal, ansonsten
0xdeadbeef
Tabelle 2: Signale des ARS ADC Access-Moduls.
Signal
Typ
Beschreibung
daq adc capture o
Eingang
startet die Datennahme im ARS ADC AccessModul
Daten der Datennahme
steuert den Schreibzugriff auf BAR1 : ’0’ für
RX/TX Engine, ’1’ für ARS DAQ Controller
setzt das Ausführungsregister zurück
Status des Ausführungsregisters
Status des Befehlsregisters
gibt die Speicheradresse für den Schreibzugriff an
Schreib-Byte-Enable Signal des Speicherbereichs,
gibt an, welche Bytes des 32 Bit breiten Datenbusses geschrieben werden sollen
32 Bit breiter Schreibdatenbus
wird dieses Signal gesetzt, werden die Daten am
Schreibdatenbus in den Speicher geschrieben
gibt den Status des Speichers an: ’0’ entspricht
bereit“, ’1’ entspricht nicht bereit“
”
”
daq adc data i[31:0] Ausgang
daq mem wr select o Ausgang
register rst o
run i
command i[3:0]
wr addr o[10:0]
wr be o[7:0]
Ausgang
Eingang
Eingang
Ausgang
Ausgang
daq wr data o[31:0]
daq wr en o
Ausgang
Ausgang
daq wr busy i
Eingang
daq
daq
daq
daq
daq
Tabelle 3: Signale des ARS DAQ Controller -Moduls.
36
D. Signaltabellen
Signal
Typ
Beschreibung
bar0 rd addr o[10:0]
bar0 rd be o[3:0]
bar0
bar0
bar0
bar0
bar0
bar0
bar0
bar0
bar0
Ausgang gibt die Leseadresse an
Ausgang Lese-Byte-Enable Signal des Speicherbereichs, gibt
an, welche Bytes des 32 Bit breiten Datenbusses
gelesen werden sollen
rd data i[31:0] Eingang 32 Bit breiter Lesedatenbus
wr addr o[10:0] Ausgang gibt die Speicheradresse für den Schreibzugriff an
wr be o[7:0]
Ausgang Schreib-Byte-Enable Signal des Speicherbereichs,
wr data o[31:0] Ausgang 32 Bit breiter Schreibdatenbus
wr en o
Ausgang wird dieses Signal gesetzt, werden die Daten am
wr busy i
Eingang gibt den Status des Speichers an: ’0’ entspricht
”
”
register rst o
Ausgang setzt das Ausführungsregister zurück
run i
Eingang Status des Ausführungsregisters
command i[3:0] Eingang Status des Befehlsregisters
Tabelle 4: BAR0 Signale des ARS Memory Controller -Moduls.
Signal
Typ
Beschreibung
bar1 rd addr o[10:0]
bar1 rd be o[3:0]
Ausgang gibt die Leseadresse an
Ausgang Lese-Byte-Enable Signal des Speicherbereichs, gibt
bar1 rd data i[31:0] Eingang 32 Bit breiter Lesedatenbus
bar1 wr addr o[10:0] Ausgang gibt die Speicheradresse für den Schreibzugriff an
bar1 wr be o[7:0]
Ausgang Schreib-Byte-Enable Signal des Speicherbereichs,
bar1 wr data o[31:0] Ausgang 32 Bit breiter Schreibdatenbus
bar1 wr en o
Ausgang wird dieses Signal gesetzt, werden die Daten am
bar1 wr busy i
Eingang gibt den Status des Speichers an: ’0’ entspricht
”
”
Tabelle 5: BAR1 Signale des ARS Memory Controller -Moduls.
37
D. Signaltabellen
Signal
Typ
rxtx rd addr i[12:0]
Eingang
Beschreibung
gibt die Leseadresse an, hierbei identifizieren die
oberen beiden Bits den Speicherbereich: ’00’ entspricht BAR0 und ’01’ entspricht BAR1
rxtx rd be i[3:0]
Eingang Lese-Byte-Enable Signal des Speicherbereichs, gibt
rxtx rd data o[31:0] Ausgang 32 Bit breiter Lesedatenbus
rxtx wr addr i[12:0] Eingang gibt die Speicheradresse für den Schreibzugriff an,
hierbei identifizieren die oberen beiden Bits den
Speicherbereich: ’00’ entspricht BAR0 und ’01’
entspricht BAR1
Eingang Schreib-Byte-Enable Signal des Speicherbereichs,
rxtx wr be i[7:0]
rxtx wr data i[31:0] Eingang 32 Bit breiter Schreibdatenbus
Eingang wird dieses Signal gesetzt, werden die Daten am
rxtx wr en i
Ausgang gibt den Status des Speichers an: ’0’ entspricht
rxtx wr busy o
”
”
Tabelle 6: RX/TX Engine Signale des ARS Memory Controller -Moduls.
38
D. Signaltabellen
Signal
Typ
daq mem wr select i
Eingang
daq
daq
daq
daq
daq
daq
daq
daq
Beschreibung
steuert den Schreibzugriff auf BAR1 : ’0’ für
RX/TX Engine, ’1’ für ARS DAQ Controller
register rst i
Eingang setzt das Ausführungsregister zurück
run o
Ausgang Status des Ausführungsregisters
command o[3:0] Ausgang Status des Befehlsregisters
wr addr i[10:0]
Eingang gibt die Speicheradresse für den Schreibzugriff des
BAR1 -Moduls an
wr be i[7:0]
wr data i[31:0]
Eingang 32 Bit breiter Schreibdatenbus
wr en i
wr busy o
”
”
Tabelle 7: ARS DAQ Controller Signale des ARS Memory Controller -Moduls.
39
D. Signaltabellen
Signal
Typ
Beschreibung
bar0 rd addr i[10:0]
bar0 rd be i[3:0]
Eingang
Eingang
bar0 rd data o[31:0]
bar0 wr addr i[10:0]
bar0 wr be i[7:0]
Ausgang
Eingang
Eingang
bar0 wr data i[31:0]
bar0 wr en i
Eingang
Eingang
bar0 wr busy o
Ausgang
gibt die Leseadresse an
Lese-Byte-Enable Signal des Speicherbereichs, gibt
32 Bit breiter Lesedatenbus
gibt die Speicheradresse für den Schreibzugriff an
”
”
setzt das Ausführungsregister zurück
Status des Ausführungsregisters
Status des Befehlsregisters
zeigt den Inhalt des Ausführungsregisters an
zeigt den Inhalt des Befehlsregisters an
bar0
bar0
bar0
LED
LED
register rst i
Eingang
run o
Ausgang
command o[3:0] Ausgang
USER
Ausgang
COUNT[3:0]
Ausgang
Tabelle 8: Signale des BAR0 -Moduls.
Signal
Typ
bar1 rd addr i[10:0]
bar1 rd be i[3:0]
Eingang
Eingang
Beschreibung
gibt die Leseadresse an
bar1 rd data o[31:0] Ausgang 32 Bit breiter Lesedatenbus
bar1 wr addr i[10:0] Eingang gibt die Speicheradresse für den Schreibzugriff an
bar1 wr be i[7:0]
bar1 wr data i[31:0] Eingang 32 Bit breiter Schreibdatenbus
bar1 wr en i
bar1 wr busy o
”
”
Tabelle 9: Signale des BAR1 -Moduls.
40
D. Signaltabellen
Signal
Typ
Beschreibung
rd addr o[12:0]
Ausgang
rd be o[3:0]
Ausgang
gibt die Leseadresse an, hierbei identifizieren die
oberen beiden Bits den Speicherbereich: ’00’ entspricht BAR0 und ’01’ entspricht BAR1
32 Bit breiter Lesedatenbus
gibt die Speicheradresse für den Schreibzugriff an,
hierbei identifizieren die oberen beiden Bits den
Speicherbereich: ’00’ entspricht BAR0 und ’01’
entspricht BAR1
”
”
rd data i[31:0] Eingang
wr addr o[12:0] Ausgang
wr be o[7:0]
Ausgang
wr data o[31:0]
wr en o
Ausgang
Ausgang
wr busy i
Eingang
Tabelle 10: ARS Memory Controller Signale des RX/TX Engine-Moduls.
41
D. Signaltabellen
Signal
Typ
trn
trn
trn
trn
Ausgang
Ausgang
Ausgang
Ausgang
trn
trn
trn
trn
trn
trn
trn
trn
trn
trn
cfg
td[31:0]
tsof n
teof n
tsrc rdy n
Beschreibung
Übertragunsdaten: zu übertragende TLP-Daten
signalisiert dem PCIe-Block den Start eines TLP
signalisiert dem PCIe-Block das Ende eines TLP
signalisiert, dass das RX/TX Engine-Modul Daten
am trn td[31:0]-Datenbus zur Verfügung stellt
tsrc dsc n
Ausgang unterbricht
die
Verarbeitung
der
TLPGenerierung
tdst rdy n
Eingang signalisiert, dass der integrierte PCIe-Block bereit ist Daten am trn td[31:0]-Datenbus entgegenzunehmen
tdst dsc n
Eingang signalisiert einen Fehler bei der Verarbeitung des
TLP innerhalb des PCIe-Block
rd[31:0]
Eingang Übertragungsdaten: empfangene TLP-Daten
rsof n
Eingang signalisiert dem RX/TX Engine-Modul den Start
eines TLP
reof n
Eingang signalisiert dem RX/TX Engine-Modul das Ende
eines TLP
rsrc rdy n
Eingang signalisiert, dass der PCIe-Block Daten am
trn rd[31:0]-Datenbus bereitstellt
rsrc dsc n
Eingang signalisiert den Abbruch des Empfangs des TLP
rdst rdy n
Ausgang signalisiert die Bereitschaft des RX/TX EngineModuls Daten am trn rd[31:0]-Datenbus zu empfangen
rbar hit n[6:0]
Eingang gibt den Speicherbereich der aktuellen Übertragung an
completer id[15:0] Eingang liefert den eindeutigen Bezeichner aus PCIe-Bus-,
PCIe-Geräte- und PCIe-Funktionsnummer
Tabelle 11: PCIe Signale des RX/TX Engine-Moduls (vgl. [15]).
42
Danksagung
An erster Stelle möchte ich mich bei Prof. Christopher Wiebusch für die Bereitstellung
des Themas und die Betreuung meiner Arbeit bedanken.
Mein Dank gilt besonders Dirk Heinen, für die gute Betreuung und stetige Bereitschaft
mir bei Problemen jedweder Art zu helfen, sowie Dmitry Eliseev, für die kompetente,
fachliche Unterstützung bei meiner Arbeit und die spannenden Einblicke in die Welt der
Hardware.
Auch möchte ich Peter Linder, Sebastian Verfers und Simon Zierke für interresante
Einblicke in das EnEx-Projekt, über meine Arbeit hinaus, danken.
Des Weiteren danke ich der Elektronikwerkstatt unter der Leitung von Wolfgang Feldhäuser
und der Mechanikwerkstatt unter der Leitung von Dieter Jahn für ihre Arbeit.
Zudem danke ich Dennis Terhorst für die hilfreichen Diskussionen.
43
Erklärung
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen
als die angegebenen Quellen und Hilfsmittel verwendet habe.
Aachen, den 12. August 2013
Declaration
I hereby certify that this document has been composed by myself, and describes my own
work, unless otherwise acknowledged in the text.
Aachen, August the 12th , 2013
44

Entwicklung von Ansteuerungs- und Datenerfassungssoftware für

Transcription

Similar documents

Summer Deals - Sussex Plumbing Supplies

Bachelorarbeit 2009 Elektronik und Software für den

12.0 Ein serielles EEProm an der I²C Schnittstelle Eine serielles

1.4 TCP/IP Protokolle - Friedrich-Schiller

Führerstand-Simulationsproramm LOCSIM

Kapitel 5.7