Fehler in der Übertragung

[Lassmiranda Densiwillja (Gast)]

Hallo zusammen,

habe eine Kommunikation zwischen FPGA und PC. Die Kommunikation erfolgt 
mittels USB und dem FT2232H von FTDI. Ich betreibe den FT2232H in 
Synchronous FIFO Mode.

Habe zur Inbetriebnahme der Strecke einen 16Bit Vector den ich einfach 
nur inkrementiere (0....FFFF-0...FFFF). Wenn ich auf dem PC mir die 
Daten anschau die ankommen, hab ich immer folgenden Fehler:

35FE 35FF 3500 3601 3601...

Das MSB wird immer um eins zu spät inkrementiert...

Habt ihr eine Idee woran es liegen könnte?

Vielen Dank eure Ideen

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Lassmiranda Densiwillja schrieb:
> Habe zur Inbetriebnahme der Strecke einen 16Bit Vector
Welchen?
Was wird wie von wo nach wo übertragen?

> Habt ihr eine Idee woran es liegen könnte?
Das ist vermutlich ein Problem mit der Byte-Reihenfolge und/oder 
Little/Big-Endian. Wenn du die Zuordnung der Bytes und die Endianess 
umsortierst, passt es:
35FD 35FE 35FF 3500 3601 3602...

  FD 35 FE 35 FF 35 00 36 01 36 02 36...

FD35 FE35 FF35 0036 0136 0236...

35FD 35FE 35FF 3600 3601 3602...


BTW:
Meine VHDL-Dateien heißen *.vhdl mit Nachnamen.
Meine C-Dateien heißen *.c!
Warum heißen deine Dateien alle *.txt?

[Lassmiranda Densiwillja (Gast)]

Hey,

hab die Dateien in einem Texteditor zwischengespeichert... Im Orgnial 
enden sie auch mit *.vhd bzw. *.cpp

Der Addierer sitzt vor dem DCFIFO (Mit unterschiedlichen Eingang und 
Ausgang Breiten)
Code für den Addierer ist jetzt untenstehend. Den Code zum FIFO hab ich 
via MegaWizard erstellen lassen und alles über Schematic miteinander 
"verbunden".

Hab einen 16 Bit Addierer im FPGA beschrieben, der alle 150ns um zwei 
inkrementiert.

entity S2P_Sync is
generic (width : natural := 16); 
port (main_clk : in std_logic; --Main_clk 100MHz
      wrreq : out std_logic;
      DCFIFO : out std_logic_vector (width-1 downto 0));
end S2P_Sync;

architecture behavirol of S2P_Sync is
type states is (idle, Data0, Data1);
signal FSM1 : states := idle;
signal intdb0: std_logic_vector (width-1 downto 0) := (others=>'0');
signal dummy : integer range 0 to 50 := 0;

begin
process begin
 wait until rising_edge(main_clk);
 dummy <= dummy + 1;
 if (dummy = 15) then
  dummy <= 0;
 end if;
end process;



process  begin
 wait until falling_edge(main_clk);
 case FSM1 is
  when idle => if (dummy=15) then
                FSM1 <= Data0;
                intdb0 <= intdb0 + '1'; 
               end if;
               wrreq <= '0';
  when Data0 => FSM1 <= Data1;
                intdb0 <= intdb0 + '1';
                DCFIFO <= intdb0;
                wrreq <= '1';
  when Data1 => FSM1 <= idle;
                DCFIFO <= intdb0;
                wrreq <= '1';
  when others => null;
 end case;
end process;

Bzgl deiner vermutung hatte ich auch schon die Idee, dass das Problem 
auf PC Seite ist da ich davor mit einem 8 Bit Addierer es versucht hatte 
und keinerlei Fehler hatte und als ich auf 16Bit umgestiegen bin kam das 
Problem...
Wenn ich im C++ Programm mir mittels Breakpoint die Werte anschaue, die 
in dem "RxBuffer" sind stimmt die Reihenfolge leider wie die Daten 
reinkommen und ausgegeben werden...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

 wait until rising_edge(main_clk);
  :
 wait until falling_edge(main_clk);

Warum unterschiedliche Takte?

Dir ist klar, dass ich diese Zeilen:

  when Data0 => FSM1 <= Data1;
                intdb0 <= intdb0 + '1';
                DCFIFO <= intdb0;
                wrreq <= '1';

ohne jegliche funktionelle Änderung auch so schreiben kann:

  when Data0 => FSM1 <= Data1;
                DCFIFO <= intdb0;
                intdb0 <= intdb0 + '1';
                wrreq <= '1';

Kann das deinen FIFO durcheinanderbringen?
Immerhin wird da ja zwischen Data0 und Data1 unterschieden.

BTW: was sagt denn deine Testbench zu diesem Problem?

[Lassmiranda Densiwillja (Gast)]

Die Daten werden bei dem DCFIFO auf steigende Flanke "übernommen" und 
damit die Daten "stabil" anliegen schreib ich sie auf fallende Flanke 
raus und auf steigende übernehm ich sie in den DCFIFO...

Wo genau liegt der unterschied in deiner Beschreibung von dem "state" zu 
meiner? Bzw. was für einen Vorteil hat deine?

Testbench sagt das es funktioniert...

Wenn ich im C-Code die Indexe (RxBuffer[p] RxBuffer[p+1]) zum Auslesen 
des Buffers ändere auf RxBuffer[p+1] und RxBuffer[p+2] ist das Problem 
mit der Zuordnung weg allerdings hab ich jetzt das Problem das 
zwischendrin ein Byte verloren geht und die Zuordnung nimmer stimmt und 
dann das MSB und LSB vertauscht sind...

[Lassmiranda Densiwillja (Gast)]

Mir ist gerade noch aufgefallen beim lesen des Fehlerreports das immer 
nach ca. 2**16 Bytes der Datenverlust eintritt...

Ich habe die InTransferSize des FT2232H auf 2**16 eingestellt. Kann es 
sein, dass wenn der "InTransferBuffer" voll ist es zu einem Überlauf 
kommt und ich Daten verliere?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Lassmiranda Densiwillja schrieb:
> und ich Daten verliere?
Vermutlich genau 1 Byte...

[Lassmiranda Densiwillja (Gast)]

Jain es ist unterschiedlich hab mal unten den "Fehlerreport" angehängt.

Fehler : 60b9    5fb9    1029
Fehler : 61b9    60b9    1030
Fehler : 62b9    61b9    1030
Fehler : 63b9    62b9    1030
Fehler : 64b9    63b9    1030
Fehler : 65b9    64b9    1030
Fehler : b966    65b9    1030
Fehler : b966    65b9    1030
Fehler : 3966    3964    2340
Fehler : b966    b964    3651
Fehler : 3966    3964    4962
Fehler : b966    b964    6272
Fehler : 3966    3964    7583
Fehler : b966    b964    8894
Fehler : 3966    3964    10204
Fehler : 0cd1    5ac6    10546
Fehler : 0cd3    0cd1    10546
Fehler : 6b71    6b6f    11515
Fehler : f96f    8c51    11852

Der erste Wert der steht ist der "neue Wert" der mittlere Wert ist der 
"alte Wert" und rechts steht die Zeile in der sich der Fehler befindet. 
Jede Zeile umfasst 25 Werte.

Bis Zeile 1030 hab ich die MSB-LSB vertauschung und dann verliere ich 
eine ungerade Anzahl an Bytes welche mir dann die MSB-LSB vertauschung 
wieder aufhebt...
Wenn ich das Programm erneut starte, kann es sein das am Anfang die MSB 
und LSB korrekt sind und dann zwischendrin eine ungerade anzahl verliere 
und dann MSB LSB vertauscht sind...

Was mich wundert hatte ja erst alles mit einem Bit Wert versucht und da 
hat es wunderbar funktioniert hatte einen 1 Stündigen Dauerlauf gemacht 
und null Fehler bekommen...

[Duke Scarring (Gast)]

Lothar Miller schrieb:
> BTW:
> Meine VHDL-Dateien heißen *.vhdl mit Nachnamen.
> Meine C-Dateien heißen *.c!

Und Deine Freundinnen? Heißen die alle *.jpg mit Nachnamen?
SCNR

Duke

[Klaus (Gast)]

Duke Scarring schrieb:
> Und Deine Freundinnen? Heißen die alle *.jpg mit Nachnamen?
> SCNR

Na jedenfalls heißen die nicht *.txt! ;-)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Duke Scarring schrieb:
> Und Deine Freundinnen? Heißen die alle *.jpg mit Nachnamen?
Nur die Hübschen...  ;-)

[tim (Gast)]

Lassmiranda Densiwillja schrieb:
> Die Daten werden bei dem DCFIFO auf steigende Flanke "übernommen" und
> damit die Daten "stabil" anliegen schreib ich sie auf fallende Flanke
> raus und auf steigende übernehm ich sie in den DCFIFO...

Macht für mich nicht viel Sinn, ich würde beides auf die steigende 
Flanke machen.

[Lassmiranda Densiwillja (Gast)]

@ tim

Die von Altera machen es so im Userguide und hab mich an den Userguide 
gehalten.

Hab dir das Diagramm mal angehängt.

Unter folgendem Link ist der Userguide: 
http://www.altera.com/literature/ug/ug_fifo.pdf

Den Addierer hab ich inzwischen auf fallende Flanke abgeändert...

[tim (Gast)]

Hallo Lassmiranda
Du hast Recht im Userguide haben es die Jungs von Altera wirklich so 
gezeichnet. Ich habe es trotzdem noch nie so gemacht, bin allerdings 
auch noch am lernen;). Zeigt die Quartus "Critical Warnings" an? Hast du 
mal mit Signal-Tab eine Aufnahme gemacht um zu kontrollieren ob dein 
Handling OK ist wenn der FTDI-Buffer voll ist?

[Christian R. (supachris)]

Vielleicht hast du ein Problem mit den knackigen Setup-Zeiten die der 
FT2232H verlangt. Schau mal ins Datenblatt, Seite 28, die Tabelle. TXE# 
braucht im Worst Case 7,15ns zum Aktivieren nach dem CLK, WR# will aber 
mindestens 8ns vor der nächsten Flanke gesetzt sein. Bei den 60MHz CLK 
hast du dann im Worst Case gerade mal 1,52ns Zeit für die 
kombinatorische Verknüpfung im FPGA....das könnte zu Datenverlust 
führen.

[Bronco (Gast)]

Christian R. schrieb:
> Vielleicht hast du ein Problem mit den knackigen Setup-Zeiten die der
> FT2232H verlangt.

In dem Fall würde es auf jeden Fall helfen, entsprechende 
Timing-Constrains anzulegen.
Dann erkennt der Build, ob er es hinbekommt, bzw. weiß überhaupt erst, 
worauf er hinarbeiten muß

[Lassmiranda Densiwillja (Gast)]

Morgen,

hatte/hab auch dir Vermutung das es mit den Contraints zusammenhängt. 
Allerdings was dagegen spricht ist halt, das es zuvor bei einem 8Bit 
Addierer einwandfrei funktioniert hatte... Hatte keinerlei Datenverlust 
bei einem 16 stündigen Dauerlauf...
Was habt ihr gemacht damit ihr das Timing einhaltet? Arbeitet ihr mit 
einer PLL die das 60MHz Signal um 90/270° verschiebt?

[Christian R. (supachris)]

Ich arbeite gar nicht mit dem FTDI. Aber selbst wenn es knapp wird, 
sollte es zu keinem Datenverlust kommen, solange du sicherstellst, dass 
du das Auslesen des FIFOs rechtzeitig nach High des TXE# stoppen kannst. 
Im Notfall wird dann das letzte Wort doppelt in den FIFO des FTDI 
geschrieben, was aber nichts machen sollte, da der ja eh voll ist, und 
das Wort dann im Nirvana landen sollte. Aber genau kann ich das auch 
nicht sagen, das Problem hatten aber schon ab und zu welche hier im 
Forum.
ich verwende den FX2 und FX3 von Cypress, die sind da flexibler, auch 
weil man den Interface Takt von außen vorgeben kann.

[tim (Gast)]

Falls du Zweifel an deinem FTDI Core hast, kannst du es mal mit diesem 
probieren:
http://opencores.org/project,ft2232hcore

[Bronco (Gast)]

Lassmiranda Densiwillja schrieb:
> Was habt ihr gemacht damit ihr das Timing einhaltet?

Ich meinte, Du solltest die Setup/Hold-Zeiten aus dem Datenblatt des 
FTDI in entsprechende Timing-Constraints für Deine FPGA-I/O-Pins 
umsetzen.
Dann weiß der Build, wann die Signale gültig/stabil sein müssen.