www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Clock Switching


Autor: Johnsn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

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 
ich diese mit entsprechenden Contraints vermeiden?

Könnten noch andere Probleme auftreten?

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Johnsn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Clock Multiplexen ist meistens nicht empfehlenswert und sollte nur 
verwendet werden wenn es absolut notwendig ist, z.B. wenn ein Clock 
ausfällt und man will auf einen alternativ Takt umschalten.
Ein sauberes Clock Multiplexen läßt sich nur in einigen FPGA's 
realisieren, z.B. bei Xilinx mit den BUFGMUX-Primitiven. Bei CPLD ist es 
überhaupt nicht ratsam.

Wenn es nur darum geht die FSM einmal schneller und einmal langsamer 
laufen zu lassen, dann solltest Du wirklich den Ratschlag von Falk 
befolgen.

Klaus

Autor: Johnsn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aus welchem Grund ist Clock-Multiplexing nicht ratsam?

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Johnsn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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/gl...

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

Autor: Johnsn (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Johnsn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Strobe, also das ClockEnable Signal darf ich aber dann schon muxen?

Autor: Johnsn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ä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?

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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


Autor: Johnsn (Gast)
Datum:

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

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.