mikrocontroller.net

Forum: FPGA, VHDL & Co. USB direkt im FPGA - Erfahrungen?


Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fitzebutze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fitzebutze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-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.

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fitzebutze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fitzebutze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-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.

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fitzebutze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fitzebutze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.