Entwicklung FPGA-basierter Funk-Kommunikationssysteme

Drahtlose Kommunikationssysteme sind heute fest etabliert und es werden immer neue Anwendungsfelder erschlossen. Damit geraten die Hersteller der dafür notwendigen Infrastruktur unter zunehmenden Druck, Betreibern möglichst kostengünstige Lösungen anbieten zu können. Die Kosten für solche Systeme bestehen neben den Anschaffungskosten der eigentlichen Anlage auch aus den Kosten für deren Betrieb, Pflege und Erwei-terung. Lösungen auf der Basis von DSPs und FPGAs sind besonders interessant, weil solche Komponenten von zentraler Stelle aus gewartet werden können und auch ganz neue Funktiona-lität nachträglich eingespielt werden kann.

Drahtlose Systeme enthalten oft FPGAs und DSPs nebeneinander. FPGAs zeichnen sich vor allem durch ihre hohe Geschwindigkeit aus – sogar komplizierte Algorithmen können auf ihnen mit Abtastraten von mehreren Hundert MHz betrieben werden. Aufgrund der hohen Rechenleistung können mit FPGAs nicht nur konventionelle Basisbandfunktionen implementiert, sondern Signale auch direkt hinter der Antenne mit hoher Geschwindigkeit verarbeitet werden. Außerdem kann bei FPGAs die Wortlänge der Festkommadaten optimiert werden und es lassen sich mehrere Kanäle in einem einzigen Gerät unterbringen, was die effektive Leistungsaufnahme und die Kosten pro Kanal senkt.

Neben ihrer freien Programmierbarkeit, Geschwindigkeit und Flexibilität eignen sich FPGAs aber auch zum „Rapid Design“ und „Rapid Verification“. In diesem Artikel stellen wir den Entwicklungsprozess für einen FPGA vor, der auf verschiedenen Produkten der Simulink-Familie, dem Xilinx System Generator for DSP™ und FPGAs von Xilinx basiert. Als konkretes Beispiel dient die Entwicklung eines 16-QAM Teleme-triesystems (16-level Quadrature Ampli­tude Modulation).

Die Methode des Model-Based Design erlaubt die Entwicklung eines Systems auf einer hohen Abstraktionsebene sowie deren automatisches Kompilieren in eine effiziente FPGA-Implementierung. Außerdem können wir mit den Hardware-in-the-Loop (HIL) Fähigkeiten des Xilinx System Generator unsere FPGA-Implementierungen direkt in Simulink co-simulieren. Das ermöglicht eine stringente Prüfung der Hardware-Implementierung und beschleunigt die Simulationen.

Der QAM-Demodulator wird von uns in drei Phasen entwickelt: Systementwurf und -modellierung, automatische Generierung der Hardwarefunktionalität und Simulation und Verifikation der Hardware. (Das in diesem Artikel vorgestellte Modell ist übrigens als Referenzentwurf im Lieferumfang des System Generator enthalten.)

Systementwurf und -modellierung

Abbildung 1 zeigt ein Simulink-Modell des 16-QAM-Systems mit Sender, Kanalmodell und Empfänger. Die Sender- und Empfänger-Sektion des Modells sind in die Subsysteme ‚FEC and QAM Symbol Mapping’ und ‚QAM Receiver’ aufgeteilt. Durch diesen hierarchischen Ansatz erhalten wir eine saubere Darstellung der obersten System-ebene, eine logische Aufteilung nach Funktionalität und gleichzeitig einen Rahmen für die Implementierung und Verifikation der einzelnen Komponenten des Entwurfs.

Senderentwurf

In Abbildung 2 ist der Aufbau des Sender-Subsystems dargestellt, das die 8-Bit-Symbole verarbeitet, die von der Sinus-Testquelle in der obersten Modell-Ebene erzeugt werden. Das Sender-Subsystem führt folgende Operationen durch:

• Reed-Solomon (RS) Codierung —Blöcke von 239 Symbolen durchlaufen einen RS-Codierer, der 16 Paritäts-Symbole an jeden Eingabe-Block anfügt und damit Code-blöcke aus je 255 Symbolen erzeugt.
• Synchronization marker (ASM)—Stellt jedem Codeblock einen 4-Byte ASM voran (für nicht-turbo-codierte Daten ist der ASM 1ACFFC1D im Hexadezimalformat). Der fertige Ausgabeblock ist 259 Bytes lang. Das Subsystem ‚Attach ASM’ erzeugt zusätzlich ein Startsignal für den RS-Codierer und zeigt ihm damit den Beginn eines neuen Codeblocks an.
• Faltungscodierung—Wandelt die Symbole in einen Bitstrom um und führt eine Faltungscodierung durch. Der Block‚Convolutional Encoder’ demultiplext den codierten Bitstrom außerdem in einen In-Phase- und einen Quadratur-Kanal (I- und Q-Kanal).
• I/Q Umwandlung —Der I/Q-Bitstrom wird von Seriell-zu-Parallel-Blöcken in zwei 2-Bit-Wortströme umgewandelt, aus denen die 16-QAM-Symbole auf der obersten Modellebene gebildet werden (ein 2-Bit-Wort je I/Q-Rail).

Kanalmodellierung

Die modulierten Daten werden durch ein Kanalmodell geschickt, in dem Simulink-Blöcke die gegenseitigen Störungen der Symbole, die Dopplerverschiebung und Additives Weißes Rauschen simulieren (s. Abb. 1). Das Modell verfügt über einen Schieberegler, mit dessen Hilfe sich die Dopplerverschiebung während der Simulation verändern lässt, um die Stabilität des Empfängers zu testen.

Die Schnittstelle zwischen dem Sender/Empfänger-Modell (Festkomma) und dem Kanalmodell (Fließkomma mit doppelter Genauigkeit) wird durch Xilinx-Gateway-I/O-Blöcke gebildet, die die Pins des FPGA repräsentieren. Diese Blöcke erlauben die Vorgabe von Datentyp, Datenformat, Quantisierung, Überlauf und Abtastzeit.

Entwurf des Empfängers

Abbildung 3 zeigt das Subsystem für den QAM-Empfänger. Da unser Entwurf für einen FPGA bestimmt ist, enthält er Blöcke aus dem System Generator Blockset. Das Subsystem für den QAM-Demodulator führt die gesamte Demodulierung durch (adaptive equalization, carrier recovery and slicing); der Rest des Empfängers übernimmt die Viterbi- und RS-Decodierung sowie die Frame-Synchronisation (Frame Aligning). Er enthält weiterhin einen Controller, der mehrdeutige QAM-Phasen auflöst. Das Subsystem „Frame Aligner” wandelt die seriellen Daten am Ausgang des Viterbi-Decoders in Bytes um, die die Eingabe für den RS-Decoder bilden. Mit Hilfe spezieller Bitmuster-Erkennungstechniken, die das ASM-Bitmuster auflösen, setzt das Substem ‚Frame Aligner’ die seriellen Daten so zusammen, dass stets das erste Bit des empfangenen ASM das MSB des zugehörigen Byte-Outputs bildet. Wenn das letzte Byte des ASM am dout-Port anliegt, wird das Match-Signal gesendet.

Abbildung 4 zeigt das Controller-Subsystem, das die Phasen der Symbole nach deren Demapping durch Inkrementierung des quad_select-Eingangs des QAM-Demodulators solange periodisch um 90° verschiebt, bis der Frame Aligner das ASM-Muster erkennt. Erst wenn das Signal synchronisiert ist, weist der Controller den RS-Decoderblock an, mit der Arbeit zu beginnen. Nach Empfang des gesamten 255 Byte langen Codeblocks stellt der Controller noch einmal sicher, dass die vier ASM-Bytes vom Frame Aligner korrekt empfangen wurden.

Automatische Hardware-Erzeugung

Durch einen Doppelklick auf das System Generator-Icon in der obersten Modellebene öffnet sich die GUI für die Hardwareerzeugung, in der man die FPGA-Famile und das genaue FPGA-Modell, den Netlist-Typ und die Taktrate für Simulink einstellt und festlegt, ob eine Testumgebung erzeugt werden soll (Abb. 5). Nach Bestätigung mit „Generate“ wird eine zyklus- und bitgenaue HDL-Netlist erzeugt, die mit Xilinx’ Im­plementierungs-Software ISE Foundation synthetisiert und FPGA-spezifisch verschaltet („placed and routed“) wird. Der System Generator bietet außerdem die Möglichkeit, automatisch einen FPGA-Bitstrom auf dem Target-Entwicklungsboard zu erzeugen (also den FPGA zu programmieren).

Co-Simulation und Hardware-Verifikation

Um einen auf einem FPGA implementierten Entwurf in eine Simulink-Simulation zu integrieren, muss man lediglich das passende Kompilierungs-Target aus dem Co-Simulationsmenü auswählen. Bei einer solchen Co-Simulation werden automatisch Bitströme zum und vom FPGA erzeugt und mit den entsprechenden System Generator-Blöcken im Simulink-Modell verbunden. Während der Simulation werden die Ergebnisse aus diesen kompilierten System Generator-Blöcken somit auf der realen FPGA-Hardware berechnet und nicht in Software emuliert. Man kann auf diese Weise den Entwurf zusammen mit der echten Hardware testen und dabei die Ausführung der System Generator-Blöcke typischerweise um den Faktor zehn bis hundert beschleunigen, was die Entwicklungs- und Debuggingzeit erheblich verkürzt. Mit dem JTAG-Interface mit Parallel Cable IV oder anderen spezialisierten Schnittstellen können die Hardware-in-the-Loop-Fähigkeiten des System Generator auch auf andere FPGA-Plattformen erweitert werden.

Alternativ kann man auch die Testumgebung sowie finale Daten in HDL-Simulationswerkzeuge, z.B. „Binary Waveforms“, exportieren, mit denen FPGA-Entwickler in der Regel vertraut sind.

Beschleunigung der Simulation mit Simulink

Die meisten Blöcke des Sender-Subsystems stammen aus dem System Generator Blockset. Sie können aber auch durch Simulink-Blöcke gleicher Funktion ersetzt werden. Das Communications Blockset enthält zum Beispiel Blöcke für die RS- und Faltungs-Codierung, die die entsprechenden Blöcke aus Abbildung 2 ersetzen können. Jeder Ansatz hat seine eigenen Stärken. Bei typischen Simulationen laufen Blöcke aus Simulink-Produkten in der Regel schneller als ihre Pendants aus dem System Generator, sie bieten dafür aber keinen direkten Weg zur FPGA-Implementierung. Die Blöcke des System Generator wiederum sind auf die Implementierung zugeschnitten und erlauben eine Simulationsbeschleunigung durch ihre HIL-Fähigkeiten. Simulink bietet in dieser Hinsicht eine sehr flexible Umgebung, in der sich immer diejenigen Blöcke kombinieren lassen, die dem aktuellen Entwicklungsstadium, z.B. Systementwurf oder Implementierung auf einem FPGA, entsprechen.

Produkte aus der Simulink-Familie und der Xilinx System Generator sind eine häufig verwendete Kombination, um FPGA-basierte Signalverarbeitungs-Algorithmen zu entwickeln. Zu den Anwendungsbereichen gehören digitale Kommunikationsgeräte, Video- und Bildverarbeitungssysteme oder auch Systeme für die Luftfahrt und die Verteidigungstechnik. Gemeinsam bilden sie die ideale Basis, um DSP-Algorithmen unter Simulink schnell zu entwickeln und anschließend automatisch auf FPGAs zu implementieren. Auf Basis der HIL-Fähigkeiten des System Generator können FPGA-Implementierungen zudem direkt mit Simulink verbunden und darin co-simuliert werden. Bei komplexen Entwürfen, die zur Verifikation über viele Millionen Zyklen hinweg simuliert werden müssen, bedeutet dies eine erhebliche Beschleunigung und damit oft die Einsparung mehrerer Monate an Entwicklungszeit.

[1] Consultative Committee for Space Data Systems, “CCSDS 101.0-B-5 Recommendation for Space Data System Standards – Telemetry Channel Coding,” June 2001.