DSPs für Open Source Hardwareprojekt

Jun 14, 2011 25 Replies

Servus,



ich bastle gerade an einem System f=C3=BCr die optische Freiraumkommunikation (aka LaserLink), das als Open Source ver=C3=B6ffentlicht werden soll. Das Projekt soll das in die Jahre gekommene und nicht mehr zeitgem=C3=A4=C3=9Fe Ronja-System (10MBit/s, Verwendung des Manchestercodierten Signals einer 10BaseT-Netzwerkkarte) beerben.



Ich bin zwischen FPGAs und DSPs geschwankt und habe mich jetzt f=C3=BCr die Verwendung eines DSPs entschieden, da damit die Implementierung der angedachten Modulationsverfahren einfacher sein d=C3=BCrfte. Ich habe zwar schon einige DSPs die in Frage k=C3=A4men bei Analog und TI gefunden, allerdings gibt es f=C3=BCr diese keine Open Source Tools.



Im Analog->Digitalpfad soll ein 12 oder 14 Bit ADC 66MS/s wandeln; die hohe Samplingtiefe tr=C3=A4gt dem zu erfassenden Dynamikumfang Rechnung (Streulicht, Blendung durch die Sonne usw.); nat=C3=BCrlich wird nur der Gleichstromanteil ausgewertet/gekoppelt, es geht um die durch S=C3=A4ttigungseffekte bedingten Nichtlinearit=C3=A4ten der Photodiode.



Digital->Analog-Wandlung erfolgt mit 10 Bit mit 30MS/s.



Die Nettobandbreite ist mit 100MBit/s angesetzt, falls es aber Rauschabstand des Signals und Rechenkapazit=C3=A4t des DSP zulassen w=C3=A4= re es w=C3=BCnschenswert, wenn es nach oben Luft h=C3=A4tte.



Interface ist Ethernet und ethernetseitig sollen auch ganz ordin=C3=A4re Ethernet-Frames dar=C3=BCber laufen. Auf der optischen Seite werden aber keine Ethernetframes =C3=BCbertragen: Stattdessen werden die Nutzdaten des Frames umgepackt, anstatt CRC32 Pr=C3=BCfsumme werden die Daten mit Reed-Solomon kodiert. Die umkodierten Nutzdaten dienen als Koeffizienten einer Inversen Short Time Fouriertransformation mit einer noch zu w=C3=A4hlenden Fensterfunktion.



Es wird also ein DSP gesucht, welcher mit so um die 200MHz bis 400MHz getaktet ist (darf auch langsamer sein, wenn er die entsprechenden Datenmengen wegschaufeln kann), mindestens 64kB, aber lieber 128kB aufw=C3=A4rts RAM hat, eine Schnittstelle f=C3=BCr so den schnellen Empfang= s ADC und einen FFT-Beschleuniger hat. Wenn dann noch Open Source Compiler/Linker und Programmiertools daf=C3=BCr verf=C3=BCgbar w=C3=A4ren, = w=C3=A4r's ideal.



Gibt's da was in der Richtung?


Wolfgang



Schau mal bei Renesas. Ich selber benutze ja einen SH2A fuer Audio, aber es gibt da auch noch speziellere und schnellere.

formatting link

Die Oberflaeche von Renesas erlaubt es fuer umsonst Programme bis maximal 256kByte Objektgroesse zu erzeugen. Es gibt aber auch einen gcc den ich auch nutze. Es soll aber auch gehen den gcc in HEW zu integrieren, allerdings habe ich das noch nicht gemacht. Wenn du den gcc verwenden willst dann solltest du bei den Typen mit DSP Erweiterung pruefen ob der gcc das kann, das weiss ich naemlich nicht.

BTW: In meinem neuen HMO2524 hat Hameg auch einen SH3 eingebaut. :)

Olaf

Eh, Wechselstrom meinte ich nat=C3=BCrlich. Bl=C3=B6der Verschreiber.

Ja, ich wollte schon fragen was der Aufwand soll und wieso du nicht einfach einen Mega8 nimmst. :-D

Olaf

[...]

Das ist schon eine ganze Menge Holz. Immerhin 300MBit/s plus Overhead. Also wohl 480MBit/s für den DSP/FPGA.

Also mehr als 6Bit pro Symbol? Oder habe ich mich verrechnet? Aber bei

30MS/s ist die maximale Symbolrate 15MSymb/s was 6.6Bit/Symbol minimal ergäbe. Das ist schon sehr sportlich.

Hmm - ist das üblich? Ich kenne mich mit Laserkommunikation nicht aus aber IMHO mach man dort OOK oder MASK. Aber Du wirst Dir sicher was dabei gedacht haben.

Die Geschwindigkeit reicht aber nie im Leben für 100MBit/s. Das wären ja

2-4 Zyklen für ein Bit. Nicht nur die Demodulation sondern vor allem auch die Dekodierung vom ReedSolomon braucht wesentlich mehr Leistung. Selbst wenn Du durch geschickte Mathematik mehr Bits pro Takt bearbeiten kannst.

Auch das erscheint mir zu wenig. Du musst ja schon mal eine ganze Menge Rohdaten vom ADC zwischenspeichern bevor Du mit der Verarbeitung anfangen kannst. Dann noch Ethernetframes die ggf. zu puffern sind usw. Zumal - wenn Du in den dreistelligen MHz Bereichen arbeitest die allermeisten CPUs sowieso einen DRAM Controller haben ist es auch kein Problem 32MByte DRAM anzuschließen.

Da fällt mir so Spontan nur ein ARM9 oder besser ARM11 ein. Die haben DSP Erweiterungen und sind vielleicht auch schnell genug. Nur möchte man dann idR. nicht von Null mit dem System anfangen sondern wenigstens ein kleines RTOS verwenden. (uCLinux, eCos usw.)

Nur ist bei diesen Prozessoren schon ein gehöriger Aufwand bei der Schal- tungstechnik zu betreiben. Meistens sind sie nur als BGA verfügbar und mit weniger als 6 Lagen wird es schwer die Anschlüsse herauszuführen. (Mit Burried Vias gehts evt. auch mit 4 - aber das ist teurer als 6 Lagen mit normalen Vias)

Ich denke man sollte das wirklich in einem FPGA machen. Der ist einfach besser dafür geeignet weil man die ganze Verarbeitung sehr schön paralelli- sieren kann. Für Opensource wäre es halt gut, wenn die Entwicklungsumgebung nicht kosten würde - man sich also z.B. auf das WebPack von Xilinx oder Lattice beschrän- ken könnte. Da wäre es herauszufinden welche größeren FPGAs unterstützt wer- den. Aber auch da ist der Schaltungsaufwand in Bezug auf Spannungsversorgung und Anzahl der zu routenden Leitungen nicht unerheblich.

Viele Grüße, Martin L.

Ich möchte Dich ja nicht demotivieren, aber Laserlinks sind leider sehr viel störanfälliger als Funklinks. Wir hatten auch mal eine Laserverbindung über

1km, die wir dann aber wegen der besseren Verfügbarkeit gegen WLAN getauscht haben. Besonders im Herbst war regelmässig Ruhe wegen Nebel. Es ist aber ein schönes Bastelprojekt - so zum Spass und zum Lernen. :-)

M.

Die gehen bei DSPs aber =C3=BCblicherweise noch parallel raus. Bei den DSPs die ich mir bisher angesehen habe bis zu 64Bit/Clock.

Angesetzt waren 6 Bit/Symbol. Auf Empfangsseite nat=C3=BCrlich mit entsprechendem Oversampling um entsprechenden Abstand der Schwebung der Samplingfrequenzen zu erreichen.

OOK stellt hohe Anforderungen an die Verst=C3=A4rker, da es theoretisch unendlich steile Flanken und kein Nachschwingen erfordert. MASK ist schon besser. Und tats=C3=A4chlich habe ich erst mit einer MASK-Modulation angefangen. Da die Amplitudenwechsel mit dem Bit-Takt erfolgen faltet man so auf das Signal harmonische mit genau diesem Takt auf und m=C3=BCllt so Bandbreite zu. Beide Verfahren takten die Bits temporal-sequenziell.

Die Idee ist nun in den Frequenzraum (nicht mit der Lichtfarbe verwechseln) zu wechseln und die Bits in ihrer Spektraldichte zu verteilen. Gleichzeitig k=C3=B6nnte man das SNR in den jeweiligen Frequenzb=C3=A4ndern bestimmen und die Bits so permutieren, dass m

=A4ren

Pro Zyklus wird =C3=BCblicherweise ein ganzes Wort verarbeitet, also bei g=C3=A4ngigen DSPs mindestens 16Bit, in modernen sogar 32 und oft sogar mehrere davon in SIMD. Multiplikation und Division brauchen meistens so um die 4 Zyklen, aber in modernen Pipeline-Architekturen erreicht man bei geschickter Programmierung >1 FLOPs/Zyklus.

Also 16Bit / Takt sind auf jeden Fall drin.

Ein Ethernetframe hat max. 2kB (ausgenommen Jumboframes, die aber nicht unterst=C3=BCtzt werden sollen), die meisten FFTs arbeiten in-place, =C3=BCberschreiben die eingegebenen Daten.

Eigentlich wollte ich das Ding so dumm wie m=C3=B6glich halten. Ethernet-Frames auf der einen Seite rein, Ansteuersignal auf der anderen Seite heraus und Vice Versa. Und die Informationen =C3=BCber SNR und =C3=A4hnlichem per UART zug=C3=A4nglich machen.

Ich habe eben gesehen, dass die Analog Devices Blackfins auch mit =C2=B5CLinux laufen und es eine OSS-Toolchain daf=C3=BCr gibt, also insofer= n w=C3=A4re das sogar eine Option.

=BCsse

Klar um Multilayer kommt man nicht herum. Es geht auch nicht darum das letztlich zum komplett selber basteln anzubieten. Eher so nach dem Muster vorbest=C3=BCckte Platine und die Optik baut man dann selber zusamme= n.

Gerade FFT braucht ziemlich viele Gates wenn man f=C3=BCr entsprechend viele Bits das Butterfly-Schema routet. Deshalb dachte ich ja gerade an die Verwendung eines DSP, da man mit jedem Oktet das hereinkommt den n=C3=A4chsten Schritt der FFT iterieren kann. Um das auf einem FPGA zu machen m=C3=BCsste man doch einen ordentlichen Batzen Schieberegister dazwischenschalten (oder ich mache gerade einen Denkfehler).

Wolfgang

Das der Durchgang durch ein steuendes Medium problematisch ist, ist mir klar. Welche Lichtwellenl=C3=A4nge war das denn? Was f=C3=BCr dunkel-/rotes= Licht undurchsichtig ist, kann f=C3=BCr Licht der doppelten Wellenl=C3=A4nge fast transparent sein. (Stichwort Mie-Streuung).

:-)

Stufe 1 ist fast abgeschlossen: Ethernetframes per Linux-TAP abgreifen und als "Audio"-Signal an die Soundkarte schicken, an deren Ausgang eine LED h=C3=A4ngt, bzw. am Eingang eine Photodiode am Verst=C3=A4rker und= das demodulierte/dekodierte Signal per TAP ausgeben. Ich will das diese Woche fertigstellen und dann versuchen die Bandbreite so weit hochzukitzeln wie es geht (wobei es da der limitierende Faktor alleine die Samplingfrequenz der Soundkarte ist und es darauf hinauslaufen wird zu kl=C3=A4ren wie viele Bits sich in ein Symbol packen lassen, bevor das Rauschen Probleme macht). BTW: Nebelmaschine ist auch schon organisiert, weil ich eben auch genau das Nebelproblem ausmessen will.

Wolfgang

"Wolfgang.Draxinger" :

Das war so ein professioneller roter oder infraroter Laser, den wir mal gebraucht gekauft haben. (also ein Datenübertragungssystem) Nebel ist kein streuendes Medium, Nebel ist ein ziemlich absorbierendes ;-), da geht kein Tuck sichtbares Licht hindurch, wenn er so richtig dicht ist. Ab einer bestimmten Menge Infrarot-Energie könnte man sich da aber nen Kanal durchbrennen :-).

Da das sowieso an den PC soll, würde ich die meiste Arbeit der CPU des PC's überlassen. Du bräuchtest dann eigentlich nur ne Hardware welche die Rohdaten schnell genug in den PC reinschaufelt. Also so ne Art Soundkarte mit 60MSPS (als USB3 Device sicher realisierbar, mit Abstrichen ev. auch USB2, mit einem aktuellen ARM-Controller sollten da 10-20MSPS machbar sein denke ich). Preisgünstige einfache und universelle Hardware sind in OpenSource Projekten auf jeden Fall beliebt. So eine "Soundkarte" wäre auch was feines für SoftwareOszilloskop oder SoftwareRadio ....

M.

Das h=C3=A4ngt von der Wellenl=C3=A4nge ab. 1300nm werden tats=C3=A4chlich = gut absorbiert, ein paar 100nm nebenan schon gar nicht mehr so sehr Den L=C3=B6wenanteil an Signalverlust macht aber Streuung aus. Bei jeder Streuung bleibt ein Teil der Energie in einem Nebeltr=C3=B6pfchen h=C3=A4ng= en. F=C3=BCr den Endeffekt spielt das keine gro=C3=9Fe Rolle: Egal ob durch Str= euung oder durch Absorbtion verursacht, die Menge Licht die am Ende herauskommt folgt einem exp(-\lambda * d) -Gesetz.

Das Ding soll sp=C3=A4ter unabh=C3=A4ngig von PCs sein, man soll es wie ein Netzwerkkabel zwischen Switches schalten k=C3=B6nnen.

Hmm, das w=C3=A4re sowieso mal eine Idee: Eine billige PCI-E Karte die einfach nur einen nackten, bidirektionalen GPIO, Takt und Interrupts bietet um ohne umst=C3=A4ndliche Basteleien mit USB oder =C3=A4hnlichem sol= ch Peripherie, wie ich sie mir vorstelle, anschlie=C3=9Fen zu k=C3=B6nnen (als= o z.B. die ADC, DAC eines solchen Systems).

Am Institut wo ich meine Diplomarbeit mache liegt ja eine Menge Zeug herum das in diese Richtung geht (VME-Bus Messwerterfassungsysteme und solcher Krempel), das ist aber alles langsamer als USB3 :(

Wolfgang

Nenn das Kind doch beim Namen: OFDM.

Kann man. Man kann auch unterschiedliche Modulationsstufigkeiten und Leistungen auf den Subträgern fahren.

Ich bin gerade dabei, meine Diss zu dem Thema (optisches OFDM für direkte Detektion) abzuschließen.

Wie? Das habe ich jetzt nicht verstanden. Du musst die Daten in den Speicher holen und kannst dann paarweise auf den Daten im Speicher arbeiten. DMA wäre gut für so etwas, würde ich vermuten.

Speicher sind im FPGA das geringste Problem. Mein Vorschlag: Kauf Dir 2 FPGA-Evaluation-Boards und fang damit an.

Gruß Henning

P.S.: Wir[TM] (Uni Bremen & Uni Kiel) hatten ursprünglich überlegt, im Rahmen unseres 3-Jahres-Forschungsprojektes auch ein Echtzeitsystem aufzubauen. Da so etwas ohne Labor-Ing. der Vollzeit daran arbeitet aber illusorisch ist, haben wir's dann gelassen. Das hat andere aber nicht davon abgehalten, so etwas durchzuziehen. Auf der ECOC '09 gab' ein Symposium zum Thema "Real-time digital signal processing for optical transceivers":

formatting link
Als Anhaltspunkt, was man so an Hardware braucht, hier ein Paper von der selben Konferenz:
formatting link

Eine typische (nicht optimierte) Split-Radix FFT sieht im Pseudocode so aus (eiskalt von der Wikipedia abgeschrieben)

Y_{0,...,N=E2=88=921}

"Wolfgang.Draxinger" :

Dann nenn das Dingens eben nicht PC sondern Router. Gibbet auch mit PCI- Express-Slots. Letztlich unterscheidet einen Router von einem PC die etwas langsamere CPU und der kleinere Aufbau. Hat eben den Vorteil, dass man sich voll auf die optische Sache konzentrieren kann und mit dem Rest - Betriebssystem, Verpacken und Verschicken übers Ethernet - auf bewährte fertige Lösungen setzen kann (Linux). Aus dem Kästle kommt hinten Ethernet raus und vorne Deine optische PCI-Express-Karte rein.

Jo, PCI-Express, was auch ins Notebook passt... :-). Im Prinzip könnte man da mit riesige Datenmengen recht schnell samplen. Da käme kaum ein kommerzieller Osci mit. Würde mich aber wundern, wenn es da nicht schon etwas im OpenHardware-Bereich gibt. M.

Matthias Weingart :

Schon etwas in die Richtung:

formatting link

Praktisch denke ich aber USB3.0 würde größere Aktzeptanz finden. Dummerweise gibt es da noch nicht so viel an für Amateure verbaubarer IC's.

M.

Matthias Weingart :

Preisgünstig wird PCI-Express aber auch nicht:

formatting link
formatting link

Dann schon eher den neuen USB3.0 Controller von Cypress mit 320MBps:

formatting link
usb-fx3/ Wobei wird dann als Plattform aber wieder beim PC angekommen sind, Router mit USB3.0 kenne ich eher nicht ;-).

M.

Das brauchst Du mir nicht zu erklären. Mein Chef hat da so ein Buch geschrieben[1]. :-)

Schon klar. Der elementare Butterfly.

Ok,...

Was verstehst Du unter Einspeisen? Die Resultate von ditfft2([x1, x2],

2) und ditfft2([x3, x4], 2) werden an die aufrufende Instanz zurückgereicht, die sie kombiniert, bevor deren aufrufende Instanz eine neue 4-Punkte-Instanz für x5 bis x8 aufruft. Wie kriegst Du das Einlesen mit der Berechnung synchronisiert? Über einen Puffer?

Nun, ein Butterfly muss ja nun zumindest mit 2 direkt benachbarten Eingangsvariablen arbeiten, was soll nach x1=x(0) und x2=x(1) als x3 und x4 als nächstes verarbeitet werden?

Ich versteh' nicht, wie man mit einer N-Punkte-FFT auf 2^N-1 "Frequenzbänder" (das Wort ist eh falsch) kommen will. Wenn Du darauf anspielst, dass während N Eingangswerte vorbeirauschen je ein N-Punkte- Spektrum aus der FFT herauspurzeln soll: Da käme in einer theoretischen verzögerungsfreien Implementierung wohl irgendwas raus, aber kein Spektrum.

Hast Du mal systemtheoretisch berechnet, was das überhaupt ist?

Gruß Henning

[1] Man schaue in das Vorwort zur 7. Auflage.

Ok, dann wäre es schon ein Spektrum, das eines gleitenden Ausschnitts. Allerdings nicht, wenn das Signal sich geändert hat, bevor die FFT komplett durchgelaufen ist.

Gruß Henning

Ganz genau. Das Ergebnis ist eine log2 Zeit-/Frequenz-Pyramide (oder ein Dreieck (wenn man die Zeitachse log2 auftr=C3=A4gt), wobei mich nur die zeitlich j=C3=BCngsten Elemente interessieren. Die hohen Frequenzen "laufen" nat=C3=BCrlich schneller durch.

t-N ... t-3 t-2 t-1 t F_N: x x x x x ... F_2: x x x x F_1: x x F_0: x

Anstatt das man nun f=C3=BCr jedes neue Sample die komplette FFT neu durchexerziert, schiebt man die in das h=C3=B6chste Frequenzband hinein; sobald dieses um N weitergeschoben wurde, wird das darunter liegende um eines weitergeschoben usw. Genau so wie bei einem Z=C3=A4hler mit Basis(Radix) N. Und jetzt rate mal woher die Bezeichnung Radix-N FFT her kommt :)

Tut es ja nicht; also das was bisher aufgenommen wurde nat=C3=BCrlich. Wenn sich nat=C3=BCrlich das ganze Signal =C3=A4ndern w=C3=BCrde, h=C3=A4tte man= ein Problem, aber die Historie bleibt ja gleich, es kommen nur neuere Samples zu den alten hinzu. Zu Anfang dieser inkrementellen FFT fehlen nat=C3=BCrlich die niedrigen Frequenzen, die kommen sp=C3=A4ter hinzu.

Wolfgang

Ich verstehe aber immer noch nicht, wie Du jetzt die Daten auf die Subträger verteilen willst.

Was meinst Du jetzt mit "die"?

In welche Richtung willst Du das schieben? Zeit- oder Frequenzrichtung?

Du hast vorhin aber noch von einer Radix-2-FFT gesprochen, sonst gäbe es ja keine Butterflies. N=2^p. Der von Dir zitierte Wikipedia-Pseudocode implementiert eine N-Punkte Radix-2-FFT.

Wie willst Du die Signalsynthese am Sender gestalten?

Gruß Henning

henning paul home: http://home.arcor.de/henning.paul PM: henningpaul@gmx.de , ICQ: 111044613

Das Kind hei=C3=9Ft tats=C3=A4chlich OFDM. Da meint man, man h=C3=A4tte sic= h was komplett selber =C3=BCberlegt, ist stolz wie Oscar das es in der Simulation funzt, und dann stellt man fest, dass man Standardtechnologie neu erfunden hat :/

Ich habe mir jetzt nochmal die M=C3=BChe gemacht die Literatur zu OFDM noch mal ganz genau zu lesen.

Ich habe mir den ganzen Sums wirklich komplett from scratch selber =C3=BCberlegt, innerhalb von ca. 2 Wochen, also mit Guard-Intervallen, QAM, Pilot-Symbolen usw.

D.h. habe ich mir das komplett selber =C3=BCberlegt? =C3=9Cber OFDM und die ganzen anderen Modulationsverfahren habe ich auch oft genug grobe Abhandlungen gelesen *seufz*

Wolfgang

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required