Zählen bei Ereignis

[vhtl (Gast)]

Hallo,

noch eine Anfänger-Frage:

Ich möchte Signalwechsel zählen, und habe das naiv so formuliert:

architecture Behavioral of counter is
  signal value : STD_LOGIC_VECTOR(3 downto 0) := "0000";
  signal prev : STD_LOGIC := '0';
begin
  count: process(BUTTON)
  begin
    if rising_edge(BUTTON) then
      value <= value + '1';
    end if;
  end process;
  do_sth: process(value)
  begin
   ...
  end process;
end Behavioral;

Dabei erhalte ich die Fehlermeldung "Bad condition in wait statement, or 
only one clock per process." Die gleiche Meldung erhalte ich, wenn ich 
es umformuliere:

  count: process
  begin
    wait until BUTTON /= prev;
    value <= value + '1';
    prev <= BUTTON;
  end process;

Ich sehe aber gar keinen zweiten Takt!

Die Umformulierung

  count: process(BUTTON)
  begin
    if BUTTON /= prev then
      value <= value + '1';
    end if;
    prev <= BUTTON;
  end process;

führt hingegen dazu, daß erst das gesamte Register und dann der Button 
wegoptimiert werden.

Also: Wie wartet man richtig auf einen Signalwechsel pro Prozeß, um 
danach z.B. einen Zähler zu erhöhen?

[ich (Gast)]

value <= value + '1'

<= ???

[ich (Gast)]

ist das < nicht zu viel?

[vhtl (Gast)]

Einen hab ich noch:

count: process
  begin
    wait until BUTTON = '0';
    value <= value + '1';
    wait until BUTTON = '1';
  end process;

ergibt "Same wait conditions expected in all Multiple Waits."

[ich (Gast)]

und fehlt ein :

[Stephan N. (someone_like_you)]

Ich weiß ja nicht welche Libs du eingebunden hast, aber einen STD Logic 
Vector kann man nicht so ohne weiteres inkrementieren.

Ich benutze da immer:

 value <= std_logic_vector(unsigned(value) + 1);

Außerdem musst du mit deinem Tastersignal aufpassen: Du verwendest das 
direkt als Takt! Wenn dein Signal von einem normalen Taster kommt, 
kann der noch ein bisschen prellen, was zu falschen inkrements führt.

Du könntest einen Takt von einem Oszillator nehmen, damit dein design 
takten und eine einfache Flankenerkennung für deinen Button 
implementieren.

[vhtl (Gast)]

Der Einfachheit halber habe ich

use IEEE.STD_LOGIC_UNSIGNED.ALL;

genommen - ich weiß, daß macht man nicht.

Mit geht's jetzt aber um das asynchrone Erkennen von Signaländerungen 
(ob der Zähler hier eine besondere Rolle spielt weiß ich nicht).

Der Button ist jetzt auch nur ein Beispiel für ein Signal, also Prellen 
bitte ignorieren.

[vhtl (Gast)]

OK, ich habe mich da wohl vertan ... Version 1 funktioniert doch, 
jedenfalls sofern man nicht zu viele Signale überwachen möchte.

[Mike (Gast)]

Nicht alles was man in VHDL beschreiben kann lässt sich auch in reale 
Hardware umsetzen. Ein FPGA stellt an den Takt ziemlich strenge 
Anforderungen und mit einem externen Button als Taktgenerator kommst du 
da nicht weit...

Die Seiten hier solltest du dir einmal anschauen:

http://www.mikrocontroller.net/articles/Taktung_FPGA/CPLD
http://www.mikrocontroller.net/articles/Metastabilit%C3%A4t
Beitrag "Verständnisfrage Einsynchronisieren"

Für echte Hardware (und nicht nur Simulation) verwendest du besser nur 
einen einzigen Takt. Mit dem arbeiten dann alle deine getakteten 
Prozesse. Deine Tasten synchronisiert du Schieberegister ein und machst 
damit eine Flankenerkennung. Wenn du eine Flanke erkannt hast, dann 
kannst du deinen Zähler aktualisieren.

Du solltest dir mal ein Buch für die Grundlagen zulegen.

[Burkhard K. (buks)]

vhtl schrieb:

> Mit geht's jetzt aber um das *asynchrone Erkennen von Signaländerungen*

Klingt nach Flankendetektion - das ist nicht ganz dasselbe wie das 
Zählen von Taktwelchsen.

Flankendetektion lässt sich per Schieberegister ("strobe" soll das 
Signal mit der zu detektieren Flanke sein) implementieren.

signal edge     : std_logic;
signal delay_reg: std_logic;
signal edge_cnt : unsigned(3 downto 0) := (others=>'0');

process
begin
    wait until rising_edge(clk);
    delay_reg <= strobe;
end process;

edge  <= (not delay_reg) and strobe;
...
process
begin
    wait until rising_edge(clk)
    if edge then
        edge_cnt <= edge_cnt +1;
    end if;
end process;

Ein asynchrones Signal muss dies zunächst einsynchronisiert werden. 
Beides in einem Rutsch hat Lothar hier beschrieben: 
http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung.

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

vhtl schrieb:
> if rising_edge(BUTTON) then
Das ist die komplett falsche Strategie, vermutlich, weil du noch die 
falsche Denkweise hast.

Um es kurz zu machen: man macht nicht unnötig viele Taktdomänen auf. 
Alles, was mit wait oder 'event oder rising_egde() oder falling_edge() 
zu tun hat, ist eine eigene Taktdomäne. Und weil man dann immer Probleme 
mit dem Taktdomänenübergang hat, sollte man versuchen, so einfache Dinge 
wie einen Taster direkt in der Zieldomäne zu erledigen.
Die Zieldomäne ist "der Takt", üblicherweise der eine Takt, der von 
einem Quarz im Bereich um 50..100MHz an einem FPGA-Pin vorgegeben wird.

vhtl schrieb:
> Mit geht's jetzt aber um das asynchrone Erkennen von Signaländerungen
> (ob der Zähler hier eine besondere Rolle spielt weiß ich nicht).
>
> Der Button ist jetzt auch nur ein Beispiel für ein Signal, also Prellen
> bitte ignorieren.
Wenn du ein Signal erkennen willst/musst/sollst, das so kurz ist, dass 
es mit dem einen einzigen FPGA-Takt nicht einsynchronisiert und darauf 
ein Pegelwechsel erkannt werden kann, dann bleibt dir als Notnagel(!!) 
nur, eine Flanke darauf zu erkennen, diesen Flankenwechsel zu speichern, 
einzusynchronisieren und mit dem einen FPGA-Takt darauf zu reagieren.
So etwa:
http://www.lothar-miller.de/s9y/archives/19-Kurzer-Spike-in-Puls-umgewandelt.html

vhtl schrieb:
> Also: Wie wartet man richtig auf einen Signalwechsel pro Prozeß, um
> danach z.B. einen Zähler zu erhöhen?
Man "wartet" eigentlich nicht, sondern man erkennt nur, dass nichts 
relevantes passiert ist und deshalb nichts getant werden muss. Relevant 
bei einem Signalwechsel ist eine Änderung eines Pegels z.B. von 0 auf 1. 
Also muss 1. der Pegelverlauf gespeichert und dann 2. in diesem Speicher 
ein Pegelwechsel erkannt und dann 3. darauf reagiert werden:

architecture Behavioral of counter is
  signal value : integer := 0;
  signal sr_button : STD_LOGIC_VECTOR(1 downto 0) := "00"; -- Schieberegister für asynchrones Eingangssignal
begin

  sr_button <= sr_button(0) & BUTTON when rising_edge(clk); -- Signal einspeichern und einsynchronisieren

  count: process(clk) begin
    if rising_edge(clk) then
      if sr_button = "01" then -- gewünschter Pegelwechsel am BUTTON erkannt
        value <= value + 1;    -- Reaktion auf die den Pegelwechsel
      end if;
    end if;
  end process;


end Behavioral;

Letztlich ist es einfach: das gesamte FPGA-Design besteht aus 
Zustandsautomaten. Das hört sich jetzt aufwändig an, aber letztlich ist 
ja jeder schäbige Zähler schon so ein Automat. Und der Automat im Fall 
hier ist einfach so gestrickt, dass er bei jedem FPGA-Takt prüft, ob das 
Schieberegister einen Flankenwechsel von 0 nach 1 beinhaltet. Wenn 
nicht, dann tut der Automat nichts. Wenn so ein Wechsel erkannt ist, 
dann zählt er den Zähler hoch.

[larsp (Gast)]

Lothar M. schrieb:
>> if rising_edge(BUTTON) then
> Das ist die komplett falsche Strategie, vermutlich, weil du noch die
> falsche Denkweise hast.
>
> Um es kurz zu machen: man macht nicht unnötig viele Taktdomänen auf.
> Alles, was mit wait oder 'event oder rising_egde() oder falling_edge()
> zu tun hat, ist eine eigene Taktdomäne. Und weil man dann immer Probleme
> mit dem Taktdomänenübergang hat, sollte man versuchen, so einfache Dinge
> wie einen Taster direkt in der Zieldomäne zu erledigen.
> Die Zieldomäne ist "der Takt", üblicherweise der eine Takt, der von
> einem Quarz im Bereich um 50..100MHz an einem FPGA-Pin vorgegeben wird.

Vielen Dank für die vielen Antworten.

Die "synchrone" Variante kenne ich durchaus, aber ich dachte, man kann 
das auch asynchron machen, zumal wenn man sonst nur kombinatorische 
Logik (heißt das so?) hat. Ich wollte daher gar keinen (externen) Takt 
verwenden.

Gilt das Gesagte nur für FPGAs, oder auch CPLDs?

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

larsp schrieb:
> zumal wenn man sonst nur kombinatorische Logik (heißt das so?) hat.
Kombinatorik = Logik

> Ich wollte daher gar keinen (externen) Takt verwenden.
Sowas kann man machen, wenn man sehr lokal bleibt oder nur ein paar 
einzelne Flipflops zu verwalten hat, die man auch "von Hand" 
konfigurieren könnte.

> Gilt das Gesagte nur für FPGAs, oder auch CPLDs?
Weil CPLDs sowieso nur sehr niedrige Komplexität haben, "darf" man dort 
eher mal solche Basteleien anfangen. In einem FPGA-Design, das evtl. 
sogar mal portiert werden soll, würde ich mich das nur in absoluten 
Ausnahmefällen trauen.

[vhtl (Gast)]

Ich muß nochmal nachhaken ...

Gerade lese ich in einem Vorlesungsskript, daß Prozesse (mit 
Sensitivity-Liste) nur dann ausgeführt werden, wenn sich einer der 
Parameter ändert:

"The process doesn't run continuously! It will be started only after 
change (event) on any signal in its sensitivity list."

Für die Simulation glaube ich das gerne. Aber gilt das wirklich auch für 
das synthetisierte Ergebnis? Wenn dem so wäre könnte ich mir doch die 
Abfrage nach rising_edge oder falling_edge sparen?!

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

vhtl schrieb:
> Für die Simulation glaube ich das gerne. Aber gilt das wirklich auch für
> das synthetisierte Ergebnis?
Nein!
Die Sensitivliste ist ausschließlich für den Simulator. Der Synthesizer 
gibt nur eine Info aus, dass bei unvollständiger Sensitivliste die 
Simulation nicht mehr zum Syntheseergebnis passt.

> Wenn dem so wäre könnte ich mir doch die Abfrage nach rising_edge oder
> falling_edge sparen?!
So wie dort etwa:
http://www.lothar-miller.de/s9y/archives/16-Takt-im-Prozess.html
Und dann gleich mal eine kombinatorische Schleife basteln:
http://www.lothar-miller.de/s9y/categories/36-Kombinatorische-Schleife