State Machine mit 2 Clocks

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).

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.

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

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:

1

process (clk_temp)

2

begin

3

 if (rising_edge(clk_temp)) then

4

       current_s <= next_s;   --state change.

5

 end if;

6

end process;

7

8

process (clk1,clk2,current_s) is

9

begin

10

 case current_s is

11

   when ready   => clk_temp <= clk1;

12

   when steady  => clk_temp <= clk2;

13

   when others  => clk_temp <= clk1;

14

 end case;

15

end process;

Bernd

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.