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.
:
Bearbeitet durch Moderator
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.aspx http://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.
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.