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
@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ß
