|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Actually, I think you have the interpretation of “implementation-specific reasons that require reset” correct in principle (it gives permission to do that whenever the PSE wants), but incorrect in terms of function in a standard.
The term “implementation-specific” in a standard is generally code for “outside the scope of the functionality defined in this standard”. Things like determining whether a PHY receiver is OK are implementation specific, as well as general fail-safes like pse_reset.
If I read “implementation-specific reasons that require reset” to be “whenever the PSE wants”, then, there is no reason for ANY other entry into IDLE than a strict pse_reset, and the result is that the only way the state diagram can inform us when a behavior specified in the standard requires transition to IDLE is by adding a state which sets pse_reset. In that case, the IDLE state has NO shown input states, and frankly, while simple, it is also clouding the functionality described in the standard.
I don’t see you wanting to do that.
Your concise/generic way has fewer words, but it does so by failing to properly describe specified behavior (even optional behaviors need to be specified) in the standard.
Now, if the issue is that the behavior itself could be accomplished without a transition to IDLE or with a different transition to IDLE, that is another story and we then have to see what that looks like – BUT, if the defined (even optional) behavior in the standard requires a transition from a specified state to IDLE, that arc and the conditions of that ARC should be shown. [Note, if the behavior is a generic escape from any state into the IDLE, that would probably be handled better by the pse_reset, but that does not appear to be the defined situation].
As far as “conciseness”, I think you’re mistaken – that horse left the building a long time ago. Right now you have at least the following paths (21 of them?) into IDLE in Figure 145-13:
from DISABLED or TEST_MODE or TEST_ERROR_PRI or TEST_ERROR_SEC or TEST_ERROR_BOTH: Pse_enable = enable:
Generic from anywhere: (Pse_enable = enable) * (pse_reset+iclass_lim_det+error_condition)
from START_CXN_CHCK_DETECT or START_DETECT: Tdet_timer_done
from SISM_START: Alt_done_pri*alt_done_sec
from CXN_CHK_EVAL: (sig_type=invalid) + tcc2det_timer_done + tdet2det_timer_done
from BACKOFF: Tdbo_timer_done
from DETECT_EVAL: ((pse_alternative = both) * ((det_temp = only_one) * (sig_pri ≠ valid) +(det_temp = both_neither) * (sig_sec ≠ valid) + (((CC_DET_SEQ = 0) + (CC_DET_SEQ = 3)) * (det_temp= only_one) * tdet2det_timer_done)) + (pse_alternative = a) * (sig_pri ≠ valid) +(pse_alternative = b) * (sig_pri = open_circuit)
from CXN_CHK_DETECT_EVAL: (sig_type = invalid) +(sig_type = single) *((sig_pri ≠ valid) +(sig_sec ≠ valid)) +(sig_type = dual) *(sig_pri ≠ valid) *(sig_sec ≠ valid)
from CLASS_EV2: tcle2_timer_done * (pd_class_sig ≠ 4)
from CLASS_EV4 or CLASS_EV5: tcle3_timer_done * (pd_class_sig ≠ temp_var)
from POWER_UP: tpon_timer_done
from POWER_ON: power_available * tmpdo_timer_done * !(error_pri + error_sec)
from POWER_DENIED: UCT
from SEMI_PWRON_SEC: !error_sec * power_available * tmpdo_timer_done
from ERROR_DELAY: ted_timer_done + option_detect_ted
However, this is right. If it is a defined behavior in the standard, then the arc should be shown.
Let’s deal with the variable, if that is the issue. I think you’re talking about “option_class_probe_only”, right? If you’re going to have a defined optional behavior, it is usual to have a variable that says that option is enabled and active. This happens all over 802.3. I don’t know how else to do it. The definition of that variable (“This variable indicates if the PSE should return to IDLE following the completion of do_class_probe.”) I might make a little different to reflect what it is functionally doing, rather than what state transition it makes. Something like ““This variable is set if the PSE is only to perform a class probe, and not proceed with the classification state diagram.” (heath or others – please refine – the idea is to say what the implemented option is, the state diagram will show that the variable causes a return to IDLE. The definition tells the reader WHY).
From: Lennart Yseboodt [mailto:lennartyseboodt@xxxxxxxxx]
This is the definition of pse_reset:
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.
On Sat, Sep 2, 2017 at 8:00 PM, George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote: