ethernet Poor eye diagram where to start looking

This is the eye diagram for the transmit pair. The receive pair is very similar. It is a LAN8700 PHY, and the MII interface has been effectively disabled, resulting in the PHY transmitting IDLE code sequences. It is forced into 100Mbit/FDX as specified in the datasheet. The configuration for 100Mbit/HDX is identical. The design utilizes the LAN8700's internal 1.8V supply to power its VDD_CORE net; there was confusion regarding the 1.8V logic supply and the VDD_CORE supply in the previous description. Power supply noise is considered unlikely, as the high, zero, and low levels appear satisfactory, indicating that the eye is not "squished." The observed violations show good transitions that appear "skewed" in time, suggesting that the issue may lie with the crystal or the supply for the crystal driver/PLL in the PHY. Allowing the eye diagram to run for about 15 minutes causes the violations in the mask to fill in, transforming the white violations in the image into white chevron shapes on the right-hand side of the blue masks. This indicates that the timing errors are more or less randomly distributed rather than caused by discrete noise affecting the timing by a specific amount. The crystal used by the PHY has a 30ppm specification, well within the 100ppm 802.3 specification and the 50ppm recommended specification outlined by the PHY. Loading capacitors are used that match the crystal's requirements and are close to the nominal capacitance specified by the LAN8700. Prior to disabling the MII interface, framing errors were observed as reported by Linux's ifconfig program. No errors occur when the link is forced to 10Mbit. An unusual observation was made regarding the RX_ER (receive error) signal from the PHY to the MAC, which never signals an error despite the accumulation of frame errors reported by the MAC. The PHY datasheet indicates that RX_ER asserts in very few situations, leading to skepticism about whether the errors are occurring between the PHY and the MAC. Basic understanding of eye diagrams is present, but insights from more experienced individuals regarding the translation of specific eye pattern mask violations to potential sources are sought. The Ethernet conformance test application software on the scope was tested against a development board, which passed successfully. Additional schematics are needed for more definitive conclusions. Current suspects include PLL power supplies, crystal issues, termination, and incorrect handling of transformer center taps, in that order. The center tap of one transformer is tied to the same inductor-isolated supply that terminates the signal lines from the other transformer, raising concerns about the design. The presence of 0.01 µF capacitors (C211, C212, C214, & C217) on the unused pins of the RJ-45 and the center taps of the transformer is noted, with a recommendation to short these capacitors. Their use is considered unusual and could potentially lead to issues, although they are unlikely to be the cause of the eye diagram problems.

The LAN8700 PHY is a critical component in Ethernet communication, responsible for converting digital signals into analog signals and vice versa for transmission over twisted-pair cables. The eye diagram is a crucial diagnostic tool that provides insights into signal integrity by visualizing the timing and voltage levels of the transmitted signal. In this scenario, the PHY has been configured for 100Mbit full-duplex operation, which allows simultaneous transmission and reception of data, enhancing network performance.

The internal 1.8V supply powering the VDD_CORE net is essential for the PHY's operation, ensuring that the internal circuits receive stable voltage levels. The eye diagram's integrity is influenced by various factors, including the quality of the crystal oscillator, the PLL's stability, and the termination of the signal lines. The observed "skewed" transitions in the eye diagram suggest potential timing issues, possibly stemming from the PLL or crystal driver. The PLL's power supply must be stable to ensure accurate frequency generation, while the crystal's specifications must align with the PHY's operational requirements.

The recommendation to remove the 0.01 µF capacitors is based on their potential to introduce unintended impedance or filtering effects that could distort the signal. These capacitors are typically used in non-standard Power over Ethernet (PoE) applications, but standard PoE configurations do not necessitate such components. The design's adherence to standard practices regarding termination and center tap handling is crucial for maintaining signal integrity and minimizing reflections that can lead to eye diagram distortions.

In conclusion, careful analysis of the PHY's configuration, power supply stability, and signal integrity components is essential for troubleshooting the eye diagram issues. Further investigation, including the provision of schematics, will facilitate a more comprehensive understanding of the problem and lead to effective solutions.This is the eye diagram for the transmit pair. The receive pair is very similar. It`s a LAN8700 PHY, and I`ve got the MII interface effectively disabled, so the PHY is transmitting IDLE code sequences. It`s forced into 100Mbit/FDX as per the datasheet. 100Mbit/HDX is identical. Correction: The design is using the LAN8700`s internal 1. 8V supply to power its VDD_CORE net; I must have been confusing the 1. 8V logic supply with the VDD_CORE supply in my earlier description. It seems to me that power supply noise is not such a high likelihood, since the high, zero and low levels are actually pretty decent. That is, the eye isn`t "squished. " The fact that the violations all look like very good transitions, just "skewed" in time makes me think the problem lies in the crystal or supply for the crystal driver/PLL in the PHY.

If I let the eye diagram run (about 15min) the violations in the mask "fill in" such that the white violations you see in the picture become white chevron (>) shapes in the right-hand sides of the blue masks. This would tell me that the timing errors are more or less randomly distributed rather than some kind of discrete noise yanking the timing off an exact amount.

The crystal that the PHY is using has a 30ppm spec which is well within the 100ppm 802. 3 spec, and even within the 50ppm recommended spec that the PHY specifies. I`m using loading capacitors which match what the crystal is looking for, and is pretty close to what the LAN8700 specifies as its nominal capacitance. Before I disabled the MII interface I would see framing errors (as reported my Linux`s ifconfig program).

There are no errors if I force the link to 10Mbit. One of the very odd things I have noticed is that if I set the scope up to trigger on the RX_ER (receive error) signal from the PHY to the MAC, it never signals an error even though the frame errors accumulate in the MAC reports. Now from reading the datasheet for the PHY, it is clear that there are actually very few situations where RX_ER would assert, but I find it very difficult to believe that with an eye diagram like what I am seeing the errors are actually between the PHY and the MAC.

I do understand the basics of eye diagrams, but I`m looking to some of the more experienced posters, hoping that they would be able to share some of their experiences in translating specific eye pattern mask violations to likely sources. I`m using the ethernet conformance test application software on the scope. I tested the conformance test app against a dev board which passes with flying colours. akohlsmith Jan 4 `12 at 0:30 I`d need schematics to say anything for certain. My suspects, at the moment, are: PLL power supplies, XTAL issues, termination, and not handling the transformer center taps correctly.

In that order. With schematics I could narrow some of that down. user3624 Jan 4 `12 at 1:04 It "smells funny" to me that the center tap of one transformer is tied to the same inductor-isolated supply that terminates the signal lines from the other transformer. And vice versa. But I haven`t done any ethernet work like this before, so I don`t know that`s not exactly what you`re supposed to do.

The Photon Jan 4 `12 at 6:13 I see many things that could potentially cause the eye diagram issues that you see. No "smoking gun", but some things that could potentially mess things up. You have 0. 01 uF caps (C211, C212, C214, & C217) on the unused pins of the RJ-45 and the center taps of the transformer.

I recommend shorting out those caps. Your use of caps here is unusual and could cause issues later on, although they are unlikely to be causing the eye-diagram issues you`re having. Near as I can tell, the only reason to have these caps is as a DC-Blocking scheme for when someone is using a non-standard power over Ethernet scheme.

Standard POE doesn`t need this protection, and since the POE standard is now "old" you are unlikely to encounter non-PO 🔗 External reference