Hallo, ich habe neulich ein interessantes Board gefunden: https://www.crowdsupply.com/tinyfpga/tinyfpga-ex Das verwendet den LFE5UM5G FPGA der 5 GBit/s SERDES eingebaut hat. Wie es aussieht wird damit USB3 gemacht ohne einen externen Stein. Von Xilinx gibt es auch einen USB3 IP, aber der kostet vermutlich was und es steht leider nicht Artix7 dabei. Der Artix7-T kann 6,6 GBit/s auf den Transceivern, das müsste also auch damit funktionieren. Habt ihr das schon gebaut oder irgendwo gesehen? Ich werde das sehr wahrscheinlich nicht selber schreiben, aber ... wenn ich irgendwo sehen würde, dass es funktioniert wäre es eine Überlegung wert.
Hi, USB 3.0 ohne Phy? Das ist eher mutig. Wäre auch eher skeptisch, dass das sauber funktioniert, für industrielle Anwendung sowieso mit Fragezeichen. Es gibt eine offene Implementation mit externem Phy (Daisho-Projekt).
Das geht schon, gab ganz zum Anfang von USB 3.0 auch Cores, bevor es den FX3 oder FT600 gab. Aber kann man nicht bezahlen. Ich müsste mal nachgucken, aber habe noch für USB 3.0, 2.0 und DMA jeweils um die 10k€ im Kopf. Man braucht dummerweise alle drei. Und ohne Phy geht das, klar, ist doch bei 3.0 direkt MGT kompatibel. Aber für 2.0 (was als Fallback zwingend ist) braucht man noch den Phy und einen extra Core. Nimm lieber einen Cypress FX3 oder den FTDI.
Christian R. schrieb: > Aber für 2.0 (was als Fallback zwingend ist) braucht man noch den Phy > und einen extra Core. Ich hatte auch noch im Hinterkopf, dass bei USB 2.0 5V-Kompatibilität gefordert war. Das machen wohl die ECP5-Eingänge nicht lange mit. Und externe Schutzdioden könnten die Impedanz versauen, aber wenn es da eine Lösung gibt, lass ich mich gerne belehren. Wenn nur USB 3.0 unterstützt wäre, kann man ja mit so einem Hack gut leben, aber wenn's beim Reinstecken in 2.0 oder gar ein chinesisches Ladekabel kaputtgeht ist halt weniger nett.
Danke! Der Fallback ist sicher zwingend? Schade eigentlich, sonst könnte man für Datenübertragung einen FT600 an USB3 hängen und für JTAG einen FT2232H an USB2.
-gb- schrieb: > Danke! > > Der Fallback ist sicher zwingend? Schade eigentlich, sonst könnte man > für Datenübertragung einen FT600 an USB3 hängen und für JTAG einen > FT2232H an USB2. Naja für die reine Funktion reichen auch die 3.0 Datenleitungen. Als Bastel Hack für zu Hause könnte man das schon so machen. Ist halt sehr abseits von der USB Spezifikationen. Und würde halt ausschließlich am USB 3.0 Anschluss klappen. Wozu JTAG? Lassen sich diese FPGAs nicht aus einem SPI Flash laden? Der ließe sich viel einfacher aus dem System selbst aktualisieren.
Naja irgendwie muss ich doch erstmal ein Design in den Flash bekommen. Wie das ohne JTAG funktioniert ist mir klar, aber ... wie kompliziert ist es aus dem Design heraus das Flash mit dem neuen Bitstream zu beschreiben? Eigentlich will ich das nicht zu Fuß mit VHDL bauen müssen sondern finde es sehr bequem im Vivado einfach klicken zu können. Ich stelle mir das so vor: Ich habe eine beliebige Datenverbindung vom PC ins FPGA also UART oder sonst was. Und dann brauche ich im FPGA noch einen Teil der das Flash beschreibt und verifiziert. Und irgendeinen Befehl der sagt, dass alle Daten die jetzt kommen ins Flash geschrieben werden sollen.
So ein in-system-Upgrade ist bei Xilinx recht simpel mit einer integrierten CPU, da kannst du auch den golden bootloader in einer unantastbaren SPI-Partition halten. Heisst also, ohne Bootloader geht das nicht, entweder du programmierst das SPI über einen Clip oder hast den JTAG-Zugang, um das SPI-Flash erstmalig über BoundaryScan zu programmieren. Beim ECP5 ist das etwas mühsamer mit in-system-Programmierung des SPI-Flash und ist nicht ganz so durchdacht wie bei Xilinx mit den ICAP-Primitiven.
OK, ich brauche also einen Microblaze. Wie hänge ich den dann an das USB Interface? Wenn ich mit dem FT2232H irgendeine Schnittstelle verwende, z. B. UART, dann kann ich Bytes senden und empfangen. Aber den brauche ich dann nicht nur um einen neuen Bitstream zu laden, sondern auch um Daten zwischen PC und FPGA auszutauschen. Wie wird da getrennt, müssen dann alle Daten der USB-Schnittstelle immer auch durch den Microblaze? Wie performant ist der so, kann der USB 2.0 auslasten wenn man den an das FT2232 FT245 FIFO Interface hängt?
Gustl B. schrieb: > Wie wird da getrennt, müssen > dann alle Daten der USB-Schnittstelle immer auch durch den Microblaze? Der FT2232H hat 2 separate UARTs, Du könntest die eine zum Microblaze nutzen, die andere zum Rest des FPGAs. Der FT2232H hat auch GPIOs (CBUS genannt), mit denen könntest Du auch vom PC aus einen Mux umschalten und damit unterschiedliche Ziele im FPGA ansprechen.
Gustl B. schrieb: > Wie performant ist der so, kann der USB 2.0 auslasten wenn man den an > das FT2232 FT245 FIFO Interface hängt? Da würde ich sowieso eine DMA-Engine für anschmeissen. Müsste es auch für Microblaze was von der Stange geben. Typischerweise kannst du einen DMA-Kanal auch für direktes Streamen von einem Datenport zum USB-FIFO konfigurieren, dass gar nichts mehr umkopiert werden muss. Die Frage ist bloss, ob dir die Bandbreite des FT245-Bulk-Mode reicht und du puffern kannst/darfst. Für vollen Durchsatz (isochroner Modus) würde ich mindestens zum FX2 greifen.
Hm, bisher verwende ich echt gerne einen FT245 FIFO, der schafft knapp 40 MBytes/s und zusätzlich noch einen weiteren FT(2)232 für JTAG (und UART). Mit nur einem FT2232H ist leider kein FT245 FIFO und JTAG möglich sondern mit JTAG geht nurnoch dieser asynchrone FIFO der eine Ecke langsamer ist. Ich brauche also für JTAG und FT245 FIFO zwei FTDI Steine und leider auch zwei USB-Buchsen. Jetzt würde ich für die höhere Datenrate gerne die FIFO Verbindung auf einen FT600 oder so umziehen aber weiterhin JTAG verwenden. Mit USB3 wäre das ja dann zu machen, den FT600 an die Superspeed Leitungen und den FT2232H an die USB2 Leitungen. Christian R. schrieb: > Naja für die reine Funktion reichen auch die 3.0 Datenleitungen. Als > Bastel Hack für zu Hause könnte man das schon so machen. Ist halt sehr > abseits von der USB Spezifikationen. Was ist daran abseits der Spezifikation? Klar, an USB2 funktioniert der FT600 Teil nichtmehr, aber das wird sowieso ein Einzelstück und in Zukunft gibt es eher mehr USB3 als USB2.
Gustl B. schrieb: > Mit nur einem FT2232H ist leider kein FT245 FIFO und JTAG möglich > sondern mit JTAG geht nurnoch dieser asynchrone FIFO der eine Ecke > langsamer ist. Echt? Kann mich irren, aber ich meinte das schon so gesehen zu haben. Beim schnellen überfliegen des Datenblattes sehe ich nur die Beschränkung dass das FIFO nur auf Kanal A geht, aber MPSSE geht ja auf beiden.
-gb- schrieb: > Und dann brauche ich im FPGA noch > einen Teil der das Flash beschreibt und verifiziert. Nicht unbedingt. Wir machen die gesamte Logik im PC, im FPGA sitzt nur ein SPI Master. Das ist viel einfacher, wenn man sowieso die Datenverbindung hat. Hardware JTAG haben wir natürlich dran für die initiale Inbetriebnahme und Debuggen. Aber auch initial kommt nur das Design ins FPGA selber, Flash File geht dann schon über unsere Software.
Christian R. schrieb: > Nicht unbedingt. Wir machen die gesamte Logik im PC, im FPGA sitzt nur > ein SPI Master. Das ist viel einfacher, wenn man sowieso die > Datenverbindung hat. Nun, ich schicke die Daten aber nicht über SPI an den FPGA. Das ist dieses FT245 FIFO Interface und beim FT600 wäre das wohl etwas ähnliches. Zitat: The FT2232H only channel A can be configured as a FT245 style synchronous FIFO interface. When configured in this mode, the pins used and the descriptions of the signals are shown in Table 3.6. To enter this mode the external EEPROM must be set to make port A 245 mode. A software command (Set Bit Mode option) is then sent by the application to the FTDI driver to tell the chip to enter single channel synchronous FIFO mode. In this mode the ‘B’ channel is not available as all resources have been switched onto channel A. In this mode, data is written or read on the rising edge of the CLKOUT.
:
Bearbeitet durch User
Gustl B. schrieb: > Nun, ich schicke die Daten aber nicht über SPI an den FPGA. Das ist > dieses FT245 FIFO Interface und beim FT600 wäre das wohl etwas > ähnliches. Soweit klar, wir nutzen ja auch das parallele Interface des FX2, FX3. Aber natürlich hat die Firmware einen Protokoll Dekoder für Lesen und Schreiben denn die Messdaten und Parameter müssen ja in unserem Fall auch übertragen werden. Und da hängt halt auch ein SPI Master Modul dran. Die Software schreibt und liest dann nur Register der Firmware, ganz ähnlich wie die Register des SPI Controllers an einem Microcontroller.
Ah ok, so stelle ich mir das auch vor. Da kommen Daten am FPGA an und da ist erstmal unklar was das ist. Da braucht man dann irgendein Protokoll, ich habe das bisher so gemacht, dass das erste Byte nach einer Pause die Startadresse ist, das zweite Byte wird dann in das Register dieser Adresse geschrieben und bei jedem weiteren Byte wird die Adresse automatisch erhöht. Das funktioniert prima. Für das Flash würde ich auch eine Adresse nehmen und wenn dann ein bestimmter Wert kommt, dann werden alle folgenden Bytes in das Flash geschrieben. Aber ic glaube ich lasse das, die bisherige Lösung mit JTAG und Vivado ist einfach zu bequem. Hast Du auch Erfahrung mit dem FT600? Bei dem FX2/3 muss man sich glaube ich um irgendwelche Endpoints und so kümmern, da muss man bei FTDI nix machen, das ist auf PC-Seite total einfach. Das Timing beim FX3 soll ja recht knapp sein, beim FT2232H geht das eigentlich wenn man es mit Statemachine baut.
Nee, da wir eine eigene VID/PID haben und den WinUSB Treiber nehmen, ist uns der FX3 lieber. FTDI ist schön aber wir wollten auf keinen Fall von deren Treiber abhängig sein. Um WinUSB kümmert sich MS, das klappt. Timing ist eng, aber machbar. Wir schaffen aber am Artix zumindest keine 100MHz, da.gibts Fehler bei den Flags. Man hat glaube ich nur 2ns Zeit um das Flag abzufragen. 83.333MHz klappt prima und erzeugt mehr Datenrate als die meisten Host Controller können. Gabs nicht eher bei den ersten FT2232 Schwierigkeiten mit den 60MHz und den Flags? Da war doch was dass man das Timing gar nicht schaffen konnte. Aber ich glaube das ist besser geworden. Ja die Endpoints muss/kann man selber definieren aber das ist kein Hexenwerk und es gibt fertige Beispiel Firmware. Allerdings braucht man halt eine eigene VID.
Christian R. schrieb: > FTDI ist schön aber wir wollten auf keinen Fall von > deren Treiber abhängig sein. Um WinUSB kümmert sich MS, das klappt. Die offene libftdi läuft auch unter Windows. Allerdings wird es ab Windows10 recht nervig mit der Treibersignierung, weiss nicht, wie gut Tools wie Zadig o.ä. das inzwischen aushandeln. Diese Krämpfe enden jeweils damit, dass sich der Kunde dann doch lieber erst mal auf eine Ethernet-Lösung einlässt.
Christian R. schrieb: > Gabs nicht eher bei den ersten FT2232 Schwierigkeiten mit den 60MHz und > den Flags? Da war doch was dass man das Timing gar nicht schaffen > konnte. Aber ich glaube das ist besser geworden. Also das geht schon wenn man genügend Register dazwischensetzt. Dann kann man das Timing sehr leicht einhalten. Aber wenn man dann die maximale Geschwindigkeit will müsste man eine Pipeline bauen. Also einem FIFO sagen, dass man lesen will, dann im nächsten Takt sind die Daten da und noch einen Takt später gibt man die auf die Pins zum FT2232H. Das hat also Latenz von ein paar Takten. Wenn da zwischenzeitlich TXE# auf high geht, der FT2232H also keine neuen Daten haben will muss man die Pipeline anhalten, bekommt aber trotzdem im nächsten Takt noch einmal neue Daten aus dem FIFO und muss das alles rückabwickeln wenn der FT2232H dann wieder Daten annimmt. Und auch bei dieser Rückabwicklung kann der plötzlich wieder aufhören Daten haben zu wollen, man kann also nicht einfach schonmal anfangen aus dem FIFO zu lesen damit am Ende der Rückabwicklung neue Daten da sind, sondern muss auch das irgendwie verkraften was passiert wenn das mehrmals unterbrochen wird. Ich habe das daher noch nicht als Pipelines geschrieben und komme auch nur auf 20 MBytes/s. Fitzebutze schrieb: > Die offene libftdi läuft auch unter Windows. Allerdings wird es ab > Windows10 recht nervig mit der Treibersignierung, weiss nicht, wie gut > Tools wie Zadig o.ä. das inzwischen aushandeln. Diese Krämpfe enden > jeweils damit, dass sich der Kunde dann doch lieber erst mal auf eine > Ethernet-Lösung einlässt. Hier mit Windows 10 und der D2XX Lib von FTDI ist das kein Problem. Funktioniert wunderbar.
Achso. Na dann ist mir der FX3 noch lieber, da hatr man das Problem nicht. Klar, man muss schnell sein, aber man hat nicht diesen Hickhack mit schon gesendet oder eventuell doch nicht. Aber vielleicht ist das auch abhängig von der Implementierung. Beim FTDI hatte mich extrem gestört, dass der 60MHz ausgegeben wird, und man den nicht selber vorgeben kann, da hat man dann wenig Möglichkeiten. Fitzebutze schrieb: > Die offene libftdi läuft auch unter Windows. Allerdings wird es ab > Windows10 recht nervig mit der Treibersignierung, weiss nicht, wie gut > Tools wie Zadig o.ä. das inzwischen aushandeln. Diese Krämpfe enden > jeweils damit, dass sich der Kunde dann doch lieber erst mal auf eine > Ethernet-Lösung einlässt. Unsere Kunden erwarten dass wir die paar Hundert Euro alle 3 Jahre für eine eigene digitale Signatur ausgeben. Wobei man die bei WinUSB nicht mal unbedingt bräuchte.
Christian R. schrieb: > Gabs nicht eher bei den ersten FT2232 Schwierigkeiten mit den 60MHz und > den Flags? Da war doch was dass man das Timing gar nicht schaffen > konnte. Aber ich glaube das ist besser geworden. Hab spaßeshalbr mal geschaut, das ist ja immer noch zu knapp. Doof. Im Sync FIFO Mode hat man im Worst Case nur 1,52ns Zeit für TXE sampeln und im Voll-Fall Pipeline anhalten: T1 - T11(max) - T12(min) = 1.52ns. Wie soll man das sinnvoll umsetzen? Beim FX2 kann ich wenigstens den Takt extern reingeben, bei den 48MHz wäre es auch so knapp, aber selbst im 8 Bit Mode reichen ja noch 40MHz, da hab ich 5,1ns Zeit. Das kriegt man locker hin. Wir nutzen immer 16 Bit Mode und 25MHz, da ist das alles entspannt. Beim FX3 ist es ja ähnlich.
Gustl B. schrieb: > Hier mit Windows 10 und der D2XX Lib von FTDI ist das kein Problem. > Funktioniert wunderbar. Klar, wenn du die standard VID/PID nutzt. Bei uns nicht der Fall, da ist ein Zertifikat nötig. Und es ging auch um die freie libftdi. Die D2XX macht unter gewissen Umständen dank eines womöglich gut gemeinten Threading-Ansatzes Murks, gerade wenn es um den vollen Durchsatz geht. Da ist bei FTDI leider so einiges "broken by design".
Christian R. schrieb: > Hab spaßeshalbr mal geschaut, das ist ja immer noch zu knapp. Doof. > Im Sync FIFO Mode hat man im Worst Case nur 1,52ns Zeit für TXE sampeln > und im Voll-Fall Pipeline anhalten: T1 - T11(max) - T12(min) = 1.52ns. > Wie soll man das sinnvoll umsetzen? Das geht schon, man weiß eben immer erst im nächsten Takt ob die Daten angenommen wurde. Daraus kann man sich eine FSM basteln die dann sehr einfach ist wenn einem 1/3 der maximalen Datenrate genügt oder die sehr komplex ist wenn man möglichst in jedem Takt schreiben will in dem TXE# low ist.
Fitzebutze schrieb: > Die D2XX macht unter gewissen > Umständen dank eines womöglich gut gemeinten Threading-Ansatzes Murks, > gerade wenn es um den vollen Durchsatz geht. Da ist bei FTDI leider so > einiges "broken by design". Das hatten wir so ähnlich auch, als wir ganz am Anfang den Cypress Treiber benutzt hatten. Der hat dann immer die asynchronen Transfers durcheinander gewürfelt. Mit WinUSB gibt's da zum Glück keinerlei Probleme, und das Ding ist komplett transparent, ging auch dann auf Anhieb mit dem FX3 mit voller 3.0 Geschwindigkeit.
So, es ist vielleicht so weit, dass ich jetzt mal mit dem FT600 etwas baue. Daher eine Bonusfrage: Für den FT600/FT601 gibt es auch sowas wie das FT_Prog. Funktioniert das, wenn ich den FT600 nur an die Superspeed Leitungen hänge oder braucht das die USB2 Verbindung? Aus dem Datenblatt https://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT600Q-FT601Q%20IC%20Datasheet.pdf und der Dokumentation zu dem Konfigurationstool https://www.ftdichip.com/Support/Documents/AppNotes/AN_370%20FT60X%20Configuration%20Programmer%20User%20Guide.pdf geht das nicht hervor. Ich vermute das geht über die USB2 Verbindung, siehe Blockschaltbild. Vielen Dank! Mein Plan B wäre einen USB2 HUB auf die Platine zu setzen. Also einmal USB2 an den FT2232 und einmal an den FT600. USB3 nur an den FT600. Den USB HUB CY7C65634 habe ich jetzt auf einer anderen Platine vorgesehen, ist aber noch nicht da, den werde ich sowieso mal testen, lässt sich im QFN-28 Package auch sehr platzsparend layouten.
:
Bearbeitet durch User
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.