I'm trying to debug a 100Mbit ethernet board and I'm running up against a problem I'm having trouble trying to resolve.

tx pair eye diagram schematic

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.

(edit: added schematic, corrected VDD_CORE supply source)

  • \$\begingroup\$ What are you triggering on? How do you know the trigger doesn't have the jitter or occasional miss, not the signal? \$\endgroup\$ Commented Jan 4, 2012 at 0:07
  • \$\begingroup\$ 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. \$\endgroup\$
    – akohlsmith
    Commented Jan 4, 2012 at 0:30
  • \$\begingroup\$ 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. \$\endgroup\$
    – user3624
    Commented Jan 4, 2012 at 1:04
  • \$\begingroup\$ Updated question to include schematic \$\endgroup\$
    – akohlsmith
    Commented Jan 4, 2012 at 5:28
  • \$\begingroup\$ 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. \$\endgroup\$
    – The Photon
    Commented Jan 4, 2012 at 6:13

2 Answers 2


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-POE standard equipment.

Remove C19 and C25, 10 pF caps on the Ethernet termination resistors. These are way too small, and too far away from anything critical to be of any use.

Change C18 and C24, 0.01 uF caps on the Ethernet termination resistors, to at least 0.1 uF. You could even try 4.7 uF. The "power rail" that these caps are decoupling needs to be fairly stable, and there could be a surprising amount of current flowing through the termination resistors. If L4/L5 is restricting current flow too much, and the caps aren't taking up the slack, then you could have data errors.

Remove C16, C17, C22, and C23-- all 10 pF caps on the Ethernet data lines. The only reason for these is EMI filtering and are not needed for debugging. Remove them to make sure they are not causing other issues. You can always put them back later if you need to.

Change C20 and C21, 0.022 uF caps on the transformer center taps, to at least 0.1 uF. 1.0 uF might be good to try as well. This line might be drooping too much given the 10 ohm resistor and L4/L5. You could even short this to VCC for debugging. The only reason for the resistor (and to a lesser extent the cap) is for EMI filtering. When you re-spin the PCB, you should connect the 10 ohm resistors directly to VDD33 instead of going through L4/L5. The 10 ohm resistor and L4/L5 are redundant. By going direct to VDD33 you can prevent injecting noise into your termination resistors and also makes optimizing the filtering in this area easier.

You'll need more caps on the VDDIO pin, or short out the bead. This pin is providing power to lots of I/O pins and will have a lot of current on it. If it is current starved because of the LC filter (bead + 0.4 uF) then you'll have lots of simultaneous switching noise on the I/O pins. That'll actually cause more noise than what you're filtering out with that bead. It's even possible for this noise to make it to the Ethernet outputs.

Verify that you have the pin-outs on your transformer correct. While unlikely, it's possible to have the center tap and another pin swapped. It's worth spending 5 minutes verifying things. For that matter, verify the pin-outs of the LAN8700 as well.

If none of that improves things, then get a 25 MHz metal can oscillator and replace your crystal. I've seen crystal circuits do weird things, so if only for the peace of mind it's worth hacking up your prototype board to make sure your clk is stable.

That's all I see at the moment. Hope this helps!

  • 2
    \$\begingroup\$ Thank you VERY much for your answer! It was indeed a weak supply for the magnetic center taps. I added a 2.2uF X5R right at the center tap and (after I used a DC ground and not a nearby AC one) it cleaned right up! -- I will take a closer look at the inductors but out of curiosity, did you think of the CT supply due to the eye or just from experience working with ethernet? \$\endgroup\$
    – akohlsmith
    Commented Jan 4, 2012 at 19:01
  • \$\begingroup\$ @AndrewKohlsmith I figured it out mostly from experience. I've lost count of the PCB's I've designed with Ethernet. Somewhere in the 20-30 range. It's fairly hard to mess up an Ethernet design, but it seems like most of the time it gets messed up with the center taps of the transformers. \$\endgroup\$
    – user3624
    Commented Jan 4, 2012 at 19:47
  • \$\begingroup\$ Frankly I'm still surprised that it shows up on the eye as a horizontal (time) deviation and not a vertical (amplitude) violation. This is why I love this site... learn all the time. \$\endgroup\$
    – akohlsmith
    Commented Jan 6, 2012 at 2:30
  • \$\begingroup\$ @AndrewKohlsmith Yea, it's not that intuitive that voltage error = time error. But think of it this way: If you have a signal with a slow edge rate on your o-scope, then small changes to the scopes trigger level will move the waveform left or right. This is especially true if you are zoomed in on the waveform several clocks after the edge you're triggering on. If the signal edges are usually fast but sometimes slow or distorted then you'll see eye diagrams exactly like what you found. \$\endgroup\$
    – user3624
    Commented Jan 6, 2012 at 3:14

My 2 cents: I agree with your recommendation to choose the right crystal oscillator for 25 MHz. I used NSC's DP83865DVH in 1 Gbit mode and when it got in a nonstable state on long test cable ("special" poor quality 5 cat and near 110 m), replacing the XTAL made a big difference. Circuit became very stable and the price of such an "improvement" is ~10 cents only.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.