Diagramma degli occhi poveri, da dove iniziare a cercare?


10

Sto cercando di eseguire il debug di una scheda Ethernet da 100 Mbit e sto incontrando un problema che sto riscontrando problemi nel tentativo di risolvere.

diagramma occhio coppia tx schematico

Questo è il diagramma a occhio per la coppia di trasmissione. La coppia di ricezione è molto simile. È un PHY LAN8700 e l'interfaccia MII è effettivamente disabilitata, quindi il PHY sta trasmettendo sequenze di codici IDLE. È forzato in 100Mbit / FDX come da scheda tecnica. 100Mbit / HDX è identico.

Correzione: il design utilizza l'alimentazione interna da 1,8 V della LAN8700 per alimentare la sua rete VDD_CORE; Devo aver confuso l'alimentazione logica a 1,8 V con l'alimentazione VDD_CORE nella mia descrizione precedente. Mi sembra che il rumore dell'alimentazione non sia così elevato, dal momento che i livelli alto, zero e basso sono in realtà abbastanza decenti. Cioè, l'occhio non è "schiacciato". Il fatto che tutte le violazioni appaiano come transizioni molto buone, solo "distorte" nel tempo, mi fa pensare che il problema risieda nel cristallo o nella fornitura del driver cristallo / PLL nel PHY.

Se lascio scorrere il diagramma oculare (circa 15 minuti), le violazioni nella maschera "si riempiono" in modo tale che le violazioni bianche che vedi nella foto diventino bianche chevron (>) forme nei lati di destra delle maschere blu. Questo mi direbbe che gli errori di temporizzazione sono distribuiti più o meno casualmente piuttosto che una sorta di rumore discreto che strappa i tempi di una quantità esatta.

Il cristallo che il PHY sta usando ha una specifica di 30 ppm che rientra nelle specifiche 802.3 di 100 ppm e anche nelle specifiche consigliate di 50 ppm specificate dal PHY. Sto usando condensatori di carico che corrispondono a ciò che il cristallo sta cercando ed è abbastanza vicino a ciò che la LAN8700 specifica come capacità nominale.

Prima di disabilitare l'interfaccia MII vedevo errori di inquadratura (come riportato dal mio programma ifconfig di Linux). Non ci sono errori se forzo il link a 10Mbit.

Una delle cose molto strane che ho notato è che se ho impostato l'ambito per attivarsi sul segnale RX_ER (errore di ricezione) dal PHY al MAC, non segnala mai un errore anche se gli errori del frame si accumulano nei report MAC. Ora dalla lettura del foglio dati per il PHY, è chiaro che in realtà ci sono pochissime situazioni in cui RX_ER affermerebbe, ma trovo molto difficile credere che con un diagramma a occhio come quello che vedo gli errori siano effettivamente tra il PHY e il MAC.

Comprendo le basi dei diagrammi oculari, ma sto guardando alcuni dei poster più esperti, sperando che possano condividere alcune delle loro esperienze nella traduzione di specifiche violazioni delle maschere oculari a probabili fonti.

(modifica: aggiunta schematica, fonte di approvvigionamento VDD_CORE corretta)


Cosa stai attivando? Come fai a sapere che il trigger non ha jitter o miss occasionali, non il segnale?
Olin Lathrop il

Sto utilizzando l'ambito del software applicativo di test di conformità Ethernet. Ho testato l'app di test di conformità su una scheda di sviluppo che passa a pieni voti.
akohlsmith il

Avrei bisogno di schemi per dire qualcosa di sicuro. I miei sospetti, al momento, sono: alimentatori PLL, problemi XTAL, terminazione e non gestione corretta delle prese del centro del trasformatore. In questo ordine. Con gli schemi potrei restringere un po 'questo.

Domanda aggiornata per includere lo schema
akohlsmith il

"Mi sembra strano" che il rubinetto centrale di un trasformatore sia legato alla stessa alimentazione isolata dall'induttore che termina le linee del segnale dall'altro trasformatore. E viceversa. Ma non ho mai fatto nessun lavoro Ethernet come questo prima, quindi non so che non è esattamente quello che dovresti fare.
Il fotone

Risposte:


8

Vedo molte cose che potrebbero potenzialmente causare i problemi del diagramma a occhio che vedi. Nessuna "pistola fumante", ma alcune cose che potrebbero potenzialmente rovinare le cose.

Sono presenti cappucci da 0,01 uF (C211, C212, C214 e C217) sui pin non utilizzati di RJ-45 e sulle prese centrali del trasformatore. Consiglio di mettere in cortocircuito quei tappi. L'uso dei tappi qui è insolito e potrebbe causare problemi in seguito, anche se è improbabile che causino i problemi del diagramma degli occhi che stai riscontrando. Per quanto ne so, l'unica ragione per avere questi limiti è come uno schema DC-Blocking per quando qualcuno sta usando uno schema power over Ethernet non standard. Il POE standard non necessita di questa protezione e poiché lo standard POE è ora "vecchio", è improbabile che si verifichino apparecchiature non POE standard.

Rimuovere i cappucci C19 e C25, 10 pF sulle resistenze di terminazione Ethernet. Sono troppo piccoli e troppo lontani da qualsiasi cosa critica per essere di qualche utilità.

Modificare i cappucci C18 e C24, 0,01 uF sulle resistenze di terminazione Ethernet, ad almeno 0,1 uF. Potresti anche provare 4.7 uF. La "power rail" che questi tappi stanno disaccoppiando deve essere abbastanza stabile e potrebbe esserci una quantità sorprendente di corrente che fluisce attraverso i resistori di terminazione. Se L4 / L5 sta restringendo troppo il flusso di corrente e i limiti non colmano il rallentamento, è possibile che si verifichino errori di dati.

Rimuovere C16, C17, C22 e C23, tutti i 10 tappi pF sulle linee dati Ethernet. L'unico motivo è il filtro EMI e non sono necessari per il debug. Rimuoverli per assicurarsi che non causino altri problemi. Puoi sempre rimetterli più tardi, se necessario.

Modificare i cappucci C20 e C21, 0,022 uF sulle prese centrali del trasformatore, ad almeno 0,1 uF. 1.0 uF potrebbe anche essere buono da provare. Questa linea potrebbe cadere troppo a causa del resistore da 10 ohm e L4 / L5. Potresti anche metterlo in cortocircuito con VCC per il debug. L'unico motivo del resistore (e in misura minore del cappuccio) è il filtro EMI. Quando si riavvia il PCB, è necessario collegare i resistori da 10 ohm direttamente a VDD33 invece di passare attraverso L4 / L5. Il resistore da 10 ohm e L4 / L5 sono ridondanti. Passando direttamente a VDD33 è possibile impedire l'iniezione di rumore nei resistori di terminazione e anche semplificare l'ottimizzazione del filtro in quest'area.

Avrai bisogno di più tappi sul pin VDDIO o cortocircuito sul tallone. Questo pin fornisce alimentazione a molti pin I / O e avrà molta corrente. Se è affamato di corrente a causa del filtro LC (tallone + 0,4 uF), avrai un sacco di rumore di commutazione simultanea sui pin I / O. Questo effettivamente causerà più rumore di quello che stai filtrando con quel tallone. È anche possibile che questo rumore arrivi alle uscite Ethernet.

Verifica che i pin-out sul tuo trasformatore siano corretti. Sebbene improbabile, è possibile avere il rubinetto centrale e un altro perno scambiati. Vale la pena spendere 5 minuti per verificare le cose. Per questo motivo, verifica anche i pin-out di LAN8700.

Se nulla di tutto ciò migliora, procurati un oscillatore in metallo a 25 MHz e sostituisci il tuo cristallo. Ho visto circuiti di cristallo fare cose strane, quindi se solo per la tranquillità vale la pena hackerare la scheda prototipo per assicurarsi che il tuo clk sia stabile.

Questo è tutto ciò che vedo al momento. Spero che sia di aiuto!


2
Grazie mille per la tua risposta! Era davvero un rifornimento debole per i rubinetti del centro magnetico. Ho aggiunto un X5R 2.2uF proprio al rubinetto centrale e (dopo aver usato una messa a terra CC e non una CA vicina) è stato pulito! - Guarderò più da vicino gli induttori ma per curiosità, hai pensato alla fornitura di CT a causa dell'occhio o semplicemente per esperienza di lavoro con Ethernet?
akohlsmith il

@AndrewKohlsmith L'ho capito principalmente per esperienza. Ho perso il conto dei PCB che ho progettato con Ethernet. Da qualche parte nella gamma 20-30. È abbastanza difficile confondere un design Ethernet, ma sembra che la maggior parte delle volte venga incasinato con i tocchi centrali dei trasformatori.

Francamente sono ancora sorpreso che si presenti sull'occhio come una deviazione orizzontale (tempo) e non una violazione verticale (ampiezza). Ecco perché adoro questo sito ... impara tutto il tempo.
akohlsmith il

@AndrewKohlsmith Sì, non è così intuitivo quell'errore di tensione = errore temporale. Ma pensala in questo modo: se hai un segnale con una frequenza di bordo lenta sul tuo o-scope, allora piccole modifiche al livello di trigger degli ambiti sposteranno la forma d'onda a sinistra oa destra. Ciò è particolarmente vero se si esegue lo zoom sulla forma d'onda di diversi orologi dopo il bordo su cui si sta eseguendo il trigger. Se i bordi del segnale sono generalmente veloci ma a volte lenti o distorti, vedrai i diagrammi oculari esattamente come quelli che hai trovato.

1

I miei 2 centesimi: sono d'accordo con la tua raccomandazione di scegliere il giusto oscillatore a cristallo per 25 MHz. Ho usato il DP83865DVH di NSC in modalità 1 Gbit e quando è arrivato in uno stato instabile su un cavo di prova lungo ("speciale" di scarsa qualità 5 cat e vicino a 110 m), la sostituzione dell'XTAL ha fatto una grande differenza. Il circuito è diventato molto stabile e il prezzo di tale "miglioramento" è di soli ~ 10 centesimi.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.