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 Andrea,

Thanks, please see below.



From: Andrea Agnes [mailto:andrea.agnes181@xxxxxxxxx]
Sent: Friday, October 20, 2017 6:22 PM
To: Yair Darshan <YDarshan@xxxxxxxxxxxxx>
Cc: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: 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.

Yair: I understand that this was one of the objectives however right now what we add creates the two problems that I show, cause violating of the spec of compliant PDs.

Please note that compliant PDs will not need to use the exits to NOPOWER due to the fact that PD voltage is not allowed to consume more than Pclass_PD so there is no reason that VPD will go below VOFF_PD and PSE is not allowed to reduce its output voltage below operating voltage during normal operation except transient overload or short circuit conditions which in this case we mat shut off the port or in case of transients which PD is required to work. The addition of NOPOWER was added to handle PDs that from some reason their input voltage fall below Voff and then raised above Von which in the real world may happen and during the transition from Voff to Von the PD counts additional class event continue to count   (which compliant PDs doesn’t allowed to do, since the class event counter should be locked after the first time going to INRUSH) and people thought that we have aslo to handle this case.

So please consider how we address the issues of violating the 80msec timer and causing overload condition after entering the NOPOWER state. We have to fix this.

The introduction of a further variable that regulate a possible (or not) use of that way is not my preferred approach.

Yair: Please explain why if this is optional and compliant PDs doesn’t have the problems that cause PD to go to NOPWER.

Maybe is possible to evaluate to remove the exit from POWER_DELAY to NOPOWER.

Yair: We thought about this solution and it will fix part of the problem (the first issue). The issue with this solution is: If you believe that we should address the case when VPD<VOFF, you should address this in all the states that the PD is powered including POWER_DELAY. Otherwise how you explain that your are doing in in POWERED and not in POWER_DELAY?

The proposed solution fix this problem by either you address is with the risk of having the two issues but then we don’t care since any way it was non-compliant behavior. Or chose not to use this option and then there is no issues.


While the point related to the 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.

Yair: It is OK by me to address the pse_power_level <==8  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