Guten Tag, Für ein Projekt muss ich einen Ethernet Phy mit einem, auf 40 Mhz getakteten, Cyclone II FPGA ansprechen. Soweit ich das Interface verstanden habe, wird sowohl der RX als auch der TX Clock von Phy-Baustein mit einer Frequenz von 40 Mhz (bei 100 MBit) generiert. Somit sind aber beide Clocks zu meinem internen Clock im FPGA asynchron. Würde es funktionieren mittels einer der interne PLL's eine eigene Clockdomain, die auf (40 + n*40) Mhz getaktet ist, einzusetzen oder habe ich etwas übersehen? (n.. Anzahl der FlipFlops die zum synchronisieren verwendet werden) Was ich leider auch nicht ganz verstanden habe, ist ob der RX und der TX Clock zueinander synchron sind, oder ist das vom Phy Baustein abhängig? Ein anderer Ansatz wäre das RMII - Interface einzusetzen. Das würde ja den Takt extern bekommen und somit syncron arbeiten wenn der FPGA den Takt generiert. Oder habe ich das Datenblatt falsch interpretiert? Hatte jemand auch schon die Problemstellung bzw. schon eine Lösung erarbeitet? Ich habe bis jetzt leider nur eine Verilog Lösung gesehen, kann aber leider nur VHDL. Danke im Vorraus! lg Johannes Müller
moin also soweit ich weiß ist der clock bei 100 mbit nicht 40 sonden 25 MHz. die frequenz wird von dem baustein erzeugt. und die tx und rx takte müssen durch buffer laufen und dem baustein zurück geführt werden. tipp benutze doch einen rmii ethernet wrapper.
> Was ich leider auch nicht ganz verstanden habe, ist ob der RX und der TX > Clock zueinander synchron sind, oder ist das vom Phy Baustein abhängig? TxCLK und RxCLK sind zueinander asynchron zum Einsynchronisieren kannst du entweder mit einem höhreren interen Takt des FPGAs die Signale abtasten. RxCLK und TxCLK sind 25 MHz also brauchst du mindestens 50 MHz zum Abtasten, oder du benutzt eine FIFO-Struktur, indem du z.B die Register, mit denen du die Rx-Daten empfängst, mittels RxCLK eintaktest und dann die Register über eine geeignete Busy-Logik wieder synchron mit dem interen Takt des FPGA ausliest. Vorteil: geringere Taktrate des FPGA möglich, Nachteil: Ist etwas komplizierter.
Ich würde das ganze Ethernetnet Interface mit dem externen (MII) Takt arbeiten lassen. Das Interface sollte dann die ankommenden Daten in einem FIFO zwischenspeichern bzw. die loszuschickenden aus einem auslesen. Und die andere Seite des FIFOs kannst du dann ja mit Systemtakt betreiben.
Danke für eure Antworten! @lulu Sorry du hast recht, bei 100 MBit sind es 25 Mhz. Danke für den Tipp mit dem "rmii ethernet wrapper", werde mich gleich mal darüber schlau machen. @Schlumpf und Matthias Ich habe schon fast befürchtet das ich um 2 Clockdomains nicht herumkommen werde. Das Problem, das ich leider mit dem FIFO haben werde, ist eine "große" Verzögerung. Das Einsatzgebiet sollte EtherCAT sein. Da wäre es wohl am doch besten mit einem höheren Takt abzutasten. Aber wäre es allgemein bei dieser Problemstellung nicht einfacher durch den EInsatz eines RMII Interface immer Taktsynchron zu bleíben, da der Takt ja in diesem Fall vom FPGA geliefert wird?
@Johannes S. >Ich habe schon fast befürchtet das ich um 2 Clockdomains nicht >herumkommen werde. Das ist kein wirkliches Problem. >Das Problem, das ich leider mit dem FIFO haben werde, ist eine "große" >Verzögerung. Das Einsatzgebiet sollte EtherCAT sein. >Da wäre es wohl am doch besten mit einem höheren Takt abzutasten. NEIN! Nimm zwei kleine (16 Worte) asynchrone FIFOs (CoreGenerator) und kopple damit deine beiden RX/TX Takte an deinen FPGA Takt. Eigentlich brauchst du nur zwei Clock-Domains. Benutze den RX-Takt als Systemtakt für dein ganzes FPGA, dann brauchst du nur noch für die TX-Seite einen kleinen asynchronen FIFO. Keine Problem mit Verzögerungen. >Aber wäre es allgemein bei dieser Problemstellung nicht einfacher durch >den EInsatz eines RMII Interface immer Taktsynchron zu bleíben, da der >Takt ja in diesem Fall vom FPGA geliefert wird? Du arbeitest IMMMER taktsynchron. Doch manchmal hat man eben mehrere Taktdomänen und die muss man RICHTIG (tm) kopplen, z.B. mit asynchronen FIFOs. MFG Falk
> Das Problem, das ich leider mit dem FIFO haben werde, ist eine "große" > Verzögerung.... Wenn du das FIFO sehr klein machst, dann ist auch die Verzögerung gering.. 2 Byte sollten locker genügen. Oder du machst es so, wie Falk es geschrieben hat, dass du eben mit dem einen Takt dein ganzes FPGA Taktest. Könnte allerdings das Problem aufwerfen, dass im Falle eines "Absturzes" des PHYs du nicht sicher sagen kannst, ob du dann noch den Takt vom PHY erhältst und somit dann auch dein FPGA "steht". Aber das müsstest du dann halt mal genauer anschauen.
@Schlumpf >zum Einsynchronisieren kannst du entweder mit einem höhreren interen >Takt des FPGAs die Signale abtasten. RxCLK und TxCLK sind 25 MHz also >brauchst du mindestens 50 MHz zum Abtasten Aber würde ich dann nicht Gefahr laufen Metastabil zu werden? Immerhin weiß ich ja die Phasenlage des einzusynchronisierenden Taktes im Vergleich zu meinem internen Takt nicht. Und das könnte zu einer Setup / Holdzeitverletzung führen. Somit müsste ich mehrere FF's seriell schalten um den Clock einsynchronisieren. @Falk und Schlumpf Jetzt ist mir richtig klar geworden, wie das mit den asynchronen FIFO's gemeint war, danke! Ich hatte bisher noch nie die Problemstellung zwischen 2 Clockdomains, deren Frequenz sehr ähnlich war, Daten zu "tauschen". Ich habe übrigends auf http://tinyurl.com/32gznm auch noch eine ganz gute Beschreibung zu einem async. FIFO gefunden, falls noch jemand daran intresse hat. @Ulrich Leicht schon was dafür implementiert? lg J.
@Johannes S. >>brauchst du mindestens 50 MHz zum Abtasten >Aber würde ich dann nicht Gefahr laufen Metastabil zu werden? Immerhin Doch. Du kannst jedoch die WAHRSCHEINLICHKEIT, dass ein metastabiles Ereigniss bis in deine Logik vordringt masiv verringern, indem du die vielzitierten Zwei-FlipFlop Synchronizer verwendest. Aber das Problem an sich solltest du sowieso nicht mit Überabtastung lösen. MfG Falk
@Johannes: Bei den Setupzeitverletzungen kannst du natürlich Glitches bekommen. Die kannst du aber mit 2 FF filtern. Die elegantere Methode ist allerdings, ein FIFO zu verwenden.
@Schlumpf
>Bei den Setupzeitverletzungen kannst du natürlich Glitches bekommen.
Metastabile Zustände, das sind nicht direkt Glitches. Das sollte man
unterscheiden.
MFG
Falk
@Falk: Du hast recht, ich korrigiere mich: Bei den Setupzeitverletzungen kannst du ein metastabiles Verhalten des FFs bekommen. Der Ausgang des FFs kann kurzzeitig den Zustand seines Eingangs annehmen, dann aber selbsttätig wieder in den ursprünglichen Zustand zurückkippen. Dieser kurzzeitige Peak, der hierbei entsteht, zeigt exakt das gleiche Verhalten, wie ein Glitch, der aus der klassichen Problematik bei der kombinatorischen Auswertung unterschiedliche schnell einschwingender FFs herrührt. Daher hab ich ihn vereinfacht auch als Glitch bezeichnet.
Bei einem metastabilen Verhalten kann der Ausgang SCHWINGEN, also auch öfter zwischen 1 und 0 hin- und herpendeln. Ob man das bei einem modernen FPGA noch mit einen Oszi beobachten kann, ist einen andere Frage. Klaus
@ Johnsn >Bei modernen FPGAs wird dieses Schwingen bereits unterdrückt. Woher weisst du das? Ist es nicht eher so, dass die Dinger dermassen schnell sind, dass sie gar keine Zeit zum Schwingen haben? Sie können sich "nur ein Weile"* nicht für einen stabilen Zustand entscheiden. MFG Falk *bei heutigen FPGAs ~1..3ns
Angehängte Dateien:
-
metastabilFF.PNG
6 KB
@Falk Ich hab jetzt nochmal nachgesehen und ich habe mich richtig erinnert! Moderne FlipFlops sind in der Lage Schwingungen zu unterdrücken. Jedoch der Ausgangspegel ist immer noch als metastabil zu interpretieren, da dieser "irgendwas" sein kann (siehe Grafik). Die Grafik verdeutlicht auch, was die berühmten 2 FFs machen, bzw. dass man mit 3 FFs auf der sicheren Seite ist.
Wo hast Du denn den Blödsinn her? Weder haben FF einen Mechanismus um Schwingungen zu unterdrücken (das würde sie sicherlich langsam machen), noch stimmt diese Grafik. Bei Metastabilität ist nicht das 1. FF nach einer gewissen zeit auf dem halben Pegel und das 2. macht dann ein sauberers Signal draus. Bei Metastabilität hat das 1. FF nach der Takt-Periode mit einer gewissen Wahrscheinlichkeit wieder einen gültigen Pegel. Diese Wahrscheinlichkeit ist sehr, sehr groß, aber nie ganz 100 %. Im Fall, daß das 1. FF trotzdem noch metastabil ist, wenn das 2. FF eintaktet, dann wird das 2. metastabil. Daß dieses dann wiederum nach Ablauf der Periode einen ungöltigen Zustand hat, ist dann sehr, sehr, sehr, sehr groß, aber immer noch nicht 100 % (praktisch schon). Klaus
Also diesen "Blödsinn" hab ich in einer ASIC-Entwurf Vorlesung gehört und nochmal nachgefragt. Diese Grafik ist sehr wohl richtig, wenn man auch der Tatsache Glauben schenkt, dass FFs Schwingungen unterdrücken können. Es gibt sogar auch FFs mit negativer Holdzeit! 8-| Du hast wohl meinen Text dazu nicht richtig gelesen. Ich habe gesagt, dass der Pegel nach dem 1. FF IRGENDWAS sein kann, aber niemals, dass der Ausgangspegel die Hälfte vom Eingangspegel ist! Mach halt einen besseren Vorschlag um "irgendwas" darzustellen! ;-)
FF mit negativer Hold-zeit haben nichts mit Metastabilität zu tun, sondern nur mit Verzögerungen im Eingang. Und Deine Grafik ist sehr interpretationsbedürftig, weil es eben nicht darum geht, ob die Ausgänge irgendeinen Pegel haben, sondern ob die Länge dieser gezeichneten Schwingung bis zur nächsten Taktflanke reichen oder nicht.
Hi! Die Sache mit negativen Holdzeiten war ja nur ein Beispiel, was jetzt nichts mit dem Thread selbst zu tun hat. Bei Bedarf kann ich gern noch näher auf die Grafik eingehen. Gruß
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.