Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_4PPOE] PD state machine issues.

Hi Yair,

thank you very much for your shared issue related PD.

The state NOPOWER keep in account the exit way of a PD to reach turn off and the idea is limit the PD power up to 44mA during VPD<Voff_PD.
The introduction of a further variable that regulate a possible (or not) use of that way is not my preferred approach.
Maybe is possible to evaluate to remove the exit from POWER_DELAY to NOPOWER.

While the point related to pse_power_level <==8  I think that your proposal is a right suggestion but it should be implemented in the definition of pse_power_level variable.

Thank you


2017-10-20 1:12 GMT+02:00 Yair Darshan <YDarshan@xxxxxxxxxxxxx>:
Hi all,
I found serious issues in PD single-signature state machine (the same issue relevant for dual-sig as well).
I’ll appriciate your inputs.
The PD state machine for single signature (and dual signature) has few issues concerning  NOPOWER state and going back to INRUSH and back to POWER_DELAY.
  1. Violation of tpowerdelay_timer when going from POWER_DELAY to NOPOWER.
  2. Possible overload condition due to the assignment of (pse_power_level <== 8).
  3. Allowing incompliant behavior of PDs that doesn’t lock their class event counter and sensitive to 2nd inrush counted as additional class event (I understand the need for this but we need to allow it as optional behavior and not mandatory behavior for PDs. For example: If PD didn’t lost its data when going to  Vpd < Voff_pd, it doesn’t need to set (pse_power_level <== 8) in NOPOWER spec so the correct assigned class will not be destroyed.
Details of issue 1:
When actual Tinrush_PD<25msec and transitioning from POWER_DELAY to NOPOWER state due to VPD<VOff_PD, sets nopower variable to TRUE.
nopower variable=TRUE will lead to bypassing tpowerdelay_timer (80msec) when returning back to POWERED through INRUSH and POWER_DELAY states which will lead to PD overloading the PSE which is still in INRUSH state. (The 25msec number is due to the fact that we are going through INRUSH state twice in the above scenario)
This scenario happens whenever Vpd is lowered below Voff_pd in POWER_DELAY or POWERED states, causing a transition to NOPOWER state, then raised above Von_pd (regardless of the time VPD was below Voff_pd).
In the case where Tinrush_PD = 0 to 25ms, then the PD state-machine will do the transition from INRUSH to POWER_DELAY to NOPOWER to INRUSH to POWER_DELAY to POWERED in 2xTirush_PD.
This is a violation of Tdelay, which is minimum 80ms and may overload PSE  by PD during INRUSH.
Same issue in dual-signature PD state machine.
Details of issue 2:
In the NOPOWER state, the assignment "pse_power_level <==8" will cause PD to have pse_available_power=8 even if originally prior to getting to NOPOWER state is was lower than 8.
As long as VPD>VReset_th, PD remembers its data. In the arguments why we add it in the past, it was claimed that PD may think that we have additional class event when transitioning from NOPOWER to INRUSH again. This argument seems not correct since PD required by spec to lock itself to ignore additional counts after first time going through inrush. Any way, we have big hole here.
Regarding PDs that doesn't lock class event counting, they are not compliant. I understand that we want to support this case in the field as well so we need to make the use of pse_available_power=8 optional as function if we lost the data or not i.e. compliant PDs will not have to do it otherwise they may go to overload conditions while they behaves correctly.
In addition, we need to add text that explains that the NOPOWER state was meant to be use for abnormal use cases and not as the typical behaviour otherwise we by pass the mandory requirements of the spec.
Bottom line: We have tried to allow supporting non-compliant PDs or PDs that their behavior is not defined by making the state machine to support those PDs but on the way we create problems that compliant PDs doesn’t have and we force them to behave in noncompliant way by violating other spec requirements.
Below is proposal to support those PDs without creating problems to PDs that behaves correctly.
Proposed Remedy:
[Allows the option to go to NOPOWER but not force it. This proposal is different than my previous proposal to Lennart and Tamir when I discuss the problem with them earlier]
1.  In the exit from POWER_DELAY to NOPOWER and in the exit from POWERED to NOPOWER, change the condition from VPD < VOff_PD to (VPD < VOff_PD)*go2nopower.
2. Add the new variable  go2nopower:
Implementation specific variable that indicates if PD will go to NOPOWER in case VPD < VOff_PD during POWER_DELAY or POWERED.
FALSE  PD will not  use NOPOWER in case VPD < VOff_PD during POWER_DELAY or POWERED
TRUE   PD will use NOPOWER in case VPD < VOff_PD during POWER_DELAY or POWERED
3. Repeat only steps 1 for dual-signature PD in page 190 for the above states.
4. [This solution allow not using   pse_power_level <==8 in case PD didn't lost its data or change its data during the transition to POWER_DELAY through NOPOWER)]
Append the following text to the definition of nopower variable:
"If pse_power_level data was not lost or changed in the event of transitioning to POWER_DELAY through NOPOWER, the assignment  pse_power_level<==8 may not be implemented in NOPOWER”
Darshan Yair
Chief R&D Engineer
Analog Mixed Signal Group
Microsemi Corporation
1 Hanagar St., P.O. Box 7220
Neve Ne'eman Industrial Zone
Hod Hasharon 45421, Israel
Tel:  +972-9-775-5100, EXT 210.
Cell: +972-54-4893019
Fax: +972-9-775-5111