Lothar Miller

FIFO (First-InFirst-Out) sind Pufferspeicher für den Übergang von schnellen Übertragungspfaden auf langsamere (z.B. USB ==> RS232). Hier werden Daten in einen Ringpuffer eingespeichert, und später mit einer niedrigeren Datenrate ausgelesen.

Alternativ können Daten von einem langsamen Medium zwischengespeichert, und dann in einem Paket auf einem schnelleren Datenpfad übertragen werden.

Ein FIFO wird demzufolge am einfachsten über einen 2^n langen Ringspeicher realisiert, der mit 2 Zählern der Breite n adressiert wird. Ist der Schreibzeiger gleich dem Lesezeiger, dann ist der FIFO leer. Erreicht der Schreibzeiger den Wert des Lesezeigers-1, dann ist der FIFO voll, der Schreibzeiger hat den Lesezeiger quasi "von hinten" eingeholt.

Immer wieder gibt es in synchronen Designs das Problem, dass auch Eingangsimpulse auftreten können, die kürzer als die Abtastperiode sind. Wenn zum Beispiel die Taktfrequenz 50MHz (==> Zykluszeit 20ns) beträgt, der kürzeste Eingangspuls aber nur 19ns sein könnte, dann kann dieses Signal nicht zuverlässig eingetaktet und ausgewertet werden.

Ein Ausweg bietet hier, das Signal direkt am Pin in einem Merker-Flip-Flop asynchron zu speichern und dann einzusynchronisieren. Nach dem Eintakten wird das Merker-FF zurückgesetzt. Eine steigende Flanke wird so, unabhängig von ihrer Dauer, einen Impuls mit einer Dauer von 1 Taktzyklus ausgeben.

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

entity Spikedetector is
    Port ( clk      : in  STD_LOGIC;
           spikein  : in  STD_LOGIC;
           spikeout : out STD_LOGIC);
end Spikedetector;

architecture Behavioral of Spikedetector is
signal sr0    : std_logic := '0';
signal sr1    : std_logic := '0';
signal merkin : std_logic := '0';
begin
   -- Merker-FF
   process (sr1, spikein) begin
      if (sr1 = '1') then 
         merkin <= '0';
      elsif rising_edge(spikein) then 
         merkin <= '1'; 
      end if;
   end process;
   
   -- Asynchrones Merker-FF eintakten
   process begin
      wait until rising_edge(clk);
      if(sr1='1') then 
         sr0 <= '0'; 
         sr1 <= '0'; 
      else
         sr0 <= merkin; 
         sr1 <= sr0; 
      end if;
   end process;
   
   -- Flanken-Impulse ausgeben
   spikeout <= sr1;
end Behavioral;

Daraus wird das hier. Hier erkennt man, dass für das Merker-FF ein asynchrones FF mit Clear-Eingang verwendet wurde. Die Synchronisations-FFs sind synchron, da auch das Zurücksetzen taktsynchron geschieht.

Und so sieht das in der Simulation aus. Man erkennt, dass auch längere Pulse nur einen (1) Augangspuls ausgeben.

Manchmal hat man das Problem, dass ein Eingangsignal prellt, man aber nicht warten kann, bis das Prellen aufgehört hat. Eine Auswertung des Flankenwechsels soll schnellstmöglich, quasi beim ersten Prellen ausgelöst, nachfolgende Preller aber ignoriert werden. Als Bais dient dieses Signal:

Hier kann die Schieberegister-Entprellung wieder ganz einfach verwendet werden. Allein durch das Ändern des Vergleichswertes wird praktisch die Schaltempfindlichkeit der Erkennung angepasst.

if (sr="11111110")...   << sofort beim Wechsel 1->0
if (sr="11110000")...   << bei "sauberer Flanke" 1->0 (kritisch)
if (sr="10000000")...   << wenn Wechsel 1->0, und 0 liegt stabil

Kritisch ist die mittlere Abfrage, weil u.U. Flanken nicht erkannt werden, wenn vor und nach der Flanke keine stabilen Signale anliegen und das Signal  z.B. so aussieht:



Keine dieser unsauberen Flanken wird von dieser 2. Variante erkannt werden.

Hier der VHDL Code der Flankenerkennung:

:
signal sr     : std_logic_vector(7 downto 0);
signal flanke : std_logic;
signal pegel  : std_logic;
:
process (clk)
begin
   if rising_edge(clk) then
      -- Schieberegister
      sr <= sr(6 downto 0) & eingang;
      -- Flankenerkennung, 1 Sync-FF, dann sofort reagieren
      flanke <= '0';
      if (sr="11111110") then flanke <= '1' end if; -- fallend
      if (sr="00000001") then flanke <= '1' end if; -- steigend
      -- Entprellen
      if (sr="11111111") then pegel <= '1' end if; -- high
      if (sr="00000000") then pegel <= '0' end if; -- low
   end if;
end process;
:

Beim Anschluss eines Quarzes ist besonders darauf zu achten, dass die von den Strömen eingeschlossene Fläche möglichst klein ist.

Dies hat zwei Gründe:

1. in eine kleine Stromschleife können von aussen weniger Störungen einkoppeln.
   Damit ist die Störempfindlichkeit und das Rauschen des Oszillators besser.
2. aus einer kleinen Stromschleife können nach aussen weniger Störungen auskoppeln.
   Damit ist die Störabstrahlung (EMV) besser.

Mit einem Bild ist der Kern der Sache leicht zu erkennen:
Der Strom, der aus dem Ausgang des Inverters herauskommt (ROT) sollte auf dem kürzest möglichen Weg wieder am nächstliegenden Massepunkt in den Controller zurückfliessen können. Darüber hinaus muß die Rückkoppel-Schleife (BLAU) vom Ausgang des Inverters über den Quarz zum Eingang des Inverter möglichst klein sein, damit keine Störsignale eingefangen werden können.

In der Praxis könnte das z.B. so aussehen:

Quarz komplett freigestellt

Unter dem Quarz sollten niemals irgendwelche Signale durchgeführt werden (und schon gar keine steilflankigen digitalen Signale). Am einfachsten gelingt das, indem auch die Massefläche so freigestellt wird, dass keine Rückströme in der Massefläche auf die Oszillatorbeschaltung einkoppeln.
Signifikant besser ist allerdings eine lokale Masseinsel, die an den Oszillator-GND-Pin des ICs angebunden ist. Das ist auch die übliche Empfehlung in den einschlägigen AppNotes und Designrules:

Lokale Masseinsel für den Quarz

Eine solche Masseinsel kann z.B. in Eagle ganz einfach durch einen Wire mit der Breite 0 erzeugt werden, der um den Quarz herum in die allgemeine Massefäche eingezeichnet wird. Über die Designrules Distance Wire-to-Wire wird dann die Breite der Isolation eingestellt.

Wenn das Gehäuse aus ESD-Gründen oder wegen der mechanischen Festigkeit z.B. mit einem Drahtbügel auf der Platine befestigt wird, dann sollte die Massefläche unter dem Quarz über den Oszillator-Ground auf die allgemeine Masse geführt werden.

Getrennte Massefläche für OscGND

Auch Atmel hat das Problem erkannt und eine AppNote dazu verfasst. In der AVR186 finden sich genau die oben angesprochenen Punkte wieder.

Und in der AppNote SLAA276A von Texas Instruments noch ein Beispiel, wie man es nicht machen sollte. Dort sieht man auf der Seite 26 links einen TUSB3410, der eigentlich eine optimale Anordnung der Oszillatorpins hat: 26+27 Oszillator, 28 Masse. Aber leider wurde die Masseführung nur schlecht ausgeführt. Hier der relevante Layout-Ausschnitt:

Schlechtes Layout des Oszillators

Hier findet sich auch noch ein Vorschlag, wie man das Quarzlayout gestalten sollte:
>http://www.mikrocontroller.net/Mischpultlayout bitte um Review

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;