[Bearbeiten] Einleitung

Heutzutage enthält fast jedes Ding im täglichen Leben ein Stück Elektronik, und fast überall ist auch digitale Elektronik dabei. Diese Digitalschaltungen werden von Ingenieuren entworfen. Vor 30 Jahren wurde diese Aufgabe mit Standard TTL Logik gelöst. Komplexe Funktionen füllten Dutzende von Platinen, jede mit hunderten von IC gefüllt, welche alle verbunden waren. Später gab es programmierbare ICs (PAL, GAL), welche durch den Anwender programmiert werden konnten und deutlich komplexere, problembezogene Funktionen mit deutlich weniger Platzbedarf erfüllen konnten. Heute sind die am weitesten entwickelten ICs die FPGAs. Diese sind in der Lage, Daten mit mehreren hundert MHz Taktfrequenz zu verarbeiten, enthalten 10.000 und mehr FlipFlops, Funktionsgeneratoren (LUTs, Look Up Table) und spezielle Funktionsblöcke ( RAM, DLLs, spezielle IO-Zellen etc.).

[Bearbeiten] Das Problem

Wenn man ein digitales System mit FPGAs entwirft, müssen ein paar grundlegende Regeln eingehalten werden, um ein stabiles Ergebnis zu erhalten. Im Allgemeinen sind FPGAs und die zugehörigen Synthesewerkzeuge auf synchrone Schaltungen ausgelegt. Aber es gibt ein paar schmutzige Tricks, welche in der guten, alten TTL-Zeit funktionierten, weil die relativ langsamen ICs und die großflächige Verkabelung als Tiefpassfilter wirkten und einige Dreckeffekte versteckten. Mit modernen FPGAs, dessen FlipFlops und LUTs mit einigen hundert MHz laufen, werden diese bösen Tricks nicht mehr gefiltert, genauer gesagt können und werden diese Tricks Probleme machen. Ein erfahrener Ingenieur wird diese Probleme von vorn herein vermeiden, aber ein Anfänger, welcher durch ein Zeitfenster aus der TTL-Zeit direkt in die FPGA-Ära hereinspringt hat diese Erfahrung (=erlebtes Leid?) nicht.

[Bearbeiten] Die Grundlagen eines Glitch

Das hier diskutierte Problem sind Glitches von digitalen Signalen. Ein Glitch ist ein sehr kurzer Puls (nur ein paar Nanosekunden lang), verursacht durch einen Dekoder. Ein Dekoder ist im Allgemeinen ein ROM, welcher einen Eingangscode (ein Vektor aus Bits) in einen Ausgangscode übersetzt. Die meisten FPGAs haben LUTs mit 4-6 Eingängen, was ganz einfach ein ROM mit 16-64 Bit darstellt, dessen Inhalt vom Entwickler festgelegt werden kann. Wenn man einen großen Dekoder mit mehr Eingängen benötigt, als eine einzelne LUT zur Verfügung stellt, dann muss man mehrere LUTs zusammenschalten bis die gewünschte Funktion erreicht ist. Im Allgemeinen ist aber die Durchlaufzeit von allen Eingängen zum Ausgang unterschiedlich, sowohl bei einer einzelnen LUT als auch bei mehreren zusammengeschalteten. D.h., wenn mehrere Eingangsbits gleichzeitig ihren Pegel wechseln, sind einige Bits schneller als andere. Das kann und wird dazu führen, dass der Ausgang des Dekoders vom aktuellen Zustand auf einen Zwischenzustand springt und nach wenigen Nanosekunden erst auf den richtigen, dauerhaften Zustand. Wenn so ein "verglitschtes" Signal als Takt oder asynchroner Reset benutz wird, verursacht das viele Probleme.

Schauen wir uns die Logik an.

Aufbau und Verzögerungszeiten der Logik

Das ist ein einfaches 2-Bit Schieberegister, welches nur zwischen den zwei Zuständen "01" und "10" wechselt.

Wenn man die Schaltung statisch betrachtet, wird der Ausgang E immer 1 sein. Aber dynamisch ist das nicht der Fall.

Wir nehmen an.

• Der Ausgang von FlipFlop 1 (C) braucht 1ns um den Eingang (C) des XOR zu erreichen
• Der Ausgang von FlipFlop 2 (B) braucht 3ns um den Eingang (D) des XOR zu erreichen
• Die Durchlaufverzögerung der FlipFlops sowie der LUT soll 1ns betragen

Diese Zahlen sind realistisch.

Jetzt schauen wir uns den Übergang des Schieberegisters von "10" aud "01" genau an.

Zeitdiagramm

• 0ns - Start der Simulation
• 1ns - Der Takteingang führt eine steigende Flanke aus, was dazu führt, dass die FlipFlops neue Daten laden
• 2ns - nach der Speicherverzögerung von 1ns liegen die neuen Daten am Ausgang der FlipFlops an (A und B). Das passiert sehr synchron (+/-100ps und weniger).
• 3ns - der neue Zustand von FlipFlop 1 erreicht das XOR-Gatter nach 1ns Laufzeitverzögerung, der Eingang des XOR ist nun "11", was am Ausgang zum Zustand '0' führen wird.
• 4ns - der Ausgang des XOR (E) geht auf den neuen Zustand '0' über nach 1ns Gatterlaufzeit
• 5ns - der zweite Eingang des XOR wechselt auf "0", weil das Signal von (B) nach 3ns Laufzeit endlich angekommen ist
• 6ns - Das XOR reagiert auf den neuen Eingangscode "01" und schaltet auf '1' nach 1ns Gatterverzögerung

Ein guter, alter TTL-IC würde da nicht mal blinzeln, aber heutige FPGAs sind sauschnell. Nicht nur die LUTs, auch die FlipFlips können höllisch schnell schalten.

[Bearbeiten] Messaufbau

Die Messungen wurden mit einem Spartan-II Evaluationboard von Insight Electronics durchgeführt. Es enthält einen XC2S100-5PQ208. Die Testschaltung wurde durch einen 36 MHz Quarz getaktet, der Wert ist aber vollkommen unwichtig, 1 MHz würde genauso funktionieren. Die Testausgänge wurden mit selbstgebauten High Speed Tastköpfen gemessen, wie sie im Buch "High speed digital Design - A Handbook of Black Magic" empfohlen werden. Die Anstiegszeit dieser Tastköpfe liegt irgendwo bei 200ps. Das Oszilloskop, mit welchen die Screenshots gemacht wurden, ist ein Tektronix TDS 3034 mit 300 MHz Bandbreite. Einige Zusatzmessungen wurden mit einem Tektronix CSA 404 mit einem 11A34 Verstärker gemacht, welcher 1 GHz Bandbreite hat. Leider konnten damit keine Screenshots gemacht werden (Softwareprobleme). Man beachte, dass die Leitungen nicht terminiert sind. Reflektionen und Überschwinger sind für diesen Test unkritisch.

Aufbau der Testschaltung

Die Testlogik wurde in VHDL definiert. Sie enthält zwei FlipFlops, welche mit jedem Takt gleichzeitig umschalten. Da sie immer entgegengesetzte Pegel haben, sollte der Ausgang des XOR immer auf '1' liegen. Aber auf Grund der ungleichen Durchlaufverzögerung der zwei Eingangsbits wird der Ausgang des XOR einen Glitch erzeugen. Dieser Glitch taktet ein drittes FlipFlop. Der "verglitchte" XOR-Augang sowie der Ausgang des 3. FlipFlops sind zur Messung auf Ausgangspins geroutet.

--The IEEE standard 1164 package, declares std_logic, rising_edge(), etc.
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;
 
 
entity glitch is
    port (
        clk_in        : in  STD_LOGIC;
        bad_clk       : out std_logic;
        glitch_detect : out STD_LOGIC
    );
end glitch;
 
architecture glitch_arch of glitch is
 
component LUT2
  port (
    I0 : in std_logic;
    I1 : in std_logic;
    O  : out std_logic
  );
end component;
 
-- Attribute applied to instantiation 
attribute INIT : string; 
attribute INIT of L_XOR : label is "6"; 
 
signal S1, S2, S3, clk_bad, clk:    std_logic;
 
begin
  -- a demonstration of a decoder generating a glitch
  
  -- toggling FlipFlops
  
  process(clk_in)  
  begin
    if clk_in='1' and clk_in'event then
      s1<=not S1;       -- these two signals are always inverted to each other
      s2<=S1;
    end if;  
  end process;
 
-- this is a big NO-NO, because the decoder produces glitches
-- clk_bad<=s1 xor s2;
 
-- we use a LUT instanciation so we can easy place then using LOC constraints
 
L_XOR: LUT2
  port map(
    I0 => S1,
    I1 => S2,
    O  => clk_bad
  );
  
  process(clk_bad)
  begin
    if clk_bad='1' and clk_bad'event then
      s3<=not s3;       -- a toggle FF, which would never toggle if the decoder output was glitch free
    end if;
  end process;
 
  glitch_detect<=s3;
  bad_clk<=clk_bad;
    
end glitch_arch;

Die Grundelemente wurden mittels Constraints auf definierte Plätze im FPGA platziert, um deterministische Ergebnisse zu erreichen. Auch die IO-Zellen wurden auf maximale Geschwindigkeit konfiguriert.

NET "glitch_detect"  LOC =  "P42";
NET "clk_in"         LOC =  "P80";
NET "bad_clk"        LOC =  "P41";

INST    s1           LOC = "CLB_R15C1.S0";          # place FF2 close to XOR LUT (C37)
INST    s3           LOC = "CLB_R15C1.S1";          # place FF3 close to XOR LUT (C37)
INST    l_xor        LOC = "CLB_R15C1.S1";          # XOR LUT
INST    s2           LOC = "CLB_R15C30.S0";         # place FF1, FAR from FF2, so the glitch will be VERY big
                                                    # modify the column C30 to set routing delay

NET "bad_clk"       drive=24;
NET "bad_clk"       FAST;
NET "glitch_detect" drive=6;
NET "glitch_detect" SLOW;

CLB Matrix

Die Verzögerung zwischen FlipFlop2 und dem XOR wurde durch einen großen Abstand bei der Platzierung erreicht. Dieser Abstand wurd Schritt für Schritt verkleinert und die Ergebnisse dokumentiert.

[Bearbeiten] Messergebnisse

Auf Kanal 1 wird das Signal bad_clk angezeigt, auf Kanal 2 glitch_detect.

FlipFlop 2 in Spalte 30

Das ist der erste Versuch. Weil die Differenz der Durchlaufverzögerung so groß ist, ist auch der Glitch recht lang. Aber sehen wir genau hin, es ist gerade mal ein 1.5ns Puls! Das ist weit weg von der Spezifikation der minimalen Pulsbreite des Taktes für dieses FPGA. Wie man sieht, schaltet FlipFlop 3 bei dem Glitch um.

FlipFlop 2 in Spalte 15

Der Glitch ist kürzer, aber das FlipFlop 3 schaltet immer noch problemlos.

FlipFlop 2 in Spalte 10

Jetzt wird es richtig schnell. Wir sehen auch die Grenzen des Oszilloskops (300 MHz), denn auf dem schnellen 1 GHz Oszilloskop erreicht der Puls noch die 0V Linie. Das FlipFlop 3 toggelt weiter.

FlipFlop 2 in Spalte 8

Und es toggelt immer noch. Aber wir haben die Grenzen des Oszilloskops und der IO-Zelle erreicht. Der Glitch ist ausserhalb nicht mehr messbar, auch nicht mit dem 1 GHz Oszilloskop. Da die IO-Zelle bis zu 24mA liefern muss und einiges an ESD-Schutzmassnahmen enthält, sind die Stukturen deutlich größer und haben damit mehr parasitäre Kapazität als die kleinen Strukturen im Kern. Dadurch werden sie langsamer. Man sieht auch, dass die Störung auf dem glitch_detect Ausgang durch Übersprechen von Ausgang bad_clk verursacht wurde.

FlipFlop 2 in Spalte 3

Jetzt haben wir die Grenzen dieser Technologie erreicht. Der Glitch ist einfach zu klein, um vom FlipFlop 3 noch "gesehen" zu werden. Nur der liebe Gott weiß, wie das Signal im Inneren jetzt aussieht. Aber Vorsicht! Das heißt nicht, dass man einen glitchfreien Dekoder erhält, wenn man die FlipFlops nah am Dekoder platziert. Die Geschwindigkeit der Logikzellen bzw. Verbindungnetze schwankt mit der Temperatur (kalt = schnell), der Versorgungsspannung (hoch = schnell) und allgemeinen Fertigungstoleranzen. Man darf nicht auf die niedrige Geschwindigkeit der ICs zählen, um sie als Glitchfilter zu missbrauchen! Wenn man die Schaltung auf eine schnellere Technologie umstellt (schnelleres FPGA, ASIC), wird diese Methode scheitern. Die einzigen zuverlässigen Wege um Glitches zu vermeiden sind

• nur jeweils ein Eingangsbit umschalten (Gray Code)
• Ein FlipFlop am Dekoderausgang nutzen, um das das Signal abzutasten

[Bearbeiten] Siehe auch

• Taktung FPGA/CPLD
• Oszilloskop

[Bearbeiten] Weblinks

• Probing High-Speed Digital Designs, Originally published in Electronic Design Magazine, March, 1997