Lothar Miller - Getakteter Prozess

Asynchroner Reset

nospam@example.com (Lothar Miller) — Wed, 10 Mar 2010 18:15:00 +0100

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;

Mit diesem Testaufbau kann mit ein paar LEDs und einem Taster oder Signalgenerator als Resetquelle das oben beschriebene Verhalten dargestellt werden: obwohl der Vektor x nur "AAAA" oder "5555" sein kann, zählt der Zähler error hoch.
Dies kann mit einer Verhaltensimulation niemals nachvollzogen und herausgefunden werden. Bestenfalls eine aufwendige Post-Route-Simulation würde bei geeigneter und unabhängiger Wahl des Takts in der Testbench evtl. Setup- und Hold-Zeit-Verletzungen anzeigen.

~~****************************************~~
In die selbe Ecke kommt man, wenn der asynchrone Reset dann noch kombinatorisch erzeugt wird:

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;

Hier ist wegen des Auftreten von Glitches bei der kombinatorischen Verknüpfung der Reset sehr anfällig. Es kann sein, dass z.B. in einer FSM nur einzelne FFs beeinflusst werden, und so die Zustandsmaschine ungültige Übergänge macht oder in undefinierten Zuständen landet.
Da hilft es auch nichts, sich selber Sand in die Augen zu streuen, und das Ganze zum Beispiel so zu schreiben:

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

wait im Prozess

nospam@example.com (Lothar Miller) — Tue, 07 Jul 2009 20:20:00 +0200

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

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(clk100MHz);
      clk <= '1';
      :
      wait until rising_edge(clk100MHz);
    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(clk100MHz);
    clk <= '1';
    :
    if enable ='1' then
      wait until rising_edge(clk100MHz);
    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

Takt im Prozess

nospam@example.com (Lothar Miller) — Sun, 19 Oct 2008 13:04:28 +0200

Ich habe lange mit mir gekämpft, bin aber jetzt zum Schluss gekommen, dass diese Beschreibung eines getakteten Prozesses am schönsten und am wenigsten fehlerträchtig ist:

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;