CPLD - Glitches/Spikes-Problem

[Peter (Gast)]

Hi,

ich taste 2 Leitungen mit dem CPLD ab und gebe dann die Daten parallel 
wieder aus. Fast immer funktioniert das auch so, aber eben nur fast.
In wenigen Fällen habe ich einen High- statt einem Low-Pegel.
Das Gezappel auf den Leitungen dauert dann immer ein paar Millisekunden 
und dann ist wieder lange Zeit Ruhe.
Der CPLD-Takt beträgt 20MHz und das Signal 10MHz.
Woran liegt das und wie bekommt man sowas in den Griff?

entity mydevice is 
  Port 
  ( 
    DIN     : in  STD_LOGIC_VECTOR (1 downto 0);
    DOUT     : out STD_LOGIC_VECTOR (5 downto 0);
    CLK     : in  STD_LOGIC;
  );
end mydevice;

architecture Behavioral of mydevice is
  type STATETYPE is (S1,S2,S3,S4);
  signal STATE, NEXT_STATE   : STATETYPE;
  signal DTMP         : STD_LOGIC_VECTOR (7 downto 0);
    signal WRITE                : out
begin

  process (PWREN,CLK) 
  begin
        
        if CLK'event and CLK = '1' then
        
            STATE <= NEXT_STATE;    

            case STATE is
                when S1 => 
                    DTMP(1 downto 0) <= DIN(1 downto 0);
                when S2 => 
                    DTMP(3 downto 2) <= DIN(1 downto 0); 
                    WRITE <= '0';
                when S3 => 
                    DTMP(5 downto 4) <= DIN(1 downto 0);
                when S4 => 
                    DOUT(5 downto 0) <= DTMP(5 downto 0); 
                    DOUT(7 downto 6) <= DIN(1 downto 0);
                    WRITE <= '1';
            end case;
            
    end if;
  end process;

  process (STATE) begin
    case STATE is
      when S1 => NEXT_STATE <= S2;
      when S2 => NEXT_STATE <= S3;
      when S3 => NEXT_STATE <= S4;
      when S4 => NEXT_STATE <= S1;
    end case;
  end process;  
    
end Behavioral;

Gruß Peter

[Falk B. (falk)]

@Peter (Gast)

>Der CPLD-Takt beträgt 20MHz und das Signal 10MHz.
>Woran liegt das

An der Asynchronität deines Taktes zu deinen 10 MHz Daten.

>und wie bekommt man sowas in den Griff?

Durch eine grundlegende Konzeptänderung. DU musst deine Eingangsdaten 
mit den zugehörigen Takt eintakten. Dann kann man, wenn man weiß wie, 
diese an einen asynchronen Takt übergeben.

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

Ich hätte das da:
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html

[Falk B. (falk)]

@  Peter (Gast)

>ich taste 2 Leitungen mit dem CPLD ab und gebe dann die Daten parallel
>wieder aus.

Hmm, vielleicht sind dein 20 MHz Takt und deine Daten schon synchron und 
du hast ein einfaches Problem mit den Setup- und Hold Zeiten?

>Das Gezappel auf den Leitungen dauert dann immer ein paar Millisekunden
>und dann ist wieder lange Zeit Ruhe.

Klingt eher nach Wackelkontakt oder so. Denn deine Statemachine läuft 
unabhängig von deinen Eingängen, ist ja nur ein Zähler mit 4 Zuständen 
und deine Daten ein einfaches Schieberegister.

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

Peter schrieb:
> Das Gezappel auf den Leitungen dauert dann immer ein paar Millisekunden
> und dann ist wieder lange Zeit Ruhe.
> Der CPLD-Takt beträgt 20MHz und das Signal 10MHz.
Sind die synchron zueinander?

Falls nicht:
> Woran liegt das und wie bekommt man sowas in den Griff?
Sag einfach mal: der Takt ist real 10.01MHz und die Daten kommen mit 
19.99MHz, dann sieht das eine Zeitlang sehr gut aus:

        ___     ___     ___     ___     ___     ___     ___     
cpld  _|   |___|   |___|   |___|   |___|   |___|   |___|
             _______         _______         _______         __
sig   ______|       |_______|       |_______|       |_______|
            |->| tsu

Langsam aber stetig wandern dann aber die Flanken vom Signal nach links:

        ___     ___     ___     ___     ___     ___     ___     
cpld  _|   |___|   |___|   |___|   |___|   |___|   |___|
              _______         _______         _______       
sig   _______|       |_______|       |_______|       |______
             |>| tsu

Und weiter....:

        ___     ___     ___     ___     ___     ___     ___     
cpld  _|   |___|   |___|   |___|   |___|   |___|   |___|
               _______         _______         _______    
sig   |_______|       |_______|       |_______|       |___
              || tsu

Und irgendwann kommen die Flanken gleichzeitig und verletzen so die 
Setup-Zeit der Speicher-Flipflops:

        ___     ___     ___     ___     ___     ___     ___     
cpld  _|   |___|   |___|   |___|   |___|   |___|   |___|
      _         _______         _______         _______   
sig    |_______|       |_______|       |_______|       |__  
       ^       ^       ^       ^ ...
       !       ! tsu=0 !       !

Und dann wird natürlich beliebiger Käse eingelesen und gespeichert. Ein 
paar Flipflops haben noch das alte Signal, die anderen schon das neue...

Ein paar Millisekunden später siehts wieder viel besser aus und das 
Spiel beginnt von vorn:

        ___     ___     ___     ___     ___     ___     ___     
cpld  _|   |___|   |___|   |___|   |___|   |___|   |___|
      __         _______         _______         _______   
sig     |_______|       |_______|       |_______|       |__  
                |----->| tsu

[Pako (Gast)]

Lothar Miller schrieb:
> Sag einfach mal: der Takt ist real 10.01MHz und die Daten kommen mit
> 19.99MHz, dann sieht das eine Zeitlang sehr gut aus:

Einfach toll! Hut ab!

[P. K. (pek)]

Pako schrieb:
> Lothar Miller schrieb:
>> Sag einfach mal: der Takt ist real 10.01MHz und die Daten kommen mit
>> 19.99MHz, dann sieht das eine Zeitlang sehr gut aus:
>
> Einfach toll! Hut ab!

Naja wird wohl ein kleiner Typo sein: Sollte wohl heissen Takt 20.01MHz 
und Daten 9.99MHz.

Richtig lustig wirds aber erst mit Takt 19.99MHz und Daten 10.01MHz, 
dann wird der gute alte Shannon zusätzlich zu den Setup-/Hold-Issues 
auch noch gerissen.

[Kan a. (Firma: Basta) (kanasta)]

Was für eine Abweichung haben denn die "normalen" Quarze? Also 19.99Mhz 
statt 20MHz sind ja 1KHz zu wenig, sooo ungenau sind die doch nicht 
oder?
Ändert natürlich nichts an dem Punkt, den Lothar gemacht hat.

[Pako (Gast)]

Peter K. schrieb:
> Pako schrieb:
>> Lothar Miller schrieb:
>>> Sag einfach mal: der Takt ist real 10.01MHz und die Daten kommen mit
>>> 19.99MHz, dann sieht das eine Zeitlang sehr gut aus:
>>
>> Einfach toll! Hut ab!
>
> Naja wird wohl ein kleiner Typo sein: Sollte wohl heissen Takt 20.01MHz
> und Daten 9.99MHz.

Nein, ich hab das vollkommen ernst gemeint! Ich find es wirklich toll, 
wie ausführlich Lothar immer alles erklärt.
Ich hab mir seine Antowrt direkt ausgedruckt und in mein 
VHDL-Erfahrungen-Heft geklebt.

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

Peter K. schrieb:
> Naja wird wohl ein kleiner Typo sein: Sollte wohl heissen Takt 20.01MHz
> und Daten 9.99MHz.
Hach, ja...

Pako schrieb:
> Ich find es wirklich toll, wie ausführlich Lothar immer alles erklärt.
Dankeschön. Aber ich mach das nur, damit nicht die gleichen Fragen immer 
wieder kommen...  ;-)

> in mein VHDL-Erfahrungen-Heft geklebt.
Du hättest das aber eher ins "Allgemeine-Hardware-Heft" kleben sollen. 
Denn dieses Problem kann (und wird) auch dich immer wieder und überall 
einholen...

[Peter (Gast)]

Erstmal vielen Dank für eure Antworten!

>>Falk Brunner:
>>DU musst deine Eingangsdaten mit den zugehörigen Takt eintakten.
Ich habe das jetzt so gemacht wie bei Lothar Miller beschrieben, also 
mit einem Synch-FF dazwischen. Leider tritt der Fehler immer noch auf.

>>Lothar Miller:
>>Ich hätte das da:
>>http://www.lothar-miller.de/s9y/archives/64-State-...
Danke für die Infos. Echt super für das Verständnis - genau da mangelt 
es nämlich noch.

>>Falk Brunner:
>>Hmm, vielleicht sind dein 20 MHz Takt und deine Daten schon synchron und
>>du hast ein einfaches Problem mit den Setup- und Hold Zeiten?
Synchronisiert ist da gar nichts. Die Daten liegen an den Eingängen an 
und per Knopfdruck wird das Sampling gestartet (also völlig unabhängig 
von den Eingangsdaten).

>>Lothar Miller:
>>Sag einfach mal: der Takt ist real 10.01MHz und die Daten kommen mit
>>19.99MHz, dann sieht das eine Zeitlang sehr gut aus:
Danke für die grafische Unterstützung! Jetzt ist mir auch das mit den 
Setup-Zeiten bewusst.

>>Peter K.:
>>Richtig lustig wirds aber erst mit Takt 19.99MHz und Daten 10.01MHz,
>>dann wird der gute alte Shannon zusätzlich zu den Setup-/Hold-Issues
>>auch noch gerissen.
Das die Abtastfrequenz nicht optimal ist, weiss ich auch, aber es ist 
eben anders nicht machbar. Es spielt auch keine Rolle, ob ich einen 
Pegel einmal oder zweimal abtaste. Wichtig ist, dass alle Pegelwechsel 
erkannt werden. Dafür sollte die doppelte Abtastfrequenz doch 
ausreichen, oder?

Gruß Peter

[Pako (Gast)]

Lothar Miller schrieb:
>> Ich find es wirklich toll, wie ausführlich Lothar immer alles erklärt.
> Dankeschön. Aber ich mach das nur, damit nicht die gleichen Fragen immer
> wieder kommen...  ;-)

Das tolle ist ja, das Du die gleichen Fragen trotzdem immer wieder 
kommen und Du sie trotzdem immer wieder erklärst ;)

[Falk B. (falk)]

@  Peter (Gast)

>Synchronisiert ist da gar nichts. Die Daten liegen an den Eingängen an
>und per Knopfdruck wird das Sampling gestartet (also völlig unabhängig
>von den Eingangsdaten).

Was mal nicht wirklich funktioniert, schon gar nicht so knapp an der 
Nyquistgrenze (auch wenn die hier so direkt nicht anwendbar ist).

>Danke für die grafische Unterstützung! Jetzt ist mir auch das mit den
>Setup-Zeiten bewusst.

Di gibt es aber nur, wenn Daten und Takt SYNCHRON zueinander sind. Wenn 
nicht, ist das sowieso für die Katz.

>Das die Abtastfrequenz nicht optimal ist, weiss ich auch, aber es ist
>eben anders nicht machbar.

Ist ist IMMER anders machbar.

> Es spielt auch keine Rolle, ob ich einen
>Pegel einmal oder zweimal abtaste. Wichtig ist, dass alle Pegelwechsel
>erkannt werden. Dafür sollte die doppelte Abtastfrequenz doch
>ausreichen, oder?

Oder. Bei Faktor vier können wir drüber reden. Das macht u.a. USB so bei 
12 Mbit/s, dort wird mit 48 MHz abgetastet und es scheint zu 
funktionieren.

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

Falk Brunner schrieb:
> Di gibt es aber nur, wenn Daten und Takt SYNCHRON zueinander sind. Wenn
> nicht, ist das sowieso für die Katz.
Nun, es erklärt, warum es immer eine Zeitlang gut geht und dann wieder 
"ruckelt".

> Oder. Bei Faktor vier können wir drüber reden. Das macht u.a. USB so bei
> 12 Mbit/s, dort wird mit 48 MHz abgetastet
Aaaaaber: da es wird nur 1 Leitung abgetastet!

Peter schrieb:
> Woran liegt das und wie bekommt man sowas in den Griff?
Kurz: das Problem hier ist so einfach nicht lösbar!
Denn es sind mehrere (hier 2) Bits, die zueinandergehören und wenn eines 
davon schon "neu", das andere aber noch "alt" eingelesen wurde, dann 
gibts eben Müll. Du brauchst also irgendeinen Mechanismus, der sagt, 
"jetzt sind die Daten garantiert stabil und sie ändern sich die nächste 
Zeit auch nicht". Bei asynchronen RAMs waren das die /WR und /RD 
Leitungen...

Du könntest natürlich wie von Falk beim USB erwähnt überabtasten und 
sagen: wenn ich 2 gleiche Bitfolgen nachinander habe, dann ist das 
stabil. Und spätestens hier kommen die Herren Shannon und Nyquist wieder 
ins Boot, denn jetzt brauchst du mehr als die doppelte Abtastfrequenz. 
Und dann kommt aber noch dazu: was passiert, wenn immer "01" am 
Eingang anliegen? Wann darfst du dann in der FSM weiterschalten? Wie 
setzt du dann das Wort zusammen? Was passiert, wenn dann nach 10 Minuten 
(und ein paar "übersprungenen Bitwechseln") wieder "10" kommt?
Hast du dann 01010110 im Register stehen, oder 01011010, oder 01101010?
Und was davon ist Richtig?

[Peter (Gast)]

Es kann sein, dass ich mich vlt. falsch ausgedrückt habe mit 'falscher 
Bitfolge' und 'Gezappel'. Deshalb mal was fürs Auge:

Tatsächliches Signal bezogen auf einen Kanal (dreimal gleicher Pegel im 
Wechsel): 111000111000111

Abtastung 1: 110000011000011
Abtastung 2: 111011110011111
Abtastung 3: 111111111111111

Alle drei Fälle kommen beim Abtasten vor. Und der dritte Fall ist das 
Problem.
Wie die beiden Kanäle zueinander abgetastet werden, spielt keine Rolle. 
Wichtig ist nur, dass keine Pegel völlig geschluckt werden.

An der Hardware liegt es vermutlich nicht, da sich die Schaltung auf dem 
Steckbrett und auf einer kleinen Platine, die ich habe fertigen lassen 
genau gleich verhält (es sei denn ich habe einen systematischen Fehler, 
was ich nicht glaube, da z.B. bei Vorbelegung von DOUT mit 8 Nullen oder 
8 Einsen genau diese dann auch ausgegeben werden).

[Pako (Gast)]

Peter schrieb:
> Alle drei Fälle kommen beim Abtasten vor. Und der dritte Fall ist das
> Problem.

Wieso? Eigentlich sollten doch alle drei Fälle ein Problem sein, weil 
sie falsche Eingangsdaten aufzeigen?

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

Peter schrieb:
> Der CPLD-Takt beträgt 20MHz und das Signal 10MHz.
Wie sieht es mit der Symmetrie des "Signals" aus?
Wie ist das Tastverhältnis?
Angenommen, du hast sowas:

        ___     ___     ___     ___     ___     ___     ___     
cpld  _|   |___|   |___|   |___|   |___|   |___|   |___|
      __      __________      __________      __________      
sig     |____|          |____|          |____|          |__
       1       1       1       1       1       1       1

Und wieder hast du 10MHz und 20MHz. Aber du erkennst nur Einsen...  :-o

Ein wenig später sind die Flanken aufeinander zugelaufen, und alles ist 
gut:

        ___     ___     ___     ___     ___     ___     ___     
cpld  _|   |___|   |___|   |___|   |___|   |___|   |___|
       ____      __________      __________      __________      
sig        |____|          |____|          |____|          |__
               0       1       0       1       0       1