I am just wondering what kind of procedures are running during the link establishment in 100Base-T ethernet in case auto negotiation is disabled (i.e. forced mode) at both ends of the ethernet connection (i.e. switch and NIC)? Thanks,

None :-) However directly forcing the mode is generally a bad idea - it tends to end up with mismatches, some of which are hard to diagnose. If you want to force (say) 100M FDX the best thing is to set the the PHYs auto negotiate advertise register (ANAR) with the single bit for the the desired mode. Then the negotiation will still happen, but the outcome is guaranteed [1]. [1] Unless you connect to an old 10M hub (which doesn't do any detection) or an old dual speed 10/100M hub that uses auto-detect not auto-negotiate. Anything that will do full duplex supports auto-negotiation.

Thanks for the reply. I agree that using auto-negotiation is a good practice but I am just wondering whether there is another state diagram similar to auto-negotiation in case both end nodes disable auto-negotiation. Actually I have a very simple configuration with 2 hosts with a single switch. When I perform ethtool eth1, then I saw two lines related to auto-negotiation. First is "advertised auto-negotiation : Yes" and second "Auto-negotiation : off". So in this configuration I think although auto-nego is disabled, the card still advertises its capabilities to the other end.

Some history might help: The original 10M HDX for UTP included 'link test pulses', a single pulse was sent at a fixed rate, reception of the pulses would typically light a little led, the polarity of the pulses could be uses to detect mis wired cables. Later cards would also auto-detect cross over (by detecting pulses on the tx pair). 100M HDX used a short burst of pulses to indicate support for 100M (and 10M), a 10M phy would treat them normally, a 100M phy would detect the burst and then auto-detect that it could use at 100M. Old dual speed hubs are two separate hubs (one for each speed) connected via a bridge. With the advent of FDX the burst of link test pulses was modified so that some of the pulses would be missing. This enabled specific register values (not only the ANAR) to be passed to the remote PHY. A 100M HDX hub would still treat it as a valid burst and do 100M. The standard MII phy interface defined 16 registers (it might have been extended). The first 8 are vendor independant and contain the ANAR and the ANRR? (received ANAR value), what they don't contain is the actual operating mode - which can be difficult to determine. There are a lot of devices that don't like being connected to 10/100 hubs. For 10M and 100M the link test pulses are sent at regular intervals. For Ge and higher things are more complicated, once the initial negotiation has happened the data pairs get connected to a powerful DSP. I suspect that regular link test pulses are no longer sent.

Thanks for the reply. When you say 'link test pulses', do you mean FLPs? or are they different pulses than FLPs in 100M case for example. When I read 802.3-2008, it talks about FLPs for 100M case that auto-nego process sends and receives many of them.

Ethernet autonegotiation | Altera Community

15 Replies

Altera_Forum
Honored Contributor
13 years ago
Yes, parallel detection is used if one end has aneg enabled and the other doesn't. If both ends have aneg disabled, they both send idle, and the mac operates in whatever mode you specify (half/full). When either end sees idle, it establishes a link.

Cheers,
Altera_Forum
Honored Contributor
13 years ago
Actually the MAC itself always has to be told whether to do FDX or HDX, the driver has to extract that information from the PHY (or ignore the PHY and use a hard-coded value).

The PHY configuration (and negotiation) control the speed. In some cases (eg some MAC using MII) the MAC doesn't need to know whether the PHY is doing 10M or 100M (I'm not sure about higher speeds).

(I suspect we are agreeing violently!)
Altera_Forum
Honored Contributor
13 years ago
Yes, I think that's what I said, the MAC has to be configured (one way or another) for duplex, via the driver polling the phy to get autoneg results, or manual control. I'm not a 10Mbps expert (most of my knowledge is 1G+), but NLPs (or link test pulses) are "idle" in 10Mbps, so yes, they are still sent in 10Mbps mode. In 100Mbps, FLPs are sent if aneg is enabled (until completion of the aneg process), otherwise it's MLT3 encoded idle.

At higher speeds the mac interface is different, i.e. gmii or xgmii, etc.
Altera_Forum
Honored Contributor
13 years ago
So do you know which specification explains MLT3 encoded idle message transmission procedures for 100Base-T case? I checked 802.3-2008 but could find much information. Should I look at previous versions?
Altera_Forum
Honored Contributor
13 years ago
The actual PMD spec for 100Base-TX is covered by the FDDI TP-PMD standard, it's not in 802.3. It's a 3 level analog signal, nothing you can interface an FPGA directly to without some external components. If you're attaching to a PHY, all you need is an MII, and you can obtain link status (etc) from the PHY's MDIO interface.

Forum Discussion

Ethernet autonegotiation

15 Replies

Recent Discussions

Dual Port Nios V BSP error

set_output_delay explained for dummies

[Test only]How to verify Agilex 3 in radiation tolerant environment

gdb server problem when debugging

Nios IDE CPU Detection