Serielle Kommunikation
Realisierung einer seriellen Kommunikation zwischen zwei FPGAs mit CRC-Fehlererkennung.
1. Versuchziel
Ziel dieses Versuches ist die Implementierung eines seriell arbeitenden Senders und Empfängers mit CRC (Cyclic Redundancy Check)-Fehlererkennung auf Basis des dargestellten FPGA-Entwicklungsboards. In diesem Zusammenhang sollen das Verständnis für eine sichere Rechnerkommunikation und die mathematischen Grundlagen der Polynomarithmetik vertieft werden.
2. Grundlagen
Kommunikationssysteme lassen sich in zwei Klassen unterteilen. Serielle Systeme übermitteln je Takteinheit nur ein Datenbit, parallele Systeme dagegen mehrere Datenbits. Eine andere Einteilung kann nach der Synchronisation vorgenommen werden. Wenn Sender und Empfänger mit unterschiedlichen Taktsignalen gleicher Frequenz arbeiten, spricht man von asynchroner Übertragung. Gewinnt der Empfänger das Taktsignal aus dem übertragenen Datenstrom zurück, handelt es sich um synchrone Übertragung.
Da die Übertragung von Datenströmen immer durch äußere als auch innere Einflüsse wie elektromagnetische Einstrahlung und thermische Elektronenbewegung gestört werden kann, sind fehlererkennende oder -korrigierende Maßnahmen erforderlich. Dafür wird in der Praxis häufig ein CRC durchgeführt, bei dem eine Polynomdivision des zu übertragenden Datenstroms durch ein vorgegebenes Generatorpolynom auf der Sende- als auch auf der Empfangsseite berechnet wird. Die Hardware dafür ist mit nur einem LFSR (Linear Feedback Shift Register) sehr einfach realisierbar.
3. Studienfragen
- 3.1. Was ist synchrone und asynchrone Übertragung bezüglich des Taktsignals? Welche Realisierungen kennen sie?
- 3.2. Was ist der Unterschied zwischen Bitrate und Baudrate?
- 3.3. Wie arbeitet eine Polynomdivision modulo 2? Zeigen sie dies am Beispiel von (x7+x6+x5+x2+x1)/(x4+x3+1).
- 3.4. Erläutern sie darauf aufbauend die Funktionsweise des CRC.
- 3.5. Wie könnte eine Hardware für die Generierung und Verifikation des CRC-Codes aussehen?
- 3.6. Wie synchronisiert man asynchrone Signale in ein synchron getaktetes Design ein?
- 3.7. Worin bestehen in VHDL die Unterschiede zwischen Variablen und Signalen?
- 3.8. Erläutern Sie das grundlegende Prinzip der Zwei-Prozess-Methode.
- 3.9. Wie arbeitet eine Testbench? Wie können die Stimuli generiert werden?
- 3.10. Beschreiben Sie den vollständigen Designablauf vom VHDL-File bis zum Download in das FPGA. Wie und zu welchem Zweck wird eine Backannotation durchgeführt?
4. Aufgaben
Vor Beginn des Praktikums ist ein Kolloquium vorgesehen. In Vorbereitung dafür sind die Studienfragen und Hausaufgaben zu lösen. Nach erfolgreicher Implementierung ist ein Versuchsprotokoll (ohne Quelldateien) anzufertigen, aus dem deutlich die Funktionsweise der Schaltungen hervorgeht. Darin sind auch einige repräsentative Simulations- und Syntheseergebnisse aufzuzeigen.
4.1. Hausaufgaben (schriftlich)
- 4.1.1. Entwickeln Sie die Zustandsmaschinen (FSM) des Senders und des Empfängers und stellen Sie diese grafisch dar. Dabei soll das asynchrone Übertragungsprotokoll wie bei der RS232 zugrunde liegen. Hierbei soll auf die Implementierung einer Flusskontrolle verzichtet werden.
- 4.1.2. Ermitteln sie für drei 8Bit-Eingabewerte den 4Bit-CRC-Code mit dem Generatorpolynom x4+x2+1.
- 4.1.3. Entwickeln sie eine geeignete Hardware für einen bitseriellen CRC-Code-Generator und -Checker für das Generatorpolynom x4+x+1.
4.2. Versuchsaufgaben
Auch hier kommt das aus der Übung bekannte Demoboard zum Einsatz. Für diesen Versuch sind allerdings zwei seperate Designs zu entwickeln, ein Sender und ein Empfänger, welche auf je einem Board implementiert werden sollen. Verwenden Sie dafür die vorgefertigten VHDL- und UCF-Dateien aus dem Template. Implementieren Sie die notwendige Hardware mit Hilfe der Zwei-Prozess-Methode. Die Richtigkeit der Implementierung ist vor dem Laden des FPGAs durch eine funktionale Simulation sicherzustellen. Der verwendete FPGA von Xilinx ist vom Typ Spartan3E (XC3S500E, Package FG320, Speed -4).
4.2.1. Aufgabe des Senders
Es sind zwei 4-Bit-Eingabewerte zu multiplizieren, die mit Hilfe der acht Dip-Schalter eingeben werden. Das Ergebnis der Multiplikation soll auf den 7-Segmentanzeigen ausgegeben werden. An das 8-Bit-Ergebnis ist ein 4Bit-CRC anzuhängen. Das Generatorpolynom ist wie in der Hausaufgabe zu wählen. Die daraus resultierenden 12 Bit sollen bei Tastendruck an den Empfänger übertragen werden.
4.2.2. Aufgabe des Empfängers
Der Empfänger hat den empfangenen 8-Bit-Wert auf den 7-Segmentanzeigen auszugeben und einen CRC durchzuführen. Wurde dabei ein Übertragungsfehler festgestellt, ist dies auf der Anzeige oder den LEDs kenntlich zu machen.
4.2.3. Weitere Aufgaben
Um Übertragungsfehler zu simulieren, soll es mit Hilfe der Dip-Schalter am Empfänger möglich sein, einzelne Bits des 8-Bit-Produktes zu kippen.
4.3. Simulationsaufgaben
- 4.3.1. Sender und Empfänger sind jeweils in VHDL zu beschreiben.
- 4.3.2. Durch Simulation des CRC-Generators und -Checkers sind alle Übertragungsfehler zu ermitteln, die nicht erkannt werden können. Welche Maßnahmen können die Anzahl der nicht erkennbaren Fehler reduzieren?
- 4.3.3. Es ist eine funktionelle Simulation und eine Simulation unter Berücksichtigung des realen Verhaltens des Gesamtsystems durchzuführen (nach Platzierung und Routing).
- 4.3.4. Die Funktionalität ist durch den Versuchsaufbau nachzuweisen.
5. Literatur
- Vorlesungs- und Seminarunterlagen: Hochintegrierte System Universität Rostock
- Vorlesungs- und Seminarunterlagen: Technische Grundlagen der Rechnerkommunikation Universität Rostock
- Lehmann/Wunder/Selz, Schaltungsdesign mit VHDL, Franzis'-Verlag, 1994
- Tietze/Schenk, Halbleiter-Schaltungstechnik, 10.te Auflage, Springer
- Ross N. Williams, A painless guide to crc error detection algorithms, Version 3, 19. August 1993
- Terry Ritter, CRC Tool
- Referenz Manual Digilent Nexys-2 Board
6. Anhang
Die vorgegebenen Templates (Quelltexte) für das Praktikum enthalten eine Testbench für die Simulation der seriellen Kommunikation. Des Weiteren enthalten sie je eine Entity-Deklaration für das Transmit- und das Receivemodul. Für jedes dieser Entities ist eine ucf-Datei (user constraints file) vorgegeben. Außerdem sind diverse Packages enthalten, die verschiedene Hilfsfunktionen zur Verfügung stellen.