Hat jemand Erfahrung damit gemacht ADC Daten 500MB/s über Ethernet an einen PC zu übertragen um die Daten dort erstmal einfach nur zu speichern und später auszuwerten. Ich würde dazu gerne ein FPGA benutzen, der das handling der ADCs übernimmt und die Daten dann an den PC überträgt. Alternative Lösung wäre PCIe aber Ethernet wäre mir lieber, da die Leitung deutlich länger sein kann und die Anbindung an den PC einfacher wäre.
Samuel C. schrieb: > Mit einer konkreten Frage kommst du vermutlich weiter. Wo liegt > das > Problem? Kann jemand IP cores (Ideal Xilinx) oder Demoanwendungen empfehlen? Am besten wäre eine TCP Verbindung, die vom Host PC aufgebaut wird aber ich denke UDP wäre einfacher. Also einfach eine Menge UDP Pakete per EthernetIP vom FPGA senden.
Samuel C. schrieb: > Mit einer konkreten Frage kommst du vermutlich weiter. Wo liegt das > Problem? Berechtigte Frage! Ich orakle, er sucht einen FIFO der über Ethernet mit TCP/IP Daten schickt. Und das auf einem FPGA.
Carsten F. schrieb: > ADC Daten 500MB/s über Ethernet an einen PC zu übertragen Wenn das "B" für Byte steht, dann müsstest du da noch ein paar Geräte-Generationen warten. Mit aktuellem Gigabit-Ethernet "schafft" man halt theoretisch 1000 Mega-bit/Sekunde, praktisch wohl maximal 940 Mega-bit/Sekunde https://de.wikipedia.org/wiki/Datendurchsatz
:
Bearbeitet durch User
Carsten F. schrieb: > Kann jemand IP cores (Ideal Xilinx) oder Demoanwendungen empfehlen? Am > besten wäre eine TCP Verbindung, die vom Host PC aufgebaut wird aber ich > denke UDP wäre einfacher. Also einfach eine Menge UDP Pakete per > EthernetIP vom FPGA senden. Wenn du's schnell entwickelt haben willst nimmst du einen Zynq/Ultrascale+ und handlest das Ethernet über das PS. 500MB/s sind halt schon ne Ansage, aber sollte gehen. Allerdings ist Daten zu Ethernet-Paketen zu packen jetzt auch nicht die Welt. Für Ethernet selbst gibt es IP-Cores. Wegstaben V. schrieb: > Wenn das "B" für Byte steht, dann müsstest du da noch ein paar > Geräte-Generationen warten. 10G gibt's jetzt auch schon ne Weile. Ist auch nicht groß schlimmer, wenn man sich nicht um das Layout kümmern muss.
Alternativ, wenn PCIe für dich einfacher ist, könntest du dafür auch Extender über Ethernet oder Glasfaser bekommen. Macht's aber vermutlich kaum günstiger. Die Frage von wegstabenverbuchsler ist daher durchaus relevant. Meinst du 500MByte/s oder 500Mbit/s?
Samuel C. schrieb: > Alternativ, wenn PCIe für dich einfacher ist, könntest du dafür > auch > Extender über Ethernet oder Glasfaser bekommen. Macht's aber vermutlich > kaum günstiger. > > Die Frage von wegstabenverbuchsler ist daher durchaus relevant. Meinst > du 500MByte/s oder 500Mbit/s? Ich meine 500MBit.
Dann würde ich das tatsächlich mal mit einem Zybo o.ä. probieren. Ist zwar immernoch mit Kanonen auf Spatzen, aber was soll's. Ist bequemer.
Wenn es nicht unbedingt Ethernet seien muss wäre USB3 eine einfache Möglichkeit. Da reicht ein kleines FIFO im FPGA und etwas Beschreibung drum herum die auch in kleine billige FPGAs passt.
> Ich meine 500MBit.
Wer seine Fragen nicht von Anfang an praezise stellen kann,
hat ueberhaupt keine Antworten verdient.
Tromp schrieb: > Wer seine Fragen nicht von Anfang an praezise stellen kann, > hat ueberhaupt keine Antworten verdient. Und Traumtänzer ebenso.
ich glaube auch ein USB3 FIFO ist wahrscheinlich einfacher, da die Daten auch sicher ankommen. Bei Ethernet kann dir immer mal einer ein Frame dir droppen, wenns zu eng wird. Ob dein UDP das absichern kann? Ansonsten brauchst du eine leistungsfähige TCP verbindung.
Beitrag "FT600 ucPipeID 0x82 - Bedeutung der Bits?" Da ist der VHDL Code und mit passenden Parametern im C Programm, das quasi 1:1 im https://www.ftdichip.com/Support/Documents/ProgramGuides/AN_379%20D3xx%20Programmers%20Guide.pdf steht, bekommt man mit dem FT600 (2 Bytes/Clock @ 100 MHz) auch fast die volle Datenrate hin. Im FPGA kann man den FT601/2 mit dem FT245 Interface befüllen. Das geht recht entspannt bei 100 MHz und vollständig als synchrones Design. Das liest aus einem internen Dual-Clock-FIFO und schreibt wenn immer möglich in den FTDI. Mehr braucht es nicht und auch das FIFO im FPGA muss nicht irre groß sein. Ich verwende 64 kBytes.
:
Bearbeitet durch User
Klakx schrieb: > Bei Ethernet kann dir immer mal einer ein Frame dir droppen, wenns zu > eng wird. Ob dein UDP das absichern kann? UDP garantiert sogar, dass es Paketausfälle nicht absichert. TCP jedoch schon und sogar ohne weiteres Zutun. Wäre ja traurig wenn im Browser ab und zu mal was fehlt.
TCP garantiert aber auch hohe Einbrüche in der Datenrate und variable Latenzen, wenn gelegentlich Pakete verloren gehen. UDP verliert dann einzelne Datenpakete, aber Rate und Latenz bleiben ansonsten erhalten. Man sollte also gut überlegen, worauf es ankommt.
> Wäre ja traurig wenn im Browser ab und zu mal was fehlt. Wenn die "Verlustrate" auf der Strecke zu gross wird, nuetzt TCP auch nichts mehr. 10 % Schwund reichen da schon. Und schwupps fehlt was. Auf einer UDP-Verbindung in einem per Port geswitchen Netz sind es eher 0 %. Der Backbone sollte das aber auch in seiner Kapazitaet unterstuetzen. Also als 10G/40G/100G ausgefuehrt sein. Niemand wird sich deswegen daher TCP auf einem FPGA antun wollen. Aber selbst kleine ungemanagede Soho-Switche haben bei 8 1G-Ports eine nonblocking 16 G Switchfabric.
Homer J. S. schrieb: > Und schwupps fehlt was. Die Verbindung bricht u.U. ab, wenn die Leitungskapazität das Retry-Verfahren nicht auffängt und eine explodierende Pufferung und Verzögerung zu Überlauf oder Timeout führt. Bei 500 aus 1000 halte ich das für ein realistisches Szenario.
:
Bearbeitet durch User
Carsten F. schrieb: > Hat jemand Erfahrung damit gemacht ADC Daten 500MB/s über Ethernet an > einen PC zu übertragen um die Daten dort erstmal einfach nur zu > speichern und später auszuwerten. Ja, vor 13 Jahren ("NetCeiver"), war Streamen von DVB-Transport-Streams in IP6-Multicast. Mit 6 Tunern so um die maximal 300Mbit/s, ging testweise aber auch mit knapp 800Mbit/s. Aus heutiger Sicht langweiliger 3S1600E mit billiger RTL8169 GBit-Karte dran, HW-Kosten 50EUR. Eigener PCI-Core, eigener DDR3-Core, ein Microblaze und viele Statemachines ;) Der Gag an den 8169 ist, dass sie zwei TX-Queues haben. Die eine hing "normal" am (uC)Linux-Teiber, die andere ging auf einen Speicherbereich, der im FPGA "on demand" die DMA-Deskriptoren zusammengebaut hat. Beim Zugriff auf die Paketdaten wurde dann im FPGA auch der ganze IP/UDP-Header on the fly zusammengebaut, bevor die eigentlichen Paketdaten aus dem Speicher kamen. Wird aber auch heute selbst mit Zusammenklöppeln fertiger IP-Cores kein Samstag-Nachmittags-Projekt sein, wenn man es noch nie gemacht hat.
> Bei 500 aus 1000 halte ich das für ein realistisches Szenario.
Bei 50 % auf WAN-Strecken ruehrt TCP sich gar nicht mehr.
WAN meint Verbindungen so ab 2 Mbps und besser und 50 bis
300 ms RTT.
Ich habe das mit einem konfigurierbaren Bridgemodul
schon mal ausprobiert. Das konnte jedes n-te Paket in
den Orkus werfen.
Bei 20 % Verlust erinnert eine SSH-Session an das Stanzen einer
Lochkarte, mit anschliessender Wartezeit von einer Minute bis
eine Reaktion zu sehen ist. Mitunter klappt auch die ganze
Sitzung ab. Solche Strecken sind in Richtung China z.B.
voellig normal.
Bei 10 % laueft HTTP schon spuerbar unrund.
Eine Webseite besteht ja neben HTML, CSS aus vielen Zutaten.
Und bei 10 % kommt da schon mal was abhanden, was haeufig
nicht mal auffaellt.
Probier es aus! Einen Paketzaehler wirst du ja wohl in dem
Quelltext des Linux-Bridgemoduls unterzubringen wissen.
Aber bei 500 aus 1000 ist es voellig utopisch dass da noch was geht.
Hoechstens theoretisch...
Kannst du das mal konkretisieren? Was meinst du genau mit 50% auf WAN Strecken? Wenn ich hier mein DSL mit Downloads fülle, kann ich nebenbei trotzdem noch rumsurfen und sogar online Zocken mit geringer Latenz bleibt möglich. Auch wenn der Torrent weit über 50% der Datenrate nutzt. Das Gleiche im LAN. Wenn z. B. mein Schreibtisch PC ein automatisiertes Backup auf das NAS schreibt, dann kann ich den wunderbar trotzdem benutzen. Auch für Internetkram und so obwohl das Netzwerk fast komplett ausgelastet ist. Nenn mir ein konkretes Szenario bei dem ich was merken würde.
Homer J. S. schrieb: > Wenn die "Verlustrate" auf der Strecke zu gross wird, nuetzt > TCP auch nichts mehr. 10 % Schwund reichen da schon. > Und schwupps fehlt was. Mehr als das ist dazu nicht zu sagen: TCP (Transmission Control Protocol) – Übertragung von Datenströmen (verbindungsorientiert, zuverlässig) UDP (User Datagram Protocol) – Übertragung von Datenpaketen (verbindungslos, unzuverlässig, geringer Overhead)
FPGA habe ich schon viel gemacht aber kein DMA oder pcie. Das soll auch kein samstagsprojekt werden.
Carsten F. schrieb: > Ich meine 500MBit. In Kuerze: - 1G-faehigen Ethernet-Core nehmen - In C programmierbaren Core um ARP/UDP zu implementieren - Schlauen DMA-Core hernehmen, der direkt aus einem Datenstrom Ethernet-Pakete 'scattert'. Auf Empfangsseite musst du, falls Paketverluste nicht tolerabel sind, deine Maschine entsprechend konfigurieren (geht mit Linux leichter als Windows) oder einen angepassten UDP-Stack hernehmen, der keine Pakete verwirft. Bei vielen Stoerungen bietet sich Forward Error Correction an. Sobald du TCP bei der Datenrate willst, kannst du von obigem 'bare metal' eigentlich die Finger lassen, und gleich einen Linux-SoC nehmen. Bei USB3 ergibt sich dasselbe Problem im 'bulk' Mode. Im 'isochronous' Mode koennen manche Motherboard-Chipsaetze Schluckauf kriegen und Pakete verlieren. Am meisten Zeit verbraet man IMHO am Interfacing mit den FTDI/Cypress Kaefern. Wenn es 'huebsche' (wenig verrauschte) Daten sind, komprimieren sie allenfalls auch gut per DPCM (adaptiv lossy oder non-lossy). So kriege ich hier meinen Datenwust auch noch durch eine 100M-Leitung.
Gustl B. schrieb: > Kannst du das mal konkretisieren? > Was meinst du genau mit 50% auf WAN Strecken? Er meint 50% Paketverlust, nicht 50% Auslastung. Selbst wenn der Paketverlust bei moderaten 3-5% liegt, fällt das bei der normalen Internetnutzung schon negativ auf. In der Theorie ist das kein Problem, in der Praxis ein Tod nach dem anderen und bei verschlüsselten Verbindungen (TLS, HTTPS) wird das alles noch viel schlimmer.
Dafür TCP zu verwenden, bringt mehr Aufwand als Nutzen. Das ganze ist doch eine stinklangweilige Streaming-Anwendung. Dazu verwenden man eben genau kein TCP, sondern UDP mit einem simplen Streaming-Protokoll On-Top. Das Prinzip ist Pipi-einfach: Der Sender, pakiert die Daten und haut sie sequentiell per UDP heraus, speichert sie aber auch in einem FIFO dazwischen. Der Empfänger streamt ebenso die Sequenz-Nummern der empfangen und der verlorenen Pakete an den Sender zurück. Der Sender löscht die quittierten Pakete aus seinem FIFO, und die verloren werden erneut (an den Anfang, das ist einfach) in die FIFO geschrieben. Das sortieren der Pakete kann man bequem am Empfänger machen, auch offline. Der Trick ist eben, dass der FIFO drei Pointer hat: Start, Gesendet und Ende. Das Ende wird durch den Rückwärts-Stream verwaltet. Bei 500 MBit/s sind das pro Gigabyte Sender-Puffer ja 16 Sekunden. In der Zeit kann man ja sogar einen Switch mit umstecken tauschen...
Homer J. S. schrieb: >> Bei 500 aus 1000 halte ich das für ein realistisches Szenario. > > Bei 50 % auf WAN-Strecken ruehrt TCP sich gar nicht mehr. > WAN meint Verbindungen so ab 2 Mbps und besser und 50 bis > 300 ms RTT. Ich meinte eigentlich 500 Mbit/s Last auf einer 1000 Mbit/s Strecke, nicht 50% Paketverlust. Auch geringe Paketverluste können dann m.E. bei einem steten Datenstrom aufgrund der Arbeitsweise von TCP Stacks zum Problem werden.
:
Bearbeitet durch User
Nick M. schrieb: > TCP (Transmission Control Protocol) – Übertragung von Datenströmen > (verbindungsorientiert, zuverlässig) TCP: Zuverlässig unter bestimmten Bedingungen. Neigung zu Abbrüchen und Verstopfungen ausserhalb davon. NB: Gerne gemachter Fehler ist TCP over TCP, z.B. TCP/IP in einem auf TCP aufbauenden VPN-Tunnel - das kann sich als Schönwetterprotokoll erweisen. UDP: Unzuverlässig, aber anders als TCP verträglich mit konstantem Datenstrom bei signifikanter Last. Man muss dann je nach Anwendung entscheiden, ob man fehlende Daten erneut anfordert, die bereits erwähnte Redundanz einbaut, oder mit einem Verlust schlicht lebt. Bei Video/Voice neigt man zu Letzterem.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Neigung zu Abbrüchen und Verstopfungen ausserhalb davon. Weil es halt gesichert ist, die Leitung ist voll. Ändert also nichts an meiner Aussage. (prx) A. K. schrieb: > Gerne gemachter Fehler ist TCP over > TCP, z.B. TCP/IP in einem auf TCP aufbauenden VPN-Tunnel Ist das dein Fehler? Ist das ein Fehler von TCP? Kann das nicht mit UDP passieren? Für was ist die Aussage ein Argumen? Für nichts? Und warum ist TCP oder UDP über einen VPN-Tunnel ein Fehler? Es sollen halt mehrere Sockets über eine sichere Verbindung laufen. Ist halt die Anforderung des Kunden.
Nick M. schrieb: > Und warum ist TCP oder UDP über einen VPN-Tunnel ein Fehler? Nur bei einem TCP-Tunnel. Weil Fehler Retries auf mehreren Ebenen zur Folge haben können, mit vervielfachter Übertragung der gleichen Daten auf beiden Ebenen, wenn man das Verhalten der beiden TCP Stacks nicht gut koordiniert. Im Jargon ist das als TCP Meltdown bekannt. UDP over TCP verliert die Fähigkeit zu isochronem Transport, weil der untere TCP Layer durch variable Latenz das empfindliche Zeitverhalten stört. Blöderweise weiss die Anwendung das nicht, die das UDP nutzt. Gute VPN-Lösungen setzten deshalb auf UDP oder pures IP, etwa IPsec oder Wireguard. OpenVPN kann leider beides: https://openvpn.net/faq/what-is-tcp-meltdown/ Ich hatte mal den Fall von gleich 3 Retransmission-Layers übereinander, noch dazu mit völlig unpassendem Zeitverhalten der jeweiligen Layer zueinander. Mit der Folge von gelegentlichen pathologischen Zuständen dauerhafter totaler Verstopfung bei keiner effektiven Nutzdatenübertragung.
:
Bearbeitet durch User
Er wird ja seinen ADC nicht am anderen Ende der Welt betreiben... In Laborumgebungen, wo man Einfluß auf die Netzwerktopologie und die Switche hat, ist UDP genau gar kein Problem, da gibt es keine Paketverluste. Und auch ein Host-PC hat i.d.R. kein Problem damit, mehrere UDP-GBit-Links gleichzeitig zu empfangen (mit einer 10 GBit/s-Netzwerkkarte). Mit der üblichen Paketgröße kommt man bei 1 GBit auf ca. 115 MByte/s. Wenn man Jumboframes kann, gehen auch 124 MByte/s. BTDT. Duke
Danke soweit. Es geht um eine feste Messeinrichtung da soll der fpga direkt am PC hängen, ohne switch dazwischen.
Nur mal ein Update. Ich habe mich entschlossen das über USB 3.0 zu machen mit dem FTDI Chip und einem Spartan 6. Der Aufwand mit Ethernet steht in keinen Verhältnis. Den FIFO des FTDI kann man leicht per FPGA befüllen (Sowas ähnliches habe ich schon gemacht) aber bis man überhaupt UDP im Spartan am laufen hat ist man einige Haare los.
Gute Entscheidung. Wenn du Fragen zum FT60x hast auch zu Schaltung und Layout dann immer her damit.
Moin, Und wie siehts aufm PC aus mit der Weiterverarbeitung ausm USB? Ethernet/UDP-Pakete hol' ich mir ueber einen Socket und fertig. Wie sieht das bei USB mit der Kommunikation ueber den Treiber oder so aus - gibts da was genormtes wie Sockets? Gruss WK
Es gibt die D3XX https://www.ftdichip.com/Drivers/D3XX.htm und die kann man schön aus C heraus verwenden.
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.