Vor ca. 15 Jahren (meine letzten Erfahrungen mit FPGA) wars nach meinem Wissensstand noch sehr schwierig lizenzfrei GBE zu erreichen. Ich Spreche von einer simplen Anforderung zum Datentransfer FPGA-PC: Also ARP und UDP packete bidirektional. Fixe IP im HDL (ohne DHCP). Wie ist die Situation aktuell? Konnen Altera (oder halt nun Intel) oder AMD/Xilinx nun sowas direkt mit den freien IP blöcken? Existieren andere freie und einfach Lösungen für dieses basic data transfer Problem?
Der TEMAC (Xilinx) ist nach meinem Wissen nach wie vor kostenpflichtig. Als ich ihn zuletzt eingesetzt hatte, lag er bei 5.000 für eine site-license.
Hallo, ich nutze in einem Projekt diesen Ethernet-MAC: https://github.com/alexforencich/verilog-ethernet Allerdings hat das Board nur 10/100 Mbit/s, aber in dem Repository finden sich verschiedene Ethernet-MACs für Geschwindigkeiten bis 10GbE. Marius
Schon mal bei opencores geschaut? Da hat es ein paar. Keine Ahnung ob die was taugen.
Hallo Danke erst mal für die Antworten. Hmm was soll ich sagen, einerseits ist es natürlich zu begrüssen, dass Opencores etc. Lösungen existieren, andererseits ist der Einarbeitungsaufwand doch erheblich. Daher wären natürlich "verified" Lösungen zu bevorzugen. Evtl. kann ich die TO Fragestellung etwas aufweiten: Gesucht: Minimalanforderung zb.: Datentransfer FPGA-PC (Datenbank (PC) - Registerliste (FPGA)) welche sich stupide immer aktuallisiert (bidirektional also 2 registerlisten). Wobei ich folgene Probleme der verschiedenen Technologien sehe: 1. UART - Langsam 2. USB (FTDI) - Bedenken wegen EMV da keine Galv Trennung. Habe ebenfalls von Langzeitstabilitätsproblemen im Industriebereich gehört. 3. PCI-e - maximale Kabellänge sehr begrenzt. Meines wissens eher ungeeignet für alles was in einem anderen Gehäuse verbaut ist. 4. ETH - Ideal wenn über LWL, auch relativ EMV robust wenn über Kabel da Trafo. Damals wurde nebst dem FPGA ein ETH fähiger uC verbaut, welcher lediglich die Brücke ETH-SPI gemacht hat und das FPGA über SPI mit Daten versorgt. Datentransfer ist ja ein Grundlegendes FPGA Problem, welche Lösungen nutzt Ihr? Was sind die Erfahrungen?
Max M. schrieb: > Vor ca. 15 Jahren (meine letzten Erfahrungen mit FPGA) wars nach meinem > Wissensstand noch sehr schwierig lizenzfrei GBE zu erreichen. > > Ich Spreche von einer simplen Anforderung zum Datentransfer FPGA-PC: > Also ARP und UDP packete bidirektional. Fixe IP im HDL (ohne DHCP). > Bis zu welcher Schicht willst du denn einen Stack im FPGA haben? - PCS/PMA ("Anschluss" an den SerDes, 8b/10b oder 64b/66b Codierung, Synchronisierung usw.) gibt es für 1G/10G lizenzfrei von Xilinx, d.h. da fällt schon mal ein ganzer Teil low-level Zeug weg - MAC (ETH-Frames zusammenbauen und checken, Flusskontrolle) kostet von Xilinx etwas; manche IP von opencores sind meiner Erfahrung nach gut anwendbar (habe vor Jahren 1G/10G MAC jeweils einen mal in Betrieb genommen und hat gefühlt out-of-the-box funktioniert) - ARP/IP/UDP gibt es direkt von Xilinx m.W. nicht, zumindest nicht als HDL, evtl. als SW für den Zynq; ansonsten als SW für beliebige uC-Softcores, wenn man es im FPGA haben will Btw.: Den 100G MAC gibt es kostenlos, wenn man die hard IP im US+ nutzt :-) .
Markus W. schrieb: > Bis zu welcher Schicht willst du denn einen Stack im FPGA haben? Bis zu der die nötig ist um das Ziel Bidirektionale kommunikation Datenbank (PC/Server) - FPGA zu ermöglichen. Bei einem anderen Tread welchen ich im uC Bereich erstellt habe ist meine Aufmerksamkeit auf Node-Red gelenkt worden; das scheint genial zu sein. Node-Red kann die Daten für die DB aufbereiten, daher kann die Netzwerkanforderung im FPGA reduziert werden: auf das lowest level node-red protokoll komunizieren. (UDP, TCP, MQTT etc.) Markus W. schrieb: > Btw.: Den 100G MAC gibt es kostenlos, wenn man die hard IP im US+ nutzt > :-) . Nun 100G ist natürlich komplett overkill, will ja nicht wissen was für ein Server benötigt würde damit Node-Red/DB diese Bandbreite ausnutzen könnte :P
Max M. schrieb: > auf das lowest level node-red protokoll komunizieren. (UDP, TCP, MQTT > etc.) Ja, genau. TCP ist schon sehr anspruchsvoll ohne CPU. Und nein, du willst das ohne CPU machen wenn du Durchsatz brauchst. Was ist denn die Ziel Datenrate?
Gustl B. schrieb: > Was ist denn die Ziel Datenrate? nun original hatte ich grob an einige 100mbit/s gedacht. Ob dies nun mit NodeRed überhaupt noch realistisch ist kann ich nicht sagen. Einfache Implementierung soll ersmal wichtiger sein als Performance.
Max M. schrieb: > 3. PCI-e - maximale Kabellänge sehr begrenzt. Meines wissens eher > ungeeignet für alles was in einem anderen Gehäuse verbaut ist. Nö, dafür gibts Lösungen und Standards, mit denen Du etliche Meter überbrücken kannst. Bei meinem Arbytegeber gibts Kameras, die über PCIe Rohbilddaten unkomprimiert mit PCIe Gen 2 x4 direkt in den PC-Hauptspeicher schreiben. Eine direkte und latenzärmere Anbindung gibts nicht. https://www.ximea.com/en/products/pci-express-high-speed-cameras-xib/cb500cg-cm Host-Karte: https://www.ioi.com.tw/products/proddetail.aspx?CatID=106&DeviceID=3036&HostID=2052&ProdID=1060236 Stecker/Kabel: https://www.molex.com/en-us/products/connectors/high-speed-pluggable-io/ipass-connector-system PCI Express External Cabling Specification Revision 3.0, Version 1.0 Ältere Spezifikation: https://picture.iczhiku.com/resource/eetop/wHigyzpZfEQiRmmv.pdf fchk
Moin, den hier kann ich, im Gegensatz zum Xilinx Temac empfehlen: https://github.com/yol/ethernet_mac Läuft mit kleinen Modifikationen auch absolut rund per Autobuffer-DMA, d.h. wenn eine CPU mit ins Spiel kommt. Überdies portabel (auf Xilinx Spartan usw. wie auch Lattice ECP* in Betrieb). Stichwort Kameras: Ich nutze die Lösung für low latency JPEG-Video-Streaming. Die GbE-Domäne wird allerdings durch Nutzung von TCP ad absurdum geführt, die volle Performance hast du nur per UDP. Und TCP in der Hardware willst du nicht wirklich nachbauen, einen TCP zwischen PCI-Wrapper in der Hardware wurde meiner Erinnerung nach mal von einem Fraunhofer-Team gestrickt und lag preislich im Bereich Luxus-Auto.
Martin S. schrieb: > Moin, > > den hier kann ich, im Gegensatz zum Xilinx Temac empfehlen: > > https://github.com/yol/ethernet_mac > > Läuft mit kleinen Modifikationen auch absolut rund per Autobuffer-DMA, > d.h. wenn eine CPU mit ins Spiel kommt. Überdies portabel (auf Xilinx > Spartan usw. wie auch Lattice ECP* in Betrieb). Stichwort Kameras: Ich > nutze die Lösung für low latency JPEG-Video-Streaming. > > Die GbE-Domäne wird allerdings durch Nutzung von TCP ad absurdum > geführt, die volle Performance hast du nur per UDP. Und TCP in der > Hardware willst du nicht wirklich nachbauen, einen TCP zwischen > PCI-Wrapper in der Hardware wurde meiner Erinnerung nach mal von einem > Fraunhofer-Team gestrickt und lag preislich im Bereich Luxus-Auto. Danke! Verstehe ich das korrekt: 8 Bit FIFO, ohne Garantie, dass Daten geordnet kommen (wegen udp, packetloss, variabler Packetgrösse etc...), ebenfalls ohne info in welchem Paket, an welcher Stelle etc. diese 8 bit liegen. Daher muss in diesen 8 Bit die jeweilige Zuweisungsinfo enthalten sein?!?
:
Bearbeitet durch User
Max M. schrieb: > Verstehe ich das korrekt: Nein. Wie kommst du auf 8 Bit? Bei UDP können Pakete verloren gehen und in zufälliger Reihenfolge ankommen. Ist eben so. Beim Versenden schreibt man üblicherweise rein welche Paketnummer das ist, dann kann der Empfänger das wieder sortieren. Das ist aber alles auf Paketebene, nicht auf 8 Bit Ebene oder wie auch immer. Wie du deine Pakete baust solltest du schon selber unter Kontrolle haben. Martin S. schrieb: > Und TCP in der > Hardware willst du nicht wirklich nachbauen, einen TCP zwischen > PCI-Wrapper in der Hardware wurde meiner Erinnerung nach mal von einem > Fraunhofer-Team gestrickt und lag preislich im Bereich Luxus-Auto. Ja, gibt es, aber nicht nur von denen. TCP hat Vorteile, aber kostet auch. TCP braucht man z. B. wenn man darüber RDMA wie iWARP machen möchte.
Gustl B. schrieb: > Wie kommst du auf 8 Bit? Nun dieser IP Block (https://github.com/yol/ethernet_mac), basiert auf einem angeblich einfach zu benutzenden 8Bit FIFO. Ich vestehe nicht, wie davon ausgegangen werden kann dass dies sortiert sein soll. Es sei den der IP Block hat eine absprache mit dem Sender (ist aber hier meines wissens nicht vorgesehen da der Sender ein PC ohne TCP-like kommunikation). Also RX FIFO = random 8 Bitausschnitte aus empfangenen Daten?
Pakete können unterschiedlich lang sein. Und irgendwie muss man dem MAC das Paket übergeben. Jetzt ist es aber unsinnig den FIFO so breit zu machen, dass das größte Paket direkt parallel reingeladen werden kann. Stattdessen hat man sich hier für einen schmalen FIFO entschieden und der Nutzer/die Schicht drüber muss das Paket Byte für Byte in den FIFO schreiben. Das steht auch hier https://github.com/yol/ethernet_mac/blob/master/README.md ganz unten. Zitat: Both the TX and the RX FIFO have a simple communication scheme. A packet unit on the FIFO interface consists of: 2 bytes of size information, most significant byte first, and then exactly as many bytes of data as were indicated. The data includes all Ethernet MAC headers (destination address, source address, and length/type) in the exact same order as defined in the standard, but not the frame check sequence trailer.
Nochmal zur Klarstellung: Ins FIFO steckt man die Rohdaten des Ethernet-Pakets, ob das UDP oder TCP oder ARP usw. ist interessiert das Interface nicht. Aus dem RX kommt entsprechend das Rohpaket wieder raus. Darüber strickt man seinen Stack oder portiert was wie lwip im Push-pull-Betrieb, das ist allerdings eine Performance-Sackgasse und bei GbE IMO komplett sinnlos. Allerdings kann man besagten Core wie gesagt relativ leicht aufbohren, dass er mit Packet-Queues so läuft, dass die CPU nur noch minimale Arbeit (Quittierung von Paket-Interrupts) hat. Dann braucht man auch je nach Konfiguration den ganzen Hardware-Rabbel nicht, und man kann den zu versendenden Nutzlast-Datenstream effektiv in einen virtuellen Port im SoC reinfüttern. [ Der TEMAC hatte diesbezüglich einen architektonischen Bock, aber andere Geschichte ] Siehe auch dazu https://section5.ch/index.php/2017/05/10/dma-autobuffering-techniques/. Senden am physikalischen Limit ist damit relativ trivial, und meistens machen FPGA-Lösungen auch nur das, beim Empfangen über längere Distanzen und Router allerdings muss sich eine separate Engine um die Sortierung kümmern. Mit TCP geht das auch, nur macht das ACK-Pingpong-Spiel das ganze viel komplexer und schwerfälliger und es kommt externes RAM mit in den Topf. Auf jeden Fall kommt man nicht umhin, sich mit der Programmierung eines auf seine Anwendung zugeschnittenen UDP/IP/ARP-Stacks und einer entsprechenden State-Machine (Software) zu beschäftigen.
https://www.enclustra.com/en/products/fpga-manager/ <-- kostet einen kleinwagen. Da das noch verkauft wird, kannst du davon ausgehen dass es gratis nix brauchbares giebt.
Gustl B. schrieb: > Bei UDP können Pakete verloren gehen und > in zufälliger Reihenfolge ankommen. Ich habe es noch nicht erlebt, das Pakete in den Switchen umsortiert wurden. I.d.R. sind die Strecken zwischen FPGA und Host-PC auch überschaubar. Max M. schrieb: > basiert auf > einem angeblich einfach zu benutzenden 8Bit FIFO. Wenn deine Rohdaten eine Bitbreite von 42 Bit (oder einem anderen krummen Wert) haben, dann muß du dir natürlich was zur Synchronisation einfallen lassen. Ansonsten füllt man das FIFO auf der Senderseite mit Bytes, die auf der anderen Seite gebündelt wieder rausfallen. Oder auch andersrum: Pakete im Host zusammenbasteln (Größe je nach MTU 1500 Byte oder 9000 Byte) und im FPGA aus dem RX-FIFO auslesen, sobald was da ist. Was der Stack macht, wenn er ein Paket nicht vollbekommt, hängt vom jeweiligen Stack ab. Martin S. schrieb: > Auf jeden Fall kommt man nicht umhin, sich mit der Programmierung eines > auf seine Anwendung zugeschnittenen UDP/IP/ARP-Stacks und einer > entsprechenden State-Machine (Software) zu beschäftigen. Wobei man für die Grundfunktionen nicht viel braucht (ARP-Response, Ping-Reply und ggf. UDP-Portfilter). BTDT.
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.