Ethernet FIFO

Mit einer konkreten Frage kommst du vermutlich weiter. Wo liegt das 
Problem?

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

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?

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.

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.

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.

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.

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.

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.

Brauchst du bei USB mit dem FT600 beides nicht. Geht auch an anderen 
Wochentagen.

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.

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.

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.

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.

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.