Seriell Parallel Wandeln mit einem Asynchronen Dateneingang

[Fabian Z. (fabi_z)]

Hallo,

ich habe eine digitales Eingangssignal (Data_in) welches asynchron 
eingespeist wird. Dieses Eingangssignal habe ich zuerst 
Einsynchronisiert für eine Flankenerkennung. Das Eingangssignal hat High 
und Lowpegel mit 2 und 4 MHz. Anschließend wollte ich dieses Signal 
welches seriell ist, parallel wandeln. Jedoch schaffe ich es nicht 
parallel auszugeben. Mein Code ist hier:

Startup: Process(CLK,Data_in)
    begin
        if rising_edge(CLK) then
            Data_In_Sync  <= Data_In_Sync(1 downto 0) & Data_in;
        end if; 
    end Process Startup;

Shift: Process(CLK)
    begin
         if rising_edge(CLK) then
              
              if (Data_In_Sync(2 downto 1) = "01") then 
                     enable <= '1';
                     Data_Buffer(15 downto 0) <= Data_Buffer(14 downto 0) & Data_In_Sync(0);  
              elsif (Data_In_Sync(2 downto 1) = "10") then 
                     Data_Buffer(15 downto 0) <= Data_Buffer(14 downto 0) & Data_In_Sync(0); 
                     enable <= '0';                  
              end if;    
                
         end if; 
     end Process Shift;

      
SIPO: Process(CLK)
     begin
     if rising_edge(CLK) then
            if enable = '1' then 
            if Data_Buffer = "0100110100110011" then
                 Data_out <= '0';
                 Sync_out <= '0';
                 Data_Buffer <= "0000000000000000";                     
             elsif Data_Buffer = "0100110100110101" then
                 Data_out <= '1';
                 Sync_out <= '0';
                 Data_Buffer <= "0000000000000000";
             elsif Data_Buffer = "0100110101010011" then
                 Data_out <= '1';
                 Sync_out <= '1';
                 Data_Buffer <= "0000000000000000";
                 end if;
                 end if;
             end if;
     end Process SIPO;
                                                  

end Behavioral;

Das zweite Problem welches ich habe, ist das von meinem Eingangssignal 
(Data_in) zum Beispiel irgendein high Pegel 500ns breit ist. Nach dem 
einsynchronisieren aber nicht mehr, da ja hart auf die steigende Flanke 
des Clks getriggert wird. Wie kann ich das bewerkstelligen das dass 
einsynchronisierte Signal bei dem erwähnten high Pegel auch die 500ns 
hat und nicht um 2.5ns verringert wird?

Grüße und vielen Dank euch

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

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?

[Amateur (Gast)]

Ist Dein Weg der richtige?
Üblicherweise sind die Daten eines seriellen Signales, relativ zur 
"eigenen" Frequenz oder zu einem externen Träger.
Eine "Einsynchronisierung" - was auch immer das heißt - kann ja nur zu 
"Deiner" Frequenz - einer anderen Frequenz wie das Eingangssignal - 
erfolgen.
Da sind üblicherweise die Daten futsch. Ausnahme, Du kannst mit vielfach 
höherer Frequenz abtasten.

[Fabian Z. (fabi_z)]

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.

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

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.

[Fabian Z. (fabi_z)]

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?

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;


entity testbench is
--  Port ( );
end testbench;

architecture Behavioral of testbench is

COMPONENT  Demod is
    Port ( CLK : in STD_LOGIC;
           Data_in : in STD_LOGIC;

    END COMPONENT;

    SIGNAL clk,data_in  :   STD_LOGIC := '0';
    
    SIGNAL  i           : INTEGER :=0;
 
    SIGNAL buf : STD_LOGIC_VECTOR(0 to 208) := "11010011010101001101001100110111001001101010100110100110100110101010011010011010101001101001100110100110100110011010011010011001101001101001100110100110100110101010011010011010101001101001100110100110101010011";

begin
    DUT : Demod 
    PORT MAP(
    CLK=>clk, 
    Data_in => Data_in,

    clk_data_in <= not clk_data_in after 125ns;

process
             for i in 0 to 208 loop
                wait for  25ns;
                     data_in <= buf(i);
                END loop;
end process;

         clk <= not clk after 5000ps;
         
end Behavioral;

[Duke Scarring (Gast)]

Es wäre schön, wenn Du compilierbaren Code einstellst:

$ vcom tb.vhd

Model Technology ModelSim SE-64 vcom 10.6c Compiler 2017.07 Jul 26 2017
-- Loading package STANDARD
-- Loading package TEXTIO
-- Loading package std_logic_1164
-- Compiling entity testbench
-- Compiling architecture Behavioral of testbench
###### tb.vhd(17):     END COMPONENT;
** Error: tb.vhd(17): near "END": (vcom-1576) expecting IDENTIFIER.
###### tb.vhd(19):     SIGNAL clk,data_in  :   STD_LOGIC := '0';
** Error: tb.vhd(19): (vcom-1294) Declaration with designator "clk" already exists in this region.
** =====> Prior declaration of "CLK" is at tb.vhd(14).
** Error: tb.vhd(19): (vcom-1294) Declaration with designator "data_in" already exists in this region.
** =====> Prior declaration of "Data_in" is at tb.vhd(15).
###### tb.vhd(31):     clk_data_in <= not clk_data_in after 125ns;
** Error: tb.vhd(31): (vcom-1136) Unknown identifier "clk_data_in".
** Error: tb.vhd(31): (vcom-1136) Unknown identifier "clk_data_in".
** Error: tb.vhd(31): ** Error: (vcom-1590) Bad expression in right operand of infix expression '<='.
** Error: tb.vhd(31): near "after": (vcom-1576) expecting ',' or ')'.
** Warning: tb.vhd(31): (vcom-1207) An abstract literal and an identifier must have a separator between them.
###### tb.vhd(34):              for i in 0 to 208 loop
** Error: tb.vhd(34): near "in": (vcom-1576) expecting ':'.
###### tb.vhd(35):                 wait for  25ns;
** Warning: tb.vhd(35): (vcom-1207) An abstract literal and an identifier must have a separator between them.
End time: 07:32:57 on May 31,2018, Elapsed time: 0:00:00
Errors: 8, Warnings: 2

Nach Behebung aller syntaktischen Fehler läuft die Simulation.
Welche Signalform hattest Du erwartet?

Duke

[A. F. (chefdesigner)]

Könnte mir bitte jemand den Sinn einer bedingten 
Serien-Parallel-Wandlung verdeutlichen?

Warum wird nur bei der Flanke weitergeschoben?

              if (Data_In_Sync(2 downto 1) = "01") then 
                     enable <= '1';
                     Data_Buffer(15 downto 0) <= Data_Buffer(14 downto 0) & Data_In_Sync(0);  
              elsif (Data_In_Sync(2 downto 1) = "10") then 
                     Data_Buffer(15 downto 0) <= Data_Buffer(14 downto 0) & Data_In_Sync(0); 
                     enable <= '0';                  
              end if;

[A. F. (chefdesigner)]

Keiner?

[Gustl B. (-gb-)]

Wann soll denn sonst weitergeschoben werden?

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

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

[Weltbester FPGA-Pongo (Gast)]

Lothar M. schrieb:
> Sinnvollerweise wird sogar nur bei der jeweils gleichen Flanke
> geschoben.
Das unübersichtliche hier ist das Weiterschalten der Eingangsdaten in 
der Bedingungsabfrage. Die gehört nach draußen, da sie eh läuft. Dann:

der TE sollte sich mal fragen, ob er alle Fälle abgefangen hat und wie 
man so etwas geschickter in eine TB versetzt.

Aber mal was anderes:

Duke Scarring schrieb:
> Es wäre schön, wenn Du compilierbaren Code einstellst:$ vcom tb.vhd
"einstelltest" (Konjunktiv Präsens)

> Model Technology ModelSim SE-64 vcom 10.6c Compiler 2017.07 Jul 26 2017
Ist die 10.6 die aktuelle Version vom SE?
Wenn ich das richtig lese, ist letzten Monat abgelaufen - was kostet 
denn aktuell eine Lizenz vom SE?

Mein AG spendiert leider nur die DE, vormalige PE.

[Duke Scarring (Gast)]

Weltbester FPGA-Pongo schrieb im Beitrag #5574655:
>> Model Technology ModelSim SE-64 vcom 10.6c Compiler 2017.07 Jul 26 2017
> Ist die 10.6 die aktuelle Version vom SE?
> Wenn ich das richtig lese, ist letzten Monat abgelaufen - was kostet
> denn aktuell eine Lizenz vom SE?
Aktuell ist 10.7c. Aber seit Jahren sind da für mich keine nennenswerten 
Features hinzugekommen, wie z.B. die Unterstützung für SystemVerilog.

Außerdem darf man dann sicher wieder den Lizenzserver updaten und ggf. 
das System auf dem dieser läuft gleich dazu.
Der Academicpreis (pro Jahr) liegt in der Höhe eines mittleren 
FPGA-Evalboards.

Duke

[Weltbester FPGA-Pongo (Gast)]

D.h. du bist an einem Institut tätig und kannst den zu den Konditionen 
bekommen? Wir haben zuletzt für den DE noch 5 stellig bezahlt!