| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
EEE-wise folk:
I’m looking at the state diagrams for the PCS in the document, and it looks like there may be one or more issues in the temporary EEE exit due to low SNR.
You’ll note that when this happens, we do not get a ‘wake’ code from the MII, but rather are receiving an lp_low_snr from the PMA from the link partner.
The first issue is in Figure 149-17.
It appears that TX_WN may need a recirculating function if it is supposed to wait until tx_lpi_active is false before exiting, and continuously re-evaluate the condition tx_alert_start_next. State diagrams only evaluate the condition on entry to a state. Otherwise, if tx_alert_start_next were false on entry, TX_WN would enter, set tx_coded to IBLOCK_T and exit with tx_lpi_req possibly still in the true state (for example, if LPI is being exited due to a low SNR message). According to Figure 149-20, tx_lpi_active is set FALSE in TX_NORMAL and TRUE in SEND_SLEEP, which can only be exited by tx_lpi_req going to false.
tx_lpi_req is described as “A Boolean variable that is set true when the LPI client indicates that it is requesting operation in the LPI transmit mode via the XGMII. It is set false otherwise.” Clearly, this is not the case with the temporary exit.
The second issue is with the same figure – it isn’t clear that we re-enter quiet-refresh signaling cleanly. Assuming that tx_lpi_req gets set to false to fix the above, and Figure 149-20 gets back to the TX_NORMAL state, you can’t get back to the SEND_SLEEP state and hence into SEND_QR unless tx_lpi_req
The second possible issue is one of intent. – is it our intent to fully wake up the far-end with a low-snr exit? the way it is now (assuming the above gets changed), an exit from quiet-refresh signaling via an ALERT from the far end transmitter would result in the receiver getting an alert and processing it just like a real wake-up.
All of these come down to intent, and there are multiple ways to fix it (I’m thinking the simplest is to have the temporary wake up happen without an ALERT, and hence no change in the receiver PCS state. that way the receive PCS stays asleep and presents LII to its XGMII. However, to do that, you need to change Figure 149-17 so that you don’t exit TX_WN on a low SNR condition, but do something that recirculates back to TX_L when the low SNR condition is gone. You also need to add a state for Figure 149-20 which exits SEND_QR on low SNR and reenters it when the condition is gone.
Before I put in the work to propose a solution, since it all just twists my brain into a pretzel, I thought I’d check and see if I was missing something simple.
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications
310-920-3860
To unsubscribe from the STDS-802-3-NGAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1
To unsubscribe from the STDS-802-3-NGAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1