Diagrama de ojo pobre, ¿dónde empezar a buscar?

Estoy tratando de depurar una placa ethernet de 100Mbit y me encuentro con un problema que tengo problemas para resolver.

Este es el diagrama del ojo para el par de transmisión. El par de recepción es muy similar. Es un LAN8700 PHY, y tengo la interfaz MII efectivamente desactivada, por lo que el PHY está transmitiendo secuencias de código IDLE. Es forzado a 100Mbit / FDX según la hoja de datos. 100Mbit / HDX es idéntico.

Corrección: El diseño está utilizando el suministro interno de 1.8V del LAN8700 para alimentar su red VDD_CORE; Debo haber confundido el suministro lógico de 1.8V con el suministro VDD_CORE en mi descripción anterior. Me parece que el ruido de la fuente de alimentación no es una probabilidad tan alta, ya que los niveles alto, cero y bajo son realmente bastante decentes. Es decir, el ojo no está "aplastado". El hecho de que todas las violaciones se vean como muy buenas transiciones, simplemente "sesgadas" a tiempo me hace pensar que el problema radica en el cristal o el suministro del controlador de cristal / PLL en el PHY.

Si dejo que el diagrama del ojo se ejecute (aproximadamente 15 minutos), las infracciones en la máscara se "completan" de tal manera que las infracciones blancas que ve en la imagen se convierten en formas de galón blanco (>) en los lados derechos de las máscaras azules. Esto me diría que los errores de temporización se distribuyen más o menos al azar en lugar de algún tipo de ruido discreto que separa la temporización de una cantidad exacta.

El cristal que utiliza PHY tiene una especificación de 30 ppm que está dentro de la especificación 802.3 de 100 ppm e incluso dentro de la especificación recomendada de 50 ppm que especifica PHY. Estoy usando condensadores de carga que coinciden con lo que el cristal está buscando, y está bastante cerca de lo que LAN8700 especifica como su capacidad nominal.

Antes de deshabilitar la interfaz MII, vería errores de trama (como se informó en mi programa ifconfig de Linux). No hay errores si fuerzo el enlace a 10Mbit.

Una de las cosas más extrañas que he notado es que si configuro el alcance para que se active en la señal RX_ER (error de recepción) del PHY al MAC, nunca señala un error a pesar de que los errores de trama se acumulan en los informes MAC. Ahora, al leer la hoja de datos del PHY, está claro que en realidad hay muy pocas situaciones en las que RX_ER se afirmaría, pero me resulta muy difícil creer que con un diagrama de ojo como el que estoy viendo, los errores están realmente entre el PHY y el MAC

Entiendo los conceptos básicos de los diagramas oculares, pero estoy mirando algunos de los carteles más experimentados, con la esperanza de que puedan compartir algunas de sus experiencias en la traducción de violaciones específicas de las máscaras de patrones oculares a fuentes probables.

(editar: esquema agregado, fuente de suministro VDD_CORE corregida)

Veo muchas cosas que podrían causar los problemas del diagrama del ojo que ves. No hay "pistola humeante", pero hay algunas cosas que podrían estropear las cosas.

Tiene tapas de 0.01 uF (C211, C212, C214 y C217) en los pines no utilizados del RJ-45 y las tomas centrales del transformador. Recomiendo acortar esas tapas. El uso de mayúsculas aquí es inusual y podría causar problemas más adelante, aunque es poco probable que causen los problemas del diagrama ocular que está teniendo. Por lo que puedo decir, la única razón para tener estos límites es como un esquema de bloqueo de CC para cuando alguien está utilizando un esquema de alimentación por Ethernet no estándar. El POE estándar no necesita esta protección, y dado que el estándar POE ahora es "viejo", es poco probable que encuentre equipos estándar que no sean POE.

Retire C19 y C25, tapas de 10 pF en las resistencias de terminación de Ethernet. Estos son demasiado pequeños y están demasiado lejos de cualquier cosa crítica para ser de alguna utilidad.

Cambie las tapas C18 y C24, 0.01 uF en las resistencias de terminación de Ethernet, a al menos 0.1 uF. Incluso podrías probar 4,7 uF. El "riel de potencia" que estas tapas están desacoplando debe ser bastante estable, y podría haber una cantidad sorprendente de corriente que fluye a través de las resistencias de terminación. Si L4 / L5 está restringiendo demasiado el flujo de corriente y las tapas no están tomando el relevo, entonces podría tener errores de datos.

Elimine C16, C17, C22 y C23: los 10 límites de pF en las líneas de datos de Ethernet. La única razón para esto es el filtrado EMI y no son necesarios para la depuración. Quítelos para asegurarse de que no estén causando otros problemas. Siempre puede volver a colocarlos más tarde si es necesario.

Cambie las tapas C20 y C21, 0.022 uF en las tomas centrales del transformador, a al menos 0.1 uF. 1.0 uF podría ser bueno para probar también. Esta línea podría estar cayendo demasiado dada la resistencia de 10 ohmios y L4 / L5. Incluso podría acortar esto a VCC para la depuración. La única razón para la resistencia (y en menor medida la tapa) es para el filtrado EMI. Cuando vuelva a girar la PCB, debe conectar las resistencias de 10 ohmios directamente a VDD33 en lugar de pasar por L4 / L5. La resistencia de 10 ohmios y L4 / L5 son redundantes. Al ir directamente a VDD33, puede evitar la inyección de ruido en sus resistencias de terminación y también facilita la optimización del filtrado en esta área.

Necesitará más tapas en el pin VDDIO, o acortar el cordón. Este pin proporciona energía a muchos pines de E / S y tendrá mucha corriente. Si no tiene corriente debido al filtro LC (cordón + 0.4 uF), entonces tendrá mucho ruido de conmutación simultánea en los pines de E / S. En realidad, eso causará más ruido del que estás filtrando con esa cuenta. Incluso es posible que este ruido llegue a las salidas de Ethernet.

Verifique que tenga las clavijas en su transformador correctas. Si bien es poco probable, es posible tener el toque central y otro perno intercambiado. Vale la pena pasar 5 minutos verificando cosas. Para el caso, verifique también los pines del LAN8700.

Si nada de eso mejora las cosas, obtenga un oscilador de latas de metal de 25 MHz y reemplace su cristal. He visto que los circuitos de cristal hacen cosas raras, así que solo por la tranquilidad de que vale la pena hackear tu prototipo de placa para asegurarte de que tu clk sea estable.

Eso es todo lo que veo en este momento. ¡Espero que esto ayude!

Mis 2 centavos: estoy de acuerdo con su recomendación de elegir el oscilador de cristal adecuado para 25 MHz. Utilicé el DP83865DVH de NSC en modo de 1 Gbit y cuando se puso en un estado no estable en un cable de prueba largo ("especial" de baja calidad 5 cat y cerca de 110 m), reemplazar el XTAL hizo una gran diferencia. El circuito se volvió muy estable y el precio de tal "mejora" es de ~ 10 centavos solamente.