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. ;-)
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.
@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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.