Diagramme des yeux pauvres, où commencer à chercher?

J'essaie de déboguer une carte Ethernet 100Mbit et je rencontre un problème que j'ai du mal à résoudre.

Il s'agit du diagramme de l'œil pour la paire d'émission. La paire de réception est très similaire. C'est un LAN8700 PHY, et j'ai l'interface MII effectivement désactivée, donc le PHY transmet des séquences de code IDLE. Il est forcé en 100Mbit / FDX selon la fiche technique. 100Mbit / HDX est identique.

Correction: la conception utilise l'alimentation interne de 1,8 V du LAN8700 pour alimenter son réseau VDD_CORE; J'ai dû confondre l'alimentation logique 1,8 V avec l'alimentation VDD_CORE dans ma description précédente. Il me semble que le bruit de l'alimentation n'est pas si probable, car les niveaux haut, zéro et bas sont en fait assez décents. Autrement dit, l'œil n'est pas «écrasé». Le fait que les violations ressemblent toutes à de très bonnes transitions, juste "faussées" dans le temps, me fait penser que le problème réside dans le cristal ou l'approvisionnement pour le pilote de cristal / PLL dans le PHY.

Si je laisse le diagramme des yeux s'exécuter (environ 15 minutes), les violations dans le masque "se remplissent" de telle sorte que les violations blanches que vous voyez dans l'image deviennent des formes de chevrons blancs (>) dans les côtés droits des masques bleus. Cela me dirait que les erreurs de synchronisation sont plus ou moins distribuées de manière aléatoire plutôt que d'une sorte de bruit discret tirant la synchronisation d'une quantité exacte.

Le cristal que le PHY utilise a une spécification de 30 ppm qui se situe bien dans la spécification 802.3 100 ppm, et même dans la spécification recommandée de 50 ppm spécifiée par la PHY. J'utilise des condensateurs de chargement qui correspondent à ce que le cristal recherche et qui sont assez proches de ce que le LAN8700 spécifie comme sa capacité nominale.

Avant de désactiver l'interface MII, je voyais des erreurs de cadrage (comme indiqué dans le programme ifconfig de mon Linux). Il n'y a aucune erreur si je force le lien vers 10Mbit.

L'une des choses très étranges que j'ai remarquées est que si je configure la portée pour qu'elle se déclenche sur le signal RX_ER (erreur de réception) du PHY vers le MAC, elle ne signale jamais une erreur même si les erreurs de trame s'accumulent dans les rapports MAC. Maintenant, en lisant la fiche technique de la PHY, il est clair qu'il y a en fait très peu de situations où RX_ER affirmerait, mais je trouve très difficile de croire qu'avec un diagramme de l'œil comme ce que je vois, les erreurs se situent en fait entre la PHY et le MAC.

Je comprends les bases des diagrammes oculaires, mais je regarde certaines des affiches les plus expérimentées, en espérant qu'elles seraient en mesure de partager certaines de leurs expériences dans la traduction de violations spécifiques du masque oculaire vers des sources probables.

(modifier: schéma ajouté, source d'approvisionnement VDD_CORE corrigée)

Je vois beaucoup de choses qui pourraient potentiellement causer les problèmes de diagramme des yeux que vous voyez. Pas de "pistolet fumant", mais certaines choses qui pourraient potentiellement gâcher les choses.

Vous avez des bouchons 0,01 uF (C211, C212, C214 et C217) sur les broches inutilisées du RJ-45 et les prises centrales du transformateur. Je recommande de raccourcir ces plafonds. Votre utilisation des bouchons ici est inhabituelle et pourrait causer des problèmes plus tard, bien qu'ils ne soient pas susceptibles de causer les problèmes de diagramme de l'œil que vous rencontrez. Autant que je sache, la seule raison d'avoir ces bouchons est un schéma de blocage DC lorsque quelqu'un utilise un schéma d'alimentation par Ethernet non standard. Le POE standard n'a pas besoin de cette protection, et comme le standard POE est désormais «ancien», il est peu probable que vous rencontriez un équipement standard non POE.

Retirez les capuchons C19 et C25, 10 pF sur les résistances de terminaison Ethernet. Celles-ci sont bien trop petites et trop éloignées de tout élément critique pour être utiles.

Modifiez C18 et C24, 0,01 uF caps sur les résistances de terminaison Ethernet, à au moins 0,1 uF. Vous pouvez même essayer 4,7 uF. Le «rail d'alimentation» que ces bouchons découplent doit être assez stable, et il pourrait y avoir une quantité surprenante de courant traversant les résistances de terminaison. Si L4 / L5 restreint trop le flux de courant et que les plafonds ne prennent pas le relais, vous pourriez avoir des erreurs de données.

Retirez C16, C17, C22 et C23 - tous les plafonds de 10 pF sur les lignes de données Ethernet. La seule raison à cela est le filtrage EMI et n'est pas nécessaire pour le débogage. Supprimez-les pour vous assurer qu'ils ne causent pas d'autres problèmes. Vous pouvez toujours les remettre plus tard si vous en avez besoin.

Remplacez les capuchons C20 et C21, 0,022 uF sur les prises centrales du transformateur, par au moins 0,1 uF. 1.0 uF pourrait également être utile d'essayer. Cette ligne est peut-être trop tombante compte tenu de la résistance de 10 ohms et de L4 / L5. Vous pouvez même le raccourcir à VCC pour le débogage. La seule raison de la résistance (et dans une moindre mesure du capuchon) est le filtrage EMI. Lorsque vous refaites tourner le PCB, vous devez connecter les résistances de 10 ohms directement au VDD33 au lieu de passer par L4 / L5. La résistance de 10 ohms et L4 / L5 sont redondantes. En allant directement au VDD33, vous pouvez éviter d'injecter du bruit dans vos résistances de terminaison et facilite également l'optimisation du filtrage dans ce domaine.

Vous aurez besoin de plus de bouchons sur la broche VDDIO ou de court-circuiter la perle. Cette broche alimente de nombreuses broches d'E / S et aura beaucoup de courant dessus. S'il est privé de courant à cause du filtre LC (perle + 0,4 uF), vous aurez beaucoup de bruit de commutation simultané sur les broches d'E / S. Cela causera en fait plus de bruit que ce que vous filtrez avec cette perle. Il est même possible que ce bruit atteigne les sorties Ethernet.

Vérifiez que les broches de votre transformateur sont correctes. Bien que peu probable, il est possible d'avoir le robinet central et une autre broche échangés. Cela vaut la peine de passer 5 minutes à vérifier les choses. D'ailleurs, vérifiez également les broches du LAN8700.

Si rien de tout cela n'améliore les choses, procurez-vous un oscillateur en métal de 25 MHz et remplacez votre cristal. J'ai vu des circuits de cristal faire des choses étranges, alors ne serait-ce que pour la tranquillité d'esprit, il vaut la peine de pirater votre carte prototype pour vous assurer que votre clk est stable.

C'est tout ce que je vois en ce moment. J'espère que cela t'aides!

Mes 2 cents: Je suis d'accord avec votre recommandation de choisir le bon oscillateur à cristal pour 25 MHz. J'ai utilisé le DP83865DVH de NSC en mode 1 Gbit et lorsqu'il est arrivé dans un état instable sur un long câble de test (5 cat "spécial" de mauvaise qualité et près de 110 m), le remplacement du XTAL a fait une grande différence. Le circuit est devenu très stable et le prix d'une telle "amélioration" n'est que de 10 cents.