|
Anzeige
|
Übergang zwischen Taktdomänen
Gast
#2004815
Hallo zusammen. Ich habe 2 Taktdomönen und ein globales Statusregister. Dies wird aus der langsameren Domäne gesetzt und in der schnelleren abgefragt. Ich habe bereits versucht den Übergang zu machen indem ich dieses Register über einen FIFO von einer zur anderen Takte. Allerdings scheine ich laut Timing analyse immernoch Probleme mit den Setup- und Hold Zeiten zu haben. Wie gestaltet man einen solchen Übergang richtig? Gruß sim
Gast
#2004929
Hallo, es gibt hier eine gute Seite dazu. http://www.fpga4fun.com/CrossClockDomain.html und wie ich Lothar Miller kenne hat er bestimmt auch was dazu auf seiner Homepage. gruß
Gast
#2005030
sim schrieb: > 2 Taktdomönen Wo kommen denn die Takte her? Sind die irgendwie korreliert? Duke
Gast
#2005078
sim schrieb: > Ich habe bereits versucht den Übergang zu machen indem ich dieses > Register über einen FIFO von einer zur anderen Takte. Allerdings scheine > ich laut Timing analyse immernoch Probleme mit den Setup- und Hold > Zeiten zu haben. Das kenne ich :-) Muss aber ein asynchrones Fifo mit 2 Takten sein. Beitrag "asynchroner FIFO und Timing Report Spartan3aDSP"
Gast
#2005194
Duke Scarring schrieb: > Wo kommen denn die Takte her? Sind die irgendwie korreliert? Ja, der eine kommt aus einer PLL (100MHz) und der andere wird über einen Taktteiler davon abgeleitet.
Gast
#2005218
sim schrieb: > Ja, der eine kommt aus einer PLL (100MHz) und der andere wird über einen > Taktteiler davon abgeleitet. Dann lässt sich doch ein synchrones Design erstellen. Wenn du mit nem Clock Enable den Takt runterteils hast du keine 2 clock domains.
Gast
#2005227
Hmm, jetzt wo du es sagst, stimmt. Komisch dass ich aber Timing Errors bekomme am Übergang die sich stark verbessern wenn ich das Register über ein FIFO führe? Warum ist das dann so?
Gast
#2005234
sim schrieb: > Hmm, jetzt wo du es sagst, stimmt. Komisch dass ich aber Timing Errors > bekomme am Übergang die sich stark verbessern wenn ich das Register über > ein FIFO führe? Warum ist das dann so? Ich weiß jetzt nicht wie du deinen Takt erzeugst. Nutzt du den Ausgang vom Zähler als Takt? Stichwort Registered Clock oder nutzt du wirlich ein clock enable? Ist ein großer Unterschied!!!!
Gast
#2005277
Hochpass schrieb: > Nutzt du den Ausgang vom Zähler als Takt? Nein, ich führe den Ausgang des Zählers nochmal über ein Flip Flpo. Wie hier beschrieben: http://www.mikrocontroller.net/articles/Taktung_FPGA/CPLD sim schrieb: > Nein, ich führe den Ausgang des Zählers nochmal über ein Flip Flpo. Wie > hier beschrieben: Zeig doch mal deinen Code mit den 2 Takten... Und wei der Eine aus dem Andreren erzeugt wird.
Gast
#2005349
Lothar Miller schrieb: > sim schrieb: >> Nein, ich führe den Ausgang des Zählers nochmal über ein Flip Flpo. Wie >> hier beschrieben: > Zeig doch mal deinen Code mit den 2 Takten... > Und wei der Eine aus dem Andreren erzeugt wird. Und zusätzlich noch, welche "Warnings" rauskommen.
Gast
#2005368
Hier der Counter der Teilt...
... und hier das Flip Flop
Warnings sind recht viele. Soll ich die hier wirklich alle Posten? Hast Du CPLD oder FPGA? Woher hast Du das Beispiel? Sieht mir irgendwie komisch aus. Ist auch nicht der komplette Code irgendwie...
Gast
#2007699
Einen Lattice XP2-8E FPGA. Was ist an dem Code komisch?
Gast
#2007837
sim schrieb: > Hier der Counter der Teilt... > process(CLK_INT) > begin > if(CLK_INT'event and CLK_INT='1') then > > if(count >= (ClockDivider-1)) then > MCLK_gated <= not MCLK_gated; > count <= 0; > elsif(count < (ClockDivider-1)) then > count <= count+1; > end if; > > end if; > end process; das 'elsif' kannst du dir sparen, da reicht ein 'else' > ... und hier das Flip Flop > process(CLK_INT, LOCK_int) > begin > > if(LOCK_int='0') then > MCLK <= '0'; > > elsif(CLK_INT'event and CLK_INT='1') then > MCLK <= MCLK_gated; > > end if; > > end process; Du erzeugst hier eine Clock aus einem Counter, also Logik. Diese MCLK willst du wohl an anderen FFs benutzen? So ala 'if rising_edge (MCLK)'? Da wird es ueblicherweise Warnings und/oder Fehler hageln, da ein Logiksignal nicht ueber die normalen Clocknetze verteilt werden kann, sondern nur ueber die normalen Routing-Resourcen. Das MCLK bzw. MCLK_gated muesstest du als clock-enable verwenden und dann fuers Timing einen 'multi-cycle' definieren.
Gast
#2007842
berndl schrieb: > Da wird es ueblicherweise Warnings und/oder Fehler hageln, da ein > Logiksignal nicht ueber die normalen Clocknetze verteilt werden kann, > sondern nur ueber die normalen Routing-Resourcen. Das MCLK bzw. > MCLK_gated muesstest du als clock-enable verwenden und dann fuers Timing > einen 'multi-cycle' definieren. Das stimmt für Lattice-FPGAs nicht. Dort ist es möglich so einen abgeleiten Takt zu erzeugen. Man sollte allerdings darauf achten die PFUs im Ripple-Mode zu verwenden und nicht im Daisy-Chain Mode um bessere Ergebnisse zu bekommen. Ein so erzeugter Takt kann dann wieder auf ein Takt-Netz geführt werden. Mehr dazu in TN1008 auf der Lattice-HP.
Gast
#2008016
Mathi schrieb: > Man sollte allerdings darauf achten die > PFUs im Ripple-Mode zu verwenden und nicht im Daisy-Chain Mode um > bessere Ergebnisse zu bekommen. Das ist interessant. Aber ich versteh die Erklärung nicht so zu 100%. Wenn ich es so aufbaue wie in TN1008 und das MSB des Counters abgreife, dann ist doch das so erzeugte Signal kein Takt der durch 16 geteilt wurde. Er hat zumindest kein Puls Pause Verhältniss von 50/50 mehr, oder? Muss ich einen solchen Takt auch nochmal über ein Flip Flop führen? Gruß Sim
Gast
#2008061
Da hätte ich gleich nich eine Frage, kann ich einen solchen gated Clock ohne bedenken verwenden? Oder ist das echt sooo schlimm wie man immer wider liest?
Gast
#2008072
berndl schrieb: > da ein > Logiksignal nicht ueber die normalen Clocknetze verteilt werden kann In diesem Punkt muss ich Mathi recht geben, ich kann dieses Signal bei Lattice durchaus auf ein Clocknetz geben. Gruß >Da hätte ich gleich nich eine Frage, kann ich einen solchen gated Clock >ohne bedenken verwenden? Oder ist das echt sooo schlimm wie man immer >wider liest? Die Antwort ist ein klares Jein mit Tendenz zum "besser nicht machen". Nur ein paar Punkte: - die gated clock ist immer leicht verzögert zum echten Takt, z.B. um 2 ns bei einer Periode von 10 ns - das hieße, bei einem Taktdomänenübergang in die eine Richtung hast du nur 8 ns Zeit zwischen den beiden Taktflanken, in die andere Richtung sogar nur 2 ns. Das wird zu Timing-Problemen führen. Der timing-check berücksichtigt das bei seinen Überprüfungen (sofern die Taktraten richtig vorgegeben sind), es gibt also eine entsprechende Meldung "timing constraints not met". - wird der abgeleitete Takt über normales Routing verteilt, ergibt sich ein großer Skew zwischen den einzelnen Registern, das führt beinahe zwangsläufig zu hold time violations - zumindest Lattice isplever kann das zwar automatisch korrigieren, aber das kostet Zeit und Ressourcen. - soll der abgeleitete Takt wieder in ein globales Taktnetz, so hat man zwar keinen skew, aber eine stark erhöhte Laufzeit. Punkt 1 wird dadurch noch viel stärker ausgeprägt. - ich bin bisher noch über kein Design gestolpert in dem ein abgeleiteter Takt wesentliche Vorteile gegenüber einem "echten" Takt aus einer DCM/PLL/DLL bzw. gegenüber einem clock-enable gehabt hätte. Zusammenfassend: Man kann eine gated clock benutzen, wenn man genau weiß was man tut, allerdings gibt es kaum Gründe dafür.
Gast
#2008169
Jan M. schrieb: > Zusammenfassend: Man kann eine gated clock benutzen, wenn man genau weiß > was man tut, allerdings gibt es kaum Gründe dafür. Ich möchte noch einwerfen, das Jans Aussagen sich auf ein FPGA-Design beziehen und es hier ein Namensproblem gibt. Von einem Gated-Clock spricht man wenn man Flipflops mittels eines Gatters und eines Enable-Signals vom Taktnetz abtrennen kann. Damit ist kein abgeleiteter Takt gemeint. Solche Techniken sind in der IC-Entwicklung gang und gebe.
Gast
#2008279
Oh, großes Entschuldigung. Ich meinte natürlich ob ich einen Derived Clock ohne Bedenken verwenden kann. Der Takt wird gemäß http://www.mikrocontroller.net/articles/Taktung_FPGA/CPLD erzeut. Sorry, aber ich denke das mit der Verzögerung gilt dann genau so, oder?
Gast
#2008294
Jetzt fällt mir gerade auf, wenn ich mir aus 100MHz einen Takt herabteile und diesen über ein FF führe um ihn zum Derived Clock zu machen, dann sind die Flanken ja doch nicht mehr sync. Denn der Derived Clock ist ja wie von Jan M. beschrieben verzögert worden. Stimmt das? Sollte ich dann doch eher den Gated Clock als Clock Enable verwenden? @ sim (Gast) >machen, dann sind die Flanken ja doch nicht mehr sync. Denn der Derived >Clock ist ja wie von Jan M. beschrieben verzögert worden. Stimmt das? Ja. >Sollte ich dann doch eher den Gated Clock als Clock Enable verwenden? Clock enable. MFG Falk Mathi schrieb: > Jan M. schrieb: >> Zusammenfassend: Man kann eine gated clock benutzen, wenn man genau weiß >> was man tut, allerdings gibt es kaum Gründe dafür. > > Ich möchte noch einwerfen, das Jans Aussagen sich auf ein FPGA-Design > beziehen und es hier ein Namensproblem gibt. Von einem Gated-Clock > spricht man wenn man Flipflops mittels eines Gatters und eines > Enable-Signals vom Taktnetz abtrennen kann. Damit ist kein abgeleiteter > Takt gemeint. Vollkommen richtig. Im FPGA sind diese beiden Arten von Takten aber praktisch identisch, deswegen auch der Mischmasch in meinem Post. Die möglichen Probleme sind in beiden Fällen gleich. >Sollte ich dann doch eher den Gated Clock als Clock Enable verwenden? Ja, das ist in jedem Fall die sauberere Lösung auf auf Dauer auch mit weniger Problemen verbunden. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
