ADIN1300 back-to-back repeater with EEE

Question

I have prototyped two ADIN1300s back-to-back using RGMII. It works fine, except when both ends use EEE. Rx works and the RGMII seems to be ok, but the MDI Tx on one of two PHYs will stop working. My testing has been with gigabit links. Any ideas?

MarkBolger · Accepted Answer

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 &ldquo;ripples&rdquo; 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:

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). 
 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. 
 
 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. 
 
 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. 
 
 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 &ldquo;rippling&rdquo; 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 &ldquo; I have this same issue with AR8035, btw, but it can be band-aided through their 'smart EEE' support. &rdquo; 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 &ldquo; If I enable EEE on both ports, however, data in one direction will stop.&rdquo;. 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

Electronic Design Services - PartnerZone

Products In This Thread

ADIN1300 back-to-back repeater with EEE

Top Replies