Hi Chris and Lennart,
It should be the objective off all PSE system vendors that spec should be correct and will support all CC_DET_SEQ as defined by this variable definition. This is currently not the case.
It is not sure that once we select CC_DET_SEQ option, we stick to it forever. As a result, we must ensure that all CC_DET_SEQ=0, 1, 2 or 3 in the state machine will be in sync with CC_DET_SEQ variable definitions.
I saw through my simulations that there are no issues with CC_DET_SEQ=0,1,2 regarding the transition from IDLE_SEC to START_DETECT_SEC. I saw the problem only in CC_DET_SEQ=3.
-The inputs from Chris just confirmed the interpretation of what we saw in the state machine but it doesn’t solve the problem when CC_DET_SEQ=3 when it used.
-What I see missing is to be able to do
“staggered detection” in any CC_DET_SEQ that allows staggered detection without any limitations if power is applied to primary or not. This condition is not relevant to any CC_DET_SEQ unless you
want to do 4PID without using the 3-finger technique.
-Lennart: Yes to,
“I would also assume that this staggered behavior is intentionally used to verify 4PID for dual-signature PDs ?” but what if I want to use CC_DET_SEQ=3 and want to use the other 4PID method which uses 3 class-events? This is the issue that is not covered.
As a result, we will not break the 4PID mechanism of this sequence since per my proposal we can do the following:
(!pwr_app_sec * pwr_app_pri) +
( (CC_DET_SEQ=3) *
option_probe_alt_sec * !det_start_pri * !det_once_sec )
+ (class_4PID_mult_events_sec*(CC_DET_SEQ=3) * !det_once_sec * det_once_pri )
The fisr part:
(!pwr_app_sec * pwr_app_pri) covers the 4PID method when doing detection on secondary when power is on at the primary. This is existing today.
The 2nd part: ( (CC_DET_SEQ=3) *
option_probe_alt_sec * !det_start_pri * !det_once_sec ) covers various cases when CC_DET_SEQ=3 is chosen. This is existing today.
The 3rd part is what is missing when you want to use (CC_DET_SEQ=3) AND you want to use the other 4PID method:
+ (class_4PID_mult_events_sec*(CC_DET_SEQ=3) * !det_once_sec * det_once_pri )
Yair
Yair
From: Lennart Yseboodt [mailto:lennartyseboodt@xxxxxxxxx]
Sent: Friday, September 1, 2017 9:33 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] PSE state machine - Stuck in ENTRY_SEC and related issues.
EXTERNAL EMAIL
Hi Chris,
Thanks for making that clear. This confirms that a different interpretation of 'staggered' and 'parallel' lies at the base of this request. In essence, what Yair wants to do is possible using sequence 0 or 1.
What we may want to do is expand a bit the explanation of CC_DET_SEQ 3, because it misses this key bit of information that the second pairset can only proceed with detection after the first is powered on.
I would also assume that this staggered behavior is intentionally used to verify 4PID for dual-signature PDs ?
So, if we allow detection to happen before the first pairset of powered on, we'll break the 4PID mechanism of this sequence ?
Kind regards,
Lennart
On Fri, Sep 1, 2017 at 6:08 PM, Chris Bullock (bullock) <bullock@xxxxxxxxx> wrote:
Hi Lennart,
For DS, Sequence 3 enforces that detection on secondary pairset does not occur until after the primary pairset is powered. That is what is meant by “staggered”. For DS, Sequence 0, the detection/class has no enforced timing relationship. “Parallel” just means that they happen pseudo-concurrently, but not necessarily sync’d.
Thanks,
Chris
From: Lennart Yseboodt [mailto:lennartyseboodt@xxxxxxxxx]
Sent: Friday, September 01, 2017 4:04 AM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] PSE state machine - Stuck in ENTRY_SEC and related issues.
Hi all,
Question to the folks who came up with the various CC_DET_SEQs.... what was the design intent of sequence 3 ?
I have the feeling there is a difference in interpretation of what is meant by "staggered" and "parallel".
For sequence 0, it is stated that "Connection Check is followed by staggered detection for a single-signature PD and parallel detection for a dual-signature PD."
Does 'parallel detection' imply that the detection has to happen precisely at the same time ?
Or can you do detect on pri, then detect on sec, and then proceed to classification ?
I would assert that the latter behavior is allowed by the state diagram.
Even if do_detect_pri and do_detect_sec are called at the same time, nothing forbids one of these functions to wait a bit until the other is done.
Kind regards,
Lennart
On Fri, Sep 1, 2017 at 3:10 AM, Heath Stewart <00000855853231d4-dmarc-request@xxxxxxxx> wrote:
Yair,
Thanks for your presentation. There are some interesting issues you identify in comments 251 and 252. We have reflected on your proposal and have created a proposal to address these issues.
Thanks,
-Heath Stewart
On Thu, Aug 31, 2017 at 3:12 AM, Yair Darshan <YDarshan@xxxxxxxxxxxxx> wrote:
Hi all,
Please review the remedy for this topic.
It handles the following:
1) Preventing to be stuck in ENTRY_SEC when detection in primary has failed or tdet_timer_pri is done when transitioning from ENTRY_SEC to
START_DETECT_SEC.
2) The transition from IDLE_SEC to START_DETECT_SEC when CC_DET_SEQ=3 is not fully covered for the staggered detection timing range.
3) Both (1and 2) prevents doing cycles of detection and classifications until host decides to power on the port.
I’ll appreciate your inputs.
Regards
Yair
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
E-mail: <mailto:ydarshan@xxxxxxxxxxxxx>.
--
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.
