Hallo Leute, ich habe gesehen das der Cypress FX3 bei Mouser auf Lager vorhanden ist. Auch das SDK Board kann man dort kaufen. Hat schon einer Erfahrungen mit dem FX3 gesammelt. Ich muss ich naher Zukunft eine USB 3 Lösung umsetzen. Bis jetzt habe ich an einen IP-Core von PLDA gedacht oder einen Cypress FX3 IC. Hier gab es vor 6 Monaten ja noch einige Probleme. Nun wollte ich mal fragen ob es sich inzwischen lohnt sich mal das SDK zu kaufen? Wie hoch ist denn inzwischen die praktische maximale Datentransferrate? hier der Link zu Mouser http://de.mouser.com/Search/ProductDetail.aspx?qs=6umP0cCPi7fr0hyabo73Ug%3d%3d http://de.mouser.com/ProductDetail/Cypress-Semiconductor/CYUSB3KIT-001/?qs=RxpMB0WAjlUdNSpGRPmYUw%3d%3d
Ich hab das DVK (noch in der ersten Beta-Version) im Einsatz am FPGA. Das geht mittlerweile sehr ordentlich, fast alle Bugs waren in der Firmware. Mit dem Slave FIFO Modus 32 Bit erreiche ich ca. 320MB/s IN Transfer und 270MB/s OUT Transfer im Bulk Modus mit 16 Paketen per Burst an einem per PCIe 2.0 verbundenen NEC Host Controller. Der FX3 ist nicht ganz so simpel wie der FX2, durch den ARM 9 Kern, aber das wird vom API alles gut gekapselt. Mittlerweile ist auch der Treiber für das DVK signiert, da kann also auch nicht mehr so viel an Bugs drin sein. Ich habe jetzt bei Digikey 2 aktuelle FX3 Chips bestellt, die haben dann hoffentlich alle Silicon Bugs raus, und da werden wir mal den FX3 auf dem DVK austauschen. Ich will auch mal das SPI Boot testen. Was wirklich doof ist, dass man die SPI im 32 Bit Slave FIFO Modus nicht nutzen kann. Ansonsten ist auch das Cypress Forum eine gute Anlaufstelle, ich bin da auch recht aktiv, und mindestens noch einer aus dem Forum hier. PLDA ist viel zu teuer. Der FX3 kann das gleiche und kostet nur ein Bruchteil, zumal man bei PLDA auch noch den EZ-DMA Core und den USB 2.0 kaufen muss, um das sinnvoll zu nutzen. Ich kann den FX3 auf jeden Fall empfehlen. Er tut was er soll, wenn man die paar Klippen umschifft (3 Clock Latenz an den Flags usw.)
Hallo Christian, es reizt mich schon sehr gleich morgen das SDK Board zu bestellen und auszuprobieren. Bin jedoch noch mindestens 1 Woche voll ausgelastet, komme gerade heute aus der Elternzeit zurück. Bis jetzt muss ich sagen habe ich noch nicht viel in der Doku gelesen. Vielleicht kannst Du ja einige Fragen beantworten. Wenn ich das SDK kaufe, ist da sicherlich eine CD. Auf der CD sind dann auch hoffentlicht einige Beispiele und eine Software drauf die ich installiere. Welche IDE wird denn von Cypress insatlliert ist dies Eclipse? Muss ich nur 3 mal auf weiter klicken und dann ist die IDE, die Beispiele und der Treiber installiert oder benötige ich erste 1 Woche und die Forum Hilfe damit die IDE funktioniert. Wenn die IDE dann installiert ist öffne ich z.B. das 1 Beispiel und einen Geschwindigkeitstest zu machen. Muss ich das Beispiel nur compilieren und dann auf den µC hochladen oder wie funktioniert es? Gibt es dazu auch eine PC Software die die empfangenden Daten darstellt? Welchen FPGA habt ihr denn angeschlossen einen Spartan 6 oder Virtex 5? Wie groß ist denn Dein FPGA Speicher damit keine Daten verloren gehen, man muss doch sicherlich einen DDR2 oder DDR3 Speicher an den FPGA anschließen um diese Datentransferraten hinzubekommen? Den Datendurchsatz den Du angegeben hast benötige ich auch :-) Genau so habe ich mir es vorgestellt :-)
Johann schrieb: > Wenn ich das SDK kaufe, ist da sicherlich eine CD. Auf der CD sind dann > auch hoffentlicht einige Beispiele und eine Software drauf die ich > installiere. CD weiß ich nicht, aber es gibt ein Download-Paket bei Cypress: http://www.cypress.com/?rID=57990 > Welche IDE wird denn von Cypress insatlliert ist dies Eclipse? Muss ich > nur 3 mal auf weiter klicken und dann ist die IDE, die Beispiele und der > Treiber installiert oder benötige ich erste 1 Woche und die Forum Hilfe > damit die IDE funktioniert. Ja, ist Eclipse mit dem FX3 SDK und ARM-GCC. Einfach Setup.exe und los gehts. Dann gibts noch eine SuperSpeed USB Suite, da ist der Treiber drin und Testprogramme zur Geschwindigkeitsmessung. Nochmal extra gibts den GPIF II Designer, mit dem man sich ziemlich frei die GPIF Schnittstelle parametrieren kann. Den braucht man aber erst mal nicht. > Wenn die IDE dann installiert ist öffne ich z.B. das 1 Beispiel und > einen Geschwindigkeitstest zu machen. Muss ich das Beispiel nur > compilieren und dann auf den µC hochladen oder wie funktioniert es? Gibt > es dazu auch eine PC Software die die empfangenden Daten darstellt? Ja, genau so. Kompilieren und das entstehende img File mit den Cypress Control Center auf den FX3 laden. Dann enumeriert er neu und du hast beispielsweise diese Streamer-Demo. Daten darstellen tut das nicht, sondern nur abholen und Speed messen. Für die FX3-Firmware sind massenhaft fertige Beispiele dabei. > Welchen FPGA habt ihr denn angeschlossen einen Spartan 6 oder Virtex 5? Spartan 6, Virtex 6 und Virtex 4. Haben uns einen Adapter gemacht, um das DVK per HighSpeed Samtec Kabel an den FMC Stecker der neuen Xilinx Boards anzuschließen. > Wie groß ist denn Dein FPGA Speicher damit keine Daten verloren gehen, > man muss doch sicherlich einen DDR2 oder DDR3 Speicher an den FPGA > anschließen um diese Datentransferraten hinzubekommen? Im Moment der interne BlockRAM. Man muss sicherlich einiges puffern, aber sooo schlimm ist das auch nicht, denn der FX3 hat im Gegensatz zum FX2 jede Menge internen Puffer. Wenn du im Burst Modus arbeitest, hast du schon mal 16384 Byte pro Paket, dann kannst du noch mehrere DMA-Buffer anlegen, die sehr schnell umgeschaltet werden. > Den Datendurchsatz den Du angegeben hast benötige ich auch :-) Genau so > habe ich mir es vorgestellt :-) Da muss man dann aber schon optimieren, gerade in der Firmware. Ist aber ganz gut dokumentiert. Die Speed-Tests hab ich erst mal mit Write und FIFO voll verbunden gemacht, um zu sehen, was theoretisch möglich ist. Mit dem Virtex 4 hab ich eine 1:1 Ersatzlösung für den FX2 gebaut, Slave FIFO Modus im 16 Bit Mode. Unsere Hardware kann an dem Interface nur 100MB/s (50MHz) liefern, in der echten Applikation erreichen wir dann ca. 90MB/s Upstream zum PC. Downstream sind nur Kommandos. Der FX2 hatte da an der gleichen Schnittstelle 36MB/s. Um eine intensive Einarbeitung kommst du nicht herum. Gerade das RealTime OS auf dem ARM braucht etwas Eingewöhnung und das API mit den ganzen Funktionen ist auch recht umfangreich. Wenn du dann Vendor Requests machen willst, oder noch ein zusätzliches Flag (was sehr nützlich ist), dann musst du schon einiges lesen und die Denkweise da verstehen.
Tausend Dank für diese sehr ausführlichen Infos es hat mir schon sehr viel weiter geholfen. Momentan habe ich auch noch recht viel zu tun aber ich denke das ich dieses Board nächste Woche kaufen werden und dieses mal ausprobiere. Zuvor werde ich die Doku mal überfliegen und dann genauer durchlesen.
Ich habe mich vor etwa einem halben Jahr mit dem Gedanken beschäftigt, vom FX2 auf den FX3 umzusteigen. In der Zwischenzeit habe ich meinen Datenstrom weiter komprimiert, und er Druck ist wieder etwas weg, zumal von der Durchsatz-Seite. Nach wie vor unschön ist, dass die 56-pin Variante vom FX2 keine UART zur Verfügung stellt und das Firmware-Debuggen somit extrem mühsam ist ohne HW-Debug-Schnittstelle (wir haben's mit Soft-I2C-zu-FPGA-zu-UART probiert, ist aber nicht wirklich toll). Kurz und gut: Der FX3 ist immer mal wieder ein Gedanke. Meine Frage nun: Das FX3-DVK kommt relativ nackt, eigentlich nur mit vielen Expansionsports. Um den FX3 zu evaluieren wäre es natürlich cool, gleich ein FPGA am FX3-FIFO zu haben. Weiss jemand von Euch von einem kommerziell erhältlichen FPGA-Zusatzboard (am liebsten mit einem Stratix, bin aber nicht heikel...), z.B. am FX3-DVK-GPF_II I/F ("P_Port to SAMTEC")?
Es gibt noch ein Board mit FMC Stecker: http://solutions.inrevium.com/products/fmc/peripherals_debug/index.html und eins von Brain Technology http://www.usb3x.de/ aber das muss man auch erst irgendwie ans FPGA Board bekommen. Das mit dem FMC Stecker kostte 998 USD, ich hatte da schon mal angefragt.
Christian R. schrieb: > und eins von Brain Technology Schaut relativ einfach zu verbinden aus. Zwar nur über Stiftleisten und nicht sehr viele Pins, aber als etwas langsamer laufendes funktionales Modell ist's möglicherweise zu gebrauchen (vielleicht sogar an mein jetziges Board anflanschbar). Merci!
Ich habe auf meinem neuen Virtex 5 Board einen ASP-134603-01 mit 160 Pins drauf gemacht, damit ich dort so ein Xilinx Spartan 6 SDK Board(SP605) anschließen kann. Jetzt muss ich wieder eine neue Zwischenplatine erstellen damit ich dann das FX3 Board anschließen kann :-) Nie hat man den richtigen Steckverbinder drauf :-(
Tja, irgendwas ist ja immer. Wir hatten ein Board gemacht, wo unten der FMC Stecker drauf ist und oben der QSH Stecker, um mit einem Samtec Kabel das Cypress DVK mit dem Adapter-Board zu verbinden, was dann auf jeden FMC-LPC Sockel gesteckt werden kann. kaum was das Board fertig, gabs dann das fertige FX3-FMC Board.
Ich habe schon mal heute schon mal das Softwarepaket von Cypress installiert und die Doku überflogen. Dabei ist mir bereits folgendes aufgefallen. Der Cypress FX3 hat ja nur SRAM also keinen dauerhaften Speicher. Daher muss das Programm z.B. in einem externen EEPROM gespeichert werden der an den I2C Bus vom FX3 angeschlossen wird. Über die PMode Pins konfiguriere ich den FX3 so das dieser weiß das die Firmware aus den externen EEPROM über I2C in den FX3 geladen werden soll. Ist dies so richtig? Ich habe mal das SlaveFifoSync Beispiel im Eclipse IDE importiert. Und den Quellcode überflogen. In diesem Beispiel wird der Bulk Transfer verwendet. Dieser zeichnet sich durch eine besonders sichere Übertragung aus da die Packete geprüft werden und gegebenfalls neu gesendet werden. Das hört sich auch super an dann muss ich mich nicht um Fehlerkorreturen bei der Datenübertragung kümmern. Meine Anwendung soll wie folgt aussehen: Ich habe einen FPGA (VIRTEX 5 momentan) und 1 AD Wandler 14Bit. Der AD- Wandler liefert den FPGA die digitalisierten Daten. Dieser speichert diese im FIFO ab und überträgt diese dann über eine 32Bit Interface an den FX3 der im sync FIFO Mode arbeitet. Kann ich durch eine leichte Modifikation von dem Beispiel (indem ich die Busbreite von 16Bit auf 32Bit änder) eine Datenübertragung von Deinen 200MByte hinbekommen oder muss ich die Enpoints noch umkonfigurieren?
Mit dem EEPROM das stimmt so. Kannst aber auch einen SPI-Flash nutzen. Bei I2C EEPROM bräuchtest du zwei Stück, weil es die nur bis 128kByte Größe gibt. Wenn du wirklich kontinuierlich messen willst, musst du sicherlich viel zwischenspeichern. Ich weiß nicht, wie das bei USB 3 ist aber bei USB 2.0 macht Windows in unserer Anwendung gerne mal Pause von bis zu 100ms, obwohl große Blöcke transferiert werden und genügend Transfers in der Warteschlange sind. Da kanst du dir ja den Speicherbedarf ausrechnen. Das Beispiel musst du bissl modifizieren, um die Burst Transfer Sache bei Super Speed nutzen. Was man da modifizieren muss, steht z.B. in der Readme in dem BulkSourceSink Projekt. Wichtig ist auch die Host-Seite. Wir nutzen den WinUSB Treiber, der ist stabiler als der Cypress und signiert. Du musst asynchron arbeiten und mehrere Transfers im Voraus anstoßen und am besten 2...3MByte pro Transfer anfordern. Dann kommst du in die Regionen.
Ich werde erst mal das Board bestellen und das mal ausprobieren. Zuvor werde ich aber noch eine Beispiele anschauen damit man besser reinkommt. So wie ich es verstanden habe besitzt der FX3 32 Endpoint, davon 16 als IN und 16 als OUT. Sehe ich das richtig das bei Superspeed ein Endpoint maximal 1024 Byte groß ist oder kann ein Endpoint auch größer sein?
1024 Byte bei BULK im SperSpeed Modus ist schon richtig. Mit maximal 16 Packets per Burst dann 16384 Byte die man auf einmal übertragen kann. Aber davon merkt man nichts, das kapselt alles der Treiber.
Schon mal tausend Dank für die sehr nützlichen Infos ich geb mal ein virtuelles Bier aus :-) Ok nur mal so zum Verständnis. Ich habe einen Endpoint dieser kann maximal 16 Pakete je 1024Byte enthalten. Dies macht dann 16384Byte insgesamt gibt es 16 Endpoints für IN und 16 Endpoints für OUT dies macht demnach 32 Endpoint je 16384Byte. Dadurch benötige ich dann 524.288kBytes an Speicher. Dann würde ja kein Speicher mehr für das Programm selbst über bleiben. Oder meinst Du das jeder Endpoint maximal aus 1024Bytes besteht bei 16 OUT Endpoints macht dies dann 1024 x 16 = 16384 Bytes? Steht für die Endpoint seperater Speicher zur Verfügugn oder werden die Endpoints in diesen 512kByte SRAM vom FX3 angelegt? Eine Frage habe ich noch zu Datenübertragung beim Bulk Transfer. Beim USB ist es ja immer so das der HOST also der PC die Daten anfordert. Wenn jetzt ein Endpoint z.B. aus 1024 Bytes besteht und ich habe bis jetzt nur 800Bytes reingeschrieben und will auch nicht mehr Bytes reinschreiben weil ich mit meiner Aufnahme fertig bin. Wird dann der noch nicht volle Endpoint auch übertragen?
Nein, das mit dem Speicher passt so nicht. Du kannst 32 Endpoints bei SuperSpeed einrichten. Das macht aber wenig Sinn. Die maximale Geschwindigkeit bekommst du nur mit einem Endpoint. Also am sinnvollsten ein EP für IN und ein EP für OUT. Speicher hast du nicht so viel. Die Transfers zwischen dem Slave FIFO und den Endpoints laufen über DMA. Du kannst dann DMA Channels anlegen, die zwischen Dem Endpoint Socket und dem GPIF Socket Daten übertragen. Diese DMA Channels haben Buffer, und so groß wie der Endpoint mal Packets per Burst. Also 16k in dem o.g. Fall. Du kannst damit es schneller geht, auch 2, 4, 8... Buffer dem DMA geben. Da muss man aber aufpassen, soweit ich weiß, geht pro DMA Kanal maximal 64k Buffer. Das sieht man in den Beispielen ganz gut. Ich nutze derzeit 2 Endpoints mit 16 Paketn pro Burst und 4 DMA Buffer. Du wirst nie 32 Endpoints nutzen können und dann schon gar nicht mit so großen Puffern. Die Endpoint Buffer selber sind dann trotzdem max. 1024 Byte groß, egal wieviel Pakete pro Burst du überträgst. Wenn du weniger als die EP-Größe übertragen willst, musst du das Paket mit dem Packet End Signal abschließen, dann kann der Host das lesen.
Da habe ich ja jetzt enorm viel gelernt vielen Dank. Ich habe auch noch einige Informationen im Internet zusammengesammelt um die USB 3.0 Übertragung besser vestehen zzu können. Gut also werde ich ein Prgramm schreiben das 1 IN und 1 OUT Endpoint besitzt. Das GPIF werde ich dann auf 32Bit sync FIFO Modus umstellen. Zudem werde ich dann DMA Kanäle einrichten so das die Daten zwischen dem Slave FIFO und dem Endpoint übder DMA übertragen werden. Kann man sich das ganze wie folgt vorstellen: Der FPGA legt die Daten (immer 32 Bit im 32 Bit Modus) an den FX3 an. Diese Daten werden von dem DMA Kanal in den Buffer geschrieben. Der Buffer ist dann z.B. 16 Packete x 1024 Bytes groß. Wenn jetzt das 1. Packet (1024Bytes) voll ist wird dieses Packet aus dem Buffer in den Endpoint geschrieben. Dadurch ist der Buffer wieder vollständig leer und es passen wieder 16 Packete in diesen Buffer. Wenn der Host dann die Anfrage an das FX3 Device stellt ob der Endpoint Daten zum versenden besitzt werden diese Daten aus dem Endpoint an den Host geschickt. Solange Daten im Endpoint vorhanden sind wird der Buffer aufgefüllt bis maximal 16 Pakete vorhanden sind.
Johann schrieb: > Wenn jetzt das 1. > Packet (1024Bytes) voll ist wird dieses Packet aus dem Buffer in den > Endpoint geschrieben. Dadurch ist der Buffer wieder vollständig leer und > es passen wieder 16 Packete in diesen Buffer. Nein. Erst wenn ein kompletter DMA-Buffer voll ist, wird er an die Endpoint Logik übergeben und dem GPIF ein weiterer DMA Buffer zur Verfügung gestellt (falls parametriert). Das dauert ein wenig. Nahtlos weiter schreiben geht nicht. Während dieser Zeit ist das FULL Flag low. Schließt du ein Paket mit Packet End ab, wird es sofort dem USB übergeben und zum nächsten Buffer weiter geschaltet. Sind die DMA Buffer aufgebraucht, ohne dass der Host Daten abgeholt hat, bleibt FULL auf Low. Eine Fußangel gibts, falls du das partial full Flag nimmst (was man ja muss, denn das FULL hat 3 Takte Latenz!): Das Partial Full reagiert nicht auf kurze Pakete. Angenommen du hast 2 DMA BUffer, schreibst zwei kurze Pakete mit jeweils Packet End in den Slave FIFO, ohne dass der Host was abholt, dann sind die Buffer voll und das partial full meldet das aber nicht. Wohl aber das normale FULL. Man muss also Partial Full und Full verknüpfen und nach dem Packet End ein paar Takte warten, um auf das FULL Flag reagieren zu können.
Na dann habe ich ja schon bereits sehr viel gelernt. Dann werde ich jeweils 1 Endpoint für IN und einen für OUT erzeugen. Anschließend den Endpoint mit 1024Bytes konfigurieren. Anschließend werde ich 4 DMA Kanäle erzeugen. Jeder DMA Kanal besitzt dann Speicher für 16 Pakete mit je 1024 Bytes. Die USB Übertragung muss ich dann auf Bulk mit 16 Burst (Paketen) einstellen. Wenn dann ein Buffer mit 16 Paketen voll ist und der Host eine Datenübertragung angefragt hat, dann wird zuerst das 1 Paket in den Endpoint geschoben und übertragen anschließend die anderen 15 Pakete. Ist es denn bei den Bulk Burst Modus so das alle 16 Pakete auf einmal übertragen werden oder muss der Host jedes Paket einzeln anfordern? Müssen alle 16 Pakete neu übertragen werden wenn z.B. das 6 Paket defekt war oder wird nur das 6. Paket neu übertragen? Wechsel der FX3 zwischen den DMA Buffern automatisch wenn 1 Buffer voll ist oder muss ich diesen manuell umschalten?
Johann schrieb: > Na dann habe ich ja schon bereits sehr viel gelernt. Dann werde ich > jeweils 1 Endpoint für IN und einen für OUT erzeugen. Sinnvoll. > Anschließend den Endpoint mit 1024Bytes konfigurieren. Anschließend > werde ich 4 DMA Kanäle erzeugen. Jeder DMA Kanal besitzt dann Speicher > für 16 Pakete mit je 1024 Bytes. Die USB Übertragung muss ich dann auf > Bulk mit 16 Burst (Paketen) einstellen. Wieso 4 DMA Kanäle? Du hast doch nur 2 Endpoints, die kannst du nur auf 2 GPIF Threads mappen, brauchst also dafür nur 2 DMA Kanäle. > Wenn dann ein Buffer mit 16 Paketen voll ist und der Host eine > Datenübertragung angefragt hat, dann wird zuerst das 1 Paket in den > Endpoint geschoben und übertragen anschließend die anderen 15 Pakete. Nee, der Buffer wird erst an USB commited, wenn alle 16 Pakete voll sind. Der Host Controller kann dann alle Daten in einem Burst abholen, wenn man auf der PC Seite mindestens so viele Daten angefordert hat. > Ist es denn bei den Bulk Burst Modus so das alle 16 Pakete auf einmal > übertragen werden oder muss der Host jedes Paket einzeln anfordern? Das muss dich nicht kümmern. Das macht alles der Treiber, du forderst nur deine Daten an, sobald die verfügbar sind, werden die in einem Burst übertragen. Die Lese-Funktion kommst erst zurück wenn genau so viele Bytes wie angefordert da sind (dann allerdings nur im Fall n x Packet Size) oder eben wenn du das Packet End während des Transfers gesetzt hast. Wenn du mehr Daten ohne Packet End anlieferst als du mit der DLL abholst, gehen die restlichen Daten verloren. Du kannst aber meinetwegen auch 2 MB einfach ans GPIF anliefern, beim letzten das Packet End setzen und am Host 2MB anfordern, dann kommt die Lesefunktion zurück, wenn er die Daten bis zum Packet End hat und es geht nix verloren. > Müssen alle 16 Pakete neu übertragen werden wenn z.B. das 6 Paket defekt > war oder wird nur das 6. Paket neu übertragen? Keine Ahnung, musst du mal in der USB Spec gucken. > Wechsel der FX3 zwischen den DMA Buffern automatisch wenn 1 Buffer voll > ist oder muss ich diesen manuell umschalten? Geht automatisch im round-robin.
Dann hatte ich das doch falsch vestanden. Demnach also zwei DMA Kanäle erstellen einen für IN und einen für den OUT Endpoint. Dann die Buffergröße für jeden DMA Kanal erzeugen. Der gesamte Buffer für den IN Endpoint ist dann z.B.maximal 65536 Bytes groß. (Endpointgröße x Anzahl Pakete pro Burst x Anzahl an Buffer -> 1024Bytes x 16 x 4 = 65536Byte) Ich werde mir in den nächsten Tagen noch mal einige Beispiele anschauen und das SDK bestelleb und es mal ausprobieren. Vielen Dank auf jedenfall für Deine unednliche GEDULD.
So kommt das schon hin. Probier es einfach aus, ist ja alles recht gut dokumentiert. Und die DMA Buffer können zusammen meines Wissens nur 128kByte groß sein.
Hallo, mein Design mit dem FX3 ist nun auch fast fertig. Hier ist eigentlich alles gesagt. Nur eins noch >> Müssen alle 16 Pakete neu übertragen werden wenn z.B. das 6 Paket defekt >> war oder wird nur das 6. Paket neu übertragen? > Keine Ahnung, musst du mal in der USB Spec gucken. In der USB Spec steht, dass im Burst Mode alle Pakete ab dem Fehler neu gesendet werden müssen. Darum brauchst du dich aber nicht kümmern. Das USb Protokol regelt der FX3 bzw. der Host autonom. Achso noch eine Sache. Wenn du deinen halb vollen DMA Buffer senden willst, und die Lesefunktion in der Software zurück kommen soll, reicht nicht immer das PKTEND (Short Packet). In doofen Situationen gehen deine Enpoints gerade auf und deine Funktion kommt nicht zurück weil kein short Packet übertragen wurde. Dann hilft nur ein ZLP. Gruß Marco
So das Board ist da endlich da :-) Ich habe die Software und den Treiber auf meinem Notebook installiert. Mein Notebook besitzt auch einen USB 3.0 Anschluß (mit hoher Wahrscheinlichkeit ist dort ein USB 3.0 Chip von NEC verbaut. Leider weiß ich nicht ob das IC an einem PCIe 2.0 Bus angeschlossen ist). Zuerst habe ich das Bulkloop Beispiel ausprobiert, indem ich es in Eclipse importiert habe. Anschließend habe ich das Beispiel compiliert und mit Hilfe des Cypress USB Control Centers in den Cypress FX3 geladen. Nachdem die neue Firmware im Cypress ist, wird im Gerätemanager unter USB Device der Cypress Chip mit "Cypress USB Bulkloop Example" angezeigt. Danach habe ich die Cypress PC Software "Buld Loop" ausprobiert allerdings wird hier keine Datentransferrate angezeigt. Die Datenübertragung scheint aber zu funktionieren. Als nächstes habe ich den Cypress Tool "USB Control Center" ausprobiert. Ich habe ich in den OUT Endpoint "Hallo Welt" geschrieben. Anschließend habe ich den IN Endpoint gelesen und es kommt auch wieder "Hallo Welt" am PC an --> große FREUDE Als nächstes wollte ich mal einen Xilinx FPGA am FX3 anschließen und Daten über das GPIF2 Interface mit 32 Bit anlegen. Wie hoch darf denn eigentlich der maximale Takt für das 32 Bit Interface sein? Wenn ich davon ausgehe das USB 3.0 mit 5GBits/s spezifiziert ist, dann muss ich doch 5GBits/32Bit teilen und komme somit auf eine Frequenz von 156,25MHz. Ist diese Freuqnez richtig?
Johann schrieb: > Als nächstes wollte ich mal einen Xilinx FPGA am FX3 anschließen und > Daten über das GPIF2 Interface mit 32 Bit anlegen. Wie hoch darf denn > eigentlich der maximale Takt für das 32 Bit Interface sein? > > Wenn ich davon ausgehe das USB 3.0 mit 5GBits/s spezifiziert ist, dann > muss ich doch 5GBits/32Bit teilen und komme somit auf eine Frequenz von > 156,25MHz. Ist diese Freuqnez richtig? Ähm, Datenblatt?!? --> 100MHz!
Ja das habe ich auch gerade gefunden. Gerade habe ich mich mal durch den Beispielcode vom Slave FIFO gekämpft. Das ist zwar alles schön programmiert jedoch doch nicht gerade einfach zu verstehen. Nun noch mal zu den 100MHz. Wenn ich einen FPGA an den FX 3 anschließe dann wollte ich die vollen 32 Bits benutzen. Dies bedeutet das ich mit 100MHz gerade mal 3,2GBits in den FX3 schreiben kann, obwohl USB 3.0 doch mit 5GBits pro Sekunde spezifiziert ist. Dann erreicht ich mit dem FX3 ja nicht die volle Bandbreite. Wenn ich dann noch bedenke das die 32Bits bidirectional sind dann muss ich ja auch noch ständig den Bus zwischen lesen und schreiben wechseln und dann wird die Datenrate deutlich langsamer.
400MB/s ist das Maximum, was der FX3 über das GPIF bewegen kann. Allerdings theoretisch. 100MHz PCLK wird schwierig, da die Setup- und Hold-Zeiten dann praktisch nicht einhaltbar sind. Die 5 GBit/s sind ja Brutto, da geht erst mal die 8B/10B Kodierung weg, also bleiben noch 4GBit/s übrig. Dann noch einiges an Protokoll-Overhead und praktisch erreichst du mit dem FX3 etwa 320MB/s wenn du nur Daten in eine Richtung transferierst. Das ist halt die Beschränkung, auch durch das parallele Interface. Mit einem seriellen MGT Interface wäre vielleicht noch mehr möglich, aber dann wieder sehr eingeschränkt. So kannst du halt quasi beliebige Protokolle fahren. Die 400MB/s stehen übrigens auch im Product Brief bzw. Datenblatt. Ob der Host Controller die volle Bandbreite schafft, ist auch eher fraglich. Übrigens kannst du zum Geschwindigkeit testen eher die Streamer Applikation nutzen, dann mit BulkSourceSink als Firmware oder halt FPGA und Slave FIFO. Und ich glaube die C++ Variante von BulkLoop zeigt auch eine Geschwindigkeit an, das bringt aber eher wenig, da ja dort maximal die Hälfte der wirklichen Bandbreite geht. Wird ja alles rumkopiert. Übrigens erreicht man die volle Bandbreite nur, wenn man den DMA auf AUTO ändert. Im MANUAL Modus muss die CPU immer wieder die Pakete an USB bzw. PIB "commiten".
Hallo Christian, USB 3.0 besitzt ja ein Adernpaar zum Senden und ein Adernpaar zum Empfangen. Daher ist es schade das ich beim FX3 immer dieser 32Bit Datenbus zwischen lesen und schreiben umschalten muss, daher geht da schon sehr viel Geschwindigkeit verloren. Aber dies ist momentean nicht so wichtig. Meine Anwendung sieht wie folgt aus. Ich möchte Daten digitalisieren und diese mit Hilfe des FX3 in den PC schreiben. Daher schreibe ich haupsächlich in den FX3 Daten rein. Später sollen über den FX3 auch noch einige Parameter an mein FPGA Board übertragen werden. Da dies nur Parameter sind ist die Geschwindigkeit nicht so entscheidend. Daher habe ich mich entschieden den FX3 im sycn. Slave Modus zu betreiben. Daher gibt es ja das SLCS#, SLOE#, SLWR#, SLRD# Ich habe aber die Read und Write Diagramme im Datenblatt nicht wirklich verstanden. Zuerst das Schreiben in den FX3: Egal ob ich in den FX3 Daten schreibe oder Daten auslese der FPGA muss im SLAVE MODUS immer einen CLK an den FX3 anlegen. Dieser darf maximal 100MHz betragen. (Ich verwende momentan einen Virtex 5) Ich lege beim Schreiben demnach die Daten an den 32Bit breiten Datenbus an. Den Datenbus stelle ich mit Hilfe des SLOE# Signals auf Eingang demnach denke ich das ich SLOE# auf '1' setzen muss. Das Signal SLRD# muss auf '1' gesetzt werden. Wenn ich dann das SLWR# Signal von '1' auf '0' setze schreibe ich die Daten in den FX3 rein. Habe ich das so richtig verstanden? Aus dem FX3 lesen: Beim lesen muss ich SLOE# auf '0' setzen damit die Ports bei FX3 auf Ausgang gesetzt werden. Zudem muss SLWR# auf '1' gesetzt werden damit ich nicht in den FX3 schreibe. Wenn ich anschließend dasn SLRD# von '1' auf '0' setze dann lese ich die Daten aus dem FX3 aus. Aber wozu benötigt man dann noch diese Adressleitungen?
Schreiben: Wie bei jedem synchronen Interface wird immer dann geschrieben, wenn zu einer stigenden Taktflanke das SLWR# Low ist (und SLRD# sowie SLOE# high sind). Beim Lesen genau so: Wenn zu einer steigenden Taktflanke das SLRD# Low, das SLOE# Low und das SLWR# High ist, werden die Daten an den Ausgang gelegt (2 Takte später allerdings). Die Adressleitungen sind dazu da, um verschiedene FIFOs anzusprechen, nämlich kanst du 4 verschiedene definieren. Diese 4 sind die physical threads des PIB im FX3 und können auf 4 von insgesamt 32 PIB Sockets gemappt werden, die wiederum per DMA an die 32 UIB Sockets gekoppelt werden können, und diese UIB Sockets wiederum können auf die 32 Endpoints gemappt werden. Alles klar ;) USB Endpoint <-> UIB Socket <-> DMA <-> PIB Socket <-> GPIF Thread <-> Slave FIFO Address. Das Mapping der PIB Sockets auf die Threads (also FIFO Adressen) iwird im GPIF Decriptor gemacht, da hab ich mal eine Erklärung im Cypress Forum geschrieben, weil das etwas kryptisch ist. Schlicht gesagt kannst du 4 Endpoints machen und die mit 4 DMA Kanälen auf die 4 Slave FIFOs bringen, die du mit den FIFO Address Leitungen adressierst. Bei deiner Anwendung hast du ja nur 2 Threads, also 2 Adressen, musst also zwischen Lesen und Schreiben auch noch die Adressleitungen umschalten. Im Cypress Demo sind die Adressen (Threads) 0 und 3 benutzt, schau mal in die Header Datei. Die Thread ID und den PIB Socket Number brauchst du übrigens, wenn du statt dem Full Flag ein partial Full Flag einstellen willst.
Ich habe mal das Datenblatt vom FX3 durchgelesen, dort habe ich leider überhaupt nichts über den internen Aufbau des FX3 gefunden. Da stehen die Spannung und die Pins dring und auch das Slave FIFO Interface. Jedoch ist das Timing dort etwas verwirrend dargestellt. Gibt es auch ein ausfürhliches Datenblatt über den Aufbau von den FX3 und den ganzen Registern? Im sync. Slave FIFO Beispiel habe ich schon gesehen das dort socket 0 und 3 verwendet werden. Das kam mir schon etwas komisch vor das nicht Socket 0 und 1 verwendet wurden. Da ich nur 2 Entpoint benutzen werde, benötige ich auch nur 2 FIFOS. Beim lesen kann ich über die Adressleitungen den richten FIFO auslesen. Wie ist es denn beim Schreiben in den FX3 muss ich dort auch die Adresse des FIFOs angeben order ist es beim Schreiben in den FX3 egal, da er immer in den selben FIFO schreibt? Wie groß ist denn dieser FIFO und wie groß ist der Socket sind die auch immer 1024Bytes groß?
Johann schrieb: > Jedoch ist das Timing dort etwas verwirrend dargestellt. Naja, so sind Timing Diagramme immer aufgebaut. Das einzige seltsame ist die Latenz der Flags und Datenausgänge. Merkt man aber schnell in der Praxis dann wie es gemeint ist. > Gibt es auch ein ausfürhliches Datenblatt über den Aufbau von den FX3 > und den ganzen Registern? Nein, denn die komplette ARM Seite incl. Registern ist vom ThreadX Realtime OS und den Cypress APIs gekapselt. > Im sync. Slave FIFO Beispiel habe ich schon gesehen das dort socket 0 > und 3 verwendet werden. Das kam mir schon etwas komisch vor das nicht > Socket 0 und 1 verwendet wurden. Das ist reine Willkür von Cypress. Genausogut kann jeder andere GPIF Thread genutzt werden. > Wie ist es denn beim Schreiben in den FX3 muss ich dort auch die Adresse > des FIFOs angeben order ist es beim Schreiben in den FX3 egal, da er > immer in den selben FIFO schreibt? Natürlich. > Wie groß ist denn dieser FIFO und wie groß ist der Socket sind die auch > immer 1024Bytes groß? Der ist nicht wirklich als FIFO vorhanden, sondern Teil des SRAM im FX3. Die Größe ist der DMA-Buffer.
Achso der Socket ist also der DMA Buffer. Dann werde ich mir in der nächsten Woche mal eine Adapterplatine erstellen lassen, damit ich das mal ausprobieren kann. Wenn ich den GPIF II Designer benutze gibt es dort als Vorlage einen sync_slave_fifo_2bit Projekt. Zuerst dachte ich was soll das denn warum benutzt man einen 2 Bit breiten Datenbus das macht doch alles keinen wirklichen Sinn. Dann habe ich festgestellt das das sync slave fifo Projekt das man mit Eclipse importiert ja auch auf dieser sync slave FIFO 2 Bit Vorlage basiert, aber trotzdem einen 32Bit breiten Datenbus ermöglicht. Für was steht denn nun diese 2 Bits? Und wo ist der Unterschied zwischen der 2Bit Vorlage und der 5Bit Vorlage im GPIF Desginer?
2Bit und 5 Bit sind die Breite des Adress-Bus am GPIF II. 2 Bit ist der normale, mit dem man maximal 4 Threads ansprechen kann. Bei dem 5 Bit ist es halt eine spezielle Frickel-Geschichte, mit der man zyklisch 4 Threds aber insgesamt 32 Sockets ansprechen kann. Das ist aber schon ziemlich abgehoben. Du als Anfänger brauchst die 2 Bit Geschichte. Also 4 Threads an 4 Sockets maximal. Die 4 Threads lassen sich übrigens völlig frei auf die 32 verfügbaren Sockets mappen, aber ich hab bei mir auch nur 1:1 gemappt, also Thread 0 auf Socket 0 und Thread 1 auf Socket 1 und fertig. Da muss ich nur eine Adressleitung umschalten. Gerade heute hab ich mal wieder weiter gemacht. Der FX3 ist durch seine Flag-Latenz ziemlich ekelig, aber ich hab da jetzt was gebaut, was das Schreiben in den FX3 verlangsamt, wobald das Partial Full Flag meldet, dass nur noch wenig Platz ist. Dann warte ich nach jedem Wort schreiben 4 Takte auf das richtige Full Flag und kann somit immer den FIFO ganz voll machen, was auch nötig ist, weil die Pakete sonst nicht comitted werden.
Da jetzt einen 16-Bit ADC mit sagen wir 1MHz Samplerate und auf der PC-Seite einen Treiber, der das als Soundkarte darstellt. Das wäre genial für Messungen mit SpectrumLab.
Dass die Leute immer glauben, mit einem ADC und ein bisschen Logik ist alles für ein Oszilloskop zusammen. Den mit sehr großen Abstand umfangreichen Teil eines Oszilloskopes nimmt das Analogteil ein. Das bissl ADC und Logik, was dann noch dran hängt, läuft unter ferner liefen.
Auf jedenfall schon mal vielen Dank für die ganzen Informationen. Du hast MIR den Arsch gerettet :-)
Christian R. schrieb: > Dass die Leute immer glauben, mit einem ADC und ein bisschen Logik ist > alles für ein Oszilloskop zusammen. Den mit sehr großen Abstand > umfangreichen Teil eines Oszilloskopes nimmt das Analogteil ein. Das > bissl ADC und Logik, was dann noch dran hängt, läuft unter ferner > liefen. Na dann machen wir die Sache doch fest: 1. Ich baue die Hardware einschließlich dem Analogteil 2. Du schreibst die Software für den Windoof-Treiber Jedem sein Spezialgebiet. Es werden uns viele danken. Eventuell sogar verkaufbar. SpectrumLab ist übrigens in erster Linie KEIN Scope, sondern ein FFT-Analyser mit Skriptsprache.
Für sowas hab ich leider keine Zeit. Außerdemn dürfte es nicht viele Bastler geben, die ein µBGA Gehäuse ordentlich verlöten und die zugehörige Platine für SuperSpeed USB designen können.
Eine Sache am FX3 hab ich gerade noch festgestellt: Wenn man an das Slave FIFO Interface genau so viele Daten angeliefert hat, wie die Größe des DMA Buffers ist, bekommt man die Daten nur, wenn man genau so viel am Treiber anfragt oder die Anfrage in Teile untereteilt, die zusammen genau so viel ergeben wie die Buffergröße. Sonst gibts Datenverlust. Liegt am FX3, ist beim CyUSB das gleiche wie bei WinUSB. Das ist wirklich ein bissl doof :/
Das geht ja nicht, dann kannst du ihn nicht vom Host auslesen. Nee, man muss nur daurauf achten immer genau so viele Bytes anzufordern wie vorhanden sind, entweder bis zum vollen Paket oder eben bis zum Packetend bei kurzen Paketen. Bei uns ist das kein Problem, die alte FX2 Software läuft ohne jegliche Anpassung auch mit dem FX3.
Hallo ! Mit dem Winusb Treiber läuft es meistens. Aber ab und an, und nur mit Super Speed, bekomme ich nicht nach vollziehbare USB Resets vom Host. Bei USB 2.0 passiert das nicht. Eine Lösung habe ich noch nicht gefunde. Irgend eine Idee ? PS: Die Daten kommen vom FPGA an 16 Bit Bus, der auch die Clock stellt. Gruss Ralf
Wechlse mal den SuperSpeed Host Controller. Da USB 3 noch nicht nativ von Windows unterstützt wird, verlässt sich WinUSB hier auf den USB Stack des Host Controller Treibers. Wir haben mit dem Renesas/NEC bisher keine Probleme. Viel Stress gibts wohl mit den ASmedia Dingern...
Es wird leider etwas länger dauern bis ich meine Adapterplatine bekomme, da unsere PCB Entwickler momentan vor dem Sommerurlaub voll ausgelastet sind. Das ist ärgerlich :-(
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.