Seriell Parallel Wandeln mit einem Asynchronen Dateneingang

Fabian Z. schrieb:
> Wie kann ich das bewerkstelligen das dass einsynchronisierte Signal bei
> dem erwähnten high Pegel auch die 500ns hat
Warum ist es nötig, dass es hinterher auch noch 500ns hat?

> Das Eingangssignal hat High und Lowpegel mit 2 und 4 MHz.
?
Kannst du das mal aufzeichnen und posten?
Oder du könntest sagen woher das Signal kommt, evtl. findet man dann 
eine Doku zum Protokoll.
Oder ist das eine übliche NRZ Codierung, wo der Takt zusammen mit den 
Daten übertragen wird?

Lothar M. schrieb:
> Fabian Z. schrieb:
>> Wie kann ich das bewerkstelligen das dass einsynchronisierte Signal bei
>> dem erwähnten high Pegel auch die 500ns hat
> Warum ist es nötig, dass es hinterher auch noch 500ns hat?

Hm ich hatte Angst das mir irgendwann das Signal wegläuft. Über lange 
Zeit gedacht.

>
>> Das Eingangssignal hat High und Lowpegel mit 2 und 4 MHz.
> ?
> Kannst du das mal aufzeichnen und posten?
> Oder du könntest sagen woher das Signal kommt, evtl. findet man dann
> eine Doku zum Protokoll.
> Oder ist das eine übliche NRZ Codierung, wo der Takt zusammen mit den
> Daten übertragen wird?

Als Eingangsfolge kommt sowas von einem Messgerät: 
100110100110011011100100110101010011010011010011010101001101001101010100 
11010011001101001101001100110100110100110011010011  Die ersten 16 sind 
Synchronisationsbits dann folgen 288 Datenbits gefolgt wieder von 16 
Synchronisationsbits.  Dieses will ich auswerten. Man kann die 
Datenfolge auch im Bild (Simulation) oben sehen. Data_in ist die 
Eingangsfolge vom Messgerät. Ich glaube das geht auch wie ich es oben 
versucht habe, jedoch ist das Problem das dass hineinschieben klappt 
aber das erkennen  mit

if Data_Buffer = "0100110100110011“ then

usw.

nicht.

Fabian Z. schrieb:
> Hm ich hatte Angst das mir irgendwann das Signal wegläuft. Über lange
> Zeit gedacht.
Natürlich, das wird passieren, wenn du den Empfang nicht zwischendurch 
wieder auf die Flanken synchronisierst.
Das ist ein NRZ Signal wie beim RC5 Code. Und so ein Signal bringt mit 
jedem Datenbit einen Taktflanke zur Synchronisation mit. Meine 
Implementierung dort kann Frequenabweichungen bin zu 25% kompensieren:
http://www.lothar-miller.de/s9y/categories/50-RC-5

> Man kann die Datenfolge auch im Bild (Simulation) oben sehen.
Diese da eingelesene Reihenfolge ist Zufall. Sie hängt  extrem von den 
Samplingzeitpunkten ab. Es klappt zwar irgendwie in der Simulation, weil 
du da ein festes und starres, immer gleich wiederkehrendes Bitmuster 
hast, es wird aber garantiert in der Realität nicht zuverlässig 
funktionieren, wenn du das einfach als Bitstrom einliest und mit einem 
festen Wert vergleichst.

Ok super, ich habe mal in deinen Code hineingeschaut und meinen daran 
angepasst. Jetzt wollte ich mal einen Simulation Langzeittest machen ob 
mir da was wegläuft. Jedoch mache ich in der Testbench was mit der 
for-Schleife falsch. Da ich zu Faul war die Bitkette immer wieder zu 
kopieren wollte ich diese mit einer Schleife immer und immer wieder neu 
einlesen. Geht aber irgendwie nicht. Was mache ich da den falsch?

1

library IEEE;

2

use IEEE.STD_LOGIC_1164.ALL;

3

LIBRARY ieee;

4

USE ieee.std_logic_1164.ALL;

5

6

7

entity testbench is

8

--  Port ( );

9

end testbench;

10

11

architecture Behavioral of testbench is

12

13

COMPONENT  Demod is

14

    Port ( CLK : in STD_LOGIC;

15

           Data_in : in STD_LOGIC;

16

17

    END COMPONENT;

18

19

    SIGNAL clk,data_in  :   STD_LOGIC := '0';

20

21

    SIGNAL  i           : INTEGER :=0;

22

23

    SIGNAL buf : STD_LOGIC_VECTOR(0 to 208) := "11010011010101001101001100110111001001101010100110100110100110101010011010011010101001101001100110100110100110011010011010011001101001101001100110100110100110101010011010011010101001101001100110100110101010011";

24

25

begin

26

    DUT : Demod 

27

    PORT MAP(

28

    CLK=>clk, 

29

    Data_in => Data_in,

30

31

    clk_data_in <= not clk_data_in after 125ns;

32

33

process

34

             for i in 0 to 208 loop

35

                wait for  25ns;

36

                     data_in <= buf(i);

37

                END loop;

38

end process;

39

40

         clk <= not clk after 5000ps;

41

42

end Behavioral;

Wann soll denn sonst weitergeschoben werden?

Andreas F. schrieb:
> Warum wird nur bei der Flanke weitergeschoben?
Sinnvollerweise wird sogar nur bei der jeweils gleichen Flanke 
geschoben. Sonst hättest du ein Double Data Rate (DDR) Design  wo sich 
mit jeder Taktflanke was ändert. Und das macht die Sache nicht 
einfacher...