Hallo zusammen Ich gedenke eine I/O erweiterung zu bauen für 2 unabhängige Einsatzmöglichkeiten: 1. FPGA-FPGA link über LWL zb mittels FTLX8574D3BCL benötigt hierbei werden einige gbps. 2. FPGA-Datenbank (auf PC über Ethernet (FTLX8574D3BCL)) link. Hierbei sollte eine signalliste auf dem FPGA mit der DB auf dem PC Synchronisiert werden. LWL GBE, benötigt werden ca 200mbps. Angedacht habe ich Cyclone oder Spartan, aber evtl. würde insbesondere für Punkt 2 ein SOC benötigt. Weiter die Frage nach der IP für dieses vorhaben. Bietet dies ein Hersteller frei zur Verfügung? Was würdet ihr für dieses Vorhaben empfehlen?
Moin, Wenn nur das Streaming schnell sein muss und nicht zig kleine Anfragen bewaeltigt werden muessen, tut's ein Minimalansatz mit UDP-Stack, ein Spartan6-LX9 mit RISC-V SoC reicht gerade noch so knapp, besser klappts mit einer ZPU-Architektur. Ansonsten kannst du auch mit Linux und hard-core(ARM) SoC draufhauen, aber auch bei den entsprechenden Komplexitaeten ins Stolpern kommmen. Nicht zu vergessen: Auch Lattice Semi (plus third parties) haben wunderschoene Streaming-Referenzdesigns fuer ihre ECP5 Plattformen. Schlussendlich gilt fuer alle: Kostenlos sind die IP nirgendwo, das Knowhow auch nicht. Das wichtigste ist ein effizienter DMA-Core, sonst bringt das alles nix (und du duempelst auf uIP/lwip-Performance rum).
In der Xilinx Welt koennte je nach Aufgabe auch der Artix was sein, das haengt halt stark von der Rechenpower ab. Schau dir mal das AC701 Evalboard an, das hat eigentlich genau das drauf was du suchst und zu allem Beispiel Designs: https://www.xilinx.com/products/boards-and-kits/ek-a7-ac701-g.html#hardware Die MGTs gehen bis 6.6 Gbps, ist die Frage ob dir das reicht? Falls nicht muss es die naechst groessere Familie sein, das sind dann die Kintex. Der Artix 7 200T ist schon ein ziemlich maechtiger FPGA, evtl. kommst du auch schon mit einem wesentlich kleinerem FPGA zurecht, z.B. ein 50T. Zum evaluieren ist das allerdings auch kein Fehler erstmal mit dem dicken FPGA anzufangen, dein Design soweit fertig zu machen und dann entsprechend den richtigen Chip auszuwaehlen.
Und warum FPGA? Das sind Aufgaben die eine CPU gut machen kann, ich sehe keinen Grund für Parallelität oder rekonfigurierbare Logik.
Weltbester FPGA-Pongo schrieb im Beitrag #6435735: > Hast du das ETH auf dem AC701 mal zum Laufen bekommen? Ging das an mich? Falls ja, muss ich mit Nein antworten, allerdings nur weil ich es nie ausprobiert habe und nicht mehr im Besitz eines AC701 bin. :-( Gustl B. schrieb: > Und warum FPGA? Das sind Aufgaben die eine CPU gut machen kann, ich sehe > keinen Grund für Parallelität oder rekonfigurierbare Logik. Nope, FPGAs scheinen erstmal genau das Mittel der Wahl zu sein. FPGAs sind geradezu zum schaufeln grosser Datenmengen gemacht. Und ueber welche CPU hat den Anbindung fuer seinen Fiberlink?
Punkt 1 und Lösung via CPU schliessen sich ja wohl bei der Datenmenge total aus. Frage dazu: Moderne (und teure) FPGAs haben ja dedizierte Cores mit entsprechend schnellen Schnittstellen nach aussen. Gibt es für kleinere FPGAs auch Phys zum Zwischenschalten zwischen FPGA-Pins und Fiberlink-Controller, so ab 10Gbps?
Sigi schrieb: > Gibt es für kleinere > FPGAs auch Phys zum Zwischenschalten zwischen > FPGA-Pins und Fiberlink-Controller, so ab 10Gbps? Das ist schwierig. Zumindest in der Xilinx Welt fangen MGTs ueber 10 Gbps erst bei den Kintex an. Die wuerde ich aber schon nicht mehr zu den kleineren FPGAs zaehlen. Die Alternative waehrend dann externe SerDes Bausteine, so dass man auf MGTs komplett verzichten kann.
FPGA schrieb im Beitrag #6435398: > Ich gedenke eine I/O erweiterung zu bauen für 2 unabhängige > Einsatzmöglichkeiten: Es ist völlig unklar für welches Gerät diese Erweiterungen seien sollen. Nur um Daten von A nach B zu schaufeln braucht man keinen FPGA. Da kann man auch Standardhardware nehmen. Z. B. Netzwerkkarten für PCIe. Gibt es fertig und auch mit hohen Datenraten.
Gustl B. schrieb: > > Es ist völlig unklar für welches Gerät diese Erweiterungen seien sollen. > Nur um Daten von A nach B zu schaufeln braucht man keinen FPGA. Da kann > man auch Standardhardware nehmen. Z. B. Netzwerkkarten für PCIe. Gibt es > fertig und auch mit hohen Datenraten. Diese Quatsch Diskussion hatten wir vor ein paar Wochen schonmal. Es sind genug Infos vorhanden um eine fachkundige Antwort zu geben. Und wenn man dem nicht maechtig ist, darf man sich auch einfach nur enthalten. ;-)
Tobias B. schrieb: > Es sind genug Infos vorhanden um eine fachkundige Antwort zu geben. Sehe ich nicht so. Um was geht es denn? Sollen viele Daten zwischen zwei noch unbekannten Geräten ausgetauscht werden? Dann wäre interessant welche Geräte das sind. Heutzutage haben sehr viele PCIe oder FMC und für beides gibt es fertige Hardware. Sollen Daten zwischen zwei FPGAs ausgetauscht werden weil die Daten aus noch unbekannten Gründen in FPGAs anfallen/vorliegen? Dann wäre interessant ob die FPGA Hardware schon fertig ist oder nicht. Denn 1. gibt es genug FPGA Boards mit (q)sfp+ drauf (Terasic hat viele) 2. Könnte man je nach Anwendung den Umweg über einen Rechner gehen. Also Daten vom FPGA über DMA in den Rechner und dann wieder über normale Netzwerkhardware raus zum zweiten Rechner. Es wurden keine Anforderungen an die Latenz genannt. Mir ist weiterhin unklar warum da FPGA drinnen sein muss. Die Entwicklung eigener Hardware mit sfp+ und FPGA wird deutlich teurer wie Hardware von der Stange. Sigi schrieb: > Punkt 1 und Lösung via CPU schliessen sich ja wohl > bei der Datenmenge total aus. Tobias B. schrieb: > Und ueber > welche CPU hat den Anbindung fuer seinen Fiberlink? Quasi jeder moderne PC mit PCIe. Da kauft man sich eine Netzwerkkarte und hat die 10 GBit/s (auch 40 GBit/s gibt es zu kaufen). Und selbst ein ganzer PC der das kann ist günstiger wie eine Neuentwicklung. Klar, braucht mehr Strom. Aber auch dazu steht nix in den Anforderungen. Tobias B. schrieb: > darf man sich auch einfach nur enthalten. ;-) Das konnte ich noch nie, bin gerne ein seltsamer unangepasster Aussenseiter.
:
Bearbeitet durch User
Gustl B. schrieb: > Quasi jeder moderne PC mit PCIe. Da kauft man sich eine Netzwerkkarte > und hat die 10 GBit/s (auch 40 GBit/s gibt es zu kaufen). Ein PC ist aber nicht nur die CPU, das Wesentliche ist beim PC der PCIe-Bus, der als DMA-Kanal genutzt wird. Die CPU spielt hier nur die dirigierende Komponente. Es gibt sogar schon PCIe-Karten mit 4* 40 GB/s, dank PCIe und DDR4 kein Problem. Probleme treten aber dann auf, wenn die Daten auch noch in "Realzeit" bearbeitet werden müssen, da ist selbst ein schneller PC zu langsam. Wurde aber hier in Foren schon oft genug beschrieben.
Sigi schrieb: > Ein PC ist aber nicht nur die CPU Hatte ich auch nicht behauptet. War auch nicht gefordert. Sigi schrieb: > in "Realzeit" bearbeitet > werden müssen, da ist selbst ein schneller PC zu > langsam. Wurde aber hier in Foren schon oft genug > beschrieben. Realzeit wurde nicht gefordert. Mag auch sein, dass es wirklich FPGAs braucht, aber nur um Daten von A nach B zu schaufeln gibt es fertige Lösungen. Selbst mit FPGA gibt es fertige Lösungen. Das ist alles deutlich günstiger wie eine Eigenentwicklung.
Danke für die vielen Antworten Nun zu Aufgabenstellung 1: Es geht um IO Erweiterung, also einen HauptFPGA hat einige seiner IOs ausgelagert. Aus EMV Gründen -> LWL Latenz kritisch. bis zu 150 Signale, um jitter gering zu halten mit relativ hoher Updategeschwindigkeit >20MHz ==> einige GBit/s Aufgabenstellung 2: Nun der HauptFPGA soll mit dem PC kommunizieren. Wie ist eigentlich egal. Sollte jedoch LWL sein. Von mir aus auch PCI-E über LWL oder USB über LWL oder was auch immer. Leider ist ETH das einzige was ich kenne, das LWL ist und bis in den GBaud Bereich geht. Daher die ETH Idee. FPGA Board ist noch nicht evaluiert. Das ganze ist Netzbetrieben -> Stromverbrauch nicht spezifiziert. Im Blick ist aktuell der Cyclone 10 GX
Noch vergessen: Aufgabenstellung 2 ist nicht latenz kritisch, einige 100mbit/s genügen ebenfalls.
FPGA schrieb im Beitrag #6444908: > FPGA Board ist noch nicht evaluiert. OK, welche Hardware gibt es doch schon und ist fest gesetzt, darf also nicht ausgetauscht werden? FPGA schrieb im Beitrag #6444908: > der HauptFPGA Gibt es den schon mit Platine? Hat der schon den LWL Anschluss oder welche Anschlüsse hat die Platine für Erweiterungen?
Gustl B. schrieb: > OK, welche Hardware gibt es doch schon und ist fest gesetzt, darf also > nicht ausgetauscht werden? HW Gibts aktuell noch keine. Ein paar Details worums im grossen geht: Eine Steuerung mit total ca. 600 (low speed) LWL I/O, welche zwingend im FPGA verarbeitet werden müssen. Daneben existieren noch etliche PLC I/O sowie entsprechend von anderen Herstellern Netzwerkgebundene Daten, welche von einem PC bearbeitet werden. Diese sind nicht delaykritisch, die Daten müssen jedoch dem FPGA zur verfügung stehen. Desshalb wird eine Kommunikation FPGA-PC benötigt. Da eine einzige Platine mit 600 LWL I/O sinnbefreit wäre(!) und die LWLs nur relativ low speed sind, ist eine IO Erweiterung geplant. Diese verschiedenen Board, sollten bestenfalls über ein identisches Layout verfügen. Die gesamte logik würde dann einfachheitshalber im HauptFPGA sein, und die anderen Platinen sind nur erweiterungs I/O. Anyway lange story kurz: es geht um die LWL Schnittstellen FPGA-PC sowie FPGA-FPGA mit den bereits beschriebenen Eigenschaften
Kannst du vielleicht noch die maximale Datenrate pro LWL spezifizieren? Zwischen 1 und 10 Gbps (und so interpretiere ich jetzt mal "mehrere") liegen in der Regel die harten Grenzen, vor allem bei den kleinen FPGAs. Und ich nehme mal an, dass auch gilt: Je mehr LWL pro FPGA angeschlossen werden koennen, desto besser?
FPGA schrieb im Beitrag #6445278: > ca. 600 (low speed) LWL I/O FPGA schrieb im Beitrag #6445278: > LWLs nur relativ low speed Was denn konkret? FPGA schrieb im Beitrag #6445278: > etliche PLC I/O Sehr unkonkret. FPGA schrieb im Beitrag #6445278: > entsprechend von anderen Herstellern Netzwerkgebundene Daten, welche von > einem PC bearbeitet werden. Diese sind nicht delaykritisch, die Daten > müssen jedoch dem FPGA zur verfügung stehen. Welche Datenrate? Wieder sehr unkonkret. FPGA schrieb im Beitrag #6445278: > es geht um die LWL Schnittstellen FPGA-PC sowie FPGA-FPGA mit den > bereits beschriebenen Eigenschaften Verstehe ich nicht warum. Du könntest ein FPGA Board nehmen mit PCIe, dickem FPGA und ordentlich Erweiterungsmöglichkeiten. Das steckst du in den PC. Damit kannst du problemlos Daten zwischen PC und FPGA austauschen. Und dann schließt du an dieses FPGA Board noch mehrere IO Platinen für die vielen LWLs an. Aber die kannst du auch elektrisch mit dem FPGA Board verbinden, es gibt FMC. Je nach Datenrate der LWLs reichen vielleicht schon die FPGA IOs direkt aus über mehrere FMCs. Der FMC HPC kann 400 IOs. Sonst gibt es IO Expander oder man könnte kleine FPGAs auf die IO Karten setzen die dann seriell mit dem HauptFPGA reden. Und wenn die IOs eines FPGAs nicht reichen, dann kannst du in einen PC auch mehrere FPGA Steckkarten stecken. Da bekommst du locker deine 600+ IOs. Die können schnell miteinander reden, ins RAM vom Rechner schreiben, ... Aber du kannst auch eine externe Platine nehmen mit schnellem LWL zum PC und vielen IOs für die langsamen LWLs. Im PC dann eine LWL Netzwerkkarte von der Stange.
Gustl B. schrieb: > Was denn konkret? FPGA schrieb im Beitrag #6444908: > Latenz kritisch. bis zu 150 Signale, um jitter gering zu halten mit > relativ hoher Updategeschwindigkeit >20MHz ==> einige GBit/s Wie bereits beschrieben. min 20MHz sampling rate, 150 LWL pro Board als Startgrösse. Gustl B. schrieb: > Sehr unkonkret. Die PLC Daten sind hier auch grösstenteils orthogonal zu dieser Diskussion. Gustl B. schrieb: > Damit kannst du > problemlos Daten zwischen PC und FPGA austauschen. Ok, super, danke, so gehts eigentlich auch. Und würde die PC-FPGA Problematik komplett lösen. Kannst du bitte kurz die problemlose: - Treiber mit DMA für Windows/Linux - IP Core welcher die Daten in einem vom usercode zugreifbaren BRAM abspeichert (z.b. mit 512 64 bit Sendeadressen und 512 64 bit Empfangsadressen welche, der IPcore/Treiber ständig mit dem PC Ram abgleichen) der Algemeinheit verfügbar machen? Eigentlich ist es angedacht, das FPGA Board ausserhalb des PCs zu platzieren. Wie sieht es bezüglich des PCI-E und aus dem Rechner rausführen. Existieren Signalbufferkabel? Gar LWL konverterter?
Tobias B. schrieb: > Kannst du vielleicht noch die maximale Datenrate pro LWL spezifizieren? > Zwischen 1 und 10 Gbps (und so interpretiere ich jetzt mal "mehrere") > liegen in der Regel die harten Grenzen, vor allem bei den kleinen FPGAs. bis zu 150 Signale, um jitter gering zu halten mit relativ hoher Updategeschwindigkeit >20MHz ==> einige GBit/s in dem bsp. wärens min 3GBit/s. Anyway wenns mehr als 20MHz drinn liegen ist dies auch super. Tobias B. schrieb: > Und ich nehme mal an, dass auch gilt: Je mehr LWL pro FPGA angeschlossen > werden koennen, desto besser? Nicht unbedingt, da das Board dann auch entsprechend gross würde, einge geschickte balance zwischen Grösse/Anzahl boards wird angestrebt. Mit 150 LWL pro Board ist eher das obere Anzahl LWL limit bezogen der Sinnvolligkeit erreicht.
FPGA schrieb im Beitrag #6445935: > Und würde die PC-FPGA > Problematik komplett lösen. Kannst du bitte kurz die problemlose: > > - Treiber mit DMA für Windows/Linux > - IP Core welcher die Daten in einem vom usercode zugreifbaren BRAM > abspeichert (z.b. mit 512 64 bit Sendeadressen und 512 64 bit > Empfangsadressen welche, der IPcore/Treiber ständig mit dem PC Ram > abgleichen) > > der Algemeinheit verfügbar machen? Warum ich? Sowas gibt es von den FPGA(Board) Herstellern. Such doch einfach mal bei Google, ich habe hier in sehr kurzer Zeit schon mal https://www.xilinx.com/support/answers/65444.html gefunden. FPGA schrieb im Beitrag #6445935: > Wie sieht es bezüglich des PCI-E und aus dem Rechner > rausführen. Existieren Signalbufferkabel? Gar LWL konverterter? Gibt es ebenfalls. Und zwar von Thunderbolt3 über https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=67&No=1143 bis zu https://www.telexsus.com/products/lecroy/pcie-external-cable-30-to-pcie-slot-adapter . FPGA schrieb im Beitrag #6445935: > Wie bereits beschrieben. min 20MHz sampling rate, 150 LWL pro Board als > Startgrösse. Gut, muss die komplette Datenmenge "nur" in das HauptFPGA oder auch in den PC? Also welche Datenrate muss zwischen FPGA und PC erreicht werden? 20 MHz ist für einen FPGA IO eher gemütlich. Nur die Anzahl der IOs die du brauchst zwingt dich vermutlich zu Zusatzhardware, diesen IO Karten mit eigenem FPGA. Ist aber machbar. Mehrere IO Karten und die übertragen die Daten auf wenigen IOs schnell zum HauptFPGA. Muss kein LWL sein, kann aber.
FPGA schrieb im Beitrag #6435398: > 1. FPGA-FPGA link über LWL zb mittels FTLX8574D3BCL benötigt hierbei > werden einige gbps. FPGA schrieb im Beitrag #6445935: > FPGA schrieb im Beitrag #6444908: >> Latenz kritisch. bis zu 150 Signale, um jitter gering zu halten mit >> relativ hoher Updategeschwindigkeit >20MHz ==> einige GBit/s > > Wie bereits beschrieben. min 20MHz sampling rate, 150 LWL pro Board als > Startgrösse. Ach so, darum hast du ein 10 Gbit/s SFP+ Modul (FTLX8574D3BCL) als Ansatz. Dieses benötigt auch >10 Gbit/s Transceiver im FPGA. Also zum Beispiel bei Xilinx Kintex-7 oder neuer. Entsprechend solltest du / eure Firma auch fit sein mit High-Speed Leiterplatten und entsprechender Messtechnik (> 40 GHz). Ich würd mal ganz genau über die >20 MHz Updategeschwindigkeit nachdenken. Das ist sehr hoch und in den meisten Umgebungen unnötig, weil es muss in kurzer Zeit auf etwas reagiert werden, aber dieses etwas kommt nicht mit 20 MHz vorbei. Durch Synchronisation der Systeme lässt sich der Jitter drücken ohne so hohe Updateraten.
Christoph Z. schrieb: > Ach so, darum hast du ein 10 Gbit/s SFP+ Modul (FTLX8574D3BCL) als > Ansatz. > Dieses benötigt auch >10 Gbit/s Transceiver im FPGA. Wieso? Die AC Kopplung des SFP+ Modules sollte doch bis auf wenige MHz oder gar kHz runtergehen. Daher sollten doch auch unter 1Gbit/s bei diesem Modul unproblematisch sein? Christoph Z. schrieb: > Ich würd mal ganz genau über die >20 MHz Updategeschwindigkeit > nachdenken. Das ist sehr hoch und in den meisten Umgebungen unnötig, > weil es muss in kurzer Zeit auf etwas reagiert werden, aber dieses etwas > kommt nicht mit 20 MHz vorbei. Durch Synchronisation der Systeme lässt > sich der Jitter drücken ohne so hohe Updateraten. Ja existieren sicherlich Tricks, anyway der Ansatz: am Einfachsten man hat generell die benötigte Updategeschwindigkeit dann kommen weitere Probleme/Themen nicht mal zum Vorschein. Aber Danke für den Hinweis. Gustl B. schrieb: > Gut, muss die komplette Datenmenge "nur" in das HauptFPGA oder auch in > den PC? Nur in das HauptFPGA. Wie gesagt alle anderen über LWL verbundenen Boards dienen nur der I/O Erweiterung. Gustl B. schrieb: > Gibt es ebenfalls. Und zwar von Thunderbolt3 über > https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=67&No=1143 > bis zu > https://www.telexsus.com/products/lecroy/pcie-external-cable-30-to-pcie-slot-adapter > . Hmm.. Diese sind zwar Kabelanbindung an PCI-E aber nicht LWL. Dennoch interessant. Gustl B. schrieb: > Warum ich? Sowas gibt es von den FPGA(Board) Herstellern. > Such doch einfach mal bei Google, ich habe hier in sehr kurzer Zeit > schon mal https://www.xilinx.com/support/answers/65444.html gefunden. Nun eben nicht, oder zumindest nicht beim Cyclone 10 GX das einfach funktioniert. Habe bei Intel mal die das PCI-E Design runtergeladen, dieses nutz lediglich einen IP Block mit Avalon Stream output. Sicherlich wird dieser irgendwie funktionieren; anyway für mein grundlegende und allgemeine Aufgabenstellung: PC Treiber mit DMA <---> FPGA dual port BRAM synchronisation kaum verwendbar. Nun es wird lediglich eine einfache (die einfachste art der Kommunikation die mir in den Sinn kommt) Signallistenbasierte kommunikation benötigt.
FPGA schrieb im Beitrag #6452388: > Nur in das HauptFPGA. Wie gesagt alle anderen über LWL verbundenen > Boards dienen nur der I/O Erweiterung. Ich verstehe ja, dass du viele IOs benötigst und da Erweiterungsplatinen planst. Aber warum soll die Verbindung zwischen Erweiterungsplatine und HauptFPGA Platine über LWL laufen und nicht elektrisch? FPGA schrieb im Beitrag #6452388: > Hmm.. Diese sind zwar Kabelanbindung an PCI-E aber nicht LWL. Dennoch > interessant. Genauso hier, warum sollen PC und HauptFPGA über LWL verbunden werden? Man könnte die Platine mit HauptFPGA doch auch mit PCIe ausstatten und in den PC reinstecken. FPGA schrieb im Beitrag #6452388: > PC Treiber mit DMA <---> FPGA dual port BRAM Ich habe noch nie PCIe mit FPGA gemacht, aber diese Aufgabenstellung sieht mir so aus als wäre die durchaus nicht unüblich und bereits ein gelöstes Problem. Mit welcher Datenrate müssen denn HauptFPGA und PC kommunizieren? Es gibt ja auch normales Ethernet, USB3, ...
Gustl B. schrieb: > Ich verstehe ja, dass du viele IOs benötigst und da Erweiterungsplatinen > planst. Aber warum soll die Verbindung zwischen Erweiterungsplatine und > HauptFPGA Platine über LWL laufen und nicht elektrisch? EMV Gustl B. schrieb: > Genauso hier, warum sollen PC und HauptFPGA über LWL verbunden werden? > Man könnte die Platine mit HauptFPGA doch auch mit PCIe ausstatten und > in den PC reinstecken. Dies ist weniger kritisch da diese gleich nebeneinander aufgebaut werden können. Von dem her ja: muss nicht zwingend LWL. (Anyway da wir generell eine EMV Panik haben, ist auch hier LWL bevorzugt). Gustl B. schrieb: > Ich habe noch nie PCIe mit FPGA gemacht, aber diese Aufgabenstellung > sieht mir so aus als wäre die durchaus nicht unüblich und bereits ein > gelöstes Problem. Genau meine Vorstellung; das PC-FPGA Kommunikationsthema sollte ein gelöstes Problem sein, und jede minute in dieses Problem investiert ist eigentlich verschwendete Zeit. Wenige 100mbit/s genügen. ETH hätte sogar einen LWL standard, PCI-E ist auch ok. Eigentlich egal wie, einfach eine einfache Lösung ab der Stange. Also: ETH oder PCI-E für dummies. Ein Bsp. das geht, und fertig - nächstes Problem. Es ist absolut Schade das die Lösung für dieses gelöste Standartproblem, nicht einfach zur verfügung steht. Und einem die Hersteller irgendwelche 1000+ Seitige Dokumentationen von irgendwelchen IPcores an den Kopf werfen wollen...
FPGA schrieb im Beitrag #6452424: > EMV OK, das kann ich verstehen. FPGA schrieb im Beitrag #6452424: > Wenige 100mbit/s genügen. ETH hätte sogar einen LWL standard, PCI-E ist > auch ok. Eigentlich egal wie, einfach eine einfache Lösung ab der > Stange. Dann kannst du auch USB nehmen mit so einem FIFO Interface wie sie der FT2232H (USB2), FT600 (USB3) oder FX3 (USB3)bieten. Ist vielleicht einfacher wie Ethernet. Zumindest zum FT600 kann ich sagen dass man da mit sehr wenig Hardwarebeschreibung schnell Daten zum PC bekommt. Es gibt auch Boards mit FPGA und USB3 wie dieses: https://opalkelly.com/products/xem7360/ Das hat auch einigermaßen viele IOs für Erweiterungskarten. Das hier https://opalkelly.com/products/xem8350/ ist sogar noch dicker. FPGA schrieb im Beitrag #6452424: > Es ist absolut Schade das die Lösung für dieses > gelöste Standartproblem, nicht einfach zur verfügung steht. Naja, das gibt es schon, einfach weil das eben schon Leute verwenden. https://opencores.org/projects/virtex7_pcie_dma https://github.com/alexforencich/verilog-pcie
Gustl B. schrieb: > FT2232H (USB2), Ja würde gehen und auch von der performance her genügen. Hmm USB hat eigentlich 3 Eigenschaften, wesshalb ichs eher gegenüber ETH und PCI-E zurückstellen würde: 1. Kein DMA (USB hat gute Gründe dafür kein DMA zu haben (sicherheit bez. unvertrauter HW etc.)) Anyway für diesen Anwendungsfall hat DMA offensichtlich Vorteile. 2. USB war/ist nicht für Industrie gedacht/vermarktet; subjektiv habe ich den Eindruck, dass die USB Akzeptanz in der Industrie nicht besonders hoch ist. 3. EMV anfällig Gustl B. schrieb: > Naja, das gibt es schon, einfach weil das eben schon Leute verwenden. > > https://opencores.org/projects/virtex7_pcie_dma > https://github.com/alexforencich/verilog-pcie Hmmpf... Danke... nun erscheint auch eher umfangreich, habs nur kurz überfolgen. Anyway vermisse eine Anleitung in der Art: 1. nehme diese files und 2. klicke hier und hier, und 3. instaliere diesen Treiber (für win/linux) und 4. nutze dieses Topfile sowie dieses C Source file als demo/test und fertig...
FPGA schrieb im Beitrag #6452890: > Hmm USB hat eigentlich 3 Eigenschaften, wesshalb ichs eher gegenüber ETH > und PCI-E zurückstellen würde: Hm, wenn dir USB2 sogar von der Geschwindigkeit reicht, dann ist das auch ohne DMA schnell genug. Ich sehe bei den Lösungen mit USB wie diesen FTDI ICs, dass das einfach ist. Das ist wenig HDL und wenig C Code und schon funktioniert das. Kein aufwändiges Protokoll und man braucht auch keine teure IP oder Lizenzen von Herstellern. Ich finde eine PCIe Lösung elegante weil das dann alles in einem PC wäre. Aber sonst bei den Datenraten kannst du auch normales Gigabit Ethernet nehmen. FPGA schrieb im Beitrag #6452890: > Anyway vermisse eine Anleitung in der Art: Habe ich jetzt auch nicht gesehen, ich vermute aber, dass sowas in den Downloads drinnen ist. Bei Terasic kannst du dir zu jedem Board Zeug runterladen. Und da sollte sowas mit dabei sein.
FPGA schrieb im Beitrag #6452388: > Christoph Z. schrieb: >> Ach so, darum hast du ein 10 Gbit/s SFP+ Modul (FTLX8574D3BCL) als >> Ansatz. >> Dieses benötigt auch >10 Gbit/s Transceiver im FPGA. > > Wieso? Die AC Kopplung des SFP+ Modules sollte doch bis auf wenige MHz > oder gar kHz runtergehen. Daher sollten doch auch unter 1Gbit/s bei > diesem Modul unproblematisch sein? "Supports 9.95 to 10.5 Gb/s bitrates*" Bei anderen Modulen werden auch 1Gb/s oder 4Gb/s(FC) garantiert.
OM7 schrieb: > "Supports 9.95 to 10.5 Gb/s bitrates*" > > Bei anderen Modulen werden auch 1Gb/s oder 4Gb/s(FC) garantiert. Ooops, Danke!
Gustl B. schrieb: > Ich finde eine PCIe Lösung elegante weil das dann alles in einem PC > wäre. Aber sonst bei den Datenraten kannst du auch normales Gigabit > Ethernet nehmen Nun GBE (LWL) ist mir eigentlich fast am liebsten. Wenn mäglich am besten noch ohne PHY etc. Also direkt FPGA-LWL Modul. Existieren für GBE entsprechende (einfache) BSP?
OT: Ist mir gerade aufgefallen, dass der 10CX105 12 Transceiver hat mit 12.5 gbaud. Diese können anscheinend direkt XGMII ausgeben. Und das mit einem FPGA für 100 Eur! Nun da diese direkt zu den SFP+ Modulen verbunden werden können, könnte damit ein 12Port 10G Switch gebaut werden. Zum Bruchteil des Marktpreises.
FPGA schrieb im Beitrag #6453594: > Nun da diese direkt zu den SFP+ Modulen > verbunden werden können, könnte damit ein 12Port 10G Switch gebaut > werden. Zum Bruchteil des Marktpreises. Für < 500 €? Mit Platine, anderen Bauteilen, Gehäuse, Entwicklung, Zertifizierung, Support, Handbuch, Software, ...? Sportlich.
http://www.xillybus.com/ scheint eine IP zu haben welche angeblich genau eine einfache Anbindung des FPGAs mit dem Rechner ermöglicht. Nun es beunruhigt mich, dass Sie für eine solche standard Anwendung zwischen 25-85k USD haben möchten. Anscheinend wird dieses basic Problem einfach von den grossen Herstellern ignoriert, dass irgendwelche nischenanbieter IP anbieten müssen... Nun zu meiner recherche bez. Cyclone 10 GX: Intel bietet irgendwelche generatoren die PCI-E- Avalon machen. Dann gibts irgendwelche generatoren bez Avalon anbindung und 1000ende Seiten Avalon Doku. Von Bsp wie ich aus dem Avalon zeugs einige FiFo oder MM lesen zu meiner Logik verbinden kann ist auch nix vorhanden. PC seitig fehlt auch alles... Intel scheint die Kunden komplett im Regen zu lassen..
Vor Jahren habe ich mal auf der Embedded World Conference einige Vorträge über eine Lösung zu sowas gehört, kann mich aber an den Namen nicht erinnern. Eins war eine Art PCI über TCP (war von Fraunhofer, glaube ich), das andere ein RPC von einer Schweizer Firma. Sollte open source gewesen sein. Müßte ich aber suchen.
FPGA schrieb im Beitrag #6435398: > Angedacht habe ich Cyclone oder Spartan, aber evtl. würde insbesondere > für Punkt Hard oder Soft-IP? Es gibt FPGA's mit fest eingebauten MAC und/oder PCIe Core, das sind wohl beim Spartan-6 die T-Typen und die Kintex-7. Einfach mal in die Übersichtstabellen nach "Embedded Hard IP" oder "Integrated IP" schauen: https://www.xilinx.com/support/documentation/selection-guides/7-series-product-selection-guide.pdf https://www.intel.co.uk/content/dam/www/programmable/us/en/pdfs/literature/br/br-soc-fpga.pdf S.9
C. A. Rotwang schrieb: > oder PCIe Core Ja das weiß er schon, was er sucht ist eine einfache Lösung wie man dann auch Daten über z. B. PCIe zwischen FPGA und PC - wenn möglich mit DMA ins PC RAM - austauscht.
Gustl B. schrieb: > Ja das weiß er schon, was er sucht ist eine einfache Lösung wie man dann > auch Daten über z. B. PCIe zwischen FPGA und PC - wenn möglich mit DMA > ins PC RAM - austauscht. Genau, einfach und bevorzugt frei verfügbare IP. Ich finde die Karikatur auf: http://www.xillybus.com/tutorials/pci-express-tlp-pcie-primer-tutorial-guide-1 ziemlich passend. "We always end up spending lots of work on data transfer". Nun dies beschreibt exakt meine Vorstellung, es gibt genug arbeit an eigener Logik, daher keine Zeit Verschwenden an basics und das Rad nicht jedesmal neu erfinden. Cyclone 10 GX hat entsprechende Hard IP. Und ebenfalls gratis IP generatoren für PCI-e - Avalon und ebenfalls eigener Logik - Avalon. Nun ich kenne mich damit nicht aus, evtl. ist es auch ganz einfach und könnte mit wenigen cklicks realisiert werden. Nur schwimme ich, und die Informationsstrukturierung/Kommunikation der Hersteller diesbezüglich ist frustrierend. Wenn sich jemand damit auskennt, kann er mir und der algemeinheit bitte kurz ein Projekt erstellen mit dem PCI-e- Avalon core, sowie mit Avalon zu eigener Logik (genügt Fifo mit clk, data, wr_en, full/empty; noch besser Bram Memory mapped)
Vielleicht mal als Referenzwert: Wir nutzen für Echtzeitregelungssysteme derzeit 10 GbE mit DPDK (Data Plane Development Kit) oder XDP (eXtreme Data Path +eBPF, Linux). Die Latenz von Host-Rechner bis zum Kabel ist bei kleinen Paketen (~120 B) 5 us und bei Jumbo Frames (~8 KiB) 13 us. Von den möglichen 10 Gb/s nutzen wir im Schnitt ca. 6 Gb/s. Der Jitter vom Paket-Anfang ist ca. 0.01 us Standardabweichung. Demnächst steigen wir auf 100 GbE um, um die Serialisierungszeit der Jumbo Frames zu reduzieren (0.7 us statt 7 us; macht bei ein paar switches schon was aus; switch selbst braucht ~0.9 us). COTS HW: NICs von Intel oder Mellanox, Server von Dell mit AMD EPYC (ggf. mehrere) und PCIe3 oder PCIe4. Trotzdem kann es einige Gründe geben, die für eine FPGA-Verwendung sprechen. Beispielsweise komplizierte Messwerterfassung/ADCs/..., Strombedarf und Abwärme, Latenz << 1 us, Jitter, ... Wir haben hier einige Geräte, die mit dem FPGA die Messwerte nach 10 GbE Ethernet übersetzen. Aber die weitere latenzkritische Auswertung/Regelung findet dann über einen oder mehrere fetten Server mit DPDK bzw. XDP statt, von wo die Steuerbefehle dann an die Aktoren gehen.
Vielleicht mal ne dumme Laienfrage: Viele FPGAs haben ja PCIe eingebaut. PCs haben ebenfalls PCIe. Das kann man jetzt schön elektrisch verbinden. Gibt es eine Möglichkeit das PCIe zwischen FPGA und PC auch optisch zu machen? Ich stelle mir das so vor: FPGA <-> Adapter <-> LWL <-> Adapter <-> PCIe-Steckplatz im PC. Wobei Adapter nur etwas "einfaches" ist vom Prinzip her wie ein QSFP, aber kein extra FPGA. Was ich gesehen habe ist FPGA <-> 10 GbE <-> LWL <-> 10 GbE <-> FPGA/NIC <-> PCIe-Steckplatz im PC. und ich verstehe nicht wirklich wieso man da den Umweg über Ethernet und einen zweiten FPGA/NIC geht. Das sollte doch möglich sein ein PCIe mit mehreren Lanes auf unterschiedliche Farben in einer Faser zu packen und zwar ohne dicken Zusatzchip. Gibt es dafür Lösungen?
Gustl B. schrieb: > und ich verstehe nicht wirklich wieso man da den Umweg über Ethernet und > einen zweiten FPGA/NIC geht. 1. (mögl.) Grund: Ethernet ist dezentral. PCIe hat eine Host-Slave Architektur. 2. Grund: Die Datenrate bei PCIe sinkt mit der Entfernung Ansonsten gibt es Anbieter für LWL-PCIe. Für 2m ganz nett.
Gustl B. schrieb: > Gibt es eine Möglichkeit das PCIe zwischen FPGA und PC auch optisch zu > machen? Ja. Ich habe hier ein System, wo ein PCIe-Switch über 20m optisches Kabel am PC (PCIe-Karte) angebunden ist. Am (externen) Switch hängen dann die FPGAs. Duke
Duke Scarring schrieb: > am PC (PCIe-Karte) angebunden ist Kannst du sagen was das für eine Karte ist? Was ist da drauf?
Gustl B. schrieb: > Kannst du sagen was das für eine Karte ist? Die Karte nennt sich NPCIe-Uplink-O-x8. Einzeln gibt es die Karte offensichtlich nicht, nur optional im Zusammenhang mit einem NAT-MCH-PHYS80. > Was ist da drauf? Im Wesentlichen 2x QSFP und ein PCI Express Switch von PLX/Avago/Broadcom: https://www.broadcom.com/products/pcie-switches-bridges/pcie-switches Duke
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.