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?
@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.
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
@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
Angehängte Dateien:
-
clkswitching.PNG
885 Bytes
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
Ä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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.