Getakteter Prozess

Warum sollte man keinen (wirklich) asynchronen Reset in einem FPGA-Design verwenden?
Was ist denn eigentlich am asynchronen Reset so schlimm?

Es gibt mehrere Argumente gegen einen solchen Reset:

****************************************
Die Flipflops im FPGA (hier Xilinx) können in zwei Modi betrieben werden:
1) als asynchrones FF mit asynchronen Clear- und Preset-Eingängen
2) als synchrones FF mit synchronen Set- und Reset-Eingägen
Wenn die übliche Lehrbuch-VHDL-Schreibweise eines getakteten Prozesses verwendet wird:

process (reset,clk)
begin
   if reset = '0' then
       :
   elsif rising_edge(clk) then
       :
   end if;
end process;

dann muß die Synthese das FF asynchron mit Clear und Preset konfigurieren. Sie kann dann z.B. einen synchronen Zählerreset nicht auf den Reset-Eingang legen, weil ja gar kein solcher Eingang vorhanden ist. Der synchrone Zählerreset muß dann mit zusätzlicher Logik und mehr Verdrahtungsaufwand aufgebaut werden. Dies resultiert in einem erhöhten Ressourcenverbrauch und in einem langsameren Design, weil evtl. eine Logikebene mehr eingefügt werden muß. Hier finden sich ausführliche Erklärungen und Untersuchungen zum Thema:
http://www.mikrocontroller.net/topic/108606
http://www.mikrocontroller.net/topic/110266

****************************************
Wesentlich schlimmer als nur der zusätzliche Ressourcenverbrauch ist aber, dass ein asynchroner Reset zu undefiniertem Verhalten des Designs beim Verlassen des Resetzustands führen kann. Aufgrund unterschiedlicher Laufzeiten innerhalb des FPGAs sehen einzelne Register den Reset zeitverzögert weggehen. Wenn dann gerade ein Takt kommt, kann es sein, dass die eine Hälfte des FPGAs noch im Resetzustand ist, die andere Hälfte aber schon arbeitet.

Hier eine einfache Beschreibung mit einem Vektor (= ein paar Register), der im Reset auf einen definierten Wert gesetzt wird. Nachdem der Reset weggenommen ist, wird der Vektor mit jedem Takt getoggelt und gleichzeitig auf die beiden gültigen Werte verglichen. Ist der Wert des Vektors ungleich des Resetwerts oder seines Komplements, dann haben nicht alle FFs gleichzeitig den Resetzustand verlassen. Wären das jetzt keine Register eines simplen Vektors, sondern FFs einer State-Machine, dann hätte diese gleich nach dem Reset einen beliebigen Zustand eingenommen.

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

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

architecture Behavioral of AsyncReset is
signal x : std_logic_vector(15 downto 0) := x"5555";
signal error : unsigned(7 downto 0) := x"00";
begin
   process (clk,rst) begin
      if rst='0' then                        -- asynchroner Reset low aktiv
         x <= x"AAAA";
      elsif rising_edge(clk) then
         x <= not x;                         -- alle Register toggeln         
         if (x/=x"5555" and x/=x"AAAA") then -- wenn ungleich:   
            error <= error+1;                -- Fehler mitzählen
            x <= x"AAAA";                    -- mit definierten Wert weitermachen
         end if;
      end if;
   end process;
   leds <= std_logic_vector(error);          -- auf LEDs ausgeben
end Behavioral;

process (a,b,c,clk)
begin
   if a='0' and b='1' and c='0' then
       :
   elsif rising_edge(clk) then
       :
   end if;
end process;

process (reset,clk)
begin
   if reset = '1' then          -- sieht zwar schön aus...
       :
   elsif rising_edge(clk) then
       :
   end if;
end process;

reset <= not a and b and not c; -- ... ist aber trotzdem kombinatorisch

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:

Schrittkette aus wait Anweisungen generiert

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

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_std.ALL;

entity Beispiel is
    Port ( clk  : in  STD_LOGIC;
           inp  : in  STD_LOGIC_VECTOR (7 downto 0);
           outp : out STD_LOGIC_VECTOR (7 downto 0);
           sel  : in  STD_LOGIC);
end Beispiel;

architecture Behavioral of Beispiel is
begin
   -- Prozess ohne Sensitiv-Liste
   process begin
      wait until rising_edge(clk);
      if (sel1='1') then
         outp <= inp;
      else
         outp <= not inp;
      end if;
   end process;   
end Behavioral;

1) Durch das Fehlen der Sensitvity-Liste funktioniert die Simulation immer wie die Hardware. Es können keine Signale in der Liste "vergessen" werden, was bekanntermaßen zu Unterschieden zwischen Simulation und Realitiät führt.

2) Durch das Fehlen der Sensitvity-Liste kann es keine asynchronen Teile des Prozesses geben. Der Prozess ist quasi automatisch synchron.

3) Es wird zum Formatieren des Quelltextes eine Indent-Ebene (Einrück-Ebene) gespart.


Ein Beispiel zum Thema unvollständige Sensitiv-Liste (Punkte 1 und 2) gibts hier.
Mal angenommen, ich habe in einer Beschreibung einen Fehler gemacht und bei der Beschreibung eines Taktes das  and clk'event  vergessen:

process (reset,clk) begin -- Sensitiv-Liste unvollständig, 
                          -- weil "and clk'event" fehlt, müsste "inp" 
                          -- für eine korrekte Simulation mit aufgenommen werden
   if (reset='1') then
      outp <= '0';
   elsif (clk='1') then   -- hier wurde "and clk'event" vergessen  
      outp <= inp;
   end if;
end process;

Durch das fehlende clk'event wird bei der Synthese ein Latch (Kombinatorik) erzeugt: wenn reset = '0' und clk = '0' sind, dann (und nur dann) wird der Wert von inp in outp gespeichert. In der Simulation sieht diese Beschreibung allerdings wegen der unvollständigen Sensitivity-Liste genauso aus wie diese getaktete korrekte Beschreibung:

process (reset,clk) begin
   if (reset='1') then
      outp <= '0';
   elsif (clk='1' and clk'event) then
      outp <= inp;
   end if;
end process;