I am currently trying to get a basic Ethernet communication between a laptop and and FPGA Development board working correctly, however, I seem to be facing an issue where the auto-negotiation is timing out.

I have the Ethernet port on my device plugged into a an Ethernet cable which is going to an Ethernet-to-USBC adapter, and this adapter is plugged into my laptop.

Prior to this I have attempted to assign an IP-Address to the device and then ping that IP address (but no response was received). Additionally, I have followed the Ethernet Firmware API for initialization calls (parsing through the code I found that this auto-negotiation happens in the first initialization call)

Would anyone have any idea on what I may be doing wrong?

For reference I am using Microsemi's M2S150 FPGA development board which has a an m88e1340 PHY from Marvell, and an ARM M3 Cortex

  • 2
    \$\begingroup\$ To have an answerable question, you'd need to show the results from meaningful debug attempts. Just saying it gives up and doesn't work is an end-user problem report, not a design engineer problem report. \$\endgroup\$ Commented Nov 17, 2020 at 23:22
  • \$\begingroup\$ With the debugging that I have done so far, my guess is that the reason pings aren't being received is because the auto-negotiation has timed out. Unfortunately, I'm not quite sure how I may be able so show a meaningful debug attempt. I can say that I stepped through the lines of the code that the Initialization function was calling and found that the auto-negotiation had timed-out (before this I didn't have any clue as to why it wasn't working). I'm not quite sure how to push forward with this new knowledge \$\endgroup\$ Commented Nov 17, 2020 at 23:31
  • \$\begingroup\$ Either make sure you are using a known good reference design for both hardware and software 100% as published/sold and unchanged, or you're going to have to dig in, understand how the auto-negotiation is supposed to work, and figure out why specifically it is failing. \$\endgroup\$ Commented Nov 17, 2020 at 23:32
  • \$\begingroup\$ Are you running windows on the laptop? \$\endgroup\$
    – user4574
    Commented Nov 18, 2020 at 1:03
  • \$\begingroup\$ yup I have windows running on the laptop \$\endgroup\$ Commented Nov 18, 2020 at 2:44

1 Answer 1


I seem to be facing an issue where the auto-negotiation is timing out.

Auto-negotiation is typically handled directly by the PHY. In every chip I have encountered, it should happen automatically without any setup as long as...

  1. The chip has power
  2. You aren't holding the chip in reset.
  3. The +/- in each differential pair is not swapped
  4. The TX and RX pairs are not swapped. Remember, when connecting directly to a device without going through a hub you need a crossover cable (or a PHY with auto MDIX enabled).
  5. You didn't disable auto-negotiation in the MII management registers by writing incorrect values in software.

You can tell that auto-negotiation completed by looking at the network connection properties in windows. If it shows a connection speed (anything at all) then it worked.

Prior to this I have attempted to assign an IP-Address to the device and then ping that IP address (but no response was received).

The echo request and echo reply (AKA ping) is part of the ICMP protocol. ICMP runs on top of UDP and IPV4 or IPV6. By default windows won't communicate to a device that is in a different sub-net.

In windows you must have (SRC_IP_ADDR & MASK) == (DST_IP_ADDR & MASK) for the source to be able to send the message. For example if your mask is FF.FF.00.00 then the upper two bytes of the PC IP address must match the upper two bytes of the device IP address

So make sure the sub-net mask and IP address in windows matches the IP address for your device. Otherwise you won't be able to communicate via IPV4/IPV4, UDP, or TCP (so no pings).

When windows sends a non-broadcast IP packet over Ethernet, it needs to know what to put into the MAC layer destination address field. This information is contained in an ARP table. The first time windows trys to send a packet to a new IP address it won't know the destination MAC address, so instead it sends an ARP request (using a broadcast MAC address) to find out. The destination replies with another ARP packet and then windows updates its table. At that point windows can actually send the packet. You have a few options here.

  1. Your device implements the ARP protocol (which is standard in most network stacks).
  2. You manually make an ARP table entry in windows.
  3. You only send packets using the broadcast IP address (FF.FF.FF.FF), in which case windows won't need ARP since it will use the broadcast MAC address (FF.FF.FF.FF.FF.FF) to send the packet.

Option 3 is a really good option for debug because it eliminates both ARP and the sub-net mask as possible failure points. But be aware that broadcast IP packets typically won't propagate through the upstream port of any Ethernet switches or routers. (but it will pass between any other ports on the switch).

If you are running windows on the laptop you need to be aware that (by default) windows is going to expect that there is a DHCP server accessible from each Ethernet port. When you plug in your device windows is going to try and obtain an IP address over DHCP. It can take a long time before windows gives up. After DHCP fails it will then try to use APIPA to obtain an address (basically by choosing a desired address and then using ARP to verify that no-one else is using it). In any case, during that whole process you can't send any IP packets (at least from normal code thats not part of an NDIS driver).

From personal experience, all three of these options work.

  1. Configure your Ethernet port to use a static IP address.
  2. Plug in an Ethernet switch between your device and the laptop. Many switches implement a DHCP server and will give windows an address.
  3. Implement a DHCP server in your device, and let it give windows an address.

Also note that if you plug in an Ethernet port connected to a PC running Windows, then Windows will send out all kinds of packets trying to figure out what its attached to and to see if it can get to the Internet. So be prepared to receive all kinds of unexpected packets during debug.

  • \$\begingroup\$ When I plug in my ethernet-usbc adapter a new ethernet connection in the network connections menu, however, regardless of whether the ethernet cable is plugged into my device's PHY there is a red X on the ethernet icon. Also to clarify when I attempted to assign my device an IP address I made sure that my sub-net mask was the same sub-net mask I found when running ipconfig. Was this the correct thing to do? \$\endgroup\$ Commented Nov 18, 2020 at 2:53
  • \$\begingroup\$ @EpicFoodCartDestroyer The sub-net mask defines what ranges of addresses are accessible to the PC. Basically you must have (SRC_IP_ADDR1 & MASK) == (DST_IP_ADDR & MASK) for the source to be able to send the message. For example if your mask is FF.FF.00.00 then the upper two bytes of the PC IP address must match the upper two bytes of the device IP address. \$\endgroup\$
    – user4574
    Commented Nov 18, 2020 at 3:30
  • \$\begingroup\$ If you get a red X in windows then it probably means that the PHY is probably not even running. I would probe C246, C257, R75 , R78 on the board with an oscilloscope and make sure that the reference clocks are going to the PHY. \$\endgroup\$
    – user4574
    Commented Nov 18, 2020 at 4:07
  • \$\begingroup\$ the media has to be capable of autoneg which here sounds like it is 1000BaseT or 10/100 or something. not fiber, etc. And if capable then both sides have to be enabled to advertise for the other side to see and/or autoneg themselves. One side being an fpga can mean that it is not configured or may be set at a fixed speed (which wont necessarily detect). Point being it doesnt always just work...Most of the chips/phys I experience dont do it but most of them are faster than gigabit. gigabit cots products, sure, they just work... \$\endgroup\$
    – old_timer
    Commented Nov 18, 2020 at 19:12
  • \$\begingroup\$ The gigabit phys I have experience dont just work either when you power them on you have to load the firmware in the proper way, etc..there is power on reset then load the firmware then kick the internals on then depending on how that is configured it just works or doesnt...phys are in general quite difficult to get working. With a purchased product or a kit of some form which this is, the demo applications should just work once powered yes. \$\endgroup\$
    – old_timer
    Commented Nov 18, 2020 at 19:18

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.