Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Chris, I am sure that it was the original intention in the SM for CC_DET_SEQ=3 but it doesn’t
cover all possibilist of CC_DET_SEQ=3 especially the popular ones that I am sure you want to support as well. The definitions of CC_DET_SEQ variable in page 109 line 38 doesn’t
say that “staggered” in CC_DET_SEQ=3 means
that it is limited to the case that one of the pairs need to be on while the other pair is donning detection. This was never the only intent. If this was the intent, how should I interpret
“staggered” in CC_DET_SEQ=1? Moreover, what if you want to POWER_ON both pairsets with minimum time delay between each pairsets and not wait to one pairset to be ON and only then to do detection on the
other? This is a PSE system objective that PSE vendors need not to overlooked. Regards Yair From: Chris Bullock (bullock) [mailto:bullock@xxxxxxxxx]
EXTERNAL EMAIL Hi Lennart, CC_DET_SEQ=3 is supposed to transition from
ENTRY_SEC to IDLE_SEC, and should not transition to START_DETECT_SEC until
pwr_app_pri is true. That is the original intention. Thanks, Chris From: Lennart Yseboodt [mailto:lennartyseboodt@xxxxxxxxx]
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]
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 Cell:
+972-54-4893019 E-mail: <mailto:ydarshan@xxxxxxxxxxxxx>.
--
Heath Stewart |