Morgen,
ich brauche mal einen Schubser in die richtige Richting.
Wir steuern zwei Geräte per FPGA über jeweils 32 Bit (1 Daten- und ein
Steuerwort). Das ganze ist recht schnell, u.A. deswegen der FPGA.
Rechnerisch ca. 30Mbit oder schneller, was parallel natürlich kein
Problem ist.
Jetzt ist die Überlegung die Übertragung zu serialisieren, galvanisch zu
trennen und räumlich zu entkoppeln. Sprich Lichtwellenleiter.
Prinzipiell reicht ja ein Schieberegister mit Latch, allerding will ich
das Rad nicht neu erfinden sondern benutzen.
Meine Recherchen haben mich bisher zu SERDES bzw. Transceiver/Receiver
ICs gebracht. Prinzipiell eine schöne Sache, aber das scheint mit etwas
komplex für den Eigenbau. Die ICs z.b. von Cypress, TI etc. scheinen
alle max, 8-10 Bit zu übertragen. Für 32 Bit bracht man man eine
schnelle Logik (Digitallogik, oder gleich IC/FPGA), ein Protokoll etc.
Außerdem wollen wir keine komplexen Platinen entwerfen.
Wie macht man das? Gibt es fertige Module?
Ggf. müsste man auch schauen ob der FPGA die Serialisierung übernimmt,
d.h. ob es IP-Cores gibt. Denn eigentlich ist die IO-Benutzung eine
massive Ressourcenverschwendung die z.Z. auch ein Problem ist.
Gruß
Christoph
Viele akuelle FPGAs haben solche Multi Gigabit Transceiver. Also z.B.
die Basis für PCIe oder SATA. Die Cores für die Ansteuerung gibts
eigentlich immer dazu, did high level Sachen wie PCIe und so kosten
meistens. Brauchst du ja aber nicht. An diese Ports kannst du direkt
z.B. SFP Module für LWL anschließen. Bei den Xilinx Demo Boards ist der
SFP Käfig meist schon drauf, das könntest du fertig nehmen.
Moin,
ev. kannst Du ja schon die 7:1 CameraLink-Logik des MachXO2 oder '3
vergewaltigen. Fragt sich halt, was du für Datenraten brauchst..
Für mehr (bis 3 Gbit/s) musst du halt zu was wie ECP3, ECP5 oder doch
was aus der Xilinx-Reihe im höheren Preissegment greifen.
Auf jeden Fall musst du da kaum viel neu machen, das kommt alles mehr
oder weniger "gratis" mit und funktioniert recht gut.
Chrikapie schrieb:> Jetzt ist die Überlegung die Übertragung zu serialisieren, galvanisch zu> trennen und räumlich zu entkoppeln. Sprich Lichtwellenleiter.
Warum kommst du von diesen Anforderungen auf dieses teure Medium? Andere
übertragen Gigabits pro Sekunde für einen Bruchteil der Kosten.
Wenn die 30MBit pro Sekunde sind, dann ist die Ein- und Ausgabe auch
ganz ohne Zusatzhardware kein Problem. Denn gleich vor dem Sender und
nach dem Empfänger ist das nur noch ein 32-bit Wort pro Mikrosekunde...
Wenn es 30 Millionen Kommandos pro Sekunde mit je 64 Bits sind, dann ist
das mit 1GBit/s schon sportlicher.
Lothar M. schrieb:> arum kommst du von diesen Anforderungen auf dieses teure Medium? Andere> übertragen Gigabits pro Sekunde für einen Bruchteil der Kosten.
Was ist da teuer? Bitte um Beispiele!
Chrikapie schrieb:> Die ICs z.b. von Cypress, TI etc. scheinen> alle max, 8-10 Bit zu übertragen.
Du solltest das Rad nicht neu erfinden.
Die 8B/10B Kodierung ist ein Standard, der technische Vorteile bietet
und überall Verwendung findet.
Viele FPGAs haben SERDES Blöcke, welche darauf basieren und
untereinander kompatibel sind.
Übertrage die 32 Bit lieber als 4 x 8Bit.
Lala schrieb:> Was ist da teuer? Bitte um Beispiele!
Teuer im Vergleich zu SATA/HDMI usw. ist das schon, ein optischer
Gigabit-Transceiver macht was her. Bei einer entsprechenden Rate würde
ich da lieber in etablierte Cores investieren und den Spass per
einfaches SATA-Kabel (been there, done that, siehe auch die Klassiker
von Dan Strother) oder auf TMDS-Basis (HDMI) umsetzen (das
Lane-Deskewing-Geraffel muss man dafür ja nicht implementieren).
Mit TMDS hat man es fast so gut wie galvanisch entkoppelt. Ansonsten
gibt es auch Verrückte, die per Twisted Cat5 lustige LVDS-Sachen machen.
10b8b ist dafür Pflicht, aber sowas muss man ja nicht neu schreiben.
Vielen Dank schonmal für die Antworten, und sorry wegen der verspäteten
Antwort.
Strubi schrieb:> Moin,>> ev. kannst Du ja schon die 7:1 CameraLink-Logik des MachXO2 oder '3> vergewaltigen. Fragt sich halt, was du für Datenraten brauchst..> Für mehr (bis 3 Gbit/s) musst du halt zu was wie ECP3, ECP5 oder doch> was aus der Xilinx-Reihe im höheren Preissegment greifen.> Auf jeden Fall musst du da kaum viel neu machen, das kommt alles mehr> oder weniger "gratis" mit und funktioniert recht gut.
Danke, natürlich geht das irgendwie. Aber ich weiß nicht ob das der
richtige Weg ist. Mein erster naiver Gedanke war: Kann man da nicht
irgendwas missbrauchen? Dann ist mir allerdings eingefallen dass man
auch einfach die richtige Lösung für das Problem kaufen kann ... ;-)
Lothar M. schrieb:> Chrikapie schrieb:>> Jetzt ist die Überlegung die Übertragung zu serialisieren, galvanisch zu>> trennen und räumlich zu entkoppeln. Sprich Lichtwellenleiter.> Warum kommst du von diesen Anforderungen auf dieses teure Medium? Andere> übertragen Gigabits pro Sekunde für einen Bruchteil der Kosten.
Naja alles ist relativ. Die Kosten für Empfänger und Sender sind nach
dem was ich bisher gesehen habe überschaubar.
Außerdem reden wir hier von einzelgefertigter Hardware für sehr
spezifische Zwecke.
Kosten sind erstmal zweitrangig, sofern die Lösung zieführend, sinnvoll
und begründbar ist.
Klaus F. schrieb:> Chrikapie schrieb:>> Die ICs z.b. von Cypress, TI etc. scheinen>> alle max, 8-10 Bit zu übertragen.>> Du solltest das Rad nicht neu erfinden.> Die 8B/10B Kodierung ist ein Standard, der technische Vorteile bietet> und überall Verwendung findet.> Viele FPGAs haben SERDES Blöcke, welche darauf basieren und> untereinander kompatibel sind.>> Übertrage die 32 Bit lieber als 4 x 8Bit.
Ja klar, mir ist es letztendlich egal was wie übertragen wird.
Die Frage ist: Wie sieht die Empfängerseite aus? Gibt es da was
fertiges?
Die Alternative ist ein vergleichbaren FPGA wie bisher. Wäre dann einer
pro Empfangsseite. Dann muss ich mich "nur" noch darum kümmern wie die
FPGAs untereinander kommunizieren.
Da bin ich allerdings recht zuversichtlich, bzw. das ist ja nichts was
man nicht was man nicht vorher rausfinden kann.
Das ganze sah auf den ersten Blick etwas übertrieben aus (d.h. unnötig
teuer).
Strubi schrieb:> Lala schrieb:>> Was ist da teuer? Bitte um Beispiele!>> Teuer im Vergleich zu SATA/HDMI usw. ist das schon, ein optischer> Gigabit-Transceiver macht was her. Bei einer entsprechenden Rate würde> ich da lieber in etablierte Cores investieren und den Spass per> einfaches SATA-Kabel (been there, done that, siehe auch die Klassiker> von Dan Strother) oder auf TMDS-Basis (HDMI) umsetzen (das> Lane-Deskewing-Geraffel muss man dafür ja nicht implementieren).> Mit TMDS hat man es fast so gut wie galvanisch entkoppelt. Ansonsten> gibt es auch Verrückte, die per Twisted Cat5 lustige LVDS-Sachen machen.> 10b8b ist dafür Pflicht, aber sowas muss man ja nicht neu schreiben.
Ich glaube ich bräuchte jemanden wie dich als Kollegen ... ;-)
Chrikapie schrieb:> Morgen,>> ich brauche mal einen Schubser in die richtige Richting.>> Wir steuern zwei Geräte per FPGA über jeweils 32 Bit (1 Daten- und ein> Steuerwort). Das ganze ist recht schnell, u.A. deswegen der FPGA.> Rechnerisch ca. 30Mbit oder schneller, was parallel natürlich kein> Problem ist.>> Jetzt ist die Überlegung die Übertragung zu serialisieren, galvanisch zu> trennen und räumlich zu entkoppeln. Sprich Lichtwellenleiter.
Warum kein LAN 100MBit
Chrikapie schrieb:
...
> Danke, natürlich geht das irgendwie. Aber ich weiß nicht ob das der> richtige Weg ist. Mein erster naiver Gedanke war: Kann man da nicht> irgendwas missbrauchen? Dann ist mir allerdings eingefallen dass man> auch einfach die richtige Lösung für das Problem kaufen kann ... ;-)>
Wenn dein FPGA halt schon steht, nimm nen externen Serdes und steuer ihn
an. Wenn du die Wahl hast, ist die pure FPGA-Lösung sicher weniger
stressig. Der Sensor-Extender mit den MachXO2 von Lattice ist z.B. gut,
der macht genau so ne LVDS-Nudelei über ein RJ45 Cat5, am einen Ende
gehn Videodaten rein, am andern wieder 1:1 raus. Ist halt nonstandard,
max. Bandbreite glaube ich bei ca 60 MB/s (600 mbit/s auf dem LVDS).
Und nicht galvanisch entkoppelt (ohne Trafo am RJ45).
Der SATA-Hack läuft wiederum auf einem Spartan6 ganz ok, allerdings
dauerte das deutlich länger als mit dem MachXO2 und lief auf eklige
manuelle Plazierung raus, die Xilinx-P&R war da echt bitchy.
Fragt sich halt, was du für nen FPGA einsetzt, und ob die galvanische
Entkopplung so zwingend ist. Wenn ja, ist Renes Argument mit einem
echten Phy auch noch gewichtig, nur bringt Ethernet wieder so andere
Probleme und Verkomplizierung.
Chrikapie schrieb:> Ich glaube ich bräuchte jemanden wie dich als Kollegen ... ;-)
Aber nicht, dass du mir dann das Zeug auf meinen Schreibtisch legst,
nech :-)
Strubi schrieb:> Chrikapie schrieb:> ...>> Danke, natürlich geht das irgendwie. Aber ich weiß nicht ob das der>> richtige Weg ist. Mein erster naiver Gedanke war: Kann man da nicht>> irgendwas missbrauchen? Dann ist mir allerdings eingefallen dass man>> auch einfach die richtige Lösung für das Problem kaufen kann ... ;-)>>>> Wenn dein FPGA halt schon steht, nimm nen externen Serdes und steuer ihn> an. Wenn du die Wahl hast, ist die pure FPGA-Lösung sicher weniger> stressig.
Genau da hänge ich aber. Wenn ich einen externen SERDES nehme, brauch
ich doch wieder eine Logik die die Daten verwertet und nach meinen
Wünschen parallelisiert?
Denn ein SERDES das mir 32Bit überträgt und parallel ausgibt habe ich
nicht gesehen, bzw. scheint ja auch etwas an der Grundidee vorbei zu
gehen.
D.h. wenn ich sowieso eine Logik brauche, dann kann ich doch direkt die
FPGA zu FPGA Lösung vorziehen ?
Strubi schrieb:> Der Sensor-Extender mit den MachXO2 von Lattice ist z.B. gut,> der macht genau so ne LVDS-Nudelei über ein RJ45 Cat5, am einen Ende> gehn Videodaten rein, am andern wieder 1:1 raus. Ist halt nonstandard,> max. Bandbreite glaube ich bei ca 60 MB/s (600 mbit/s auf dem LVDS).> Und nicht galvanisch entkoppelt (ohne Trafo am RJ45).
Witzig, da gibts ein Raspberry-Shield für :-D ... ist vielleicht was für
mich zum Spielen daheim.
Strubi schrieb:> Fragt sich halt, was du für nen FPGA einsetzt, und ob die galvanische> Entkopplung so zwingend ist. Wenn ja, ist Renes Argument mit einem> echten Phy auch noch gewichtig, nur bringt Ethernet wieder so andere> Probleme und Verkomplizierung.
Ist ein Virtex-5. Galv. Entkopplung weil Geräte mit hohe Lasten
geschaltet werden (120kW peak) und Erdschleifen vermieden werden müssen.
Außerdem ist es natürlich furchtbar cool (deswegen müssen es auch
zwingend sichtbares Wellenllängen sein).
Strubi schrieb:> Chrikapie schrieb:>> Ich glaube ich bräuchte jemanden wie dich als Kollegen ... ;-)>> Aber nicht, dass du mir dann das Zeug auf meinen Schreibtisch legst,> nech :-)
Ne das nicht. So ein Problem ist nur ein furchtbar undankbares
Smalltalkthema. Aber auch eins bei dem 15 Minuten Kaffeepausengespräch
mehr bringen als 4 Stunden google.
Chrikapie schrieb:
..
> Denn ein SERDES das mir 32Bit überträgt und parallel ausgibt habe ich> nicht gesehen, bzw. scheint ja auch etwas an der Grundidee vorbei zu> gehen.> D.h. wenn ich sowieso eine Logik brauche, dann kann ich doch direkt die> FPGA zu FPGA Lösung vorziehen ?>
Ja, zumindest hat sich das bei mir so immer herausgestellt.
32 Bit gibt's m.W. nicht, also etwas Demux/Mux-Logik musst du so oder so
basteln, 7:1 ist ja auch an den 28 Bit des CameraLink-Standards
orientiert.
Das ist ja ansich auch ein Klacks umzusetzen, wenn man sich nicht die
Sorgen betr. der physikalischen Uebertragung machen müsste.
> Strubi schrieb:>> Der Sensor-Extender mit den MachXO2 von Lattice ist z.B. gut,>> der macht genau so ne LVDS-Nudelei über ein RJ45 Cat5, am einen Ende>> gehn Videodaten rein, am andern wieder 1:1 raus. Ist halt nonstandard,>> max. Bandbreite glaube ich bei ca 60 MB/s (600 mbit/s auf dem LVDS).>> Und nicht galvanisch entkoppelt (ohne Trafo am RJ45).> Witzig, da gibts ein Raspberry-Shield für :-D ... ist vielleicht was für> mich zum Spielen daheim.>
Poste doch mal den Link, würde mich auch interessieren. Konnte es nicht
finden.
> Strubi schrieb:>> Fragt sich halt, was du für nen FPGA einsetzt, und ob die galvanische>> Entkopplung so zwingend ist. Wenn ja, ist Renes Argument mit einem>> echten Phy auch noch gewichtig, nur bringt Ethernet wieder so andere>> Probleme und Verkomplizierung.> Ist ein Virtex-5. Galv. Entkopplung weil Geräte mit hohe Lasten> geschaltet werden (120kW peak) und Erdschleifen vermieden werden müssen.> Außerdem ist es natürlich furchtbar cool (deswegen müssen es auch> zwingend sichtbares Wellenllängen sein).>
Du hast ja Randbedingungen :-)
Also die mir so gängigen Dinger gehen alle bei 850nm los (IR).
Langsamer geht es sicher auch bei 650, die Fasern sollten das packen.
HDMI/TMDS hacks fallen aber so wohl weg, wenns massefrei sein muss.
> Strubi schrieb:>> Chrikapie schrieb:>>> Ich glaube ich bräuchte jemanden wie dich als Kollegen ... ;-)>>>> Aber nicht, dass du mir dann das Zeug auf meinen Schreibtisch legst,>> nech :-)> Ne das nicht. So ein Problem ist nur ein furchtbar undankbares> Smalltalkthema. Aber auch eins bei dem 15 Minuten Kaffeepausengespräch> mehr bringen als 4 Stunden google.
Bei Google findet man lange schon keine Geheimtips mehr...
>> Strubi schrieb:> Poste doch mal den Link, würde mich auch interessieren. Konnte es nicht> finden.
Unter Development Kits & Boards
http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/RaspberryPiFPGA.aspxhttp://www.bugblat.com/products/pif/index.html
Gibts auch bei watterott
(http://www.watterott.com/de/Bugblat-PIF2-FPGA-for-Raspberry-Pi). Bin
mir nicht ganz sicher ob das sinnvoll ist, aber zum Spielen reicht es
hoffentlich. Ich hab auch keine Ahnung was für ein Rattenschwanz an
Ärgernissen das hinter sich herzieht. Aber wenns geht wäre das ein
schöner Test-Zwerg.
>>> Strubi schrieb:> Du hast ja Randbedingungen :-)> Also die mir so gängigen Dinger gehen alle bei 850nm los (IR).> Langsamer geht es sicher auch bei 650, die Fasern sollten das packen.> HDMI/TMDS hacks fallen aber so wohl weg, wenns massefrei sein muss.
Naja gut die sichtbare Wellenlänge ist eher eine der ... optionalen
Requirements ;-) Aber irgendwas muss natürlich blinken und leuchten.
>> Strubi schrieb:>>> Chrikapie schrieb:>>>> Ich glaube ich bräuchte jemanden wie dich als Kollegen ... ;-)>>>>>> Aber nicht, dass du mir dann das Zeug auf meinen Schreibtisch legst,>>> nech :-)>> Ne das nicht. So ein Problem ist nur ein furchtbar undankbares>> Smalltalkthema. Aber auch eins bei dem 15 Minuten Kaffeepausengespräch>> mehr bringen als 4 Stunden google.>> Bei Google findet man lange schon keine Geheimtips mehr...
Ich will ja keine Geheimnisse ;-)
nachtrag: was natürlich für das FPGA-Shiel spricht ist dieser eine Satz:
"And Flashing Lights!!"
;-)
Ist jetzt offtopic: Aber sowas find ich wirklich wichtig. Wäre nicht das
erste mal, dass unsinnige oder nicht vorhandene Status-LEDs für
Verwirrung sorgen. Z.B.: rote LED leuchtet = alles super. Toll. Hat nur
noch die grüne Fehler-LED gefehlt.
