Hallo! Ich habe das Mini Modul mit dem FT2232H von FTDI. Es soll im synchronem FIFO Modus betrieben werden. Verbunden ist das Ganze mit dem Xilinx ML507 mit einem Virtex-5 FPGA drauf. Das Konfigurieren des FT2232H per FTD2XX lib funktioniert tadellos. Nach dem Setzen des Bit Modes wird der Clock aktiviert. Auch das Schreiben und Lesen haut prinzipiell hin. Jedoch nur teilweise. Wir haben zwei Dinge versucht. 1. Der 60 MHz Clock des FT2232H wird direkt als Clock für das Design im FPGA verwendet. Hier entstehen aber Timing Probleme. Am Oszi konnten wir verfolgen, dass die Signale richtig gesetzt werden. Am PC kommen jedoch ein paar falsche Byte an. 2. Der 60 MHz Clock wird mittels DCM im FPGA phasenverschoben. Somit können wir das Timing anpassen und die Zeiten werden eingehalten. Jedoch geht dann schon im FT2232H in Byte verloren. Da bei zB 10 Byte nur 9 am PC ankommen. Wir haben folgenden Aufbau: Der PC sendet zB 10 Byte zum FT2232H. Der FT2232H setzt RXF# low. Der FPGA setzt im nächsten Cycle OE# low und im darauffolgenden Cycle RD# für einen Clock-Cycle auf low. Danach gibts einen Cycle Delay und das zuvor gelesene Byte wird wieder mit WR# zurückgeschrieben und vom PC gelesen. Und das Ganze soll zB 10 Mal passieren. Quasi eine Art Streaming wobei der FPGA jedes Byte verarbeiten soll. Wir haben auch festgestellt, dass der Clock des FT2232H einen ordentlichen Jitter aufweist, der jedes Mal, wenn OE# auf low gesetzt wird, schlimmer wird - was dem DCM gar nicht gefällt. Hat irgendjemand Erfahrung mit diesen Timing-Angelegenheiten am FT2232H bzw. warum der Clock auf OE# reagiert. Oder hat jemand einen Tip, ob es mit DCM oder ohne besser gehen sollte? Ich wäre für alle Anregungen dankbar. Beste Grüße Johannes
Hmm. Leider kann ich Dir nicht helfen. Ich habe FT2232H sowohl im sync als auch im FIFO Mode mit einem Altera FPGA (Cyclone III) ausprobiert und muss sagen, dass es auf Anhieb geklappt hat. Ich musste weder die Phase schieben, noch sonst was (nur richtig contraint und das war's). Geblieben bin ich beim FIFO mode, aber aus anderen Gründen. Grüße, Kest
Johannes schrieb: > Wir haben auch festgestellt, dass der Clock des FT2232H einen > ordentlichen Jitter aufweist, der jedes Mal, wenn OE# auf low gesetzt > wird, schlimmer wird - was dem DCM gar nicht gefällt. > > Hat irgendjemand Erfahrung mit diesen Timing-Angelegenheiten am FT2232H > bzw. warum der Clock auf OE# reagiert. Oder hat jemand einen Tip, ob es > mit DCM oder ohne besser gehen sollte? Das die Xilinx DCM auf zu großen Input-Jitter allergisch reagieren habe ich auch schon gehört. Mit dem FT2232H habe ich mich noch nicht näher befasst (auch wenn er schon in meiner Bastelkiste liegt). Wie wäre es, wenn ihr dem FT2232H seinen Takt laßt und dem FPGA einen eigenen Takt gebt. Dazwischen packt ihr (in beide Richtungen) ein asynchrones FIFO. So sollte es funktionieren. Duke
1. Wie hoch ist denn den Jitter wirklich? Wie habt ihr das gemessen? Hat Euer Messgerät auch genügend Bandbreite? Ich kann den Clock des FT2232H mit einem Logikanalysator untersuchen. Dieser kann das Clocksignal mit 2GHz abtasten. Ich kann dann mal ein paar Bilder online stellen. Aber ich bin der Meinung das es nicht so viel ist wie Du behauptest. 2. So viel ich weiß verwendet der FT2232H doch einen externen Quarz. Hast Du schon mal überprüft ob dieser einwandfrei funktioniert? 3. Hast Du eine eigene Platine erzeugt oder verwendest Du das mini Module (Evaluation Board) von FTDI? 4. Bis jetzt habe ich nur den sync. FIFO Mode verwendet. Ich habe einfach das FTDI-Mini-Module gekauft, die WR# Leitung auf GND gelegt, somit sendet der FTDI-Chip ständig Daten. Jetzt kann man die TXE-Leitung untersuchen. Bis jetzt benötigte der FTDI Chip "nur" 1ms Pausen bis die Übertragung zum PC abgeschlossen war. Dies muss ich jedoch noch mal genauer untersuchen, daher immer einen ausreichend großen FIFO als Ausgabepuffer verwenden. Durch das Dauersenden habe ich eine Datentransferrate von bis zu 32MByte erreicht. (leider sind keine 40MByte möglich) Hier mal ein Link: Beitrag "FTDI USB erzeugt Blue Screen" Man muss dringend aufpassen das man auf der PC-Seite den FTDI-Chip richtig konfiguriert, da sonst die Daten nicht fehlerfrei übertragen werden. Laut FTDI muss unbedingt die FT_SetFlowControl() Funktion verwendet werden da es ansonsten zu Datenverlusten kommt.(siehe Seite 4 in Application Note AN_130 von FTDI) Das was ich noch nicht hinbekommen habe ist den Datenbuffer auf PC Seite mit Hilfe der zu vergrößern. Dieser ist halt sehr klein und läuft dadurch schnell über. Laut FTDI soll es gehen ab leider nicht bei mir :-) Die Treiberversion 2.06.02 erzeugt bei mir unter WinXP 32 Bit und Windows Vista 64Bit Blue Screens. Wemm ich das gleiche Programm verwende und den Treiber 2.06.00 verwende, dann erhalte ich keine Blue Screens. Jedoch steht beim Treiber 2.06.00 das Daten verloren gehen sollen und dies mit der neuen Variante behoben wurde.
So ich habe mal die Jitter vom FTDI Clock vermessen. Die Ergebnisse sind im Bild gut zu erkennen. Ich habe die Messung mehrfach durchgeführt und die Ergebnisse sind identisch. Die Auflösung des Logikanalysators liegt bei 125ps(8GHz) Da der Jitter +- 125ps beträgt denke ich mal das dieser noch deutlich geringer ist. Nur leider kann ich nicht genauer messen. Vielleicht hat ja jemand ein Messgerät welches besser ist :-) Die Ergebnisse sind im Anhang gut zu erkennen.
Mit dem neuen Treiber 2.08.02 habe ich eine Übertragungsgeschwindigkeit in Richutung PC von 40MByte pro Sekunde erreicht.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.