Lothar Miller - Einsynchronisieren

Testaufbau Metastabilität

nospam@example.com (Lothar Miller) — Thu, 08 Oct 2009 19:47:00 +0200

Wie könnte ein einfacher Aufbau aussehen, um Metastabilität darzustellen? Ein Eingangssignal wird auf ein Flipflop ffS eingelesen und der Ausgang dieses ffS parallel auf 2 Flipflops (ffA und ffB) eingetaktet. Die Ausgänge dieser beiden Flipflops werden auf Gleichheit des eingetakteten Signals verglichen und bei unterschiedlichen Werten ein Zähler hochgezählt, der dann auf LEDs ausgegeben wird.

Testaufbau Metastabilität entsprechend XAPP094

Falls die beiden FFs die gleichen Werte einlesen, wird auch am Ende der Schieberegisterkette immer der selbe Wert herauskommen, und der Zähler wird nicht hochzählen.

Wenn aber die beiden FFs unterschiedliche Werte einlesen, weil das ffS metastabile Zustände annimmt, dann wird der Zähler Werte ungleich 0 anzeigen. In der Verhaltenssimulation kann ein solcher Fehler nicht gefunden werden.

Und dazu die VHDL-Beschreibung

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity Metastable is
    Port ( clk : in  STD_LOGIC;
           inp : in  STD_LOGIC;
           leds : out  STD_LOGIC_VECTOR (7 downto 0));
end Metastable;

architecture Behavioral of Metastable is
signal ffS : std_logic := '0';
signal ffA : std_logic := '0';
signal ffB : std_logic := '0';
signal cnt : unsigned(7 downto 0) := (others=>'0');
begin
   process begin
      wait until rising_edge(clk);
      ffS <= inp; -- Sync-Flipflop
      ffA <= ffS;
      ffB <= ffS;
   end process;

   process begin
      wait until rising_edge(clk);
      if (ffA /= ffB) then
         cnt <= cnt+1;
      end if;
   end process;
   
   leds <= std_logic_vector(cnt);
end Behavioral;

Allerdings ergibt sich mit den Standardeinstellungen folgendes Ergebnis:

INFO:Xst:2261 - The FF/Latch <ffA_3> in Unit <Metastable> is equivalent to the following FF/Latch, which will be removed : <ffB_3>
WARNING:Xst:1896 - Due to other FF/Latch trimming, FF/Latch <cnt_7> has a constant value of 0 in block <Metastable>.
WARNING:Xst:2677 - Node <sr1_0> of sequential type is unconnected in block <Metastable>.
# Counters                                             : 1
   8-bit up counter                                      : 1
# Registers                                            : 1
   Flip-Flops                                            : 1
# Xors                                                 : 1
   1-bit xor2                                            : 1

Und quasi als Ausrufezeichen:
Clock Information: No clock signals found in this design

Die Synthese hat also erkannt, dass beide Flipflops ffA und ffB das selbe machen. Sie hat eines der beiden Register herausoptimiert und dann ermittelt, dass der Vergleicher überflüssig, und damit der Ausgangswert für die LEDs immer 0 ist.

Also muß erst mal das Wegoptimieren des Schieberegisters unterbunden werden.
Der Versuch, das Attribut KEEP auf die Schieberegister anzuwenden, funktioniert nicht.
Erst das Ändern der Syntheseoption --> Xilinx Specific Options --> Equivalent Register Removal auf unchecked ergibt dieses Ergenbis:

Macro Statistics
# Registers : 11
Flip-Flops : 11

Erst mit dieser Einstellung werden auch tatsächlich 3 Flipflops und der 8-Bit-Zähler implementiert.

Mit diesem Aufbau wird erkennbar, dass bei handelsüblichen Taktfrequenzen (<100MHz) der Zähler nichts zu tun hat. Es werden keine metastabilen Zustände erkannt. Bis zur jeweils nächsten Taktflanke hat sich am Ausgang des ffS ein stabiler Pegel eingestellt.
Erst bei sehr hohen Taktfrequenzen (>300MHz) zählt der Zähler cnt ab und zu hoch. Xilinx sagt in der AppNote XAPP094 dazu, dass aktuelle FFs in FPGAs sehr schnell sind und sich Metastabilität erst bei sehr hohen Taktfrequenzen bemerkbar machen kann.

Wer jetzt aber meint, externe Signale nicht mehr einsynchronisieren zu müssen, geht auf dem Holzweg. Denn was sich durchaus signifikant bemerkbar macht, sind Laufzeitunterschiede im Routing eines Signals. Hier lassen wir das Synchronisierungs-FF einfach mal weg

architecture Behavioral of Metastable is
signal ffA : std_logic := '0';
signal ffB : std_logic := '0';
signal cnt : unsigned(7 downto 0) := (others=>'0');
begin
   process begin
      wait until rising_edge(clk);
      ffA <= inp;
      ffB <= inp;
   end process;

   process begin
      wait until rising_edge(clk);
      if (ffA /= ffB) then
         cnt <= cnt+1;
      end if;
   end process;
   
   leds <= std_logic_vector(cnt);
end Behavioral;

Und mit dieser Implementation ist dann in der realen Hardware zu sehen, dass der Zähler bei Änderungen des Signals inp doch recht oft hochzählt. Es wird also, obwohl beide Schieberegister das selbe Eingangssignal erhalten, manchmal ein unterschiedlicher Pegel erkannt. Dies kann leicht anhand des Schaltplans erkannt werden.

Verzögerung durch Routing im FPGA

Hier braucht z.B. das Signl inp bis zum ffA wegen eines aufwendigeren Routings länger. Wenn in der Zwischenzeit eine Flanke des Taktsignals kommt, dann haben die beiden FF unterschiedliche Pegel für das Signal inp gespeichert.

Wenn die Schaltung jetzt nicht so einfach wäre, sondern z.B. eine Statemachine, dann würden diese beiden Komponenten ab und zu ein unterschiedliches Eingangssignal sehen und entsprechend falsch reagieren. Dazu näheres und ein anschauliches Beispiel im folgenden Beitrag.

Fazit: Weil Metastabilität ein statistischer Prozess ist und eigentlich 1 Flipflop schon reichen würde, aber Ingenieure gerne 100% Sicherheit einkalkulieren, gilt

Jedes asynchrone Signal sollte über mindestens zwei Flipflops eingetaktet werden.

State-Machine mit asynchronem Eingang

nospam@example.com (Lothar Miller) — Fri, 02 Oct 2009 18:57:00 +0200

Warum sollten externe Signale einsynchronisiert werden?
Meist wird dabei auf das Hammerargument "Metastabilität" von Flipflops verwiesen und damit jede weitere Frage automatisch abgewürgt. In der Praxis ist Metastabilität aber weniger verbreitet als man denkt. Moderne FFs in FPGAs fangen sich nach kürzester Zeit wieder (<2ns) und haben dann am Ausgang einen stabilen Pegel. 500MHz? Da kann eigentlich nichts mehr schiefgehen. Damit sind wir also wieder bei der Frage:

Warum sollten externe Signale einsynchronisiert werden?
Externe Signale müssen einsynchronisiert werden, weil sie idR. zwar an einer Stelle (am Pin) ins FPGA hineingehen, dort aber dann im Routing wild hin- und herverdrahtet werden und u.U. über Kombinatorik an etlichen FFs ankommen. Und hier kann es dann durchaus sein, dass ein paar FFs schon eine '1' erkennen, wenn andere noch meinen es gelte die vorhergehende '0'. Als Beispiel hier eine kleine State-Machine, die das verdeutlicht.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity FSM_AsyncInp is
    Port ( clk  : in  STD_LOGIC;
           inp  : in  STD_LOGIC;
           outp : out STD_LOGIC_VECTOR (1 downto 0));
end FSM_AsyncInp;

architecture Behavioral of FSM_AsyncInp is
signal state : std_logic_vector (1 downto 0) := "00";
begin
   process begin
      wait until rising_edge(clk);
      case (state) is 
         when "00" => if (inp='0') then state<="01"; end if;
         when "01" => if (inp='1') then state<="10"; end if;
         when "10" => state<="00";
         when others => Null;
      end case;      
   end process;
   outp <= state;
end Behavioral;

Ausgehend vom Zustand "00" geht es abhängig vom inp zum Zustand "01", von dort weiter zum Zustand "10", um danach wieder bei "00" anzufangen. Der Zustand "11" ist nicht definiert und kann eigentlich nicht auftreten. Soweit alles klar.

Wenn wir aber mal den erzeugten Plan dieser FSM ansehen, dann sind dort die beiden FF zu sehen und davor jeweils die Kombinatorik, die zum Weiterschalten verwendet wird. Hier ist das jeweils ein AND, auf das die entsprechenden Zustandssignale und der Eingang inp aufgeschaltet sind. Sehen wir uns mal den Zustand "01" genauer an:

Die FSM im Zustand "01"

Der Zustand ist stabil, solange am Eingang inp '0' anliegt. Dann wird über die beiden AND der Pegel an den Eingängen der FFs weiterhin auf "10" gehalten. Mit einem Wechsel des Eingangs inp nach '1' kurz vor einer steigenden Flanke des Taktsignals kann jetzt folgendes passieren:

Fehlerhafter Übergang in den undefinierten Zustand "11"

Das AND B erkennt schon die '1' und schaltet an den Eingang des linken FF eine '1'.
Am AND A ist aber noch die '0'. Zusammen mit der '0' vom aktuellen Zustand ergibt das auch am Eingang des rechten FF eine '1'. Und genau jetzt kommt der Takt. Ergebnis: beide FF schalten eine '1' auf ihren Ausgang durch, die FSM hat den ungültigen Zustand "11" erreicht.

Der Folgezustand, der mit der nächsten Taktflanke eingenommen wird, ist danach übrigens nicht "00" sondern wieder "10", die FSM ist komplett aus dem Tritt geraten. Auch interessant ist, dass die FSM den Zustand "11" keineswegs hält (so etwas könnte man ja aus dem VHDL-Code ableiten), sondern irgendwie weitermacht.

Einsynchronisieren von asynchronen Signalen

nospam@example.com (Lothar Miller) — Sun, 26 Apr 2009 07:52:11 +0200

Man hört immer wieder vom Eintakten oder Einsynchronisieren von Signalen. Mache man das nicht, so heißt es, komme man in Teufels Küche.
Und es ist tatsächlich so: Wer irgendwelche (asynchronen) externen Signale in seinem FPGA-Design verwendet, wird früher oder später das Problem bekommen, dass "es eigentlich funktioniert". Aber einmal pro Stunde, oder Tag, oder Woche passieren eigenartige Sachen. Das Unangenehme dabei ist, dass die Fehlerforschung so unwahrscheinlich schwer ist, weil
1. Die Fehler nur selten und nicht unbedingt reproduzierbar auftreten,
und
2. Die Fehlerbilder gar nicht auf die eigentliche Fehlerursache hindeuten.

Was ist aber jetzt dieses Eintakten?
Fangen wir mit einem einfachen aber trotzdem treffsicheren mechanischen Modell an. Eine Kugel liegt in einer gebogenen Bahn und kann dort nur 2 definierte Zustände annehmen. Nennen wir diese Zustände '1' und '0'.

Die Kugel, die den Zustand des Flipflops darstellt, muß über den Berg von Low nach High geschoben werden. Es ist also eine Mindestenergie nötig, die zum Umschalten des Zustands verwendet wird.

Reicht die Energie nicht aus, dann kann es sein, dass die Kugel nicht ganz zum anderen Zustand überwechselt. Sie bleibt dann u.U. auf einem undefinierten, metastabilen Zustand, und findet erst nach einiger Zeit einen definierten Pegel.

Auch ein Flipflop kann 2 nur definierte Pegelzustände annehmen: High und Low. Die Energie, die zum zuverlässigen Umschalten vom einen in den anderen Zustand nötig ist, wird hier über die Zeit definiert, die das Signal vor und nach der Taktflanke stabil sein muß. Diese Mindestzeiten heißen Setup-Zeit tsu und Hold-Zeit th.

Werden diese Zeiten verletzt, kann es sein, dass der Ausgang (jeweils nach Ablauf der Clock-To-Output Zeit tco) keinen stabilen Zustand erreicht hat und erst wieder auf einen definierten Pegel zurückfinden muss. Dieses Stabilisieren geht relativ schnell, so dass bei der nächsten Taktflanke idR. bereits wieder ein definierter Pegel vorliegt.

Jetzt könnte man ja sagen:
Dann ist ja alles gut, warum die ganze Aufregung?

Hier die Auflösung: in einem FPGA sind viele FFs an irgendwelche Eingänge angeschlossen. Und wenn dann im Zweifelsfall einige dieser FFs (ausgehend vom gleichen Eingangssignal) nach dem Stabilisieren je nach Platzierung oder Bauteiltoleranzen eine '1' haben und andere eine '0', dann kann man sich vorstellen, dass hier irgendwann mal was schiefgehen wird.

Zum oberen FF kommt die Flanke des Eingangssignals früher, zum unteren FF später. Auch wenn das nur Bruchteile von ns sind, ergeben sich bei Verletzung der Setup- und Hold-Zeiten an den FF-Ausgängen unterschiedliche Zustände.
Im Besonderen gilt dies, wenn so ein asynchrones Eingangssignal zum Weiterschalten in einer State-Machine verwendet wird. Wenn hier 2 FFs einen unterschiedlichen Zustand einnehmen, nimmt u.U. die ganze State-Machine einen falschen Zustand ein.

Kurz zusammengefasst: für der Übergang zwischen zwei Taktdomänen und allgemein zum Eintakten von externen asynchronen Signalen (Taster, Schalter, Encoder, ...) müssen diese Signale daher über zwei Flipflops eingetaktet werden. Dies kann z.B. so gemacht werden:

Hier der VHDL-Code dazu:

signal ff1_out  : std_logic;
signal ff2_out  : std_logic;
:
process begin -- Einsynchronisieren
   wait until rising_edge(clk);
   ff1_out <= async_in;
   ff2_out <= ff1_out;
end process;

process begin 
   wait until rising_edge(clk);
   if (ff2_out = '1') then   -- Synchronisierten Eingang verwenden
   :   end if;   
end process;

Schöner liest sich sowas allerdings, wenn ein Schieberegister (hier: insr) eingesetzt wird:

signal insr  : std_logic_vector(1 downto 0);
:
process begin -- Einsynchronisieren
   wait until rising_edge(clk);
   -- Schieberegister
   insr <= insr(0) & input;
end process;

process begin 
   wait until rising_edge(clk);
   if (insr(1) = '1') then   -- Synchronisierten Eingang verwenden
   :   end if;   
end process;

Daraus lässt sich dann auch schnell eine synchrone Flankenerkennung basteln. Dazu muss nur ein weiteres FF dazugehängt werden, damit Pegelwechsel erkannt werden können:

signal insr  : std_logic_vector(2 downto 0);
:
process begin
   wait until rising_edge(clk);
   -- Schieberegister
   insr <= insr(1 downto 0) & input;
end process;

process begin
   wait until rising_edge(clk);
   if (insr(2 downto 1) = "10") then 
      -- fallende Flanke von input
   end if;
   if (insr(2 downto 1) = "01") then 
      -- steigende Flanke von input
   end if;
end process;

Natürlich kann mit einem Schieberegister auch ein paralleler Bus eingetaktet werden:

     bus : in std_logic_vector(7 downto 0); 
:
type SRBusTyp is array (1 downto 0) of std_logic_vector(7 downto 0); 
signal srbus : FeldTyp;
:
process begin -- Schieberegister   wait until rising_edge(clk);   
   srbus <= srbus(0) & bus;
end process;

process begin
   wait until rising_edge(clk);
   if (srbus(1)(3)='1') then 
      :
   end if;
end process;

Allerdings ist es im Allgemeinen nicht sinnvoll, z.B. einen Datenbus einzusynchronisieren. Beim Einsynchronisieren eines 4-Bit Datenbusses, der z.B. von "0000" nach "1111" wechselt, können zwischendurch auch z.B. die Zustände "0001", "0101", "1010", oder jeder der insgesamt 14 ungültigen Zustände auftreten.
Hier ist der bessere Weg, die Daten vom Bus mit einem Validierungssignal (z.B. steigende Flanke von Write#) in FFs zu übernehmen (also direkt in FFs eintakten), und nur das Write# Signal einzusynchronisieren, und eine synchrone Flankenerkennung zur Datenweitergabe zu verwenden:

     db  : in std_logic_vector(7 downto 0);  -- Datenbus 
     wrn : in std_logic;                     -- Schreibsignal, low-aktiv
:
signal intdb : std_logic_vector(7 downto 0); 
signal wrnsr : std_logic_vector(2 downto 0);
:
process begin -- Daten lokal mit wrn eintaken
   wait until rising_edge(wrn);
   intdb <= db;
end process;

process begin -- Schieberegister fuer Schreibsignal
   wait until rising_edge(clk);
   wrnsr <= wrnsr(1 downto 0) & wrn;
end process;

process begin -- synchrone steigende Flanke wrn 
   wait until rising_edge(clk);
   if (wrnsr(2 downto 1) = "01") then 
      :
   end if;
end process;

Nicht zu vergessen:
Das asynchronste Signal schlechthin ist der externe RESET.
Der gehört zwingend einsynchronisiert, denn sonst kann z.B. durch einen kurzen ESD-Spike das FPGA nur partiell zurückgesetzt werden. Am besten ist, nur dort einen Reset zu verwenden, wo wirklich einer nötig ist. Und dann den Reset einzusynchronisieren und nur synchron zu verwenden:

  reset : in std_logic; -- Resetsignal
:
signal resetsr : std_logic_vector(1 downto 0);
:
process begin -- Einsynchronisieren
   wait until rising_edge(clk);
   resetsr <= resetsr(0) & reset;
end process;

process begin 
   wait until rising_edge(clk);
   : -- normale Bearbeitung
   if (resetsr(1)='1') then
     : -- Reset-Bearbeitung, letzte Zuweisung im Prozess gilt.
   end if;
end process;

Und eines sollte man sich immer im Hinterkopf behalten:Eine metastabile Situation lässt sich durch keine wie auch immer geartete Maßnahme vermeiden. Jeder "Lösungsvorschlag" in dieser Richtung beruht stets auf einem Denkfehler, der das Auftreten der Metastabilität an irgendeiner Stelle ignoriert. Durch das Hintereinanderschalten von mehreren Abtaststufen (Flip-Flops) kann lediglich die Wahrscheinlichkeit und die Auswirkungen des Fehlers beliebig stark reduziert werden.