Hallo Leute, ich bin gearde dabei den FT601 Chip von FTDI in Betrieb zu nehmen. Hierzu habe ich den Endpoit auf 1 Pipe IN gestellt. Demnach ist der interne Buffer von FTDI Chip auf 8192Byte gestellt. Bei dieser Einstellung soll der FT601 Chip die beste Performance liefern. Demnach kann ich durch diese Einstellung auch nur noch Daten vom Gerät in den PC in eine Richtung übertragen. Dies ist auch so später in der rellen Anwendung. FTDI selber stellt eine Streaming Benchmark Tool zur Verfügung. Dies habe ich gestartet und den Performance Test durchgeführt. Ich erhalte mit einem Stream eine Transferrate von 361MB/s. Das ist schon mal recht viel jedoch habe ich gelesen das der FX3 von Cypress bis zu 450MB/s erreicht. Jedoch würden mir die 361MB/s ausreichen. Jetzt aber zu meiner Entdeckung. Ich habe mit dem Oscilloscope die #TXE Leitung vom FT601 untersucht. Dort ist mir aufgefallen das die Leitung sehr häufig für 2,612ms den Zustand '1' besitzt. Demnach kann ich für eine sehr lange Zeit keine Daten in FT601 FIFO schreiben. Somit ist ein konstantes Streming ohne ausreichend großen Buffer nicht möglich. Wenn ich nicht möchte das Daten verloren gehen dann muss ich 2,161ms / 10ns * 4Byte = 864,4kByte im FPGA zwischen speichern. Für die Umsetzung möchte ich einen XC7A35T (Artix 7) verwenden. Nur hat der leider nicht genügen internen Block Ram um die 2,612ms Pause zu buffern (der artix 7 besitzt 225kByte internen Block RAM und ich benötige 864kByte). Ich muss Messdaten von einen ADC konstant übertragen können. Und es dürfen natürlich keine Daten verloren gehen. Hat jemand schon Erfahrungen mit dem FT601 gemacht?
Ich glaube du musst erstmals irgendwie identifizieren woher diese Wartezeiten kommen. Kannst du den USB Verkehr irgendwie auch loggen? Kann man da auch 2ms lange Lücken sehen? Wenn der USB irgendwie gar nix mehr tut für 2ms dann ist ja kein Wunder dass du den Buffer nicht mehr füllen kannst. Hast du da irgendwelche Hubs dazwischen? Sagt der Datenblatt irgendwas dazu? Sind hier irdendwelche Zeite spezifiziert? In welcher Richtung hat der Benchmarktool die Daten gesendet? PC -> FTDI FTDI -> PC?
Michael schrieb: > Das ist schon mal recht > viel jedoch habe ich gelesen das der FX3 von Cypress bis zu 450MB/s > erreicht. Jedoch würden mir die 361MB/s ausreichen. Die 361MB/s kratzen schon an der maximalen Grenze. USB 3.0 hat eine Brutto-Datenrate von 500MB/s (5Gbit/s, 8B/10B Kodierung), netto im BULK Modus bei Rückenwind und im freien Fall vielleicht so knapp 400MB/s. Der Cypress FX3 schafft maximal theoretisch 440MB/s oder so, aber man kriegt ja durch das 100MHz GPIF II maximal 400MB/s rein, in echt etwa 360MB/s. Und das auch bloß bei genügend großen Puffern und maximaler Ausnutzung der Transfergrößen usw.
Musst du die einzelnen ADC Samples unverändert übertragen oder darfst du die schon im FPGA vorverarbeiten? Also z. B. immer nur die Änderung, Differenz vom aktuellen Sample zum Vorherigen. Sonst würde ich externen SRAM nehmen, oder den Artix XC7A200, der hat viel BRAM.
Michael schrieb: > Dort ist mir aufgefallen das die Leitung > sehr häufig für 2,612ms den Zustand '1' besitzt. Demnach kann ich für > eine sehr lange Zeit keine Daten in FT601 FIFO schreiben. Was verwendest Du als PC-Host System? Kannst Du dort mal ein anderes System testen (Linux <-> Windows)? Duke
Hallo Christian, demnach brauche ich nicht auf den FX3 zu hoffen. In der Doku von FX3 steht doch drin das er 440MB/s kann. Aber wenn Du schon sagst das das Interface zwischen FPGA und FX3 maximal 400MB/s kann, dann wundere ich mich wie die 440MB/s schaffen. Warum können die die Buffer nicht mal größer machen. Die können doch 2 Buffer im Chip verbauen und dann mit einem Multiplexer zwischen den Buffern umschalten. Es kann doch nicht sein das dort immer die Pausen von 1,4us sind. Dadurch kann ich doch dann nur 360MB/s über das Interface in den Chip schreiben. Hat der FX3 auch immer unregelmäßig so extream lange 2 ms Pausen?
Ich habe schon 2 PCs getestet und beide zwigen das gleiche Bild.
Die 440MB erreicht man schon, aber nur aus dem internen Speicher. Werbung halt. Beim FX3 hat man die Freiheiten, sich mehrere DMA Buffer anzulegen, die schaltet der DMA Controller dann durch. Die meisten Pausen kommen aber durch den Host, da ist es auch egal, ob Windows oder Linux. Manchmal geht das bis in die zig Millisekunden. USB ist nicht Echtzeit fähig und BULK wird abgearbeitet wenn nix anderes anliegt. 361MB/s ist schon super, da ist wie gesagt kaum Luft nach oben. In echt hab ich 320MB/s gesehen, aber wir betreiben das GPIF momentan mit nur 80MHz, da gehen so knapp über 300. Mit 100MHz muss man schon ordentlich die Setup und Hold Zeiten beachten, das war mir zuviel Gefrickel.
Vielen Dank für das Feedback. Was verwendest Du denn um die Daten zwischen zu speichern? Einen DDR RAM oder gibt es für so etwas noch SRAM?
Wir haben da ein 200er Artix dran, der hat genug BRAM für unsere Anwendung. Der Puffer vor dem FX3 ist 512kByte groß, im FX3 hab ich ja dann auch nochmal so groß wie möglich die beiden DMA Buffer, müsste ich jetzt nachgucken. Zum Glück kann man am FX3 alles frei einstellen, und internes RAM hat der auch einigermaßen genug.
Haoolo Christian, Habe ich das richtig verstanden das man beim FX3 den 512kByte großen Speicher mit benutzen kann? Dies würde mir ja einen exteren DDR RAM erparren. Hast Du beim FX3 auch immer so lange Pausen wo der FPGA keine Daten in FX3 schreiben kann so das der Block Ram vom FPGA nicht ausreicht? Ich habe noch eine 2. Anwendung wo wir die Datenströme von 2 externen Kameras an den PC übertragen wollen. Hier habe ich auch an USB 3 gedacht. Der Datenstrom von jeder Kamera ist ca. 65MByte/s.
Du kannst nicht nur, du musst. Beim FX3 gehen alle DMA Buffer usw. vom internen RAM ab. Wir haben im FPGA nochmal 512kB für BULK IN dazu, aber klar, je nachdem wie schnell der Host ist, meldet der FX3 dann oft voll und der FPGA muss warten. Ist aber bei uns kein Problem, wir haben kein Streaming und speichern die Messwerte sowieso in Stücken nach einem Trigger. Für lückenlosen Stream ist und bleibt USB einfach nicht geeignet. Und wurde auch nicht dafür gemacht.
Was verwendet ihr denn um USB Daten zu Unetrsuchen. Gibt es das Tools oder Software? Ich würde gerne wissen wie viele Pakete Fehlerfrei übertragen werden und wie viele Fehler bei der Übertargung auftreten.
Das ist doch im Normalfall nicht nötig. Bei BULK erfolgt eine Prüfung der Daten mit bis zu 3 Re-Transmits, wenn dann immer noch falsch, kommt ein Fehler. Bei ISO hat du eh keine Garantie ob alle/korrekte Daten kommen, da wird lediglich die Bandbreite garantiert. Für harte Fälle haben wir einen LeCroy USB 3.0 Analyzer.
Ich versuche halt zu verstehen warum der Chip die Busy Leitungung (FIFO ist voll #TXE Leitung)für über 2ms auf '1' setzt. Werden so viele fehlerhafte Pakete erkannt das er oft ein Retry machen muss. Oder sendet das Betriebssystem einfach 2ms lang kein ACK Signal zurück. Ich würde ungern einen DDR Speicher an den FPGA anschließen. Dies würde wieder die Firmware deutlich aufwendiger gestalen und auch das Layout für komplexer und teurer werden. Hast Du einen praktischen Erfahrungswert wie das beim FX3 ist?
Michael schrieb: > Was verwendet ihr denn um USB Daten zu Unetrsuchen. Z.B. USBTrace http://www.sysnucleus.com/
Danke für die Info. Der Preis scheint ja auch noch zu gehen. Kann man damit sämtlich USB Datenströme analisieren?
Michael schrieb: > Hast Du einen praktischen Erfahrungswert wie das beim FX3 ist? Ja klar, schrieb ich ja. Du kannst auch schnell Pausen von 50ms, 200ms und mehr organisieren. Wirf mal Windows Update an, während des Transfers. Oder starte McAffee Virenscanner. Außerdem muss man auch einigen Hirnschmalz in die Buffer Verwaltung auf der Host Seite stecken...2ms ist doch nix.
Bist Du sicher, dass die Denkpause nicht durch den PC oder die PC Software bedingt ist?
Uwe B. schrieb: > Bist Du sicher, dass die Denkpause nicht durch den PC oder die PC > Software bedingt ist? Das versuchte ich ihm ja auch zu erklären, aber ich glaube er denkt noch dass USB immer die volle Bandbreite liefert. Man kann ja mal Windows Update starten oder gar Eclipse starten während des Datentransfers, dann werden die "Denkpausen" noch viel viel länger.
Bei dem FT2232H in sync. Fifo Modus muss man jede Menge USB Request Buffer vorhalten. Macht das FT60x Programm das auch? Das kann man aber wahrscheinlich nicht sagen, das die Bibliothek close source ist...
Bei dem Performance Test wird die CPU so gut wie nicht belastet. Ich habe nur das Streamin Tool von FTDI auf laufen. Demnächst werde ich noch einen USB Bildschirm anhließen und die Performance erneut testen. Die Bildschirmdaten werden zwar in die andere Richtung übertragen, jedoch müssen die Daten ja mit einem ACK bestätigt werden. Dies kann dann die Performance vom Datenstream deutlich reduzieren. Alle Daten Display und ADC Daten laufen gemeinsam über einen USB 3 Hub.
Aber nein :-) Ich habe auf meinem Board einen USB 3.0 Hub. Dieser besitzt 4 Ausgänge. 1. Ausgang --> FT601 2. Ausgang --> FT601 3. Ausgang --> USB 3 zu HDMI Konverter (USB 3 Grafikkarte) 4. Ausgang --> FT2232H (USB 2.0 zu JTAG um Firmware in den FPGA zu laden) Es gibt 2 Datenstreams die in den FPGA gehen. Der eine Datenstream wird über den 1. FT601 übertragen und der 2. Datenstream über den 2. FT601 Chip. Der Hub sorgt dafür das nur 1 USB 3 Kabel zum PC benötigt wird. Der 1. Stream erzeugt ca. 260MB/s Daten. Der 2. Datenstream ca. 110 MB/s
Michael schrieb: > Der 1. Stream erzeugt ca. 260MB/s Daten. Der 2. Datenstream ca. 110 MB/s Da bist Du schon über die 360 MS/s die oben angesprochen wurden. Gratulation. > einen USB 3.0 Hub. Dieser besitzt 4 Ausgänge. Und der macht nicht 4x die USB3.0-Bandbreite sondern teilt die auf, erfahrungsgemäß. Duke
Im Grunde ist es doch nur ein 2.0 USB hub und ein PCIe Switch für die 3.0er Leitungen? Kann mir auch nicht vorstellen das die USB 2.0 über die 3.0 rx / tx Leitungen läuft die hätten dann 4 GBit.
Der Hub selber hat zwei Hubs integriert. Der erste Hub ist für USB 2 und der 2. Hub fur USB3.
Bitte 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.