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

Re: [802.3_4PPOE] Class Probe Presentation Review



Agree.

Yair

 

From: Lennart Yseboodt [mailto:lennartyseboodt@xxxxxxxxx]
Sent: Saturday, September 2, 2017 10:36 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Class Probe Presentation Review

 

EXTERNAL EMAIL

Hi George,

This is the definition of pse_reset:
Inline image 1

I don't see how we can interpret "implementation-specific reasons that require reset" to mean anything other than "whenever the PSE wants".

What we can probably agree on, is that it is fully OK for a PSE to transition back to IDLE at any time it wants.

We need a mechanism for that. I feel pse_reset is that mechanism.

If others don't see it that way, we should add another variable that allows flipping back into IDLE at any time.

Or change the definition of pse_reset such that it is clear this variable may be used for this purpose.

My specific objection to the IDLE arc in Heaths proposal is that it introduces a new variable, which has no other purpose than to steer the state diagram to IDLE when it reaches a specific state. Having one such construct sends the message that returning to IDLE is not possible, without an explicit arc.

It doesn't matter HOW you get to IDLE, as long as it is allowed to go there no ?

Let's use the most concise/generic way please.

Kind regards,

Lennart

 

On Sat, Sep 2, 2017 at 8:00 PM, George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:

Yair –

While I agree that we should not be making arcs for all POSSIBLE re-entries to the IDLE state, we should reserve the pse_reset path for ‘implementation specific’ entries, as it is described in the variable.

We SHOULD depict the paths for options specified in the standard in the state diagram – otherwise while there may be a path to interoperable behavior, if we don’t specify that behavior in the state diagram, the behavior described in the state diagram is incomplete.

 

Are there so many of these options specified in the standard that the state diagram becomes overly complex – I don’t think so, and I certainly hope not.  That would be another issue in itself.  Not capturing behavior specified in the standard in the state diagram isn’t the solution.

 

-george

 

From: Yair Darshan [mailto:YDarshan@xxxxxxxxxxxxx]
Sent: Saturday, September 02, 2017 6:01 AM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>; STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_4PPOE] Class Probe Presentation Review

 

George,

 

I agree with Lennart that “Arcs to IDLE should indicate mandatory transitions to IDLE”. The rest should be done by global pse_reset as we did for the high-level state diagram. Otherwise we will have incomprehensible state machine (return to IDLE from almost every state).

 

For the dual-sig state diagram there is a comment that addresses it i.e. by adding global pse_ready_pri/sec. See darshan_04_0917.pdf attached that addresses comments i-198 and i-269.

 

Regards

Yair

 

 

From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Friday, September 1, 2017 6:08 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Class Probe Presentation Review

 

EXTERNAL EMAIL

Lennart –

I’m not sure I agree with you.  While you could go with a ‘generic’ return to IDLE for any one of a number of things,

if the standard is specifying a particular optional behavior that exits a specific state on a specific condition and returns to IDLE due to that, it should be specified as an arc.

 

There is a difference between ‘optional behavior’ and ‘proprietary’ or ‘implementation-specific’ behavior which is still compliant to the standard. 

 

Where I am uncertain is how that return to idle is specified currently in the state diagram.

Right now, I see (page 125, top level diagram) a return from the test-states, and two entries – one from the disabled state, and one conditional on (pse_enable = enable) * (pse_reset + iclass_lim_det + error_condition)

 

If you are referring to entry into IDLE by means of pse_reset, then the definition of pse_reset wouldn’t imply using it for something like this.  While it allows for “implementation-specific reasons require reset of PSE functionality”, that isn’t what Heath is specifying.

-george

 

From: Lennart Yseboodt [mailto:lennartyseboodt@xxxxxxxxx]
Sent: Friday, September 01, 2017 1:58 AM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Class Probe Presentation Review

 

Hi Heath,

1. There is no need to add arcs to IDLE for optional behavior.

The PSE state diagram is at any time allowed to return to IDLE.

As such, the variable option_class_probe_only and the arc from CLASS_PROBE to IDLE are redundant.

2. Your logic for option_class_probe_only coming out of CLASS_PROBE is inverted to the meaning you assigned to it.

I really object to adding optional arcs to IDLE, since if we do this once, we open the floodgates to get arcs from every state to IDLE.

Arcs to IDLE should indicate mandatory transitions to IDLE.

 

Kind regards,

Lennart

 

 

On Fri, Sep 1, 2017 at 2:33 AM, Heath Stewart <00000855853231d4-dmarc-request@xxxxxxxx> wrote:

All,

 

As promised we are providing baseline for out class probe presentation from Berlin. Both are attached; root presentation and baseline.

 

It should be noted that Yair has also identified additional reasons that class probe is useful. I have not yet modified the "justification" portion of the presentation to include his comments - but will. Yair has been very collaborative on this topic.

 

Please consider this class probe proposal - it has a couple minor changes from what some of you have seen over the last few weeks. Also note that Yair has reflected on my approach and is offering another CLASS_PROBE baseline alternative. 

 

We've (David and I) tried to keep the scope as narrow as possible in this change as to limit changes to the draft.

 

  1) Allow class probes to determine class/detect of SS and DS PDs

  2) Limit power dissipated

  3) Ensure power is not applied after class probe by returning to IDLE_XXX

        a) IDLE_XXX will return to main IDLE using existing logic

 

We've been hesitant to adopt Yair's proposal in preference to this proposal:

 

  4) Other proposal allows asynchronous return to IDLE_XXX. This can have unintended consequences for tpon and detection sequences becoming unbounded eg you can do whatever you want.

  5) Other proposal creates a CLASS_PROBE(eg short,short,short)->CLASS_RESET->(Long,short,short)->CLASS_RESET->(Long) class event path that is not desirable.

 

  6) I'm not sure it is useful to have option_class_probe_pri/sec differentiation. If the room feels differently we'll be open to the consideration.

 

Enjoy,

 

--

Heath Stewart
Design Center Manager, Mixed Signal

Office   (805) 560-7658
Mobile  (805) 895-0499
Websites      
analog.com, linear.com

Linear Technology is now part of Analog Devices.  Learn more.

 

Inline image 2