Aufruf einer CLK-gesteuerten FSM mittels einer Buttonflanke

[Gilles B. (gilles_b)]

Grüßt euch alle!

Also folgendes Problem:
Ich benutze ein Spartan-6 von XILINX und bin momentan auf dem SP605 
Evalboard unterwegs.

Ich habe einen Button1, welchen ich schon (habe ich bereits überprüft) 
erfolgreich entprelle. Ich habe dann also intern ein sauberes "Pushed" 
Signal in meiner architecture, welches eben konstant auf 1 ist wenn der 
button gerade eingedrückt ist und ansonsten 0. Liefer mir also sobald 
ich drücke ne steigende Flanke...

Soweit so gut.

Diese Flanke möchte ich nun (ohne dass ich den restlichen code mit in 
den Entprell-Prozess reinschreiben muss) nutzen, um damit folgendes 
Auszulösen:

Mit einer FSM (6 Zustände...), welche über einen (internen Takt) mit 2 
Hertz, abgelaufen wird soll eine LED auf dem Board An-Aus-An-Aus-An-Aus 
gehen, also 101010.

Bisher dachte ich da an folgendes:

Procedure Sequenz (  signal CLK_2Hz : in STD_LOGIC;
            signal State : inout BIT_VECTOR;
      signal LED1 : out STD_LOGIC) is
begin
  if (CLK_2Hz='1' and CLK_2Hz'event) then
    
    case State is
    when "000001" => State <= "000010"; LED1 <= '1';
    when "000010" => State <= "000100"; LED1 <= '0';
    when "000100" => State <= "001000"; LED1 <= '1';
    when "001000" => State <= "010000"; LED1 <= '0';
    when "010000" => State <= "100000"; LED1 <= '1';
    when "100000" => LED1 <= '0';
    when others => null;
    end case;
    end if;
end Sequenz;


......
......
......
......
......
--UND NUN NACH DEM ARCHITECTURE-BEGIN:

        Activate : process(Pushed)
  begin
    if (Pushed='1' and Pushed'event) then
      State <= "000001"; --Zustand der FSM
      Sequenz(CLK_2Hz, State, LED1);
    end if;
  end process Activate;

Problem ist, dass wenn die Pushedflanke kommt, die FSM nicht komplett 
durchläuft, sondern erstens mein CLK-2Hz einfach ignoriert wird und 
einfach bei jedem button-push einfach nur der zustand der FSM um eins 
hochgeht...

Habt ihr eine Lösung parat?

Allgemein habe ich immer wieder das Problem, dass ich mit Flanke-1 einen 
Ablauf, welcher durch Flanke-2 synchronisiert wird, auslösen möchte...

Dank euch!

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

Du hast viel zu viele Takte in deinem Design! Ein Takt ist alles, was 
mit 'event (oder rising_edge bzw. fllaing_edge) abgefragt wird. Lies mal 
meine Postulate im Beitrag "vhdl-richtlinien f. synthese?"

Und dann befass dich mit dem Thema Einsynchronisieren und dem 
richtigen Entprellen von Tastern und der anschliessenden 
Flankenerkennung:
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren
http://www.lothar-miller.de/s9y/categories/5-Entprellung
http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung


BTW: dein Design kann sowieso nicht funktionieren, weil State von 2 
Prozessen getrieben wird. Das bekommst du so nicht durch den 
Synthesizer...

Gilles Backhus schrieb:
> Allgemein habe ich immer wieder das Problem, dass ich mit Flanke-1 einen
> Ablauf, welcher durch Flanke-2 synchronisiert wird, auslösen möchte...
Deine "Flankendenkweise" ist das Problem. In einem synchronen 
FPGA-Design (und nur sowas macht man heute) gibt es keine Flanken, 
sondern nur Zustände.


Und nochwas: als Anfänger brauchst du für sowas unglaublich Simples wie 
eine FSM GARANTIERT keine Procedure. Vergiss diese sequenteille 
Softwaredenkweise. Das geht bei Hardware nicht!

Gilles Backhus schrieb:
> Mit einer FSM (6 Zustände...), welche über einen (internen Takt) mit 2
> Hertz, abgelaufen wird soll eine LED auf dem Board An-Aus-An-Aus-An-Aus
> gehen, also 101010.
>
> Bisher dachte ich da an folgendes: ...
Ich denke da an ein Schieberegister...

[Udo (Gast)]

Lothar Miller schrieb:
> Vergiss diese sequenteille
> Softwaredenkweise. Das geht bei Hardware nicht!
Sagt wer?
Sicher geht das, sie ist nur nicht unbedingt notwendig und gezeigt. 
Sequenzielle Bearbeiter sind dennoch oft genug im Einsatz um Resourcen 
zu sparen.

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

Udo schrieb:
> Lothar Miller schrieb:
>> Vergiss diese sequentielle Softwaredenkweise.
>> Das geht bei Hardware nicht!
> Sagt wer?
Ich.
> Sicher geht das, sie ist nur nicht unbedingt notwendig und gezeigt.
> Sequenzielle Bearbeiter sind dennoch oft genug im Einsatz um Resourcen
> zu sparen.
Es geht nicht um das getaktete schrittweise Abarbeiten einer Aufgabe mit 
einer FSM oder in einer Pipeline. Es geht darum, dass es in einem 
Prozess kein "erst das, und dann das" gibt. Und es geht darum, dass eine 
Zeile eines Prozesses eben nicht eine gewisse "Bearbeitungszeit" 
braucht. Genausowenig in einer Prozdur und einer Funktion.

>> Vergiss diese sequentielle Softwaredenkweise.
>> Das geht bei Hardware nicht!
Nimm eine for-Schleife: in Software wird die Schritt für Schritt x-mal 
nacheinander (sequentiell) abgearbeitet. In Hardware (VHDL) produziert 
eine for-Schleife aber x-mal die selbe Baugruppe. In der Hardware wird 
die komplette Schleife zum selben Zeitpunkt abgearbeitet.