I have a PCB designed using both 10Mbit and 100Mbit Ethernet, I have produced 100 boards 97% of which work perfectly (both 100Mbit and 10Mbit). On 3% of my boards the 10Mbit operates all the time, but the 100Mbit fails on some interfaces. For example I have two Ethernet ports from my PC, one from the motherboard and a second PCI-X Ethernet card. On the motherboard port all devices operate correctly. On the PCI-X based port 10Mbits works and 100Mbits doesn't. The PCI-X Ethernet device obviously works for the 97% of the devices. If I use a switch between the PCI-X port and my device 100Mbit works all the time.

I'm concerned that I have a problem with my Ethernet interface causing it to be marginal. Has anybody seen this before or could somebody offer some hints of where to look for the problem?


I'm using the Micrel KSZ8041 Ethernet PHY.

When I find a failing PCB it doesn't work with other designs I have which I know are in spec (although thanks this was a good suggestion).

Here are my schematics:

On my failing units I have

  • Removed the ESD protection.
  • Added 1uF on the transformer center tap.
  • Adjusted all the filtering components.
  • Swapped most components between a working unit and a failing unit except the PHY and DSP.

My connector P300 is not an RJ45, instead it is a 2mm through hole header where a custom wire loom connects to an RJ45 on a separate PCB. I have excluded this header and the separate PCB from the equation by wiring directly to P300.

Not sure if it makes a difference but this works with a longer Ethernet cable (5m is okay 0.5m is not).... which points to the matching components/layout. I've reviewed the grounding.

On the inside of the transformer the tx & rx are balanced and on an internal plane between two ground planes (the tx & rx pair are tightly coupled together (9 mils separation) and good spacing between the pairs & other tracks (at least 40 mils). On the outside of the transformer the tx and rx pairs run over a separate chassis gnd plane.

I'm convinced the problem is between the PHY and the outside world (not excluding the PHY). When I probe the rx0 line between the PHY and the DSP a working unit shows only traffic when I ping, but a failing unit has a constant stream of data (presumably idle characters incorrectly received).

I'm currently investigating renting some compliance testing equipment.

  • 4
    \$\begingroup\$ Adding some further detail, schematics, and specific part numbers would help provide more considered, qualified responses. \$\endgroup\$ Mar 12, 2013 at 6:30
  • 1
    \$\begingroup\$ Consider the possibility that your design and/or the port you connect to is be (slightly) out of spec, which might be no problem when the peer side is well within spec. \$\endgroup\$ Mar 12, 2013 at 8:11
  • \$\begingroup\$ I am controlling the PHY Linking speed, I have excluded everything but 100 Full duplex from the auto negotiate table. We acheive a link, but data (presumabbly incorrectly received idle characters) is constantly send out of the PHY to the DSP. Could this be a synchronisation failure? \$\endgroup\$
    – user20123
    Mar 13, 2013 at 5:16
  • \$\begingroup\$ You should have enough reputation to post the schematic now, and you can always consider the built-in design tool (CircuitLab) \$\endgroup\$
    – clabacchio
    Mar 13, 2013 at 7:51
  • 2
    \$\begingroup\$ You are starting to get into territory where layout matters as much as schematic. But also consider mislabeled/misinstalled passives or marginal magnetics. Can you "move" the problem by trading parts between boards? You might also see if there is $$$ ethernet test gear you could rent to get compliance metrics more detailed than works/doesn't. \$\endgroup\$ Mar 13, 2013 at 13:46

3 Answers 3


This is not a complete answer, but it's a good first step.

I recommend checking the PHY's mode switches. It's probably set to auto-negotiate, meaning the PHY will fall back on a slower data rate if the faster one proves marginal. If you can force the faster data rate, it'll be much easier to debug the problem.


We can only guess from the information you have given. The fact that it works at low frequency but not at high frequency is a clue that somewhere some high frequency issues have not been properly addressed. This may be a systemic problem so that high frequency opreation is marginal and happens to fail 3% of the time. Or, the non-working units could each have a failure that hurts high frequency operation a lot more than low frequency operation.

Given the above, I'd look closely at the terminating resistors, filters on the center taps, decoupling of all the chips envolved, and the general layout including the ground plane and ground currents. Perhaps it is as simple as the terminating resistors didn't get properly soldered on the failed units. Worst case you have something like badly designed ground or even left off a bypass cap or series inductor or filter cap for the center tap of the transmit primary.


Since no one mentioned it, I'll chip in.

This sounds like a signal integrity problem, where reflections due to impedance mismatching distort the signal. Care should be taken that the impedance of the transmission line (PCB traces and twisted pairs) doesn't change along the way. For Ethernet it's 50 ohms single ended (traces) or 100 ohms differential (cable). Ideally, you would make an eye diagram with an oscilloscope to check if there's good separation between the symbols.

Those resistors to the right of the connector in the schematic seem out of place since they change the impedance the signal sees and cause reflections, and the low incidence of the problem hints at component tolerances. Series terminations like this are done very close to the driver and in the absence of shunt terminations (which you are using and are the norm for Ethernet). Non-Ethernet connector and cable in between also looks like a source for reflections. The fact that it works with a longer cable may be because the reflections get attenuated more. Altium has a nice article on terminations.

About the traces, it is a common misconception that differential traces must be tightly coupled. They mustn't, coupling them together only changes the relation between common-mode and differential-mode impedances. If they are far apart, then Zdm = 2*Zcm, which is what many standards assume (for Ethernet we use two 50 ohms single-ended terminations for a 100 ohms differential pair). We route them together for convenience, but one should always use a line calculator to get the right impedances with the stack-up in question. Xilinx had a cool article about it that I can't find, but this one will do for now.

  • \$\begingroup\$ On component variations, the other obvious/trivial check that hopefully has been completed is to confirm batch numbers/date stamps plus a complete visual inspection of components looking for any variations, etc. Have any boards been reworked with components being replaced or cut tracks repaired during production process? \$\endgroup\$
    – PDP11
    Oct 5, 2023 at 3:20

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.