www.mikrocontroller.net

Forum: FPGA, VHDL & Co. OFDM - welcher FPGA?


Autor: dschneid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin daran interessiert, einen Transceiver für OFDM zu entwickeln, 
und zwar im Rahmen von Powerline Communications. Ich habe mich in die 
Theorie und die entsprechenden Standards ganz gut eingelesen und mich 
vorab ein wenig mit Verilog beschäftigt. Jetzt geht es aber darum, einen 
konkreten Chip auzuwählen, auf dem das dann laufen soll. Ich habe noch 
nichts auf einem FPGA entwickelt, und ich bin auch neu im ganzen Bereich 
der Datenübertragung, das sage ich gleich vorneweg.

Das System soll vorerst auf 64 Kanälen senden (sprich: 64-point FFT), 
die im Frequenzbereich zwischen ungefähr 2 und 30 MHz liegen, wobei die 
einzelnen Träger zunächst eine einfache Form von QAM nutzen sollen. Die 
Symbollänge sollte im einstelligen Mikrosekundenbereich liegen. Spätere 
Ziele sind die Aufteilung des Frequenzbereiches in mehr Kanäle und 
adaptive Anpassung an Probleme mit der Leitung. Laut den Quellen, die 
ich gelesen habe, müssten so Datenraten bis 50 Mbit/s möglich sein.

Ich wüsste jetzt gerne, welcher Chip diese Anforderungen erfüllt, oder 
ob vielleicht sogar ein normaler DSP oder Mikroprozessor ausreichen 
würde.

Wie schon gesagt: Das Thema ist mir neu. Kann also durchaus sein, dass 
ich grobe Fehler begehe oder was wichtiges verschweige. Bitte habt dann 
etwas Nachsicht. ;-)

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine normale 64-Punkt FFT (komplex->komplex) braucht n/2*log2(n)=192 
Butterflies, pro Butterfly sind das 4*MUL und 6*ADD/SUB, evtl. noch eine 
Skalierung hier und da.. Die MULs sind das, was die Performance 
bestimmt, der Rest läuft meistens so nebenher. Für 5us pro FFT musst du 
also entweder mit ca. 40MHz 4MULs parallel machen oder mit ca. 160MHz je 
ein MUL. Das ist dann aber auch nur die FFT, weitere Filter, 
Dekodierung, etc. fehlt da noch.

Für typische FPGAs ist das so oder so kein Problem, da zB. Xilinx 
Spartan3 schon mehrere dedizierte MUL/DSP-Blöcke haben und auch locker 
mit >100MHz laufen. Ich würde schon fast sagen, das FPGAs dafür 
überdimensiniert sind, solange nicht noch weitere Verarbeitung dazukommt 
(Fehlerschutz, etc.). Dann kann man die Parallelität im FPGA voll 
ausnutzen. Auch nett ist es bei FPGAs, dass man nahezu beliebige 
Interfaces ins Design setzen kann und bis auf AD/DA/Speicher kaum mehr 
externen Kram braucht. Leider ist das Entwickeln für FPGAs nicht ganz so 
einfach...

Für bessere DSPs ist das mit der FFT auch nicht besonders 
herausfordernd, nur muss man den passenden DSP finden ;-) TI hat da in 
den 320Cx-Familien genügend mit Taktfrequenzen >200MHz zur Auswahl, 
Analog Devices gibts auch noch (Shark/Blackfin). Die Entwicklung für 
DSPs ist ingesamt etwas einfacher, weil man meistens in C arbeiten kann. 
Für zeitkritische Sachen nimmt man dann entweder fertige Kernels aus der 
Herstellerlibrary oder muss dann doch mal auf die Assemblerebene, wenns 
ganz knapp wird.

Ich würde aber erstmal raten, dass du dir über die Rechenanforderungen 
wesentlich genauer klar werden musst. Also Anzahl der Butterflies/s, 
Genauigkeit (16Bit oder Single Precision FP), zusätzliche Filtertaps für 
Equalizer/etc, "Control"-Code zur Synchronisation, Dekodierung und 
Fehlerschutz.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@dschneid:

> einen Transceiver für OFDM zu entwickeln
Sinnvollerweise baut man sich erstmal ein Referenzsystem (mit 
Kanalmodell) in eine geeigneten Hochsprache. Dort kannst Du dann auch 
sehen ob Deine FFT, QAM und Symbollänge ausreichend ist. Außerdem kannst 
Du mit dem Refernzsystem prüfen, ob Dein FPGA anschließend richtig 
rechnet.

Prinzipiell sind FPGAs dafür geeignet, aber wie der Vorredner schon 
schrieb, ist der Einarbeitungsaufwand nicht unerheblich. Du mußt mit 
mindestens 6 Monaten rechnen, bei dem was Du machen willst. Außerdem 
brauchst Du ja auch noch eine passende Hardware mit ADC/DAC und der 
Anbindung an die Powerline.

Die FFT und der QAM-(de)mapper gehen fix, bzw. das gibt es als fertigen 
Core, aber bis die Kontrollogik drumherum richtig läuft...

Duke

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es kommen schnell noch ein paar digitale Filter hinzu und dann 
Transeiver. Beide Richtungen auch noch gleichzeitig im Duplexverfahren 
ein Kanal hin und auf einen anderen zurück?
Der DSP ist dann doch überfordert.
Ich glaube du solltest den FPGA bevorzugen. Ich habe gerade einen Cordic 
Algorithmus (erzeugt Sinussignale) in einen Spartan3 implementiert und 
kann locker die Stützstellen mit 200MHz ausgeben. Mit einem Virtex würde 
ich sogar 400MHz schaffen. http://www.dossmatik.de/elektronik.html

Bei deiner Anforderung 5-30MHz würden das ca 40 Stützstellen sein. Damit 
sollte ein Signal detektierbar sein.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.