Taktgenerierung

[Michael S. (decimad)]

Hallo Leute!

In meinen weiteren Experimenten bin ich über ein neues Problem 
gestolpert.
Alles fing an, als ich einen Automaten mit sehr langsamen (1hz) Takt 
betrieben habe. Dieser Takt entstand aus einem Taktteiler.

Nun fallen mir 2 Varianten ein, aus dem Board-Takt einen eigenen Takt zu 
generieren, einmal durch einfach Teilung (Bitabgriff hinter einem 
Inkrementer) zum anderen durch Vergleich mit einer Konstanten hinter dem 
Inkrementer. Natürlich haben beide leicht andere Eigenschaften (Bei der 
2. würde mir direkt einfallen, wie ich den Takt "zurücksetzen" könnte). 
Gibt es irgendwelche Gründe, die gegen eine der Varianten sprechen?

Zweites Problem: Man möchte ja nun als Benutzer mit so einem Automaten 
kommunizieren und ist zumeist ungetaktet. Daher treffen Eingaben nicht 
zu Taktflanken sondern einfach irgendwann ein. Gibt es irgendeinen Weg 
in VHDL um ohne Warnungen und zuverlässig ein RS-Flipflop mit 
asynchronem Set generieren zu lassen (also eigentlich: um externe events 
im getakteten Prozess bearbeiten zu können)? Ich habe viel rumprobiert 
in meiner Hauptentity aber kam erst zum Erfolg, als ich mir eine externe 
Flipflop-Entity wie folgt in das Design genommen hab:

entity FF is
    Port ( S : in  STD_LOGIC;
           R : in  STD_LOGIC;
           CLK : in  STD_LOGIC;
           O : out  STD_LOGIC);
end FF;

architecture Behavioral of FF is
  signal O_int: std_logic := '0';
begin
  O <= O_int;

  process (CLK, S)
  begin
    if (S = '1') then
      O_int <= '1';
    elsif rising_edge(CLK) then
      if (R='1') then
        O_int <='0';
      else
        O_int <= O_int;
      end if;
    end if;
  end process;
end Behavioral;

Ist das evtl. eine schlechte Umsetzung?

Ich wurstele mich ja gerade erst in die Thematik ein, wäre für jede 
Hilfe dankbar!

Viele Grüße,
Michael

[D. I. (Gast)]

Lies dir mal etwas zum Thema Einsynchronisierung durch auf Lothars 
Homepage

[Michael S. (decimad)]

Okay, das ist auch eine interessante Geschichte. Also in meinem Fall 
habe ich eine 1Hz-getaktete FSM und möchte sie vom Grundzustand 0 auf 
ihren Weg schicken, indem ich einen Knopf drücke. Also brauche ich 
erstmal einen asynchronen FF damit die FSM überhaupt etwas mitbekommen 
kann, wenn man zwischen den Taktflanken drückt. Wenn nun der FF kurz vor 
der Taktflanke hochschaltet, könnte die Logik dahinter ins Schlingern 
geraten. Wenn ich jetzt allerdings noch einen synchronen FF 
dahinterpacke, dann würde mein Knopfdruck erst eine ganze Sekunde später 
verarbeitet werden, oder sehe ich das falsch? Die einzige Lösung, die 
ich da erkenne ist, die FSM mit weitaus höherem Takt zu betreiben und 
die derzeitigen Zustände entsprechend zu duplizieren/verlängern.

Sehe ich da etwas falsch?

Viele Grüße,
Michael

[Alex (Gast)]

Du brauchst keinen zweiten langsamen Takt. Nimm den Systemtakt und 
erzeuge einen jede Sekunde einen Ein-Takt-breiten Puls und gebe diesen 
auf den Clock Enable Eingang, wenn sich da nur jede Sekunde was ändern 
soll. BTW: Wofür brauch man für solch langsame Anwendungen einen FPGA?

[Stefan W. (wswbln)]

...außerdem sollte es für die FSM halbwegs egal sein, wie schnell sie 
getaktet wird, solange die Bedingungen für die State-Wechsel 
entsprechend klar definiert sind. Oder spielt es bei Dir eine Rolle, 
wieviele Takte eine FSM in State A bleibt, bevor die Bedingung zum 
Wechsel nach B erfüllt ist?

Wenn Du Verzögerungen brauchst, nimm dafür einen extra Zähler, den Du 
(mindestens) in State N-1 zurücksetzst, in State N freigibst und dann 
nach State N+1 wechselst, wenn er einen bestimmten Stand erreicht hat.

[Michael S. (decimad)]

Ja, die FSM soll automagisch jede Sekunde den Zustand wechseln (nach 
einem Tastendruck). Funktioniert ja auch alles ganz toll, aber ich war 
auf der Suche nach besseren Lösungen.

Da gefällt mir die Sache mit dem Clock-Enable besser als würde ich meine 
FSM um Zähler bereichern, die vom Geschehen ablenken.
Man braucht für solch langsame Dinge kein FPGA, das ist schon klar, das 
sollte mich doch aber nicht davon abhalten sowas mal im "langsamen" und 
"beobachtbaren" durchzuspielen. Womit habt ihr denn angefangen? Ein 
3d-Beschleuniger? :)

process(clk)
begin
  if rising_edge(clk) then
    if ce='1' then
 
    -- Aktionen hier einfügen, welche mit langsamen Takt laufen    
 
    end if;
  end if;
end process;

Solche Konstrukte werden also durch Clock-Enable auf der Hardware 
synthetisiert, ja? Solange der Puls-Generator mit dem selben Takt läuft 
wie dieser Prozess kann es auch nicht passieren, dass die CE'te-FSM 
sozusagen zweimal durchläuft für einen Puls, ja?

Damit habe ich jetzt schon zwei praktische Dinge für meine Bibliothek, 
einen Taktgenerator und einen Pulsgenerator :) Für das Eintakten von 
Signalen und parallelen Signalen könnte man sich wahrscheinlich auch 
noch Bibliotheks-Netzwerke basteln, dann scheitert es hinterher nicht an 
der Faulheit. :)

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

Michael S. schrieb:
> praktische Dinge für meine Bibliothek,
> einen Taktgenerator
Ein Taktgenerator ist nicht praktisch, sondern praktisch unnötig, will 
heißen in der Praxis unnötig, wenn nicht sogar schädlich...  ;-)

Ein Takt auf einem FPGA ist nicht etwas, das man so leichtfertig mit 
einem Teiler erzeugt. Nein, das ist eine ernsthafte und kritische Sache, 
dafür gibt es spezielle Baugruppen auf dem FPGA (Taktmanager).

> Solche Konstrukte werden also durch Clock-Enable auf der Hardware
> synthetisiert, ja?
Sieh dir doch einfach mal den RTL-Schaltplan deines Codes an...

Michael S. schrieb:
> Nun fallen mir 2 Varianten ein, aus dem Board-Takt einen eigenen Takt zu
> generieren, einmal durch einfach Teilung (Bitabgriff hinter einem
> Inkrementer) zum anderen durch Vergleich mit einer Konstanten hinter dem
> Inkrementer.
> Gibt es irgendwelche Gründe, die gegen eine der Varianten sprechen?
Es sind keine 2 Varianten. Beide machen letztlich das Selbe.

> Zweites Problem: Man möchte ja nun als Benutzer mit so einem Automaten
> kommunizieren und ist zumeist ungetaktet. Daher treffen Eingaben nicht
> zu Taktflanken sondern einfach irgendwann ein. Gibt es irgendeinen Weg
> in VHDL um ohne Warnungen und zuverlässig ein RS-Flipflop mit
> asynchronem Set generieren zu lassen
Aus diesem Grund läuft deine "langsame" FSM eigentlich mit 50MHz, wird 
aber nur 1 mal pro Sekunde (über den Clock-Enable) weitergeschaltet. 
Benutzereingaben werden trotzdem mit 50MHz abgestastet und 
einsynchronisiert. Auf dieses einsynchronisierte Signal kannst du dann 
z.B. eine Flankenerkennung loslassen:
http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung

Wenn du tatsächlich einen so/zu langsamen Takt aussen am FPGA anleigen 
hast, dann kannst du auf folgende Art feststellen, ob zwischen 2 Takten 
ein Eingang aktiv wurde:
http://www.lothar-miller.de/s9y/categories/19-SpikePuls