I'm interested in putting together both a fixed rack, and a modular rack system using gigabit ethernet for the backplane.

I was thinking of this where the fixed backplane would use something like a 14-port switch chip to allow for 12 in rack modules, plus a possible 'upstream' and 'downstream' connection to extend the rack. For the modular rack, where the rack is built by clipping additional modules in, it would use something like a 3-port switch in each module. With 'upstream', 'downstream' and 'module' connections.

It appears that 803.2ap or 1000basekx are the 'standards' for backplane ethernet, however I've been unable to find any switch ICs that would match what I would expect for this. Does anyone know of vendors / chips which support this?

I've seen some chips from Microchip VSC7511 (4-port switch with SimpliPHY), although the pin count for these chips seems a lot higher than I would have expected. e.g. the VS7511 (4 port) has a pin count of 172 (QFN) vs something like the KSZ9896 (6 port) with a pin count of 128 (QFP).

I really would like to avoid having to use magnetics twice on every link however.

I'm open to any other ideas for a nice (modern) multi-master backplane bus system also.

  • \$\begingroup\$ What does your backplane bus system need to achieve, by the way? \$\endgroup\$ Commented Jan 30, 2021 at 13:25
  • \$\begingroup\$ @MarcusMüller you mean in terms of data rate? as fast as economically possible. \$\endgroup\$
    – BevanWeiss
    Commented Jan 31, 2021 at 0:23
  • \$\begingroup\$ well, that's not a spec. give us numbers. \$\endgroup\$ Commented Jan 31, 2021 at 11:12
  • 1
    \$\begingroup\$ @MarcusMüller I assume you're asking me for 'numbers' to propose alternative bus systems. Although I did clearly mention 1000basekx, which provides numbers. I'm looking for that kind of magnitude (~gigabit). Higher is obviously 'nicer', but I feel that cost jumps up significantly. Latency would need to be low milliseconds. \$\endgroup\$
    – BevanWeiss
    Commented Jan 31, 2021 at 19:26
  • 1
    \$\begingroup\$ I'd likely have a lower speed CAN bus also, as a secondary bus to offload some overhead comms (like device enumeration, etc). I've looked at a few other bus options, like PCI, PCIe and RapidIO. PCI requires too many signals. PCIe switches seem more tailored towards wider lane configurations and use lots of power. RapidIO seemed like an ideal technical fit, but it doesn't seem to have much support amongst microcontrollers (especially lower end microcontrollers). Ethernet would allow a high speed backplane, whilst still allowing for lower cost 100Mbps micros to be used in each 'slot'. \$\endgroup\$
    – BevanWeiss
    Commented Jan 31, 2021 at 20:02

1 Answer 1


Perhaps someone will come along with a better 'answer' later. But the conclusion here is pretty much just "it'll be fine".

In the Ethernet PHY world, there are two different methods of driving the differential pairs, current-mode and voltage-mode.

If using current-mode, then coupling transformers will always be required. If using voltage-mode, then for the shorter distances expected in intra-board routing the magnetics can be left aside, and just capacitors used to separate the Tx / Rx bias voltages.

So if going for an ethernet driven backplane, voltage-mode PHYs should be selected, with switch architecture then 'as desired' for the application (i.e. either a star network with a large port count central switch, or a linear network with numerous low port count distributed switches). Latency of the switching elements would need to be factored in, along with overall power usage.

Trace impedance should be matched to the 100ohms, with Tx/Rx termination resistors as required (if not internally terminated already) and coupling capacitors of ~0.47uF are a good enough start. The coupling capacitor value may require some tweaking due to transceiver characteristics (different vendor / series).

http://ww1.microchip.com/downloads/jp/AppNotes/jp578072.pdf http://ww1.microchip.com/downloads/cn/AppNotes/cn586761.pdf


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.