Forum: FPGA, VHDL & Co. FPGA zum PC über USB, FX2 oder FT2232H?


von Gustl B. (-gb-)


Lesenswert?

Hallo, ich möchte für ein Projekt Daten vom FPGA zum PC schicken und 
benötige zwingend mehr als 22 MByte/s.

Bisher habe ich immer nur UARTs verwendet, das war einfach aber jetzt 
brauche ich was Anderes und stehe vor der Wahl der Hardware. Ich möchte 
das sowohl von FPGA Seite aus möglichst einfach bedienen können, da 
sieht das von FTDI ganz schick aus, aber auch die Software am PC sollte 
möglichst einfach sein. Ich kann zwar ein bischen C aber eben nicht viel 
und die Code Schnipsel von FTDI sind nicht wirklich das was man will. 
Gibt es da eine Anlaufstelle für Demo Code wie man von der Schnittstelle 
liest oder darauf schreibt? Ich will das verwenden aber eigentlich kein 
Rad neu erfinden, mir reicht schon der FPGA Teil.

Was könnt ihr mir empfehlen? Mit was kommt man einfach zum Ziel?

Vielen Dank!

von Strubi (Gast)


Lesenswert?

Moin,

ist das nicht schon ein vielgeposteter Klassiker?
Wenn Dir Bulk-Transfer reicht und du einen Spartan6 oder äquivalent 
hast, ist der 2232H ev. ausreichend und wohl am einfachsten anzusteuern. 
Bin mir aber bei den 22 MB/s nicht sicher, da musst du ev. mit der 
libusb-1.0 was von Hand zusammenstiefeln, die Performance der FTDI-libs 
ist nicht sonderlich gut. Beim 2232(H) musst du allenfalls (je nach 
FPGA) mit den FIFO-Timings aufpassen, hier gibts dazu einige Berichte.
Mit dem Cypress FX2 kommst Du nahe 48 MB/s, aber der 8051 will erst mal 
programmiert werden. Da findest Du allerdings eine Menge Code z.B. bei 
GnuRadio.
Der FX2 ist recht robust und das FIFO-Interface etwas durchdachter, mit 
dem Chip kann man allgemein sehr viel machen (Endpoints rel. frei 
implementieren).
Wenn du nicht puffern kannst, wie z.B. bei Kameradaten, dann geht nur 
isochron und du musst mit Datenverlust klarkommen. Die isochronen Queues 
zu programmieren ist auch so ne Sache, das ist unter Windows auch 
weniger witzig/robust. Unter Linux hast du da mehr Debug-Möglichkeiten, 
gerade wenn z.B. dein Chipsatz rummuckt.

Gruss,

- Strubi

von Gustl B. (-gb-)


Lesenswert?

Genau vor dem Firmware Dingens schrecke ich etwas zurück. Gibt es da 
kein Default das man auf das EEPROM des FX2 schreibt und dann kann man 
dem über das Slave FIFO die Daten überreichen? Aber gut dann werde ich 
mir den mal angucken, hier an der Uni haben den auch schon Leute im 
Einsatz.

Also puffern kann ich schon aber halt nicht sooo irre viel. So 100 
kBytes werden wohl drinnen sein. Verwenden will ich einen dickeren 
Artix. Die Daten kommen zwar nicht von einer Kamera aber auch von einem 
bilderzeugenden Gerät, einem Transmissionselektronenmikroskop. Beim UART 
kann man einfach in Python die Schnittstelle aufmachen und Daten lesen, 
das hätte ich auch gerne in möglichst einfach in C mit dem FX2. Mal 
einlesen und Code suchen ...

von Christian R. (supachris)


Lesenswert?

FX2 Firmware ist nicht wild, such mal hier im Forum nach meinen 
Beiträgen, ich hatte eine Slave Fifo Firmware gepostet. Wir haben mit 
dem FX2 und FX3 keine Probleme. Im FPGA reicht eine simple State 
Machine.
Wir arbeiten mit dem WinUSB Treiber weil damals der LibUSB Treiber noch 
nicht signiert war. Mit genug Buffer schafft man 42MB/s BULK IN.

von Gustl B. (-gb-)


Lesenswert?

Also ich habe hier leider kein Board mit FX2, das Nexys4 hat zwar einen 
FT232H aber da ist nur der UART mit dem FPGA verbunden ... naja ich hab 
hier auch noch zwei UM232H Platinen, also mit FT_Prog auf 245 FIFO und 
D2xx eingestellt, aber: Das Modul gibt nichtmal den Takt aus.

Hab da auch mit pyusb mal rumgestochert und kann die Endpoints auflisten 
lassen, finde also das Gerät, aber das bleibt irgendwie stumm ... naja 
erstmal Wochenende^^.

Wenn ich etwas Budget bekomme zum spielen werde ich mal den Cypress 
Stein ausprobieren, von ZTEX gibt es da ordentlich Beispiele.

Edit: Hab doch noch ein altes Basys von Digilent da mit einem 
CY7C68013A. Also ISE auspacken ...

: Bearbeitet durch User
von Johann (Gast)


Lesenswert?

Ich habe auch mit dem FT2232H so um die 45MByte/s mit den von FTDI 
bereitgestellte API geschafft. Der Aufwand war eigentlich sehr gering.

In Labview selber war das Empfangsprogramm schon nach 30 Minuten fertig 
gewesen. In C gibt es auch die gleichen Beispiele.


Ich würde jedoch aber lieber zu FT60X raten. Dieser basiert auf USB3 und 
hat genau wie der FT2232H ein paralleles Interface. Einfach Daten 
anlegen und Clock und Write Signal anlegene und schon werden die Daten 
übertragen.

USB 3 hat einen entscheidenen Vorteil es gibt für das Senden und 
Empfangen der Daten je eine separate Leitung das ist leider bei USB 2.0 
nicht so. Daher ist man immer auf dem Host (PC) angewiesen wann er eine 
Anfrage an den Client stellt (hast Du Daten für mich wenn ja bitte 
senden)

Daher benötigt man bei USB 2.0 meist noch einen möglichst großen 
Zwischenspeicher damit keine Daten verloren gehen. Die FPGAs selber 
haben nicht besonders viel RAM intern so das Du einen externen DDR 
Speicher benötigst. Dies macht die Umsetzung schon viel aufwendeiger.

Daher würde ich eher zum USB 3.0 Chip raten hier kannst Du die Daten 
einfach schreiben und sofern das Paket fertig ist wird es auch gleich 
übertragen.

von Johann (Gast)


Lesenswert?

Preislich hält sich das auch noch in Grenzen

bei 100 Stück kostet der FT2232H ca. 5,4$ und der FT600 ca. 7,8$

Wenn Du jedoch noch den DDR RAM beim FT2232H hinzunimmst dann ist die 
ISB 3 Lösung deutlich günstiger. Auch der Cypress FX2 hat das gleich 
Problem das liegt am USB 2.0 Standard. Hier gibt es leider keine 
separate RxD und TxD Leitung so wie Du es von der UART umsetzung kennst. 
Dies wurde erst wieder mit der USB3.0 eingeführt.

Du must auch kein bedenken haben das der USB 3.0 Chip zu schwer ist von 
der Anstererung. Wenn Du willst kannst Du auch nur einen Takt von 50MHz 
an den Chip anlegen. Du benötigst ja nicht die vollen 400MByte/s :-)

Es gibt den FTDI FT60X als TF600 und FT601. Der Unterschied ist die 
breite des Datenbusses. Beim FT600 ist der Bus 16 Bit breit und beim 
FT601 ist der Bus 32Bit breit. Demnach benötigst Du beim FT601 auch nur 
die halbe Frequenz.

von -gb- (Gast)


Lesenswert?

Vielen Dank! Jetzt mal ne blöde Frage: Wieviel muss man denn da puffern? 
Ich dachte so maximal 100 kByte sollten reichen. Braucht man da mehrere 
MBytes? Du sprichst von externem DRAM ...

von Christian R. (supachris)


Lesenswert?

Kommt halt drauf an wie dein Datenstrom aufgebaut ist. Wenn das BULK 
ist, kommen die Daten ja immer an, aber kann halt mal etwas dauern, 
Windows ist manchmal stark beschäftigt. Wir haben durchaus Pausen von 
mehreren 100ms gemessen.

von Gustl B. (-gb-)


Lesenswert?

HM HM. Also der FT232H sieht mir am einfachsten aus, lesen und schreiben 
will ich gar nicht, mir reicht wenn ich  dauerhaft ca. 25MB/s zum PC hin 
schaffe. Mal gucken ob das klappt und ob da ein kleinerer BlockRAM FIFO 
reicht um Verluste zu vermeiden. Vielleicht ist das unter Linux auch 
schon besser.

von Ich (Gast)


Lesenswert?

Gustl B. schrieb:
> Vielleicht ist das unter Linux auch
> schon besser.
Unter Linux ist das definitiv besser. Wir haben einem FPGA mit FT2232H 
256 MBit SDRAM als Ringpuffer spendiert, damit die Kiste unter Windows 
zuverlässig läuft. Für Linux haben die paar k Blockram ausgereicht.

von Gustl B. (-gb-)


Lesenswert?

Krass also deutlich hätte ich mir den Unterschied nicht vorgestellt. 
Verwenden werde ich wohl einen dickeren Artix, brauche das BRAM aber 
auch für andere Dinge noch, so 100kB für den FIFO sind aber drinnen.

von berndl (Gast)


Lesenswert?

kannst dir ja mal das:
https://github.com/makestuff/libfpgalink/wiki/FPGALink

und das:
https://groups.google.com/forum/#!forum/fpgalink-users

anschauen. Ist 'ne schoene Library, die der Chris da zusammengebastelt 
hat. Und im FPGA ist es pures VHDL, geht also mit jedem Baustein. Fehlt 
nur die Synchronisation der knapp 50MHz USB CLK in die FPGA CLK Domaene, 
sind aber nur ein paar Register mit Handshake...

Laeuft bei mir seit ein paar Jahren mit einem Atlys (Spartan6) sowie 
einem RaspberryPi 1 zuverlaessig (Pi schafft so knapp 15MB/sec, PC 
muesste 40MB/sec schaffen)

von Christian R. (supachris)


Lesenswert?

Wir haben auch nur 128k oder 256k BlockRam dran und das geht auch unter 
Windows schnell und zuverlässig, wir erreichen knapp über 40MB/s im 
Mittel, bzw. knapp 300MB/s beim FX3 mit 80MHz Slave Fifo. 100MHz wollte 
nicht zuverlässig.  Die mehreren 100ms Pause sind Extremfälle. Wir 
arbeiten mit WinUSB und BULK Modus.

von Johann (Gast)


Lesenswert?

Ich habe auch einen Spartan 6 genommen und alle BlockRams für die 
Pufferung verwendet. Jedoch ist das einfach sehr wenig was die FPGAs als 
Speicher besitzen.

Wenn da mal 100ms Pause ist und das ist wirklich der Extremfall dann 
sind das bei 40MB/s 4MBtye Buffer die man benötigt. Es sei denn Du 
kannst damit leben das auch mal Daten verloren gehen, da Dein Ringbuffer 
so klein ist das er schon nach 5ms der erste mal komplett überschrieben 
wird.

Daher solltest Du als 1. klären ist es erlaubt das ab und Zu Daten 
verloren gehen. Manchamal ist es auch gut wenn du die Pakete aufsteigend 
mit Nummern versiehst um festzustellen ob Pakete verloren gehen. Zudem 
ist ein Zeitstempel sehr gut, da man oft den Zeitbezug bei der 
Messdatenverarbeitung benötigt.

Der FT60X funktioniert doch von der Ansteuerung sehr ähnlich wie der 
FT2232H dann kann man auch gleich USB3.0 verwenden und muss sich über 
den Buffer keine Gedanken machen :-)

von Christian R. (supachris)


Lesenswert?

Johann schrieb:
> Der FT60X funktioniert doch von der Ansteuerung sehr ähnlich wie der
> FT2232H dann kann man auch gleich USB3.0 verwenden und muss sich über
> den Buffer keine Gedanken machen :-)

Aber nur in der Theorie. Die volle Geschwindigkeit bekommt man auch bei 
3.0 nur wenn man viele Daten am Stück liefern kann, und das sind da noch 
viel mehr. Reicht bei 2.0 ein voller Microframe (10 bis 11 512 Byte 
Pakete) muss es bei 3.0 schon ein voll gepackter Burst aus 16 Paketen zu 
je 1024 Byte sein.

von Gustl B. (-gb-)


Lesenswert?

So, da bin ich wieder.

Mit dem FT232H bekomme ich ca. 31 MB/s hin unter Windows und mit C.
Unter Linux und mit C waren es in einem ersten Test nur 6 MB/s. Warum 
ich aber zu Windows gegangen bin ist, dass ich unter Linux nur manchmal 
das Gerät öffnen konnte. sprich meistens hab ich das zwar gefunden, 
konnte Seriennummer und so lesen, aber
ftStatus = FT_Open(0, &ftHandle);
hat nur sehr selten funktioniert.

Naja, mal weiter stochern und gucken ob die Daten auch ohne Verluste 
über die Leitung kommen.

von Gustl B. (-gb-)


Lesenswert?

Also mit einem 1 kByte FIFO fehlen doch einige Daten, ich tippe mal so 
auf ein paar Promille. Abes es fehlen nich einzelne Bytes sondern ganze 
Blöcke.

von Strubi (Gast)


Lesenswert?

Hi Gustl,

Gustl B. schrieb:
> Unter Linux und mit C waren es in einem ersten Test nur 6 MB/s. Warum

Hast du den FTDIchip per libft2xx für Linux angesteuert? Die ist mir als 
nicht sonderlich robust in Erinnerung und machte damals bei mir auch 
komisches Zeug, mal war sie schnell, dann wieder lahm. Irgend eine 
Timing-Sache. Mit der OpenSource-libftdi kriegt man die Performance nur, 
wenn man die Endpoint-Buffer immer schön gefüllt hat und die 
Latency-Timer nicht zuschlagen. Bei duplex (read/write)-Geschichten muss 
man da ab und an etwas versetzt arbeiten, z.B. erst mal zwei 
Frage-Pakete abschicken und erst dann die Antwort auf das erste 
einlesen. Dabei muss man die Puffergrösse beim FTDI immer etwas im Blick 
behalten.
Sonst sind die 31 MB aber mal doch schon stattlich. Das sollte in Linux 
ansich auch hinzukriegen sein, auf jeden Fall per isochronen Handbetrieb 
(aber das geht m.W. nicht mit libftdi).

Grüsse,

- Strubi

von Gustl B. (-gb-)


Angehängte Dateien:

Lesenswert?

Hallo, ja ich verwende die libft2xx, unter Windows macht die auch was 
sie soll. Aber ... ich habe gerade ein anderes Problem und kann das 
nicht so genau lokalisieren:

Also der FT232H gibt eine 60 MHz Clock aus zu der ich synchron die Daten 
anlegen muss und so, ok, ausserdem verwende ich sonst im FPGA eine 50 
MHZ Clock. Später im Projekt werden 8 1 MSps ADCs ausgelesen und 
zusammen mit zwei 11 Bit-Werten zum PC geschickt. Zusammen macht das 
also rund 22 Bytes und zwar jede us.

Also hab ich das jetzt alles mal geschrieben samt FIFO. Ich schreibe 
also alle 50 Takte der 50 MHz Clock 22 Bytes (= 176 Bits) in den FIFO.

Diese Daten generiere ich vorher so, dass hochgezählt wird. Also das 
erste mal haben die 22 Bytes die Werte 0, ... ,21, das nächste mal 22, 
... ,43 und so weiter bis dann ein Byte den Wert 255 hat und das nächste 
0. Aber immer zusammen als 22 Byte std_logic_vector.

Gut, immer wenn das FIFO nicht leer ist, dann lese ich aus der 60 MHz 
Domäne einen solchen 22 Byte Wert. Wenn ich auf den FTDI schreiben darf, 
also TXE = '0', dann schreibe ich da nacheinander die 22 Bytes raus.

Auf der Gegenstelle, am PC hab ich dann ein C programm geschrieben das 
das einfach alles liest und in eine Datei schreibt, und dann ein Python 
Sktipt, das das auf Fehler prüft.
Geprüft wird ob ein neues Byte um 1 größer ist als das vorherige. Und 
zwar wenn das neue Byte > 0 ist, also kein Sprung von 255 nach 0 
vorliegt.

Und da fallen doch einige Fehler raus. Weil ich nicht weiß wieso, hab 
ich ne Zeil lang im Nebel gestochert, mein VHDL editiert und geguckt ob 
ich da was machen kann. Im Simulator in der Waveform sieht das immer 
ganz gut aus. Aber das hat alles nichts gebracht und ich vermute 
irgendwie, dass es aber am FPGA-Teil liegt, denn manchmal wurden auch 
ganze 22-Byte Folgen wiederholt gesendet.
Egal, also die Python-Test-Dingens mit Textio in die Testbench gepackt 
und siehe da, dort gibt es keine Fehler (ausser am Anfang als ich mal 
TXE in der Testbench eine Zeit lang auf '1' habe, aber das liegt an der 
Form wie ich auf Fehler Prüfe).

Ich bin also mit meinem sehr sehr kleinen Latinum am Ende.
Wie seht Ihr das? Mache ich irgendetwas offensichtliches falsch? Sieht 
es OK aus aber Ihr würdet trotzdem was anders machen?

Ich verwende ein UM232H Modul mit FTDI, einen kleinen Spartan 6 und ISE.

Vielen Dank!

von Gustl B. (-gb-)


Angehängte Dateien:

Lesenswert?

Oh und in der Tat war da ein Fehler:

Die neue Testbench (die macht erratisch ab und zu das TXE für ne Zeit 
lang auf '1') wirft bei der alten Hardwarebeschreibung einen Fehler 
(wird ausgegeben), und zwar wenn beim letzten zu sendenen Byte (von den 
jeweils 22) das TXE auf '1' gegangen ist (also nicht mehr geschrieben 
werden darf). Da wird das letzte Byte (und WR) nicht gehalten bis TXE 
wieder '0' ist.

Mit der neuen Hardwarebeschreibung ist dieser Fehler weg. Auf Hardware 
hab ich das noch nicht getestet, bin gerade nicht zu Hause.

Ein Hoch auf den Simulator!

: Bearbeitet durch User
von Gustl B. (-gb-)


Lesenswert?

Und noch ein Edit: Jetzt konnte ich testen und habe weiterhin Fehler 
drinnen. Bin für jede Erkenntnis dankbar!

von Gustl B. (-gb-)


Angehängte Dateien:

Lesenswert?

Männo!

Habe das UM232H von FIDI an einen kleinen Spartan angeschlossen und 
erzeuge dort Daten. Es wird immer hochgezählt in dem zu sendenden Byte 
und es wird auch simuliert, dass manchmal keine neuen Daten kommen. Das 
klappt unter ISE in der Simulation ohne Fehler und auch auf Hardware 
ohne Fehler. Ok, manchmal sind in 100 MBytes mal ein oder zwei Fehler, 
aber das schiebe ich mal auf die Verkabelung. Wenn ich ohne simulierte 
Unterbrechung sende bekomme ich ca. 26 MB/s fast fehlerfrei in Windows. 
Also alles schick.

Jetzt hab ich, weil sich in meinem ISE der erzeugte FIFO (das wird eine 
Erweiterung zum Vorhandenen) irgendwie nicht einbinden lässt, das mal 
auf Artix und VIVADO umgebaut. Also Code ist fast 1:1 erstmal zum 
testen, nur die Pinzuordnung wurde angefasst. In der Simulation ist auch 
dort alles schick, nur auf der Hardware gibt es massig Fehler ... Board 
ist ein Nexys4, das hat leider nur diese PMODs und die sind oft nicht 
Clockcapable. Man.

Egal, angehängt habe ich das ISE Projekt. Da scheitere ich gerade daran 
den FIFO so einzubinden, dass es dann auch baut.
Wenn man da statt der lx9_FT245_0.vhd die 
lx9_FT245_0_20160617_halfrate.vhd verwendet, dann geht alles, aber ohne 
FIFO. Jo ich erzeuge da die Bytes sehr umständlich, weil ich dort das 
Lesen aus einem FIFO mit einem Takt Verzögerung simulieren möchte.

Vielen Dank für alle Ratschläge!

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
Noch kein Account? Hier anmelden.