Fehler in der Übertragung

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.

1

entity S2P_Sync is

2

generic (width : natural := 16); 

3

port (main_clk : in std_logic; --Main_clk 100MHz

4

      wrreq : out std_logic;

5

      DCFIFO : out std_logic_vector (width-1 downto 0));

6

end S2P_Sync;

7

8

architecture behavirol of S2P_Sync is

9

type states is (idle, Data0, Data1);

10

signal FSM1 : states := idle;

11

signal intdb0: std_logic_vector (width-1 downto 0) := (others=>'0');

12

signal dummy : integer range 0 to 50 := 0;

13

14

begin

15

process begin

16

 wait until rising_edge(main_clk);

17

 dummy <= dummy + 1;

18

 if (dummy = 15) then

19

  dummy <= 0;

20

 end if;

21

end process;

22

23

24

25

process  begin

26

 wait until falling_edge(main_clk);

27

 case FSM1 is

28

  when idle => if (dummy=15) then

29

                FSM1 <= Data0;

30

                intdb0 <= intdb0 + '1'; 

31

               end if;

32

               wrreq <= '0';

33

  when Data0 => FSM1 <= Data1;

34

                intdb0 <= intdb0 + '1';

35

                DCFIFO <= intdb0;

36

                wrreq <= '1';

37

  when Data1 => FSM1 <= idle;

38

                DCFIFO <= intdb0;

39

                wrreq <= '1';

40

  when others => null;

41

 end case;

42

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...

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...

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?

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...

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

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

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

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.

@ 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...

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. 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ß

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?

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

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.