Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Chris, The question was mainly for
“staggered” when used for dual-signature
PDs. Regarding staggered for single-signature it is less important since we are limited by Tpon, but yet the term
“staggered” need to be well defined in
both cases and they have to have the same definition. Please see below. Yair From: Chris Bullock (bullock) [mailto:bullock@xxxxxxxxx]
EXTERNAL EMAIL 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”.
Yair: This is clear, but it should not be the only possibility for staggered. See my previous mails about it. The original intent and definition of
“staggered”
was to do detection of the 2nd pairset without overlapping with detection of the 1st pair. This means any time after the 1st pair detection to before power on, during power on and after power on for dual-signature PD. The use
of 4PID concept only will determine the must timing between them. For DS, Sequence 0, the detection/class has no enforced timing relationship.
Yair: How you would be interpreted
“staggered”
for “Sequence 1 for dual-sig PD? “Parallel” just means that they happen pseudo-concurrently, but not necessarily sync’d. Yair: This is fine but where this is defined?
I suggest defining “parallel” and “staggered” in CC_DET_SEQ variable definition in page 109. I plane that it will be part of darshan_13_0917.pdf that touches the
comments where the intent is not clear. What about: “parallel detection is when detection of both pairsets are done within Tdet. “staggered detection is when the detection of the secondary starts after detection on the primary ends”. This definition is a bit overlaps the 1st definition
but technically is correct and covers all cases explicitly. Yair 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 |