Ethernet MDI trace routing

Several months back I posted this question, the answer to which was very helpful and was incorporated into my schematics. I’m now in the process of routing my custom carrier board, and the implementation of this ethernet interface is causing some issues.

The layout of my board is such that the distance between the MXM3 MDI pads and the MCU to which the ethernet interface connects (there are no magnetics, nor an RJ45 connector in this interface, it is a direct MCU-CoM connection) will be somewhere between 100mm and 150mm (once routing has been implemented). Furthermore, I don’t have the ability to cleanly route directly between the MXM3 pads and the transceiver, so the use of vias (I’m using a 4-layer board) will be necessary. As such, I have the following questions:

  1. The The Layout Design Guide states that trace length between the MXM3 and magnetics should be less than 100mm, while documentation for my ethernet transceiver states the RX+/- and TX+/- differential pairs should be less than 75mm. Am I correct in my understanding that I could route the MDI traces to the transceiver, keeping the routes under ~75mm (per the Layout Design Guide), then route the RX+/- and TX+/- traces to the MCU, keeping them under ~75mm (per the ethernet transceiver datasheet) without issue?
  2. I will be forced to use vias on each of the MDI traces between the MXM3 pads and the transceiver. Table 7 of the Layout Design Guide specifies “2 vias for all MDI traces” as being the maximum number of vias allowed; am I correct in my understanding that this means each MDI trace can use up to 2 vias? I.e. one via to go from layer A to layer B, then a second via to go from layer B back to layer A.
  3. To confirm, when using vias for each of the MDI traces, I will need to use a 10nF stitching capacitor at each via, as I will be swapping from a GND plane reference to a PWR plane reference?
  4. Following on from my earlier post/question linked above, I just want to confirm that for a direct ethernet connection between the MCU and the Apalis, I can use capacitive coupling (i.e. series capacitors on the traces) only, so don’t have to consider magnetics at all? I.e. the connection between the Apalis and the external ethernet transceiver uses only ETH1_MDIO-, ETH1_MDIO+, ETH1_MDI1- and ETH1_MDI1+ (for 10/100 operation)?

Any guidance/clarification would be greatly appreciated as always!

Dear @jars121,

I am glad to hear that your project is proceeding! I would really like to check one more time the schematic, so feel free to send a pdf printing of the ETH interface to my private email:
Regarding your questions:

  1. I would not be worried about the total of 150mm of routing length. After the magnetics, the ETH interface can work with 100 mt cables. And, as far as I understood, you should be also able to be within the limits specified in the HW design guides. so I really think should not be an issue.

  2. Yes, you are correct: each MDI trace can use up to 2 vias, I am sorry, the message is not really clear on the guide. Anyway, also here there is some tolerance: we specified two just to send the message that it is better to avoid a lot of vias in these interfaces.

  3. If you are forced to refer these signals to a power reference plane, stitching caps should be used. Another option would be having a GND island on the power plane and use this as a reference for your signals. This GND island needs to have a good connection to the main GND plane and return current vias placed next to the signal vias are recommended in this case (this concept is explained in figure 39 of the HW design guide).

  4. Yes, we tested this approach on our production tester and so far we never had issues. You probably need only a single cap on the lines even we did the version with two capacitors (described in the quesion mentioned above) as we had also the magnetics assembly option.There are also many documents online about this topic, this is one example:

I hope this helps, please don’t hesitate to get back to me if you need further help.

@diego.tx my apologies for the delay in responding, I’ve been addressing other areas of the design in the meantime. I’ll be revisiting the ethernet interface again shortly, and will most certainly take you up on your offer to send through some schematics to your email address. Thanks!