| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
On the 25G architecture call today, it was pointed out that we (BASE-T) might need to consider an edit to the portion of clause 78 (EEE) that speaks to fast wake / deep sleep, which may be found in
subclause 78.1.3.3.1 PHY LPI transmit operation of the 802.3bx
Draft 2.1 (section 6) revision spec, on page 37, starting at line 16: For PHYs with an operating speed of 40 Gb/s or greater that implement the optional EEE capability, two modes of LPI operation may be supported: deep sleep and fast wake.
Deep sleep refers to the mode for which the transmitter ceases transmission during Low Power Idle (as shown in Figure 78–3) and is equivalent to the only mechanism defined for PHYs with an operating speed less than 40 Gb/s. Deep sleep support is optional for PHYs with an operating speed of 40 Gb/s or greater that implement EEE with the exception of the PHYs noted in Table 78–1 which do not support deep sleep.
Fast wake refers to the mode for which the transmitter continues to transmit signals during Low Power Idle so that the receiver can resume operation with a shorter wake time (as shown in Figure 78–4). For transmit, other than the PCS encoding LPI, there is no difference between fast wake and normal operation. Fast wake support is mandatory for PHYs with an operating speed of 40 Gb/s or greater that implement EEE. The way I read this, for BASE-T PHYs, we have a different situation – clock recovery continues because of the refresh operation, so normal LPI operation is kind of a blend
of the two – that is what is currently in the draft We had some discussion a long time ago, from which I do not recall the outcome. Reading the above, I believe we have a choice: -
We can add a ‘fast wake’ where RS-LDPC-encoded LPI signals are transmitted continuously by the PHY, and the PHY doesn’t go into any special mode when it gets
the LPIs – it just passes them through. This would allow the rest of the system to go into an energy efficient state from which it can recover without any lag due to the PHY (no refresh cycles, no ALERT, etc.). This involves some edits to our existing text,
and allocation of a bit for fast wake. -
OR, we can edit the text in clause 78.1.3.3.1 to make BASE-T PHYs different and exempt them from the requirement at the end of the paragraph above. I believe the first option is probably the best, and the second option is the easiest – something to discuss at the PHY meeting Thursday. George Zimmerman Principal, CME Consulting Experts in Advanced PHYsical Communications Technology george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx 310-920-3860 (PLEASE NOTE NEW EMAIL ADDRESS.
THE OTHER WILL STILL WORK, BUT PLEASE USE THIS FOR CME BUSINESS) |