Signal per Taktflanken setten/resetten

[Thaddäus (Gast)]

Moins.
Ich hab ein Signal, welches durch einen Taster auf high gesetzt werden 
soll, um direkt danach, zur steigenden Taktflanke, verwertet zu werden, 
und wieder low gesetzt zu werden. Setzen und Löschen jeweils bei 
steigender Taktflanke. Damit soll eine art Lauflicht (Details spielen 
hier keine Rolle) einen Schritt weiter laufen, aber eben nur EINEN 
Schritt pro Tastendruck, und nicht 100, nur weil der Taster 100 Takte 
lang gedrückt ist. Ich brauch quasi die Funktionalität eines 
SET/RESET-FlipFlops, welches aber nur auf Flanken reagiert. Kann mir 
jemand einen Anstoss geben?
Mfg

[Thaddäus (Gast)]

Scheint sich erledigt zu haben. Hab einfach zwei beide Flanken in einem 
Prozess abgefragt. Ich dachte zwar, sowas wär nicht gut, aber da weder 
Simulation noch Synthese gemuckt haben... na mal sehen.

[Thaddäus (Gast)]

OK, das ganze ist also doch ein Problem. ISE Meckert über das hier

  process(set, reset)
  begin
  if(rising_edge(reset))then
    out_int <= '0' after 5 ns;
  end if;
  if(rising_edge(set))then
    out_int <= '1' after 5 ns;
  end if;
  end process;

Wie krieg ich das in synthesefähig hin?

Mfg, T.

[Clemens M. (panko)]

Nach meinem Kenntnisstand ist after nicht synthesefähig. Da müsste man 
wohl eine Art delay zu Fuß machen. Das ist aber durch fehlenden 
Sytemtakt natürlich nicht möglich irgendwie.

edit: Kannst du da nicht einen Takt anschließen? Dann könnte man ja 
einen Zähler starten wenn die Flanke kommt (die wenn ich Herrn Miller 
richtig verstanden habe ohnehin besser durch ein Schieberegister sollte 
und dann als "0001" dieses Vektors erkannt würde) und nach dessen Ablauf 
( 5 ns ) eben das Ausgangssignal erst setzen.)

Wobei ich gestehen muss, daß 5 ns natürlich auch mal ECHT fix ist für 
einen Zähler ;-)) Ich glaube das ist nciht praktikabel. Ein RC Glied 
scheint mir aber heutzutage nicht mehr Stand der Technik zu sein. Bei 
diskreter Logic hätt ich einfach ein delay Glied vor einen Buffer 
gemacht.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Thaddäus schrieb:
> OK, das ganze ist also doch ein Problem. ISE Meckert über das hier

 
   process(set, reset)
   begin
   if(rising_edge(reset))then
     out_int <= '0' after 5 ns;
   end if;
   if(rising_edge(set))then
     out_int <= '1' after 5 ns;
   end if;
   end process;

Nachdem deine VHDL-Beschreibung ja letzlich in reale Hardware umgesetzt 
werden soll, kannst du nur Bauelemente verwenden, die es auf FPGAs/CPLDs 
gibt. Ein solches Bauteil wie du es beschreibst (mit 2 Takteingängen) 
ist dort nicht vorhanden. Du mußt deine Denkweise mehr in Richtung 
Hardware überarbeiten...

> Damit soll eine art Lauflicht (Details spielen hier keine Rolle)
> einen Schritt weiter laufen, aber eben nur EINEN Schritt pro
> Tastendruck, und nicht 100, nur weil der Taster 100 Takte
> lang gedrückt ist. Ich brauch quasi die Funktionalität eines
> SET/RESET-FlipFlops, welches aber nur auf Flanken reagiert.
Du brauchst eine Flankenerkennung.

> Kann mir jemand einen Anstoss geben?
Flankenerkennung:
http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung
Lauflicht:
http://www.lothar-miller.de/s9y/archives/61-Lauflicht.html
Ergibt zusammen:

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

entity Lauflicht is
    Port ( clk : in  STD_LOGIC;
           button : in std_logic;
           leds : out  STD_LOGIC_VECTOR (7 downto 0));
end Lauflicht;

architecture Behavioral of Lauflicht is
  signal buttonsr : std_logic_vector (2 downto 0) := "000";
  signal rise : std_logic;
  signal sr : std_logic_vector (7 downto 0) := "10000000";

begin
   process begin  -- Einsynchronisieren und Flankenerkennung
      wait until rising_edge(clk);
      buttonsr <= buttonsr(1 downto 0) & button;
   end process;
   rise <= '1' when buttonsr(2)='0' and buttonsr(1)='1' else '0';

   process begin  -- das Lauflicht
      wait until rising_edge(clk);
      if (rise='1') then   -- steigende Flanke
         if (sr="00000001") then
            sr <= "10000000";
         else
            sr <= '0' & sr(7 downto 1);
         end if;
      end if;
   end process;

   leds <= sr;
  
end Behavioral;

Ein paar Tipps für Anfänger:
Es gibt nur 1 Takt im Design.
Es wird nur 1 Flanke dieses Takts abgefragt (rising oder falling).
Es gibt keinen (und schon gar keinen asynchronen) Reset.
Es wird jedes asynchrone Signal mit 2 FFs einsynchronisiert.
Ausnahmen von den genannten Regeln sind nur mit fundierter Begründung 
möglich.

[Steffen Hausinger (Gast)]

Hallo Lothar

Lothar Miller schrieb:
> Es wird jedes asynchrone Signal mit 2 FFs einsynchronisiert.

Warum genügt denn nicht 1 FF?

if rising_edge(CLK) then
    mysig_sync <= mysig_aync;
end if;

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Steffen Hausinger schrieb:
> Warum genügt denn nicht 1 FF?
Es ist eine Frage von Wahrscheinlichkeiten.
Als Stichwort für die weitere Suche: Metastabilität.

[Steffen Hausinger (Gast)]

Dann ist die Wahrscheinlichkeit für Metastabilität bei

...f_signal << f_sample und
...kurzem t_rise/t_fall

also geringer und man könnte auch mit einem FF auskommen, ja? Ist das 
überhaupt wirklich ein reales Problem (= hatte das schonmal jemand?) 
oder eher akademischer Natur?

[Christian R. (supachris)]

Steffen Hausinger schrieb:
> Ist das überhaupt wirklich ein reales Problem (= hatte das schonmal jemand?) 
oder eher akademischer Natur?

Leider viel öfter als man denkt. Und vor allem blöd zu finden, da das 
meistens sporadisch auftritt.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Ob sich Metastabilität wirklich auswirkt, hängt vorrangig von der im 
FPGA verwendeten Taktfrequenz ab. Die heutigen FFs stabilisieren sich so 
schnell auf einen definierten Pegel, dass die tsu des nachfolgenden FF 
bei Taktfrequenzen <200MHz nicht verletzt wird.

Christian R. schrieb:
> Leider viel öfter als man denkt. Und vor allem blöd zu finden, da das
> meistens sporadisch auftritt.
Ich würde sagen: weit seltener als man meint.
Oft wird ein Fehler der Metastabilität zugeschrieben, der einfach nur 
einem fehlerhaften Design zuzuschreiben ist...  :-/
http://www.lothar-miller.de/s9y/archives/62-Testaufbau-Metastabilitaet.html

[Xenu (Gast)]

Das Metastabilitätsgespenst geht wieder um.

Das Problem ist nicht Metastabilität, sondern daß ein von außen 
kommendes, asynchrones Signal an mehrere Flip-Flops angeschlossen
wird - und das geht garantiert in die Hose. Weil es dann passieren kann,
daß bei einer Taktflanke, bei der sich auch gleichzeitig das Signal 
ändert, ein Flip-Flop eine 1 speichert, und ein anderes eine 0. Eine 
schizophrenes Design sozusagen.

Lösung: Externe Signale immer zuerst in ein Flip-Flop eintakten und 
mit diesem (Flip-Flop-Ausgangs)Signal weiterarbeiten.

Darüber hat auch schon Peter Alfke (bis vor kurzem Chefdesigner bei 
Xilinx) mal einen schönes Posting auf comp.arch.fpga geschrieben:

http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/c6594798db796f15/98687de342676d58

[Christian R. (supachris)]

Lothar Miller schrieb:

> Ich würde sagen: weit seltener als man meint.
> Oft wird ein Fehler der Metastabilität zugeschrieben, der einfach nur
> einem fehlerhaften Design zuzuschreiben ist...  :-/

Ja das stimmt. Das "öfer als einem lieb ist" bezog sich eher auf blöde 
Effekte, wenn ein asynchrones Signal nicht richtig einsynchronisiert 
wurde. Hätte ich müssen dazuschreiben....

[Thaddäus (Gast)]

Perfekt, genau was ich gesucht habe. Bin einfach dem Vorschlag von 
Lothar Miller gefolgt, funktioniert prima.