Diagrama do olho pobre, por onde começar a procurar?

Estou tentando depurar uma placa Ethernet de 100Mbit e estou enfrentando um problema que estou tendo problemas para tentar resolver.

Este é o diagrama do olho para o par de transmissão. O par de recebimento é muito semelhante. É um LAN8700 PHY, e eu tenho a interface MII efetivamente desativada, então o PHY está transmitindo seqüências de código IDLE. É forçado a 100Mbit / FDX conforme a folha de dados. 100Mbit / HDX é idêntico.

Correção: O projeto está usando a fonte interna de 1,8V do LAN8700 para alimentar sua rede VDD_CORE; Eu devo ter confundido a fonte lógica de 1,8V com a fonte VDD_CORE na minha descrição anterior. Parece-me que o ruído da fonte de alimentação não é uma probabilidade tão alta, pois os níveis alto, zero e baixo são realmente bastante decentes. Ou seja, o olho não é "esmagado". O fato de todas as violações parecerem muito boas transições, apenas "distorcidas" a tempo, me faz pensar que o problema está no cristal ou no suprimento para o cristal driver / PLL no PHY.

Se eu permitir que o diagrama ocular corra (cerca de 15 minutos), as violações da máscara "preenchem", de modo que as violações brancas que você vê na figura se tornem formas brancas de chevron (>) no lado direito das máscaras azuis. Isso me diria que os erros de temporização são distribuídos mais ou menos aleatoriamente, em vez de algum tipo de ruído discreto, arrancando a temporização de uma quantidade exata.

O cristal que o PHY está usando possui uma especificação de 30ppm, que está dentro da especificação 802.300 de 100ppm e mesmo dentro da especificação recomendada de 50ppm especificada pela PHY. Estou usando capacitores de carregamento que correspondem ao que o cristal está procurando e está bem próximo do que o LAN8700 especifica como sua capacitância nominal.

Antes de desativar a interface MII, eu via erros de enquadramento (conforme relatado no programa ifconfig do meu Linux). Não há erros se eu forçar o link para 10Mbit.

Uma das coisas muito estranhas que notei é que, se eu configurar o escopo para disparar no sinal RX_ER (receber erro) do PHY para o MAC, ele nunca sinaliza um erro, mesmo que os erros de quadro se acumulem nos relatórios do MAC. Agora, ao ler a folha de dados do PHY, fica claro que existem realmente muito poucas situações em que o RX_ER afirmaria, mas acho muito difícil acreditar que, com um diagrama ocular como o que estou vendo, os erros estão realmente entre o PHY e o MAC.

Entendo o básico dos diagramas oculares, mas estou olhando para alguns dos pôsteres mais experientes, esperando que eles possam compartilhar algumas de suas experiências na tradução de violações específicas da máscara de padrão ocular a fontes prováveis.

(editar: adicionada fonte de fornecimento esquemática e corrigida do VDD_CORE)

Vejo muitas coisas que potencialmente poderiam causar problemas no diagrama ocular que você vê. Não há "arma de fumar", mas algumas coisas que podem potencialmente atrapalhar as coisas.

Você possui tampas de 0,01 uF (C211, C212, C214 e C217) nos pinos não utilizados do RJ-45 e nas derivações centrais do transformador. Eu recomendo colocar em curto esses limites. O uso de tampas aqui é incomum e pode causar problemas mais tarde, embora seja improvável que eles estejam causando os problemas do diagrama de olho que você está tendo. Quase como eu posso dizer, a única razão para ter esses limites é como um esquema de bloqueio de DC para quando alguém estiver usando um esquema não padrão de energia sobre Ethernet. O POE padrão não precisa dessa proteção e, como o padrão do POE agora é "antigo", é improvável que você encontre equipamento padrão que não seja do POE.

Remova as tampas C19 e C25, 10 pF dos resistores de terminação Ethernet. Eles são muito pequenos e muito distantes de qualquer coisa crítica para serem úteis.

Altere os limites C18 e C24, 0,01 uF nos resistores de terminação Ethernet, para pelo menos 0,1 uF. Você pode até tentar 4.7 uF. O "trilho de força" que essas tampas estão desacoplando precisa ser razoavelmente estável e pode haver uma quantidade surpreendente de corrente fluindo através dos resistores de terminação. Se L4 / L5 estiver restringindo muito o fluxo de corrente e as tampas não estiverem dando folga, você poderá ter erros de dados.

Remova C16, C17, C22 e C23 - todos os 10 pF caps nas linhas de dados Ethernet. A única razão para isso é a filtragem EMI e não é necessária para depuração. Remova-os para garantir que não estejam causando outros problemas. Você sempre pode devolvê-los mais tarde, se precisar.

Altere as tampas C20 e C21, 0,022 uF nas derivações centrais do transformador, para pelo menos 0,1 uF. 1.0 uF também pode ser bom para tentar. Essa linha pode estar caindo demais, considerando o resistor de 10 ohm e o L4 / L5. Você pode até fazer um curto-circuito no VCC para depuração. A única razão para o resistor (e em menor grau a tampa) é a filtragem EMI. Ao girar novamente a PCB, você deve conectar os resistores de 10 ohms diretamente ao VDD33 em vez de passar por L4 / L5. O resistor de 10 ohm e L4 / L5 são redundantes. Ao ir direto para o VDD33, você pode impedir a injeção de ruído nos resistores de terminação e também facilita a otimização da filtragem nessa área.

Você precisará de mais tampas no pino do VDDIO, ou diminuirá o comprimento do cordão. Esse pino está fornecendo energia para muitos pinos de E / S e terá muita corrente nele. Se houver falta de corrente por causa do filtro LC (cordão + 0,4 uF), haverá muito ruído de comutação simultâneo nos pinos de E / S. Isso realmente causará mais ruído do que o que você está filtrando com essa conta. É até possível que esse ruído chegue às saídas Ethernet.

Verifique se as pinagens do seu transformador estão corretas. Embora improvável, é possível trocar a torneira central e outro pino. Vale a pena gastar 5 minutos verificando as coisas. Para esse assunto, verifique também as pinagens do LAN8700.

Se nada disso melhorar, obtenha um oscilador de metal de 25 MHz e substitua seu cristal. Eu já vi circuitos de cristal fazendo coisas estranhas, então, se for para ficar tranquilo, vale a pena invadir sua placa protótipo para garantir que seu clk esteja estável.

É tudo o que vejo no momento. Espero que isto ajude!

Meus 2 centavos: concordo com sua recomendação de escolher o oscilador de cristal certo para 25 MHz. Usei o DP83865DVH da NSC no modo de 1 Gbit e, quando ficou em um estado instável em um cabo de teste longo (qualidade "especial" de baixa qualidade, 5 gatos e perto de 110 m), a substituição do XTAL fez uma grande diferença. O circuito se tornou muito estável e o preço dessa "melhoria" é de apenas 10 centavos.