Clock Switching

@Johnsn

>Wenn ich eine FSM laufen habe und ab einem bestimmten Zustand den Takt
>erhöhe (um mehr als das 100-fache), kann es dann sein, dass die Hardware
>nicht mehr funktioniert, weil Timingverletzungen auftreten, oder kann

Nicht wenn man es richtig macht. Deine FSM läuft IMMER mit dem 
höchstmöglichen Takt (z.B. 100 MHz). Wenn sie langsamer laufen soll, 
muss ein Clock-Enable Signal mit 1 MHz erzeugt werden. Diese Umschaltung 
zwischen Clock enable = Dauer eins und nur ein Takt von hundert kann 
beliebig schnell erfolgen.Der Takt wird dabei nicht verändert, nur das 
Clock-Enable Steuersignal.

>ich diese mit entsprechenden Contraints vermeiden?

Nein, nur durh die richtige Entwurfsmethode.

>Könnten noch andere Probleme auftreten?

Probleme können immer auftreten. Man muss es "nur" richtig machen. ;-)

MfG
Falk

Also ich hätte es so geplant, dass ich dem Design 2 Takte zur Verfügung 
stelle (die beiden sind synchron zueinander) und dann einfach 
multiplexe.

Aus welchem Grund ist Clock-Multiplexing nicht ratsam?

@Johnsn

>Aus welchem Grund ist Clock-Multiplexing nicht ratsam?

Weil

a) wenn man es falsch macht Glitches entstehen (ultrakurze, unsaubere 
Taktpulse), die bringen dir deine synchrone Logik durcheinander, weil 
einige FlipFlops schalten dann (die ein klitzekleinwenig schneller sind) 
und einige nicht -> SCHLECHT!

b) wenn man es richtig macht immer noch das Problem der Asynchronität 
zwischem (neuen) Takt und (alten) Dateneingängen besteht

Beide Problem umgeht man mit dem von mir beschriebenen Verfahren.

MfG
Falk

Ok. Ich habs jetzt trotzdem mal stur mit MUX ausprobiert und es hat auch 
geklappt, Glitches sehe ich allerdings keine am Scope.

Ich will aber auch die Methode mit ClockEnable versuchen und die 
Taktsignale dann vergleichen. Allerdings hab ich das noch nicht so ganz 
verstanden. Ist das ClockEnable Signal also auch ein Takt, wird aber 
nicht als solcher verwendet, sondern kommt auf den Enable-Eingang eines 
FFs?

@Johnsn

>Ok. Ich habs jetzt trotzdem mal stur mit MUX ausprobiert und es hat auch
>geklappt, Glitches sehe ich allerdings keine am Scope.

;-)
Du bist mutig. Nein, nur naiv. Glitches sind GANZ üble Sachen, die zu 
finden kann bisweilen SEHR schwierig sein. Sieh dir das mal an.

http://www.geocities.com/jacquesmartini/digital/glitch/glitch.html

Na, immer noch mutiger Takt-Muxer? Wenn ich dir ein Rat geben darf. Wenn 
du dir viel Stress und im professionellem Umfeld einen bösen Reinfall 
sparen willst, vergiss das Takt-Muxen.

>Ich will aber auch die Methode mit ClockEnable versuchen und die
>Taktsignale dann vergleichen. Allerdings hab ich das noch nicht so ganz
>verstanden. Ist das ClockEnable Signal also auch ein Takt, wird aber
>nicht als solcher verwendet, sondern kommt auf den Enable-Eingang eines
>FFs?

Es ist ein Steuer (enable) Eingang. Etwa so

-- clock enable
process(clk)
begin
  if rising_edge(clk) then
    cnt_ce <= cnt_ce +1;
    if cnt_ce =0 then
      ce <='1';
    else
      ce <='0';
    end if;
  end if;
end process;

--vom clock enable gesteuerter Zähler
process(clk)
begin
  if rising_edge(clk) then
    if ce='1' then
      cnt <= cnt +1;
    end if;
  end if;
end process;

MfG
Falk

Also du meinst, dass ich einfach Strobes erzeuge und dann im 
sequentiellen Process diese Strobes abfrage?

Ich hab es bisher so gelöst (Grafik im Anhang): 100MHz ist der 
Ausgangstakt. Diese teile in einmal in 50MHz und 400kHz. Es sind also 
alle Clocks synchron zueinander. Am Anfang (PowerOn und Initialisierung) 
läuft die FSM mit 400kHz und ab einem Zeitpunkt wird auf 50MHz 
umgeschalten und bleibt so schnell.

Die Frequenzteiler habe ich auch mit Zähler realisiert, allerdings lasse 
ich dann ein FlipFlop toggeln anstatt einen Strobe auszulösen.

@Johnsn

>Also du meinst, dass ich einfach Strobes erzeuge und dann im
>sequentiellen Process diese Strobes abfrage?

Genau.

>Ich hab es bisher so gelöst (Grafik im Anhang): 100MHz ist der
>Ausgangstakt. Diese teile in einmal in 50MHz und 400kHz. Es sind also
>alle Clocks synchron zueinander. Am Anfang (PowerOn und Initialisierung)

Nicht ganz. Die Phase stimmt nicht. Und JA, das ist für ein FPGA von 
heute ein wesentlicher Unterschied.

>Die Frequenzteiler habe ich auch mit Zähler realisiert, allerdings lasse
>ich dann ein FlipFlop toggeln anstatt einen Strobe auszulösen.

Machs mit clock enables. EoD.

MFG
Falk

Den Strobe, also das ClockEnable Signal darf ich aber dann schon muxen?

Ähm, ich habe noch was Wesentliches vergessen: Und zwar dieser "gemuxte" 
Clock wird sowohl intern, also auch dann extern von einer SD-Karte 
genutzt. Da komm ich mit CEs nicht weit?

@ Johnsn

>Den Strobe, also das ClockEnable Signal darf ich aber dann schon muxen?

Ja, solange das alles normal synchron gemacht wird.

>Ähm, ich habe noch was Wesentliches vergessen: Und zwar dieser "gemuxte"
>Clock wird sowohl intern, also auch dann extern von einer SD-Karte
>genutzt. Da komm ich mit CEs nicht weit?

Dann musst du dein Design ändern. Mit deinem bisherigen Ansatz schiesst 
du dir ins Knie.

MfG
Falk

Wie stellst du dir das vor? Die SD-Karte selbst braucht bei der 
Initialisierung 400kHz und danach kann man sie schneller takten.

@ Johnsn

>Wie stellst du dir das vor? Die SD-Karte selbst braucht bei der

OK, wenn es darum geht, den Systemtakt für FPGA und SD-Karte 
umzuschalten, un du sowieso 100 MHz hast, dann sollte eine saubere 
Lösung möglich sein.

Mit deinem 100 MHz Takt baust du dir einen Zähler + State Machine, 
welche zunächst den 400 kHz-Takt und danach den 50 MHz Takt erzeugt. 
Wichtig ist dabei, dass das Ausgangssignal (der umschaltbare Takt) 
DIREKT von einem FLipFlop gespeist wird (welches mit 100 MHz getaktet 
wird). Dadurch kannst du dir sicher sein, dass der Takt glitchfrei ist. 
Den kannst du dann als Takt für SD-Karte und FPGA verwenden.

MFG
Falk