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.
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.
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
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/OFPGA 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_dmahttps://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.
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.
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
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
