Ethernet link speed auto detection

[Altera_Forum]

Hi 

 I have a custom board with a ethernet PHY connected to the FPGA using RGMII. I am using triple speed ethernet and iniche. I do not have the signals set_10 and set_1000 from the PHY. I can get the network to work on either 1000 or 100 by connecting eth_mode to 1 or 0 or using the ETH_SPEED bit in the command_config register. How can I get it to auto detect the link speed?

[Altera_Forum]

Read the triple speed ethernet user guide pdf! It's all written and shown there.

[Altera_Forum]

Thank you, but I would not have asked before looking there. 

I guess I just have missed it then. I will have another look, hopefully I will find it this time.

[Altera_Forum]

figure 4-12 on page 4-24

[Altera_Forum]

Thank you. Figure 4-12 on page 4-24 is for MII/GMII interface. I am using a RGMII interface so I think the correct figure should be 4-13. My logic is as shown in 4-13 with set_1000 and set_10 tied to 0 in the FPGA. With this logic I can use the MAC in 1000 or 100, but I have to manually select the speed with the ETH_SPEED bit in the command_config register. What I am looking for is a way to make the MAC or iniche detect the ethernet link speed without using the set_1000 input.

[Altera_Forum]

Those pins are not dependent on MII/GMII/RGMII bus and are valid for all types. Check the RGMII bus specification.

[Altera_Forum]

Ok, but the problem is that I do not have those inputs (set_1000 and set_10) to the FPGA and I am wondering if there is another way to detect the link speed.

[Altera_Forum]

Then use the management bus to the PHY. Do You use a tcp/ip stack?

[Altera_Forum]

I am able to read the PHY registers over MDIO (MDIO Space 1 in the TSE component). I see that the correct speed is reported but it is not reflected in the ETH_SPEED bit in the command_config register. I am using a tcp/ip stack (iniche) and it is working. The project is based on the simple socket server RGMII template. I have added the PHY profile with alt_tse_phy_add_profile so iniche should have information of where to find the correct status register and bit location for the link speed. Is there something else I am missing to get it to detect and change the speed?

[Altera_Forum]

You can use the function getPHYSpeed() provided by HAL driver (include altera_avalon_tse.h) 

Or you can manually read the proper phy register using mdio interface.

[Altera_Forum]

Check the TSE MAC driver sources. The driver tells the speed during setup, so check how the driver checks registers.

[Altera_Forum]

Are you using a different PHY's than the ones officially supported by the TSE? 

If you added a custom PHY to the driver, you need to provide a function that reads the link speed from the MDIO registers and configure the TSE accordingly. Have a look at the Marvel 88E111 driver for an example.

[Altera_Forum]

The MAC I am using is Marvell 88E1116R. It was reported as unknown during startup, so I added a PHY profile for it and after that it was not reported as unknown. First I did not add a link_status_read function to it, but after seeing your post I added one. Now it sets the MAC to the same speed as the PHY during startup, but it will not change speed later if the PHY speed changes. The link_status_read function is only called once during startup so if the link speed changes later PHY speed is changed but not the MAC speed. To get around the problem I poll the MDIO status register for the PHY speed and update the MAC speed. But I would like to have the driver handle the speed changes.

[Altera_Forum]

If the PHY's LED pins are connected to the FPGA then you can detect the link state and speed directly, and trigger an interrupt on the CPU in case of speed change. If not then the only solution is to regularly poll the MDIO registers and reconfigure the MAC, as you are doing right now.

[Altera_Forum]

--- Quote Start ---  If the PHY's LED pins are connected to the FPGA then you can detect the link state and speed directly, and trigger an interrupt on the CPU in case of speed change.  --- Quote End ---    Workaroundish method :D

[Altera_Forum]

But it works ;) 

Actually the older PHYs used to have a pin that could directly report the link status. But today we want smaller and smaller PHYs, the chips have fewer pins so they have to reduce the number of functions. Monitoring the LED pins work quite well. I did that on a design that has a continuous built-in-test routine that needs to check regularly that all the links are up. MDIO polling works, but monitoring the LED pins is a lot faster. Unfortunately during an MDIO read access with the TSE the CPU is frozen until the response has been received, and I'd rather have the CPU do something else during the MDIO cycle.

[Altera_Forum]

Unfortunately I do not have access to the LED pins from the PHY but the polling method I use now are working fine. Thank you all for the help.