FSM mit "zwei Clocks"

[Schotter (schottre)]

Hi,

seit zwei Tagen zerbreche ich mir mittlerweile den Kopf, wie ich eine 
StateMachine aufsetze, die durch einen externen Impuls ans Laufen 
gebracht wird. Konkret will ich nur über 4 Werte mitteln, wobei 3 davon 
nacheinander eintreffenden und der vierte das Ergebnis der vorherigen 
Mittelung ist.

Mit Blick auf http://www.lothar-miller.de/s9y/categories/37-FSM habe ich 
mein Glück versucht^^ vorher hatte ich noch andere Gehversuche, die sich 
zwar wunderbar mit ghdl simulieren ließen, aber allesamt an

Error (10822): HDL error at meanvalue.vhdl(98): couldn't implement registers for assignments on this clock edge

gescheitert sind.

Mein aktueller Versuch sieht sinngemäß so aus:

signal new_data_available : std_logic := '0';

Averaging : process
begin
  wait until rising_edge(clk);
  case state is
    when reset =>  --alles auf 0
    when idle =>  --nur warten
    when start =>
      new_data_available <= '0'  --verursacht einen Fehler
      state <= etc...
    when etc...
  end case;

  if(rst = '1') then
    state <= reset;
  elsif(new_data_available = '1') then
    state <= start;
  endif;
end process;

NewData : process (v_in_new)
begin
  if(rising_edge(v_in_new)) then
    new_data_available = '1';
  end if;
end process;

Meine Hoffnung bestand natürlich darin, dass ich so der Fehlermeldung 
von oben entkomme, aber jetzt erhalte ich eine "andere". Die Simulation 
setzt mir ab dem Zeitpunkt zu dem new_data_available auf '0' zurück 
gesetzt wird den new_data_available auf 'u' :/

Kann mir da wer 'nen Tipp geben wie das unter einen Hut kriege? Meine 
Phantasie stößt so langsam an ihre Grenzen :)

Danke,
Thorsten

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

Thorsten S. schrieb:

  wait until rising_edge(clk);
       new_data_available <= '0'  --verursacht einen Fehler


 if(rising_edge(v_in_new)) then
     new_data_available = '1';

Das wäre ein Dual-Clock-Flipflop. Hast du sowas schon mal gesehen?
Zudem sieht das zweitere verdächtig böse nach einem asynchronen Eingang 
aus. Und jeder asynchrone Eingang muss erst mal irgendwie 
einsynchronisiert werden!

> Meine Hoffnung bestand natürlich darin, dass ich so der Fehlermeldung
> von oben entkomme
Ja, wenn die Hoffnung nicht wäre...

> Kann mir da wer 'nen Tipp geben wie das unter einen Hut kriege?
Und was ist dein Ziel?
Was sollen die Signale machen und bewirken?
Kannst du da mal ein Timingdiagramm/Ablaufdiagramm zeichnen?

[Schlumpf (Gast)]

Abgesehen von dem, was Lothar bereits schrieb, versuchst du hier 
"new_data_available" in zwei verschiedenen Prozessen zu verändern. Und 
das geht auch schief.

[Schotter (schottre)]

Lothar Miller schrieb:
> Was sollen die Signale machen und bewirken?
> Kannst du da mal ein Timingdiagramm/Ablaufdiagramm zeichnen?
Timingdiagramm inkl. Code habe ich mal angehängt. Das ist allerdings 
noch meine vorherige Codeversion. Da wird beim Übersetzen auch 
gemeckert, aber die Simulation zeigt genau das was ich haben will.

> Und jeder asynchrone Eingang muss erst mal irgendwie
> einsynchronisiert werden!
http://www.lothar-miller.de/s9y/archives/41-Einsynchronisieren-von-asynchronen-Signalen.html 
habe ich schon gelesen, das Problem dahinter auch verstanden, aber 
zwischen Problem verstanden und Abhilfe schaffen, ist's noch ein 
Schritt, der mir noch nicht aufleuchtet.

> Und was ist dein Ziel?
...mein Problem ist, dass

signal ff1_out  : std_logic;
signal ff2_out  : std_logic;
:
process begin -- Einsynchronisieren
   wait until rising_edge(clk);
   ff1_out <= async_in;
   ff2_out <= ff1_out;
end process;

process begin 
   wait until rising_edge(clk);
   if (ff2_out = '1') then   -- Synchronisierten Eingang verwenden
   :   end if;   
end process;

ff2 doch auch wieder an clk hängt und ich das aus der FSM heraus dann 
wieder nicht zurücksetzen könnte. Die Frage ist also letztlich wie ich 
das dann trotzdem mache? Schreibe ich mir da einen Zähler, der ff2_out 
und ff1_out wieder auf '0' setzt? Oder gibt es noch andere 
Möglichkeiten?

Ja und jetzt seh ich's erst. Dein Beispiel fängt doch keine Peaks am 
Eingang von ff1 ab. Aber genau das möchte ich ja....
D-Flipflop. Man man man, sorry für die Blöderlasfragen^^

[Schlumpf (Gast)]

Ich glaube, bis jetzt konnte keiner hier so recht verstehen, was du 
eigentlich willst.
Du willst ne FSM machen, die irgendwas tut und bastelst da wilde 
Konstruktionen mit Registern in mehreren Prozessen.

"Ordentlich" macht man sowas, indem man dem gesamten Design einen 
Systemtakt verpasst. Dieser Takt taktet ALLE Register (ausnahmslos)

Deine eingehenden Signale werden dann wie Daten interpretiert. Wenn du 
eine steigende Flanke auf einem eingehenden Signal erkennen willst, dann 
schiebst du das Signal durch zwei Register und vergleichst, ob das eine 
auf Low und das andere auf High ist. Damit hast du die Flanke erkannt.

[Schotter (schottre)]

Ja ne, ein D-FF reicht mit dem Takt nur das weiter was am Eingang 
anliegt. Wenn mein Peak abgeklungen ist, kann er auch nicht 
weitergereicht werden.

Schlumpf schrieb:
> Wenn du eine steigende Flanke auf einem eingehenden Signal erkennen
> willst, dann schiebst du das Signal durch zwei Register und vergleichst,
> ob das eine auf Low und das andere auf High ist. Damit hast du die
> Flanke erkannt.
Und damit fange ich "Peaks" ab? Also Eingangssignale, die kürzer als 
mein clk sind?

[Schlumpf (Gast)]

Thorsten S. schrieb:
> Und damit fange ich "Peaks" ab?

Ach so, ist jetzt ein Peak das Problem? Ich dachte, dein problem sei, 
dass du ne FSM hast, die nicht laufen will, weil du da irgendeine 
volgelwilde Konstrunktion mit mehreren Takten hast.

Aber Peaks kann man auch abfangen, indem man den Eingang durch mehrere 
Register schiebt und z.B. einen Mehrheitsentscheid macht.

Aber auch hier gilt: Alle Register arbeiten schön brav mit dem 
Systemtakt

[Schlumpf (Gast)]

Oder willst du auf Peaks reagiere?
Sorry, ich versteh nicht, was du eigentlich vor hast. Und deinen Code 
mag ich mir beim besten Willen nicht anschauen.
Formuliere doch einfach mal in ein paar zusammenhängenden Sätzen, was 
dein Design können soll, dann kann man dir hier auch sicher helfen

[Schotter (schottre)]

Schlumpf schrieb:
> Oder willst du auf Peaks reagiere?
> Sorry, ich versteh nicht, was du eigentlich vor hast. Und deinen Code
> mag ich mir beim besten Willen nicht anschauen.
> Formuliere doch einfach mal in ein paar zusammenhängenden Sätzen, was
> dein Design können soll, dann kann man dir hier auch sicher helfen

Dann versuche ich's nochmal^^

v_in_new : in std_logic;           --soll als Peak interpretiert werden
v_in : in unsigned (11 downto 0);  --hier sind dann die Werte die v_in_new ankündigt

Wenn ich es mir recht überlege, dürfte es von den zeitlichen Abläufen 
her vollkommen ausreichend sein, wenn ich mit dem Systemtakt nachschau, 
ob v_in_new = '1' ist, sprich ich könnte das auch in die FSM 
verschieben. Aber ich würde schon gerne wissen, wie ich das asynchroner 
hinbekomme.

Man nehme ein flankengesteuertes RS-FF bei dem v_in_new auf S liegt und 
dieses im Falle eines Peaks auf '1' setzt. Zurückgesetzt wird das FF 
über R, was mit dem clk verbunden ist. Der Ausgang von diesem FF geht in 
ein weiteres D-FF das ich von der FSM aus abfrage.

Das wäre jetzt mein analoger Ansatz (Verzögerungen etc. außen vor 
gelassen). War das einigermaßen verständlich?

Das von dir angesprochene Schieberegister habe ich mittlerweile auch 
gefunden,
http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung
aber mit Peaks könnte ich damit nicht handhaben oder?

[Schotter (schottre)]

So, es hat ewig gedauert, aber ich habe mein eigentliches Problem 
endlich gelöst und jetzt kann ich es auch in Worte fassen :D

Nochmal zur Situation: Ich habe ein asynchrones Eingangssignal, das mir 
neue Daten meldet. Damit ich die Daten nur 1x lese, dachte ich mir ich 
triggere auf eine steigende Flanke und ob das Signal dann 5 oder 50 ns 
lang high ist, kann mir dann egal sein. Und hier hatte ich mich dann 
verrannt.

Das Schieberegister hat mich dann vom Flankentriggern abgebracht, aber 
der mehrmalige Durchlauf der FSM war noch nicht unterbunden.

signal insr  : std_logic_vector(2 downto 0);
:
process begin
   wait until rising_edge(clk);
   -- Schieberegister
   insr <= insr(1 downto 0) & input;
end process;

process begin
   wait until rising_edge(clk);
   if (insr(2 downto 1) = "10") then 
      -- fallende Flanke von input
      new_data_available <= '0';
   end if;
   if (insr(2 downto 1) = "01") then 
      -- steigende Flanke von input
      new_data_available <= '1';
   end if;
end process;

Dazu bedurfte es noch eines weiteren Bits und die Sache war gegessen.

    :
  end case;

  if(rst = '1') then
    state <= reset;
  elsif (new_data_available = '1' and state = idle) then
    triggered <= '1';
    if(triggered = '0') then
      state <= inc;
    end if;
  elsif (new_data_available = '0') then
    triggered <= '0';
  end if;
end process;  --FSM

Nochmals Danke für die Beiträge...auch wenn mich keiner verstanden hat^^ 
geholfen hat's mir trotzdem ;)

[Klaus F. (kfalser)]

Thorsten S. schrieb:
> Nochmal zur Situation: Ich habe ein asynchrones Eingangssignal, das mir
> neue Daten meldet. Damit ich die Daten nur 1x lese, dachte ich mir ich
> triggere auf eine steigende Flanke und ob das Signal dann 5 oder 50 ns
> lang high ist, kann mir dann egal sein. Und hier hatte ich mich dann
> verrannt.

In einem solchen Fall sollte man die Funktionalität trennen.
Du schreibst Dir
a) ein Modul, das das Eingangssignal einsynchronisiert und bei einer 
Flanke am Ausgang einen Puls mit genau einer Taktperiode High liefert
b) die FSM, die auf diesen Puls reagiert und die Verarbeitung macht

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

Thorsten S. schrieb:
> im Falle eines Peaks
Was ist ein Peak?
Willst du eher einen "Spike" erkennen können (also einen Impuls, der 
fürs reguläre Eintakten zu kurz ist oder sein kann)?
Offensichtlich ja:
> ob das Signal dann 5 oder 50 ns lang high ist, kann mir dann egal sein.
Dann kannst du die Sache so angehen:
http://www.lothar-miller.de/s9y/categories/19-SpikePuls

[Schlumpf (Gast)]

Du willst glaub offensichtlich genau das, was Lothar vermutet hat.
Falls dein "new-data-avilable" Signal so kurz ist, dass du es nicht mit 
dem Systemtakt erfassen kannst, dann mach es so, wie Lothar es 
beschrieben hat.
Falls du aber sicherstellen kannst, dass das Signal länger als 2 
Systemtakte ist, dann sample es mit dem Systemtakt ein und mach mit der 
unter anderem von mir beschriebenen Methode eine Flankenerkennung.
Also schieben durch mehrere Register und vergleich der Registerinhalte.