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 Lennart and all,

Please see my response below.

Yair

 

From: Lennart Yseboodt [mailto:lennart.yseboodt@xxxxxxxxxxx]
Sent: Sunday, October 22, 2017 4:35 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx; Yair Darshan <YDarshan@xxxxxxxxxxxxx>
Subject: Re: [802.3_4PPOE] PD state machine issues.

 

EXTERNAL EMAIL

Hi Yair, all,

 

A few things are getting confused here.

 

The NOPOWER state was added to provide permissible behavior for PDs that are in a powered condition, and then the voltage drops to in the Voff range.

Yair: I believe that if we are in a powered condition, going down below VOff_PD and the above Von_PD is not a compliant behavior since during powering mode PD is required by design to limits its power to PClass_PD so no reason voltage will go down and PSE is not allowed to go below Vpse min for longer time then specified by the transients condition where PD is still required to operated.

I understand the need to support legacy PDs and newly designs for 802.3bt that have some realistic issues however we need to do it in a way that doesnt force compliant PDs to violate existing other critical requirements that a compliant system should not violate.

 

The Type 2 state diagram also provided behavior for this condition, however that was an unintended side effect of the definition of a variable.

That state diagram says that as soon as the voltage is outside of the VPort_PD range, the PD must return to IDLE.

Yair: This behavior make sense and may be with wider scope as long as we are not creating new issues. See above.

If the voltage then was again in the VPort_PD range, the PD would again end up in the MDI_POWER1 state, but was limited to Class 3 power, even if it had Class 4 power originially.

Yair: Agree, but still doesnt solve the issues caused by the NOPWER state.

In short: this state diagram was so broken, nobody implemented it that way.

Yair: Nobody didnt implement it not because it was broken. Vendor did whatever they want since it was uncompliant behavior or at least implementation specific behavior that we shouldnt define in the first place. We have PSE operating range and we have PD operating range. What happened inside those ranges is a compliant behavior what it outside this range should be left to the vendor to decide.

Currently, the state machine cause violating the 80msec timer use and causing overloading the PSE during the 1st 50msec range actually the first 25msec range and also cause overload due to the assignment pse_power_level=8 in the NOPOWER state.

 

Some PDs chose to indeed freeze the class event counter in case of voltage dips, others "kept counting".

Yair: Those who kept counting are not compliant and if this is not clear we need to explain and clarify it in the spec so we dont need further states to handle it. And if we want to support those PDs anyway, we need to do it in an optional way that doesnt force PDs that was designed correctly to use this behavior of NOPOWER when they dont need it.

If the addition of NOPOWER was error free then no issues with it.

In order, not to make otherwise compliant PDs non-compliant, the NOPOWER state sets the class counter to the highest possible value.

Yair: It will make it non-compliant. Here is the use case.

  1. PD was powered. The required class was 8. The assigned class was 6. Pse_avail_pwr=6.
  2. Now we go to NOPOWER. In NOPWER we assigned pse_power_level=8. PD that did everything correctly remembers its data and lock its class event counter befor going to INRUSH etc. Now pse_power_level=8. PSE didnt change its Pse_avail_pwr=6, as a result a good compliant PD will go to overload.

 

What we absolutely must prevent though, is that in any form of normal operation the PD state diagram passes through the NOPOWER state, because that completely breaks classification.

A number of problems have now been discovered:

 

  1. PDs that use too low a value for the tinrush_pd timer can pass through NOPOWER because the capacitor is still being charged.

Yair: This is additional problem. Now we have 3 problems:

  1. bypassing the delay timer when actual Tinrush is less then 25msec causing overload.
  2. Overload caused by the assignment to value 8 in the pse_power_level parameter.
  3. PDs that use too low a value for the tinrush_pd timer can pass through NOPOWER because the capacitor is still being charged

2. Overload and transients are all currently events that can pass a PD through NOPOWER, depending on the value that is chosen for VOff_PD.

Yair: Correct but this fact creates the additional problems listed above.

Andreas' solution to remove the arc from POWER_DELAY to NOPOWER fixes issue 1, but as you point out, creates a small hole in the behavior in case voltage dips during those first 80ms.

Yair: Yes. Andreas proposal fixes issue (a) in the list above.

It doesnt fixes issue (b) which is not a small hole since it forces a compliant PD to be exposed to overload.

 

What I would suggest is the following:

 

  1. Change the definition of the tinrushpd_timer such that it runs precisely 50ms. That way, a PD either has reached a stable VPD, or it fails inrush requirements when it passes to POWER_DELAY.

Yair: Do you mean to make it 50msec min and 60msec max? How you can set it to precisely 50ms..??

  1. Change Voff_PD to be a range from 30V to 36V. That means that under overload and transient conditions, the PD will stay in the POWER_DELAY or POWERED state and does not pass through NOPOWER.

Yair: This is problematic. You may narrow the Hysteresis range of existing PD chip designs. We need to ask all PD chip vendors.

 

I think that fixes all of the issues without creating new ones.

 

Yair: I propose the following fix options:

Option 1:

1. Delete the exit from POWER_DELAY to NOPOWER. [This will resolve the issue of bypassing the 80msec timer.]

2a. Delete the assignment pse_avail_pwr<==8 from the NOPOWER state OR

2b) add the following text to the variable pse_power_level definition: "When in NOPOWER state, the assignment to the value 8 is optional."

"

Option 2:

1. Make the two inputs to NOPWER optional and pending in implementation specific variable. Change the condition of these two inputs to (VPD<VOff_PD) *option_nopower.

2. Add the variable option_nopower to the variable list.

option_nopower

Implementation specific variable that indicates if PD will go to NOPOWER in case VPD < VOff_PD during POWER_DELAY or POWERED.

Values

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.

--- Yair ----

 

Lennart

 

On Sun, 2017-10-22 at 08:45 +0000, Yair Darshan wrote:

Hi Andrea,

Thanks, please see below.

Yair

 

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.

 

EXTERNAL EMAIL

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

 

Regards,

Andrea

 

 

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.

Yair

-------------

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:

go2nopower

Implementation specific variable that indicates if PD will go to NOPOWER in case VPD < VOff_PD during POWER_DELAY or POWERED.

Values

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