ADIN1300 back-to-back repeater with EEE

Hi Mark,

Could you provide some more information on the strapping you have selected for the MAC interface on each of the devices? And what type of link is on either of the two ADIN1300 PHY’s?

Best Regards,
Mark

Hi Mark,

Could you provide some more information on the strapping you have selected for the MAC interface on each of the devices? And what type of link is on either of the two ADIN1300 PHY’s?

Best Regards,
Mark

MACIF_SEL1/SEL0 => 00  but I take off TxC delay through MDIO register write

PHY_CFG1/CFG0 => Gnd/3.3V

I have a working MDIO interface, so I can tinker with any registers you suggest.  So it's RGMII.  For both ends RxD -> TxD, RxC -> TxC, RxCtl -> TxCtl.  The RxC delay is left in, I take off the TxC delay.  I've verified that packet replication is correct (except for EEE issue). 

One of the test setups uses a Qotom network PC that has 4 1Gig ports.  Runs linux.  So I use two ports back-to-back through the ADIN1300 repeater setup.  If no EEE selected via ethtool, all is well.  If I enable EEE on just one port, it works.  If I enable EEE on both ports, however, data in one direction will stop.

Any other info I should give you?   I have this same issue with AR8035, btw, but it can be band-aided through their 'smart EEE' support.

Hi Mark,

After discussing with the team please see the following:

Block diagram of ADIN1300 RGMII Back to Back configuration shown below

The issue is that in the ADIN1300 PHYs connected back-to-back, the wake-up time “ripples” from RX to TX. That is due to the way the Assert LPI (ALPI) is generated on the RX side.

According to figure 40-11a in IEEE Std 802.3-2018, ALPI is generated in the RX PCS LP_IDLE state while lpi_mode = ON, as shown below:

The lpi_mode signal is in turn generated in the PHY control, and according to Figure 40-16b, it is set to ON in the UPDATE state, when entering LPI, as shown below.

Therefore lpi_mode will remain set to ON until the PHY control returns to the SEND IDLE OR DATA state (transition C) in case of normal operation or the Subordinate SILENT state (transition B) in case of errors, i.e., it will stay ON during the whole RX wake-up.

In reference to figures above, say that the MAC in both PC ports have ALPI set on the RGMII TX and therefore after some time all PHYs have entered LPI and are in the (PHY control) QUIET state.

Now, if MAC (1) de-asserted LPI on the RGMII TX, that will trigger the following events:

1. GE PHY (2) will exit the QUIET state to begin the wake-up sequence, and start transmitting Idles (tx_mode = SEND_I in the WAKE state).
2. ADIN1300 (3) will receive the Idles, which will set signal_detect = TRUE, and will also exit the QUIET state to start the wake-up sequence.

However, the RGMII RX will keep ALPI asserted because lpi_mode = ON, which means that ADIN1300  (4) will keep receiving ALPI on its RGMII TX and will not start the wake-up.

1. After a maximum of 16.5 us, ADIN1300 (3) will complete its wake-up, which will cause that lpi_mode is set to OFF and LPI will be de-asserted on its RGMII RX.

This means that ADIN1300 (4) will no longer receive ALPI on its RGMII TX, so that loc_lpi_req = FALSE and it will exit the QUIET state to start the wake-up sequence, and will start transmitting Idles.

1. GE PHY (5) will receive the Idles, which will set signal_detect = TRUE, and will also exit the QUIET state to start the wake-up sequence.

It will keep the ALPI indication on its RGMII RX to the MAC (6) until the wake-up is complete.

1. After a maximum of 16.5 us, the GE PHY (5)  will complete its wake-up and indicate that to the MAC (6) by de-asserting LPI on the RGMII RX.

However the wake-up time of the end-to-end connection (from MAC 1 to MAC 6) could be up to 2 x 16.5 us, which is twice the required time, due to the “rippling” of the wake-up in the ADIN1300 connected back-to-back. Although, I am not sure whether this is the root cause of the reported problem, but is potentially a real issue. If MAC (1) started packet transmissions after the wake-up time (16.5 us) some packets would be lost.

Previous comment says “ I have this same issue with AR8035, btw, but it can be band-aided through their 'smart EEE' support. ” From the DS, that is a mode in which they buffer the data during the wake-up, which would indicate the additional end-to-end wake-up time could be the issue. If the NW PC wake-up time could be configured, it might help to fix this problem.

However, another previous comment says “ If I enable EEE on both ports, however, data in one direction will stop.”. That could be related to the configuration (Main/Subordinate) of each of the PHYs (2 to 4), can you confirm the Main/Subordinate configuration on PHYs 2 and 4 from the block diagram above?, but if PC to ADIN1300 links are configured identically (i.e. the ADIN1300 PHYs are slaves and the PC ports are Main, or vice-versa), both directions would be symmetrical, so I do not see how data could pass in one direction and not in the other.

Regards,

Mark

Mark,

Thanks for the in-depth analysis!  I need to take more time to study that, but I think I can answer the last paragraph at least.  By main/subordinate I think you mean the same as master/slave, which can be manually configured in register 9, is that correct?  So I tried both sides as master, both as slave, and mixed, and confirmed the results in register 0xA, but this did not make any difference.

On the 'one direction failing', it might be timing, the order in which packets are received.  It's always the same port in test software, and packets are always sent in the same order.

My Qotom box, btw, doesn't seem to support changing the wake-up timing, so I haven't been able to try that.

Hi Mark,

Yes that assumption is correct for main/subordinate meaning

Best Regards,

Mark