1、Realizing Asymmetric Datarates via Energy Efficient Ethernet(EEE)Dr.Philip AxerAxonne Public1Agenda Introduction to EEE Timing and Latency Partitioning Configurations,Power&Robustness SummaryAxonne Public2Introduction to EEEAxonne Public3The need for AsymmetryEnterprise/Datacenter:Dynamic traffic pa

2、ttern.Exact use-case known by the users.Usually,service contracts that give guaranteeSymmetric data rates(except for last-mile)Automotive has obvious source/sink relationMajority of data is streaming data that is generated in the Zone and flows to central processingControl data flows in opposite dir

3、ection(actuation,sensor control,handshaking messages such as TCP/IP,)Axonne Public4Control(I2C)FusionRadarRadarRadarRadarDisplayVideo streamVideo streamRadar streamControl(I2C)ECUCameraVideo streamUser AUser BUser CUser DNetworkDatacenter applicationAutomotive applicationAsymmetric rates over symmet

4、ric EthernetTodays Ethernet(BASE-T1)is full-duplex and symmetric:same rate in both directionsExcept for 10BASE-T1SAll T1 speed grades=100M use active IDLE and exchange data when no Ethernet frames are being transmitted.Power consumption is data-independent and under-utilized links use powerEnergy Ef

5、ficient Ethernet (802.3-2022 Clause 78)addresses this issueEEE is specified for all 1000BASE-T1,2.5GBASE-T1,5GBASE-T1,10GBASE-T1 and 25GBASET1.Axonne Public5EEE Use-case:ImagerEthernet Imager with PoDL support(Example values)I2C Control 400 kHz60 fps4k RAW10PoDL to supply radar or camera nodesAssumi

6、ng I2C control activity linked to frame rate period of 17ms,downstream link is mostly idleAxonne Public6ECU12VPoDLETH-CSIPHYImagerCSII2CxMIINote:ETH-CSI is usually up-integratedDiagram not to scaleUpstreamDownstreamTrainingTrainingImager InitStreamingControl frameEEE-LPIHow dowsthis work in detail?E

7、EE IntroductionLow Power Idle(LPI)Client decides when linkgoes into power saving mode(LPI mode)LPI is asymmetric and directions can go into LPI indepdentely,e.g.:TX direction can be in LPI and RX direction remains activeDuring LPI state,PHY sends cyclic REFRESH sequence to maintain timing lockWakeup

8、 is signaled via an ALERT(Link sync sequence),followed by a WAKE(training sequence)Axonne Public7Low Power Idle(LPI)ClientMACReconciliation SublayerPHYxMIIPhysical Layer Signaling(PLS)Service Interface Low Power Idle ClientService Interface IDLE/DATASleepQuiteRefreshQuiteRefreshAlertWakeIDLE/DATAIDL

9、ETiming and latencyAxonne Public8EEE TimingThe PCS uses Reed-Solomon frames(RS-FEC frames)In EEE everything happens on RS-FEC frame boundary.RS-FEC frame counters serves as common time base for MASTER and SLAVESynchronized within 0 to 4 RS-FEC frames(better for speeds 10G)REFRESH and ALERT are inter

10、leaved between MASTER/SLAVE to avoid interferenceREFRESH once per cycle.Distinct start points for ALERT Axonne Public9SLEEP8RAIDLE/DATAWIDLE/DATA841SLEEPRlpi_quite_time=96 RS-FEC framesAIDLE/DATAWLength of signal#RS-FEC framesMasterSlaveAlert start pointsRefresh for SLAVE on RS-FEC#51Refresh for SLA

11、VE on RS-FEC#95EEE Timing cont.When new data is available,MAC needs to defer until link is available latencyTwo EEE flavors(user setting):“EEE”and“Slow-Wake”Slow-Wake has one alert start points per cycle higher latency but more power saving potentialLatency for wakeup(assuming the wakeup happens aft

12、er SLEEP signal has completed*):Waiting for the next ALERT opportunity+ALERT duration+WAKE duration Normal:10G:6.4 us 5G:12.8us 2.5G:25.6usSlow:10G:34.56us 5G:69.12us 2.5G:138.24usAxonne Public10(illustrative scenario,not worst-case)SLEEPRADATAWDATAMDIAlert start pointsxMIIFrameLPIData available ins

13、ide MACDataNo DataDataIdleFrameNo DataDeferingWakeup latency*)based on“Case 2”and“Case 4”latency 802.3 Clause 78.5 Putting the latency into perspectiveLatency is large,when compared to Ethernet frameLatency is small in relation to I2C transaction(for 5G and 10G much faster)Axonne Public11Latency2.5G

14、 Wakeup latency(EEE)25.6us2.5G Wakeup latency(Slow-Wake)138.24usFrame period at 60 Hz16666 us1500 octet frame 2.5G4.8 us64 octet frame 2.5G0.2 usI2C Read(400 kHz,1 Byte,no clock streching)72.5 usI2C Write(400 kHz,1 Byte,no clock streching)97.5 usPartitioningAxonne Public12LPI ClientThe 802.3 view is

15、 to put the LPI clienton-top of the xMII interface(i.e.inside a SoC/switch)MAC sends LPI control words through xMII to enter LPIMAC sends IDLE control words through xMII to exit LPIMAC needs to obey LPI timing(how long to send LPI,how long to defer on wakeup)Axonne Public13Low Power Idle(LPI)ClientM

16、ACReconciliation SublayerPHYxMIIPhysical Layer Signaling(PLS)Service Interface Low Power Idle ClientService Interface 802.3 view on LPI ClientThe IEEE 802.3 view on LPI is very loose the LPI clients behavior is not specifiedNot specified when LPI is entered and exitedHeuristics to enter LPI are comp

17、letely left to the implementer no relation to 802.1Q queuing,shaper,etcLPI Client(cont.)Broad spectrum of EEE support in MACssome MACs do not implement EEE at allLPI codewords not generated/understoodsome MACs implement poor EEEFor example:Software register to manually enter LPI via softwareLPI is n

18、ot automatically entered/left based And some MACs implement good EEEFor example:LPI entered based on 802.1Q decisions(i.e.queue fill levels)OEMs/Tier1 companies cannot pair every EEE PHY with every SoCAxonne Public14Autonomous EEEA PHY product can easily make EEE decisions on its own,without MAC inv

19、olvementLPI Client inside PHYDuring the wakeup time,the PHY needs to buffer arriving TX frames*):11.2 kb for EEE(for 2.5G T1)46.4 kB for Slow-Wake(for 2.5G T1)Viable solution for EEEOld idea and products are already out since the beginning of EEEAxonne Public15PHYFIFOLPI ClientLPITXxMIIMDIEmptyRX*)b

20、ased on“Case 1”and“Case 3”latency 802.3 Clause 78.5 Timestamping-Autonomous EEEPHY latency not constant anymore because the FIFO is buffering wakeup latencyMAC-based PTP timestamps may be incorrect due to FIFO variability to accommodate PHY wakeupCan be easily overcome with the following solutionsPH

21、Y timestamping Timestamp the actual packet release time at the PHYMeassure PHY resistence time and compensate MAC timestamp accordinglyAxonne Public16PHYFIFOLPI ClientLPITXxMIIMDIEmptyRXPTPPowerAxonne Public17Configurations&Power consumptionAll MASTER/SLAVE configurations are possible and part of fu

22、ture IOPT testsSyncE-like scenario possible:“controller”as MASTER distributes clock to SLAVE sensor nodes Axonne Public18ModeQualitative Power consumptionTX IDLE/DATA,RX IDLE/DATAHighTX LPI,RX IDLE/DATAMediumTX IDLE/DATA,RX LPILowTX LPI,RX LPILowestSinkPHYSlavePHYMasterSourceLPIDataSinkPHYMasterPHYS

23、laveSourceLPIDataPower consumption depends on LPI states in TX/RX direction:Some loose ends OPEN TC-16 is trying to fill in some blanks EEE interoperability&conformance tests EMI(?)Some points not addressed/discussed yet Bridging the gap between 802.1Q and 803.2 EEE Do we need a standard when to ent

24、er/exit LPI based on the queuing/prios/shapers/gates/?Axonne Public19Dashboard Overview&SummaryAxonne Public20Asymmetric Ethernet via 802.3ch+EEEPlug-and-play style,works with standard MACs Solution is ready sample and near-final silicon availableEverything is Ethernet&builds on-top of proven T1 tec

25、h less diverse technology ecosystemHigh data rate available in upstream direction Fast OTA,firmware update Diagnostic scenario in which data is routed through alternative pathsSimple Interoperability ecosystem,asymmetric but without chipset solutions less combinations of things to test againstAxonne

26、 Public21SummaryEEE available today contrary to other technologyScalability EEE also available for future T1 PHYs(25BASE-T1)EEE incurs additional latency during wakeup scenarioCompared to I2C latency(the control channel to sensors),latency is negligibleLPI Client(EEE decision)can be in MAC or PHYEasy to retrofit SoC that do not have EEE support with Autonomous EEE PHY implementation Some ecosystem work(IOPT,conformance,802.1Q,)to be done OPEN Alliance TC16Axonne Public22