Effect of Ethernet PHY interface on the speed of Ethernet

Question

I have been working on this new project where I need to include Ethernet.

But the microcontroller of my project doesn't have any Ethernet PHY included (no MII, RMII, GMII, etc.)

So, I am instead using SPI to interface my Ethernet controller with my microcontroller, thus effectively making SPI as my Ethernet PHY.

Now, my question is,

SPI is one of the low speed interfaces in the arena which may be used up to 100  Mbit/s at the most (stretching it too far).

Ethernet, on the other hand, is one of the high-speed interfaces starting from 1 Gbit/s, 10 Gbit/s, 100 Gbit/s, etc.

Won't the speed of Ethernet be limited in such a case? (I think it should.)

But the datasheet claims otherwise. In spite of the SPI interface, it claims  Gbit/s and  Gbit/s speeds.

Answer 1

The chip can connect at 10 Mbps and 100 Mbps Ethernet link speeds, and it has a maximum SPI bus speed of 40 MHz.

So yes, even if it can communicate with 100 Mbps link speed, it won't achieve 100 Mbps throughput as it it is limited by the SPI bit rate, and so even slow microcontrollers with slow SPI bit rates can still work with this chip, as there are packet buffers and FIFOs inside the chip.

Answer 2

The Ethernet controller datasheet you link claims 10/100 Mbit/s speeds, not Gbit/s speeds.

The controller is capable of negotiating with other 10BASE-T or 100BASE-TX interfaces on the network, and of transferring frames of data at that rate.

The average throughput of the controller will be limited by the speed of your SPI connection with the MCU. Data is moved between the MCU and data frame buffers in the controller at whatever speed the SPI and MCU can support. The controller communicates each data frame at the full 10 Mbit/s or 100 Mbit/s speed with the network.

Answer 3

Ethernet link speeds range from 10 Mbit/s to 400 Gbit/s currently. Generally, each Ethernet frame must be transmitted atomically, without any pauses.

For low-speed devices, that mandates decoupling transmission and processing speeds using buffers. There's a Tx buffer where a frame can be assembled using SPI and then sent out at the link speed (which could be any speed, depending on the PHY). A buffer of the same type is used for receiving: an incoming frame is stored in the Rx buffer where it can be read out at any speed via SPI. Multiple buffers are often used to avoid losing frames while the previous one is still being processed and to streamline data flow.

Note that Ethernet is very often used with TCP/IP on top, requiring a local stack for processing which is not trivial. If you don't want to or can't implement or integrate that stack, you might want to consider a more sophisticated IP network module that integrates that functionality already.

Answer 4

The ethernet controller will exchange packets through a 10Mbit/s or a 100Mbit/s link. Those packets are sent from or stored into internal memory in the controller, at full speed. The rest is up to you, speed-wise.

If your only job is reflecting the packets, unchanged, back to the sender: this controller can do it at full wire speeds, most likely.

If you need to actually transfer the whole packet from the controller's memory to your system over SPI, or vice-versa, it'll work at up to 1/3 wire speed at 100MBit/s, assuming you run SPI at full speed, and your microcontroller is keeping the SPI link busy at all times, without pauses - i.e. you're using DMA or a dedicated realtime peripheral to deal with SPI.

In many cases you will not need to transfer the whole packet between the controller and your system. For example, if you're having a TCP/IP connection open, then the outgoing packet's headers and destination can be preset in the controller's RAM. Only small changes will be necessary, e.g. the sequence number, and the packet's payload.

When receiving a packet, you may start processing its contents before the whole packet has been transferred over SPI. For example, if you're parsing the packets byte-by-byte, you would be running the parser in parallel with SPI transfer, at least as long as the parser throughput is lower than the SPI data rate. Such overlap can help lower latency and improve throughput in spite of the SPI's limitations.

SPI bus time is the limiting factor, so for maximum throughput there should be as little idle time on that bus as possible.

Those are micro-optimizations but they may be helpful.