State Machine mit 2 Clocks

[Bege (Gast)]

Hallo,

ich möchte eine Statemachine bauen, die abhängig vom State 
unterschiedliche Clock-Signale zum Weiterschalten benutzt.

Ich habe 2 Clocks in meinem System (CLPD+µC). Während der Init-Phase 
wird das CPLD vom µC mit dem Takt versorgt (GPIO, low Speed). Danach 
schaltet der µC einen Clk-Generator (exterer PLL Baustein) ein. Das CPLD 
soll dann mit dieser Clk arbeiten.

Also in etwa so:
(Ist nur ein Bespiel. Mein Design hat noch mehr Ein- u. Ausgangssignale 
und States.)

--state machine process.
process (current_s,input)
begin
  case current_s is
     when ready =>          --when current state is "ready"
     output <= '0';
     if(input ='1') then
      next_s <= steady;
     else
      next_s <= ready;
     end if;  

     when steady =>;        --when current state is "steady"
     if(input ='0') then
      output <= '0';
      next_s <= ready;
     else
      output <= '1';
      next_s <= go;
     end if;
    
     when go =>;            --when current state is "go"
      output <= '1';
      next_s = go;
  end case;
end process;

process (clk1,clk2)
begin
 if (current_s = ready) and (rising_edge(clk1)) then
       current_s <= next_s;   --state change.

 else if ((current_s = steady) or (current_s = go)) and (rising_edge(clk2)) then
       current_s <= next_s;   --state change.
      end if;
 end if;
end process;

Geht das so ?
Gibt es bessere Lösungen ?
Kann man den unteren Prozess übersichtlicher schreiben?
Wenn die Übergänge von weiteren States abhängen wird das schnell 
unübersichtlich.


Gruß und Danke
Bernd

[Achim S. (Gast)]

Bege schrieb:
> Geht das so ?

Was sagt denn dein Synthesetool? Ich hoffe doch mal dass es mault, weil 
es die zwei rising_edge-Abfragen in einem Prozess nicht in Hardware 
abbilden kann.

Was für ein CPLD verwendest du denn? Der Coll-Runner II hat 
beispielsweise einen CLK-Multiplexer, der die Auswahl verschiedener 
Taktquellen zulässt. Allerdings kann die Auswahl der Clk im 
CLK-Multiplexer nur zur Programmierzeit geändert werden. Ein Umschalten 
der CLK während der Laufzeit ist bei dem Chip nicht vorgesehen (und wird 
daher nicht funktionieren, auch wenn du es anders beschreibst).

Mein Vorschlag wäre: lass die Logik zum Hochfahren aus der langsamen CLK 
laufen (und zwar immer, nicht nur beim Hochfahren). Und lass die 
"schnellen" FSMs aus der schnellen CLK laufen. Gib das Clock-Enable für 
die schnelle CLK aber erst frei, wenn die externe PLL eingeschwungen 
ist.

Bege schrieb:
> Wenn die Übergänge von weiteren States abhängen wird das schnell
> unübersichtlich.

Stimmt: steig auf die Ein-Prozess-Schreibweise für FSM um. (Die hier 
benutzte Zwei-Prozess-Schreibweise ist nett fürs erste Erklären, beim 
praktischen Arbeiten ist aber - zumindest für meinen Geschmack - die 
Ein-Prozess-Schreibweise sehr viel angenehmer).

[Simon (Gast)]

Wenn Du ausreichend Logik-Zellen hast. Lass zwei identische 
state-machines (jeweils eigene Signale/Register) mit deinen 2 clocks 
gleichzeitig laufen und multiplexe deren Ausgänge mit einer 
übergeordneten state-machine. Diese mit der schnelleren clock laufen 
lassen und darin ggf. Konflikte zwischen den Zuständen auflösen.

[Simon (Gast)]

oooder aber wenn die clocks nicht ohnehin schon allzu schnell sind. 
wähle eine noch schnellere clock (kgV) und arbeite mit clock enables...

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

Bege schrieb:
> Geht das so ?
Ein getakteter Prozess wird in ein oder mehrere Flipflops umgesetzt. 
Gibt es Flipflops im CPLD, die 2 Takteingänge haben? Nein? Also geht es 
nicht.

Oder andersrum: hast du irgendwo anders schon mal so eine Beschreibung 
gesehen? Nein?

> Während der Init-Phase wird das CPLD vom µC mit dem Takt versorgt (GPIO,
> low Speed). Danach schaltet der µC einen Clk-Generator (exterer PLL
> Baustein) ein. Das CPLD soll dann mit dieser Clk arbeiten.
Kannst du dir Glitches erlauben? Kannst du das CPLD während der 
Taktumschaltung in den Reset versetzen?

> Gibt es bessere Lösungen ?
Wenn das mit dem Reset nicht geht, dann wirst du einen glitchfreien 
externen Taktumschalter brauchen. Sowas wie den ICS580-01
Oder probier mal das da:
https://www.google.de/search?q=clock+switching+glitch+free

[Bege (Gast)]

Danke für die Antworten.

>Was sagt denn dein Synthesetool?
Hab's noch nicht ausprobiert.

>Was für ein CPLD verwendest du denn?
Ist ein XC95x144.

>Wenn Du ausreichend Logik-Zellen hast.
Leider nein.

>wähle eine noch schnellere clock
habe nur die beiden genannten Clk-Sourcen.

>Gib das Clock-Enable für die schnelle CLK aber erst frei, wenn die >externe PLL 
eingeschwungen ist.
Dafür sorgt der µC.

>Oder andersrum: hast du irgendwo anders schon mal so eine Beschreibung
>gesehen? Nein?
Nein, deswegen frage ich ja ob es überhaupt möglich ist.
Bzw. wie man so etwas macht. Mein Vorhaben sollte doch nicht 
ungewöhnlich sein. Jeder moderne µC oder PC kann seine Systemfrequenz an 
die geforderte Leistung anpassen.

>Wenn das mit dem Reset nicht geht
Reset geht nicht.

>Kannst du dir Glitches erlauben?
Ja. Die Statemachine soll abhänging von div. Eingangssignalen durch die 
States schalten. Selbst wenn beim Umschalten des Clks ein Glitch 
entsteht, ändern sich die Eingangssignale nicht. Der aktuelle State 
sollte also nicht verlassen werden.

Ich denke ich werde den Clk-Multiplexer vor den CLK-Eingang der 
Statemachine hängen und dann abhängig vom State umschalten.

In etwa so:

process (clk_temp)
begin
 if (rising_edge(clk_temp)) then
       current_s <= next_s;   --state change.
 end if;
end process;

process (clk1,clk2,current_s) is
begin
 case current_s is
   when ready   => clk_temp <= clk1;
   when steady  => clk_temp <= clk2;
   when others  => clk_temp <= clk1;
 end case;
end process;

Bernd

[Christian R. (supachris)]

Bege schrieb:
> Ich denke ich werde den Clk-Multiplexer vor den CLK-Eingang der
> Statemachine hängen und dann abhängig vom State umschalten

Meines Wissens haben die alten XC95 keine Clock Muxer.

[Weltbester FPGA-Pongo (Gast)]

Christian R. schrieb:

> Meines Wissens haben die alten XC95 keine Clock Muxer.

Brauchen sie auch nicht, weil man die noch bequem gaten und muxen 
konnte. Erst bei den FPGAs ist es ein Problem (geworden) Takte zu 
multiplexen.

Wenn es keine Clock buffer gibt, müssen die Signale der konkurierenden 
Taktdomäne eben einsynchronisiert werden und mit der Domäne 1 laufen - 
so wie man es überlicherweise eben tut.

Es gibt konkret überhaupt keinen Grund eine FSM mit unterschiedlichen 
Takten laufen zu lassen, wenn nicht eine Form der Redundanz oder 
wirklich beide Ausgänge benötigt werden.

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

Weltbester FPGA-Pongo schrieb im Beitrag #4569447:
> Erst bei den FPGAs ist es ein Problem (geworden) Takte zu multiplexen.
Naja, wenn da eine FSM drauf läuft und beim Umschalten des Taktes ein 
Glitch auftritt, dann kommt es eben auch drauf an, ob jedes Flipflop 
genug Energie fürs Umschalten bekommt. Im schlimmsten Fall (und der 
passiert laut Murphy täglich) sehen dann bei einem 8 Bit Zähler 7 
Flipflops den Glich als Takt und einer ignoriert ihn...
Und dieses Problem ist letztlich plattformunabhängig. Das passiert mit 
74er TTL genauso wie mit 500MHz FPGAs.
Die Taktumschaltung muss also unbedingt glitchfrei sein. Oder die 
betroffenen FSM und Zähler im Reset.

[J. S. (engineer)]

Etwas wissenschaftlicher ausgedrückt liegt das Problem darin, dass auch 
die schnellsten der schnellen FPGAs digitale Bausteine sind, die ein 
zeitdiskretes Verhalten aufweisen. Speziell zum Taktzeitpunkt sind die 
Zustände per Definition illegal und unbekannt. Da kann man - anders als 
in Software - keine Annahmen über den Zustand machen und das 
Fortschalten berechnen, es sei denn, man sorgt dafür daß die Zustände 
stabil sind, also etwaige Taktodomänen-Wechsel geschützt sind.

In der Software ist das kein Problem, das zu beschreiben und in 
C-Programmen zu nutzen, weil eine CPU zu einem Zeitpunkt nur eine Aktion 
ausführen kann.

Die obige Aufgabe löst man daher mit entweder zwei asynchronen domains 
und synchronen states (synch auf datenebene) oder mit synchronisierten 
asynchronen Signalen (synch auf signalebene).

Vorschlag 1 impliziert eine erhöhte Latenz zwischen den Domänen und die 
höchste Abtastrate innerhalb derselben -
Vorschlag 2 impliziert, daß die maximale Frequenz der einzigen Domäne 
unterhalb der Hälfte der kleineren der beiden Wechselfrequenzen der 
Eingangssignalen liegt.