Lothar Miller

Immer wieder taucht die Frage auf, ob mehrere wait-Statements im Prozess synthetisierbar sind. Die Antwort dazu heißt: "Ja, aber es gelten signifikante Einschränkungen".

Aber zuerst mal die Grundlagen. Ein verzweifelter Mensch möchte sowas synthetisieren:

---

entity wait_im_process is
    Port ( din  : in   STD_LOGIC;
           dout : out  STD_LOGIC := '0';
           clk  : out  STD_LOGIC := '0');
end wait_im_process;

architecture Behavioral of wait_im_process is
begin

  process begin
    dout <= '0';
    wait for 10ns;
    clk <= '1';
    wait for 10ns;
    clk <= '0';
    dout <= '0';
    wait for 10ns;
    clk <= '1';
    wait for 10ns;
    clk <= '0';
    dout <= din;
    wait for 10ns;
    dout <= '1';
    wait for 10ns;
    clk <= '0';
    dout <= '1';
    wait for 10ns;
  end process;

end Behavioral;

---

Klar, sagt jetzt jemand, so geht das nicht, weil Zeiten nicht synthetisierbar sind. Für zeitliche Abläufe auf dem FPGA muß eine Statemachine mit einem entsprechenden Takt (10ns=100MHz) her, die einen Schritt nach dem anderen abarbeitet. Schade, das bedeutet viel Umschreibarbeit.

---

architecture Behavioral of wait_im_process is
signal cnt : integer range 0 to 6;
begin

  process begin
    wait until rising_edge(clk100MHz);
    case cnt is
      when 0 => dout <= '0';
      when 1 => clk <= '1';
      when 2 => clk <= '0';
                dout <= '0';
      when 3 => clk <= '1';
      when 4 => clk <= '0';
                dout <= din;
      when 5 => dout <= '1';
      when 6 => clk <= '0';
                dout <= '1';
    end case;
    if (cnt<6) then cnt <= cnt+1;
    else            cnt <= 0;
    end if;
  end process;

end Behavioral;

---

Aber was wäre, wenn ich das Ausgangs-Beispiel einfach nur auf einen Takt mit 10ns Zyklusdauer beziehe und von dem z.B. auf die steigende Flanke reagiere? So etwa:

---

entity wait_im_process is
    Port ( clk10ns : in  STD_LOGIC;
           din  : in   STD_LOGIC;
           dout : out  STD_LOGIC := '0';
           clk  : out  STD_LOGIC := '0');
end wait_im_process;

architecture Behavioral of wait_im_process is
begin

  process begin
    dout <= '0';
    wait until rising_edge(clk10ns);
    clk <= '1';
    wait until rising_edge(clk10ns);
    clk <= '0';
    dout <= '0';
    wait until rising_edge(clk10ns);
    clk <= '1';
    wait until rising_edge(clk10ns);
    clk <= '0';
    dout <= din;
    wait until rising_edge(clk10ns);
    dout <= '1';
    wait until rising_edge(clk10ns);
    clk <= '0';
    dout <= '1';
    wait until rising_edge(clk10ns);
  end process;

end Behavioral;

---

Geht sowas?
Ja, die Synthesetools (zumindest von Xilinx) sind so schlau und erkennen, dass das ganze eine Schrittkette darstellt und mithin eine Statemachine ist. Und die wird dann auch daraus generiert:

 

Rechts oben ist die Statemachine, die aus der Anweisungsfolge erzeugt wurde. Danach kommen Vergleicher, die den entsprechenden Wert auf die Ausgangs-FFs schalten.

 

Die schlechte Nachricht ist, dass diese Schrittkette nur geradeaus durchläuft. Es gibt keine Möglichkeit, den Ablauf anzuhalten oder zu ändern, weil die States keinen Namen haben und somit auch keiner gezielt ausgewählt werden kann.
Das mit dem Anhalten kann mit einem bösen Trick umgangen werden, indem einfach ein Clock-Enable Signal verwendet wird:

---

  process begin            
    if enable ='1' then
      dout <= '0';
      wait until rising_edge(clk10ns);
      clk <= '1';
      :
      wait until rising_edge(clk10ns);
    end if;
  end process;

---

Allerdings muß dafür die Warnung
The following signals are missing in the process sensitivity list: enable
in Kauf genommen werden. Das heißt, dass die Simultion nicht mehr der Realität entspricht. Der Versuch, die Sensitivity-List zu vervollständigen gibt allerdings einen Fehler:
statement WAIT not allowed in a process with a sensitivity list
Also wie gesagt: ein übler Trick.

Einzelne wait-Abschnitte mit einem Clock-Enable zu versehen klappt dann überhaupt nicht mehr:

---

  process begin            
    dout <= '0';
    wait until rising_edge(clk10ns);
    clk <= '1';
    :
    if enable ='1' then
      wait until rising_edge(clk10ns);
    end if;
    clk <= '0';
    dout <= '1';
    wait until rising_edge(clk10ns);
  end process;

---

Dieser Versuch gibt den Fehler
Recurse wait not supported or bad place of Exit or Next statement

Was tun, wenn ein std_logic_vector den Bereich (0 downto 0) hat, und dessen Elemente auf andere Signale abgebildet werden müssen?

Die Lösung ist ganz einfach: es wird nur das 0. Element des Vektors verwendet

---

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity VectAssign is
    Port ( dins  : in  STD_LOGIC;
           dos   : out STD_LOGIC;
           dinv  : in  STD_LOGIC_VECTOR (0 downto 0);
           dov   : out STD_LOGIC_VECTOR (0 downto 0));
end VectAssign ;

architecture Behavioral of VectAssign is
begin
   dov(0) <= not dinv(0) and     dins;
   dos    <=     dinv(0) and not dins;
end Behavioral;

---

Aus dieser Beschreibung macht die Synthese dann folgendes:

Zufallszahlen erzeugt man im FPGA am einfachsten mit einem LFSR (Linear Feedback Shift Register). Im deutschen Sprachraum darf man auch Linear rückgekoppeltes Schieberegister dazu sagen.

Hier der Code für ein 8, ein 16 und ein 32-Bit-Schieberegister:

---

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

entity LFSR is
    Port ( clk     : in  std_logic;
           value32 : out  std_logic_vector (31 downto 0);
           value16 : out  std_logic_vector (15 downto 0);
           value8  : out  std_logic_vector ( 7 downto 0));
end LFSR;

architecture Behavioral of LFSR is
signal rnd32 : std_logic_vector (31 downto 0) := (others=>'0');
signal rnd16 : std_logic_vector (15 downto 0) := (others=>'0');
signal rnd8  : std_logic_vector ( 7 downto 0) := (others=>'0');
begin
   process begin
      wait until rising_edge(CLK);
       -- 8Bit
       rnd8(7 downto 1) <= rnd8(6 downto 0) ;
       rnd8(0) <= not(rnd8(7) XOR rnd8(6) XOR rnd8(4));
       -- 16Bit
       rnd16(15 downto 1) <= rnd16(14 downto 0) ;
       rnd16(0) <= not(rnd16(15) XOR rnd16(14) XOR rnd16(13) XOR rnd16(4));
       -- 32 Bit
       rnd32(31 downto 1) <= rnd32(30 downto 0) ;
       rnd32(0) <= not(rnd32(31) XOR rnd32(22) XOR rnd32(2) XOR rnd32(1));
   end process;
   value32 <= rnd32;
   value16 <= rnd16;
   value8  <= rnd8;
end Behavioral;

---

In der Simulation sieht man schon, dass nach einer Anlaufphase (die allerdings auch schon unterschiedliche Werte enthält, das Bild täuscht hier ein wenig) die Zahlen schon optisch recht zufällig aussehen:

Immer wieder kommt die Diskussion auf, ob denn jetzt die Ein- oder Zwei-Prozess-Darstellung von Zustandsautomaten einfacher zu verstehen und implementieren sei.

Wenn man aus der schulmäßigen Logik herkommt, dann wird ein Automat auf eine Weiterschaltlogik (die den Folgezustand ermittelt) und einen Zustandsspeicher abgebildet.

Es wird also eine Abbildung in zwei Prozesse nahegelegt:
1) der eine Prozess übernimmt taktgesteuert den Folgezustand, der
2) vom anderen Prozess aus den Eingangssignalen und/oder dem aktuellen Zustand ermittelt wird.

Damit könnte ein einfacher Automat mit den Zuständen reset, idle, work und done so aussehen:

---

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

entity FSM is
    Port ( clk : in  STD_LOGIC;
           rst : in  STD_LOGIC;
           start : in  STD_LOGIC;
           stop  : in  STD_LOGIC;
           dout  : out  STD_LOGIC_VECTOR (3 downto 0));
end FSM;

architecture Verhalten of FSM is

type state_t is (reset, idle, work, done);
signal state, next_state : state_t := idle;
signal counter, next_counter : unsigned(3 downto 0) := "0000";

begin
   process begin
      wait until rising_edge(clk);
      state   <= next_state;
      counter <= next_counter;
   end process;

   process (state, rst, start, stop, delay, counter)
   begin      
      next_counter <= (others=>'0');
      case state is
         when reset => next_state   <= idle;
                      
         when idle  => if (start='1') then
                          next_state <= work;
                       end if;
        
         when work  => if (stop='1') then
                          next_state <= done;
                       end if;
                       next_counter <= counter+1;

         when done  => if (stop='0') then
                          next_state <= idle;
                       end if;
      end case;
      if (rst='1') then
         next_state <= reset;
      end if;
   end process;
  
   dout <= std_logic_vector(counter);

end Verhalten;

---

Aus dem Zustand idle kommend, wird mit dem Signal start der Zustand work angesprungen. Im Zustand work wird der Zähler solange hochgezählt, bis das Signal stop aktiv wird. Danach geht es über den Zustand done zurück nach idle. Wird der Eingang rst aktiv, so geht es ohne Umleitung in den Zustand reset. Parallel wird der Zähler counter concurrent auf dout ausgegeben.

Weil ein Zähler auch nur eine FSM ist, muß für das Hochzählen von counter in der Kombinatorik der Folge-Zählerstand next_counter ermittelt werden. Dieser wird dann mit dem nächsten Takt auf counter übernommen.

Bis hierher war es eigentlich noch übersichtlich.
Jetzt möchte ich aber gerne das Hochzählen von counter im Zustand work etwas gemächlicher gestalten. Ein Verzögerungszähler für 10 Takte delay (von 0 bis 9) vor dem Hochzählen von counter muß her.
Jetzt könnte ich das Spiel genauso wie mit counter und next_counter machen, aber diesmal bin ich zu faul und nehme den Verzögerungszähler delay einfach gleich in den getakteten Teil:

---

architecture Verhalten of FSM is
type state_t is (reset, idle, work, done);
signal state, next_state : state_t := idle;
signal delay : integer range 0 to 9 := 0;
signal counter, next_counter : unsigned(3 downto 0) := "0000";

begin
   process begin
      wait until rising_edge(clk);
      state   <= next_state;
      counter <= next_counter;

      if(state=idle) then -- in idle: Delay-Zähler zurücksetzen
         delay <= 0;                     
      end if;

      if(state=work) then -- in work: hier wird gezählt
         if (delay < 9) then  -- solange kleiner 9:
            delay <= delay+1; -- zählen
         else
            delay <= 0;       -- sonst zurücksetzen
         end if;
      end if;
   end process;

   process (state, rst, start, stop, delay, counter)
   begin      
      next_counter <= (others=>'0');
      case state is
         when reset => next_state   <= idle;
                      
         when idle  => if (start='1') then
                          next_state <= work;
                       end if;
        
         when work  => if (delay = 9) then           -- wenn das Delay abgelaufen ist:
                          next_counter <= counter+1; -- counter um eins hochzählen
                       end if;
                      
                       if (stop='1') then
                          next_state <= done;
                       end if;
  

         when done  => if (stop='0') then
                          next_state <= idle;
                       end if;
      end case;
      if (rst='1') then
         next_state <= reset;
      end if;
   end process;
  
   dout <= std_logic_vector(counter);

end Verhalten;

---

Fertig. Hurra, die Simulation zeigt, dass es geht:

Aber wer sich den Code ein halbes Jahr später anschaut, wird den Kopf schütteln, und sich fragen, wie und was da wann wozu verwendet wird.

Ich schreibe deshalb meine State-Machines nur noch in der Ein-Prozess-Darstellung. In dieser Darstellungsart wandert einfach nur die Weiterschaltlogik in den getakteten Teil. Das obige Beispiel sieht also so aus:

---

architecture Verhalten of FSM is
type state_t is (reset, idle, work, done);
signal state : state_t := idle;
signal delay : integer range 0 to 9 := 0;
signal counter : unsigned(3 downto 0) := "0000";

begin

   process begin
      wait until rising_edge(clk);
      case state is
         when reset => counter <= (others=>'0');
                       state   <= idle;
                      
         when idle  => delay   <= 0;
                       if (start='1') then
                          state <= work;
                       end if;
        
         when work  => if (delay < 9) then      -- solange kleiner 9:
                          delay <= delay+1;     -- zählen
                       else                     -- sonst:
                          delay   <= 0;         -- zurücksetzen
                          counter <= counter+1; -- und counter hochzählen
                       end if;

                       if (stop='1') then
                          state <= done;
                       end if;

         when done  => if (stop='0') then
                          state <= idle;
                       end if;
      end case;
      if (rst='1') then
         state <= reset;
      end if;
   end process;
  
   dout <= std_logic_vector(counter);

end Verhalten;

---

Diese Ein-Prozess-Beschreibung ergibt genau das selbe Simulationsergebnis, sie hat aber deutliche Vorteile:
1) Deutlich weniger Schreibaufwand und bessere Übersicht
2) Ich brauche weniger Signale (next_counter, next_state)
3) Das Ganze ist garantiert synchron
4) Die Ausgangssignale sind registriert und damit synchron
5) Es werden garantiert keine Kombinatorischen Schleifen erzeugt

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 "geschubst" werden. Es ist also eine Mindestenergie nötig, die zum Umschalten des Zustands verwendet wird.

Reicht die "Anschubs"-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 festgelegt, die das Signal vor und nach der Taktflanke stabil sein muß. Halt, sagt jetzt einer: elektrische Energie berechnet sich aus E = 1/2*C*U², da ist keine Zeit drin! Richtig, aber trotzdem muss die Eingangskapazität des Flipflops auf die Spannung für die nötige Energie aufgeladen werden. Und weil man die internen Widerstände vom Pin zum Flipflop nicht kennt und nicht messen kann, hat sich etabliert, dass man sagt: wenn am Eingangspin der Pegel mindestens x Picosekunden vor dem Taktsignal und y Picosekunden nachher stabil ist, konnte sich der Kondensator des Flipflops soweit aufladen, dass die Energie zum Umschalten sicher reicht. Diese Mindestzeiten heißen
Setup-Zeit  tsu (Dateneingang stabil vor der Taktflanke)  und
Hold-Zeit  th (Dateneingang stabil nach der Taktflanke).

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. Bei aktuellen FPGAs sind deshalb bei Taktfrequenzen bis 200MHz keine metastabilen Effekte zu beobachten!

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. Und zwar unabhängig von der Taktfrequenz!

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 einem "gleichzeitigen" Takt durch Verletzung der Setup- und Hold-Zeiten an den FF-Ausgängen Out1 und Out2 u.U. 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 evtl. die ganze State-Machine einen falschen Zustand ein.
Dieser sehr beliebte Fehler hat annähernd die selben Auswirkungen und Symptome wie metastabile Flipflops. Im Gegensatz zur Metastabilität, die erst ab >>300MHz eine Rolle spielt, kann der hier beschiebene Effekt aber bei jeder Taktfrequenz auftreten, also z.B. auch in einem schnarchlangsamen 1MHz-Design! Und er wird es garantiert irgendwann mal.

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 oder einen Adressbus 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. Daran anschließend wird dann eine synchrone Flankenerkennung auf dem Write# Signal zur Datenweitergabe oder -weiterverarbeitung verwendet:

---

     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 
      -- jetzt kann der eingelesene intdb verwendet werden
      :
   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;

---

Wieviele Flipflops sind nötig?
Solange die Taktfrequenz im moderaten Rahmen (um oder unter 100MHz) ist, reicht es theoretisch aus, wenn Signale mit 1 Flipflop einsynchronisiert werden. Allerdings kann da eine gern verwendete Syntheseoption unsichtbar ganz kräftig in die Suppe spucken: das Register Doubling. Die Flipflops im FPGA haben einen maximalen Fan-Out, der besagt, wie viele Nachfolger (Gatter oder Flipflops) angeschlossen werden dürfen. Sind mehr Nachfolger da, verdoppelt die Synthese einfach das Flipflop und schließt das Eingangssignal parallel an beide Flipflops an. Und genau das macht ja die Probleme: ein asynchrones Signal, das mit unterschiedlichen Laufzeiten an 2 Flipflops angeschlossen ist.

Das zweite Flipflop sorgt da für Klarheit: das erste Flipflop der Synchronisierungsstufe wird sicher nicht verdoppelt, weil sein Fan-Out locker ausreicht, um viele Nachfolger des evtl. verdoppelten zweiten Flipflops zu treiben. Die unterschiedliche Laufzeit macht hier kein Problem und kann von der Toolchain beherrscht werden, das dann nur noch eine Worst-Case Betrachtung nötig ist: wie lange dauert es schlimmstenfalls, bis alle Flipflops der zweiten Stufe einen stabilen Pegel sehen?

Bei externen Signalen wird für die erste Stufe gleich das Flipflop im IO-Block verwendet, so kann dann das Signal gleich danach auf evtl. verdoppelte Flipflops der zweiten Stufe weitergeführt werden.

Obacht!
Eines sollte man sich trotzdem 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.