FT2232H sync fifo garbage output

[tobias (Gast)]

Hallo,

ich versuche einen FT2232H über den synchronen FIFO Mode mit einem FPGA 
zu verbinden um zum FPGA Daten zu senden. Mein Problem ist, das bei dem 
FT ständig irgendwelcher Datenmüll raus kommt und zudem das RXF# 
(scheinbar) verzögert ist.

Ich habe über FT_PROG den FIFO Mode aktiviert und sehe auch im Logic 
Analyzer den 60MHz Takt.

Für mein Testsetup habe ich OE# und RD# konstant auf Ground gezogen. 
SIWU# und WR# sind konstant auf VCC. Somit sollte ich in der Lage sein 
Readbursts zu erzeugen die ich dann mit dem Logic Analyzer lesen kann. 
Ich habe sonnst nichts an den FT angeschlossen. Nur den Logic Analyzer 
ohne FPGA.

Ich habe das Beispiel in TN_167_FIFO_Basics verwendet mit einer kleinen 
Modifikation: Ich erzeuge ein Array mit 32 Elementen, die ersten 16 
Elemente werden von 0-15 durch nummeriert und die letzten 16 sind 0. 
Somit bin ich in der Lage einfach zu verifizieren, ob die gesendeten 
Daten korrekt sind.

Ich habe ein Screenshot von meinem Logic Analyzer hochgeladen (die 
letzten drei Bits vom Datenbus fehlen, da ich nur 8 Ports habe, soll 
aber nicht weiter stören). Man sieht die Wellenformen, wo das RXF# noch 
high ist, das die korrekten Daten (scheinbar) empfangen wurden. 
Zumindest würde ich genau das auf dem Bus erwarten, wenn RXF# auf low 
geht.

Die Realität sieht aber anders aus. Ich lese für x Takte in dem 
Readburst einfach irgendwas, die letzten 32 Takte von dem Burst sehen 
aber meist ganz gut aus, so das ich dann meine Daten wieder erkenne.
Ich habe auch schon mit FT_Purge() versucht die FIFOs zu clearen, 
allerdings ohne erfolg. Wenn ich die gleichen Daten ein zweites mal 
sende (2. Readburst), bekomme ich etwas, was halbwegs nach dem aussieht, 
was ich erwarte, aber trotzdem nicht korrekt ist.

Jetzt bin ich natürlich etwas ratlos. Ich hätte nicht erwartet, das man 
da so viel falsch machen kann, und mir fehlt auch tatsächlich die 
Fantasie, was da falsch ist und frage daher, was ich da falsch gemacht 
haben könnte :(

Hier auch der Code:

int main(int argc, char *argv[])
{
    FT_HANDLE fthandle;
    FT_STATUS status;
    status = FT_Open(0, &fthandle);
    if(status != FT_OK)
    {
        printf("open status not ok %d\n", status);
        return 0;
    }
    status = FT_ResetDevice(fthandle);
    if(status != FT_OK)
        printf("reset status not ok %d\n", status);
    UCHAR Mask = 0xFF; // Set data bus to outputs
    UCHAR mode = 0;
    UCHAR mode1 = 0x40; // Configure FT2232H into 0x40 Sync FIFO mode
    status = FT_SetBitMode(fthandle, Mask, mode); // reset MPSSE
    status = FT_SetBitMode(fthandle, Mask, mode1); // configure FT2232H into Sync FIFO mode
    FT_Purge(fthandle, FT_PURGE_TX | FT_PURGE_RX);
    if(status != FT_OK)
        printf("mode status not ok %d\n", status);
    DWORD data_written;
    static UCHAR data_buf[32] = {0};
    for (int i = 0; i < 16; i++)
    {
        data_buf[i] = i;
    }
    status = FT_Write(fthandle, &data_buf, 32, &data_written);
    status = FT_Write(fthandle, &data_buf, 32, &data_written);

    if(status != FT_OK)
        printf("status not ok %d\n", status);
    else
        printf("output data \n");
    status = FT_Close(fthandle);
    return 0;
}

Grüße
Tobias

[Gustl B. (-gb-)]

Ja TXE# und RXF# reagieren etwas spät, das muss man korrekt auswerten. 
Und sonst wenn RXF# high ist ... dann ist doch schlicht nicht definiert 
was auf dem Bus ist. Das musst du ignorieren. Könnte hochohmig sein oder 
so, dann sieht man da auch Flanken.

Daten sind nur sicher valide wenn RD# und RXF# zur steigenden Flanke von 
CLKOUT low sind.

[tobias (Gast)]

Gustl B. schrieb:
> Ja TXE# und RXF# reagieren etwas spät, das muss man korrekt auswerten.
Was heißt etwas spät? Wenn RXF# low ist zur steigenden Flanke, dann 
erwarte ich korrekte Daten. Was kann ich da anders auswerten? Das es ein 
wenig Zeit braucht (max 9ns), habe ich im Datenblatt gelesen, aber bis 
zur steigenden Flanke sollte es sich doch stabilisiert haben.

> Und sonst wenn RXF# high ist ... dann ist doch schlicht nicht definiert
> was auf dem Bus ist. Das musst du ignorieren. Könnte hochohmig sein oder
> so, dann sieht man da auch Flanken.
Logisch, wahrscheinlich ist das wirklich Zufall, trotzdem haben die 
Zufallsdaten da die Werte, die ich erwarten würde, wenn RXF# low ist. Es 
erspart mir gerade nur das manuelle Zeichnen :)

> Daten sind nur sicher valide wenn RD# und RXF# zur steigenden Flanke von
> CLKOUT low sind.
Und genau das ist mein Problem. RD# ist dauerhaft auf low, was korrekt 
sein sollte, wenn ich bursten will. RXF# sollte dann 32 Takte low sein 
und meine 32 bytes an Daten ausgeben. In der Realität bleibt es aber für 
hunderte Takte low und sendet irgendwas.

[Gustl B. (-gb-)]

Dann würde mich die Hardwarebeschreibung interessieren. Der Bus ist ja 
bidirektional, da kann man auch Konflikte bauen ...

Wenn du das HDL hier anhängst simuliere ich dir das gerne.

[tobias (Gast)]

Das ist sehr nett, aber sowas habe ich noch nicht. Ich habe erstmal mit 
der Software angefangen um den Chip ein wenig kennen zu lernen. Ich habe 
hier das FT2232H Mini Module.

Wie gesagt, OE# ist konstant auf low, habe daher keine Bus turnarounds. 
WE# ist konstant auf high um das Schreiben zu unterbinden. RD# ist 
konstant auf low um Readbursts zu simulieren.

Müsste das nicht im synchronen Modus ausreichend sein?

Sonnst sollte es sich ja recht simpel auf einen AXI Stream bus mappen 
lassen, s_tvalid = !RXF#, RD# = !s_tready und s_tdata = data. Dazu noch 
ein FIFO fürs Clock Domain Crossing und der Prototyp sollte laufen.