Schlechtes Augendiagramm, wo soll ich anfangen zu suchen?

Ich versuche, ein 100-Mbit-Ethernet-Board zu debuggen, und stoße auf ein Problem, das ich nur schwer lösen kann.

Dies ist das Augendiagramm für das Sendepaar. Das Empfangspaar ist sehr ähnlich. Es ist ein LAN8700-PHY, und ich habe die MII-Schnittstelle effektiv deaktiviert, sodass der PHY IDLE-Codesequenzen überträgt. Es wird gemäß Datenblatt in 100 Mbit / FDX gezwungen. 100 Mbit / HDX ist identisch.

Korrektur: Das Design verwendet die interne 1,8-V-Versorgung des LAN8700, um sein VDD_CORE-Netz mit Strom zu versorgen. Ich muss die 1,8-V-Logikversorgung mit der VDD_CORE-Versorgung in meiner früheren Beschreibung verwechselt haben. Es scheint mir, dass Stromversorgungsrauschen keine so hohe Wahrscheinlichkeit ist, da die hohen, Null- und niedrigen Pegel tatsächlich ziemlich anständig sind. Das heißt, das Auge ist nicht "gequetscht". Die Tatsache, dass die Verstöße alle wie sehr gute Übergänge aussehen, nur zeitlich "verzerrt", lässt mich denken, dass das Problem im Kristall oder in der Versorgung des Kristalltreibers / der PLL in der PHY liegt.

Wenn ich das Augendiagramm laufen lasse (ca. 15 Minuten), werden die Verstöße in der Maske so "ausgefüllt", dass die weißen Verstöße, die Sie auf dem Bild sehen, zu weißen Chevron (>) -Formen auf der rechten Seite der blauen Masken werden. Dies würde mir sagen, dass die Timing-Fehler mehr oder weniger zufällig verteilt sind und nicht irgendeine Art von diskretem Rauschen, das das Timing um einen exakten Betrag abreißt.

Der Kristall, den der PHY verwendet, hat eine 30-ppm-Spezifikation, die gut innerhalb der 100-ppm-802.3-Spezifikation und sogar innerhalb der vom PHY angegebenen 50-ppm-Spezifikation liegt. Ich verwende Ladekondensatoren, die dem entsprechen, wonach der Kristall sucht, und die dem, was der LAN8700 als Nennkapazität angibt, ziemlich nahe kommen.

Bevor ich die MII-Schnittstelle deaktivierte, wurden Framing-Fehler angezeigt (wie im ifconfig-Programm meines Linux angegeben). Es gibt keine Fehler, wenn ich die Verbindung zu 10Mbit erzwinge.

Eines der sehr merkwürdigen Dinge, die mir aufgefallen sind, ist, dass wenn ich das Oszilloskop so einstelle, dass es das Signal RX_ER (Empfangsfehler) vom PHY zum MAC auslöst, es niemals einen Fehler signalisiert, obwohl sich die Rahmenfehler in den MAC-Berichten ansammeln. Nach dem Lesen des Datenblattes für die PHY ist klar, dass es tatsächlich nur sehr wenige Situationen gibt, in denen RX_ER behaupten würde, aber ich finde es sehr schwierig zu glauben, dass bei einem Augendiagramm wie dem, was ich sehe, die Fehler tatsächlich zwischen der PHY und liegen der MAC.

Ich verstehe die Grundlagen von Augendiagrammen, aber ich schaue auf einige der erfahreneren Poster, in der Hoffnung, dass sie einige ihrer Erfahrungen bei der Übersetzung bestimmter Verstöße gegen Augenmustermasken in wahrscheinliche Quellen teilen können.

(Bearbeiten: Schaltplan hinzugefügt, korrigierte VDD_CORE-Bezugsquelle)

Ich sehe viele Dinge, die möglicherweise die Probleme mit dem Augendiagramm verursachen können, die Sie sehen. Keine "rauchende Waffe", aber einige Dinge, die möglicherweise etwas durcheinander bringen könnten.

Sie haben 0,01 uF Kappen (C211, C212, C214 und C217) an den nicht verwendeten Pins des RJ-45 und den mittleren Abgriffen des Transformators. Ich empfehle, diese Kappen kurzzuschließen. Ihre Verwendung von Kappen hier ist ungewöhnlich und kann später zu Problemen führen, obwohl es unwahrscheinlich ist, dass sie die Probleme mit dem Augendiagramm verursachen, die Sie haben. Soweit ich das beurteilen kann, besteht der einzige Grund für diese Obergrenzen in einem DC-Blockierungsschema, wenn jemand ein nicht standardmäßiges Power-over-Ethernet-Schema verwendet. Standard-POE benötigt diesen Schutz nicht, und da der POE-Standard jetzt "alt" ist, ist es unwahrscheinlich, dass Sie auf Nicht-POE-Standardgeräte stoßen.

Entfernen Sie die Kappen C19 und C25, 10 pF an den Ethernet-Abschlusswiderständen. Diese sind viel zu klein und zu weit von allem entfernt, was kritisch ist, um von Nutzen zu sein.

Ändern Sie C18 und C24, 0,01 uF Kappen an den Ethernet-Abschlusswiderständen, auf mindestens 0,1 uF. Sie könnten sogar 4,7 uF versuchen. Die "Stromschiene", die diese Kappen entkoppeln, muss ziemlich stabil sein, und es könnte eine überraschende Strommenge durch die Abschlusswiderstände fließen. Wenn L4 / L5 den Stromfluss zu stark einschränkt und die Kappen nicht den Durchhang aufnehmen, können Datenfehler auftreten.

Entfernen Sie C16, C17, C22 und C23 - alle 10 pF-Kappen auf den Ethernet-Datenleitungen. Der einzige Grund dafür ist die EMI-Filterung, die für das Debuggen nicht benötigt wird. Entfernen Sie sie, um sicherzustellen, dass sie keine anderen Probleme verursachen. Sie können sie später jederzeit wieder einsetzen, wenn dies erforderlich ist.

Ändern Sie die Kappen C20 und C21, 0,022 uF an den Mittelhähnen des Transformators, auf mindestens 0,1 uF. 1.0 uF könnte auch gut zu versuchen sein. Diese Leitung kann angesichts des 10-Ohm-Widerstands und von L4 / L5 zu stark abfallen. Sie können dies sogar zum Debuggen an VCC kurzschließen. Der einzige Grund für den Widerstand (und in geringerem Maße für die Kappe) ist die EMI-Filterung. Wenn Sie die Platine erneut drehen, sollten Sie die 10-Ohm-Widerstände direkt an VDD33 anschließen, anstatt L4 / L5 zu durchlaufen. Der 10 Ohm Widerstand und L4 / L5 sind redundant. Wenn Sie direkt zu VDD33 wechseln, können Sie verhindern, dass Rauschen in Ihre Abschlusswiderstände eindringt, und die Filterung in diesem Bereich vereinfachen.

Sie benötigen mehr Kappen am VDDIO-Pin oder schließen die Perle kurz. Dieser Pin versorgt viele E / A-Pins mit Strom und hat viel Strom. Wenn es aufgrund des LC-Filters (Perle + 0,4 uF) an Strom mangelt, treten an den E / A-Pins gleichzeitig viele Schaltgeräusche auf. Das verursacht tatsächlich mehr Rauschen als das, was Sie mit dieser Perle herausfiltern. Es ist sogar möglich, dass dieses Rauschen zu den Ethernet-Ausgängen gelangt.

Stellen Sie sicher, dass die Pinbelegung Ihres Transformators korrekt ist. Obwohl dies unwahrscheinlich ist, ist es möglich, dass der mittlere Hahn und ein weiterer Stift ausgetauscht werden. Es lohnt sich, 5 Minuten damit zu verbringen, die Dinge zu überprüfen. Überprüfen Sie auch die Pinbelegung des LAN8700.

Wenn nichts davon die Dinge verbessert, holen Sie sich einen 25-MHz-Metalldosenoszillator und ersetzen Sie Ihren Kristall. Ich habe gesehen, wie Kristallschaltungen seltsame Dinge tun. Wenn es also nur zur Beruhigung ist, lohnt es sich, Ihr Prototyp-Board zu hacken, um sicherzustellen, dass Ihr Clk stabil ist.

Das ist alles was ich im Moment sehe. Hoffe das hilft!

Meine 2 Cent: Ich stimme Ihrer Empfehlung zu, den richtigen Quarzoszillator für 25 MHz zu wählen. Ich habe den DP83865DVH von NSC im 1-Gbit-Modus verwendet, und als er auf einem langen Testkabel ("spezielle" schlechte 5-Katzen-Qualität und fast 110 m) in einem instabilen Zustand war, machte das Ersetzen des XTAL einen großen Unterschied. Die Schaltung wurde sehr stabil und der Preis für eine solche "Verbesserung" beträgt nur ~ 10 Cent.