Hallo zusammen Ich bin daran mein FX3-FPGA-Board unter USB 3.0 in Betrieb zu nehmen. Vom FPGA sende ich Daten in relativ grossen Einheiten (100 KByte - 900 MByte) über das Slave-Fifo-IF via FX3 zum PC, jeweils gestuffed auf Packet (1024 Byte für USB 3.0), gefolgt von einem Leerpacket (PKTEND ohne Daten). PC-seitig lese ich jeweils 2 MByte-Pakete (FX3Device.dataInEndpoint.XferData), d.h. N-1 Pakete a 2 MByte plus der Rest. Das funktioniert für USB 2.0 tipp-topp, in der USB 3.0 Version kriege ich aber immer noch zusätzliche Daten (in den beobachteten Fällen immer '0'). Es scheint als würde ergänzt, und zwar so, dass die Gesamtlänge (X*65536)-(j*8) Bytes gross ist (j normalerweise 1, es wurde auch schon bis zu j=4 beobachtet). Mit dem SignalTap sehe ich, dass die zusätzlichen Daten nicht im FPGA generiert werden, d.h. dort ist alles sauber. Hat jemand schon was Ähnliches gesehen? Idee was ich verbocke? Zum Zweiten ganz was praktisches: Ich benutze das standard-GPIF-SlaveFifo-I/F welche für USB 3.0 eine DMA-Buffer/Fifo-Grösse von 1024 Byte, für USB 2.0 eine von 512 Byte hat. In einem ersten Schritt habe ich mein FPGA für meine USB3.0-Tests fix auf 1024-er-Blöcke angepasst, frage mich aber ob das sinnvoll automatisiert werden kann, ohne dass das FPGA wissen muss, ober der FX3 im 2.0 oder 3.0-Mode ist. Was ist hier "best practice"? Merci!
Gast
#3912340
Hallo P. K., leider kann ich Dir auf Deine Frage keine Antwort geben, weil ich bisher auch nur mit dem FX2 gearbeitet habe, dafür aber eine Frage von mir. Was für ein FX3 FPGA Board benutzt Du ? Gruß vom FPGA-Freak
FPGA-Freak schrieb im Beitrag #3912340: > Was für ein FX3 FPGA Board benutzt Du ? Unser eigenes... ...ist nicht kommerziell erhältlich.
bei uns war auch anfangs etwas probleme mit dem packetend, geht aber alles gut, mit wirklich grossen datenmengen, >= 300MB/s high speed ADC capture. ich glaube leerpakete senden wir nie ist andes gelöst bei uns.
Jo bei uns auch ohne Probleme. Die Hostsoftware sagt dem FPGA die Anzahl und der FPGA schließt die Pakete dann ab. Lesen in 2MB großen Blöcken über WinUSB. Vielleicht ist das bei dir so ein "Feature" des Cypress Treibers. Der ist ganz schön seltsam.
Ich bin auf einen Thread gestossen, der erwähnt, dass ZLPs nicht funktionieren mit dem Default-Cypress-Slave-I/F. Bis jetzt (USB2.0) hatte ich keine Probleme damit, werde aber hier mal einhaken... http://www.cypress.com/?app=forum&id=167&rID=87073
Das könnte auch sein. Ich hatte das wahrscheinlich mal. Als ich ganz zu Beginn das VHDL Modul vom FX2 auf den FX3 umgesetzt habe, hatte ich das noch so drin, dass wie beim FX2 nötig, das PKTEND Signal erst 2 Takte nach dem letzten Word des Short Packet aktiviert wird, da ging auch nix richtig am FX3, denn da muss das zusammen mit dem letzten Wort kommen. Dann gehts korrekt. Mag sein, dass ZLP nicht klappt.
Gast
#3918237
Habt ihr schon gesehen das es auch bald einen USB 3.0 Chip von FTDI geben wird :-)
Naja, die hatten schon vor Cypress angekündigt, an dem Chip zu arbeiten. Wird ja auch Zeit. Hoffentlich kriegt der nicht auch so ein krankes Timing am FT245 FIFO Interface wie der FT2232H usw. Insgesamt sind die Cypress Chips aber weitaus flexibler, allerdings natürlich mit mehr Einarbeitung verbunden.
Gast
#3918282
Na das ging ja schnell ;-) (Cypress 2011) Und auch nur Parallel... das braucht soviele Pins ;-/
Naja, wirklich verfügbar ist der FX3 seit 2013, also sooo viel später sind sie nicht. Seriell wäre schon manchmal schicker, aber das erfordert dann immer einen FPGA mit MGT o.ä. als Gegenstelle.
Gast
#3918389
Christian R. schrieb: > Seriell wäre schon manchmal schicker, aber das erfordert > dann immer einen FPGA mit MGT o.ä. als Gegenstelle. MGT meinte ich auch gar nicht ;-) Mit normalem LVDS reicht ja schon ein kleines FPGA ohne MGT, spart trotzdem einige Pins bzw. bringt RX+TX gleichzeitig. (und man könnte es umschaltbar gestalten für parallel)
Naja gut, dann brauchste aber ein FPGA mit SERDES drin, und musst dich erst ma syncen usw. wäre aber durchaus sinnvoll, da geb ich dir recht. 100MHz 32 Bit ist auf dem Layout auch ziemlich blöde, und der FX3 hat ja sogar Probleme mit dem internen Substrat-Rauschen und/oder Ground Bouncing, wenn man das GPIF mit 3,3V laufen lässt, dann steigt die USB 3 PLL aus.
Wenn ich den in http://www.cypress.com/?app=forum&id=167&rID=87073&start=21 erwähnten Delay von >125us draufschlage funktioniert das Ganze soweit, dass mit der USB3.0 nicht ständig abschmiert, aber die "known Problems and Solutions" helfen da wenig weiter. Werde mich wohl am gegenwärtigen "works for me" Status erfreuen und dann gelegentlich ein MyCase starten um mehr dahinter zu blicken und die Ursachen verstehen.
Gast
#3927051
Wenn der FTDI Chip draußen ist werde ich mal ein Demo Board kaufen und den Chip ausprobieren.
Gast
#3930633
Christian R. schrieb: > Hoffentlich kriegt der nicht auch so ein krankes > Timing am FT245 FIFO Interface wie der FT2232H usw. Hast Du Dir mal ein neueres Datenblat fuer den FT2232H angeschaut? Da ist das Fifo Timing deutlich relaxter,,,
Nachtrag zur ursprünglichen "Aufgabenstellung": Es hat sich herausgestellt, dass bei mir (auf 2 verschiedenen PCs) die Kombination von ASMedia Host Controller und dem zugehörigen Treiber 1.10.0.0 für die Probleme verantwortlich war. Da die "Suche nach Treiber im Netz" immer mit "ist auf dem neuesten Stand" reagiert hat, war mein Verdacht zuerst mal auch nicht auf diesen gefallen. Ein Zwangsupdate auf 1.16.22.0 (!) hat das Problem dann behoben. Zwischenzeitlich eingebaute Karten mit Renesas und VIA Host Controllern haben ebenfalls problemlos gearbeitet. Ebenfalls problemlos funktioniert ein Motherboard mit Intel Host Controller.
Das deckt sich mit unseren Erfahrungen. Wir empfehlen unseren Kunden dringend, auf ASMedia zu verzichten, die machen einfach zuviel Ärger.
Gast
#4037037
Ich habe ähnliche Erfahrungen gemacht mit anderen USB-3 SuperSpeed Geräten. Manche USB-3 Controller arbeiten nicht sauber, insbesondere günstige Steckkarten. Renesas funktioniert gut, und man sollte wohl die 2A Version nehmen. Bestens gehen die von Intel im Chipsatz eingebauten Chips z.B. QM-77 und ähnliche.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.