| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Slight update and change on the proposed solution… discussing these offline we noticed we didn’t really do what was needed. When I started talking about it with Brett, we realized that all the originally proposed change did was send you
back to SILENT allowing SLAVE SILENT to take as much time as it wanted – which was the original problem. So, what the solution needed to do was not re-enter SILENT, but force a transition to TRAINING. Thank you, Brett for bringing this up. The key point is to make it clear that you could not dwell in slave silent for longer than 40msec. Brett and I had a difference of style – he would write a text requirement, along the lines of ‘A
compliant PHY shall not dwell in SILENT for longer than 40msec’, where as I would put the behavior in the state diagram with a timer. Either works, but I prefer having it all in the state diagram, as it puts everything in one place, doesn’t make the diagram overly complex, AND is consistent with 802.3 state diagram rules. This timeout is not only forces the startup along, but fixes some assumptions in the diagram and makes compliant behavior more observable. Really all you need at the slave is a good clock to move to training and converge the echo canceller,
where you CAN converge equalizers if you want to do it that way. Good SNR is one indicator of that, but it isn’t actually required for a good clock. Why someone wouldn’t go ahead and force loc_SNR_margin to OK if they were going to do that, is a mystery
to me, but you could have a slave receiver which only gets good SNR after a longer training, achieved after the EC has converged. As far as observability is concerned, you really can’t observe the local SNR indicator going to OK, and as the diagram is, the
slave could sit there until the link_fail_inhibit_timer kicks in, and you’d have no idea why. However, you can observe the amount of time the SLAVE spends in silent, and it shouldn’t get stuck in silent. So, what all this really does is tell the designer that a compliant PHY cannot expect to spend more than 40msec in SILENT. Making this change makes it clear to any implementer that the master needs to signal en_slave_TX within 40msec and cannot use too much time for itself or it will get overridden by the timer.
If you design based on that, you will get kicked out of SILENT and have to move on, giving the link partner a chance to converge on your transmitted signal. At that point, for interoperability, it is up to you to either converge or not.
You don’t have an out which allows you to run with a link partner of YOUR design spending longer in SILENT, but cheating a link partner of a different vendor out of enough time in TRAINING. With this change, the response would now be: P154 L39 Add the following definitions to 149.4.4.2, before minwait_timer: max_silent_timer A timer used to determine the maximum amount of time the PHY Control stays in the SILENT state. This timer shall expire 40 msec after being started. In Figure 149-33 Insert “start max_silent_timer” to the SILENT state Add additional condition for exiting SILENT state and entering the TRAINING state, OR'ed with the existing conditions: “max_silent_timer_done” (append "+ max_silent_timer_done to " ((config = MASTER) +(config = SLAVE * loc_SNR_margin = OK *en_slave_tx = 1)) * minwait_timer_done ) Editorial license to conform to IEEE 802.3 style. From: George Zimmerman These comments are about making sure our state diagrams result in interoperable 100ms startup. We had a problem which showed up in 10GBASE-T interoperability plugfests where we didn’t have times enforced for the SILENT and TRAINING states,
and one vendor might take longer than another in the SILENT state, leaving the other without enough time to train in the other state. This hole was plugged by a ‘recommended’ timing put in in 802.3az, but that was a patch – we shouldn’t repeat it. So, the gist of these comments are the same – incorporate the 100msec timing objective into the timing in the PHY control state diagram. Initially, comment 169 proposed 2 timers, and we worked a solution around that (you’ll see it in the proposed responses), BUT, just after Natalie posted, Alireza and I had a quick discussion. Alireza pointed out that we already have the
link_fail_inhibit_timer, which kicks us out of startup (both in Figure 149-32 and in Figure 98-7 if auto-neg is used). So, we really only need one timer, for the silent state (which really only applies to the slave if you look at the state diagram). That
makes things really easy, as opposed to the published solution, which has 2 timers, not really so hard, but definitely a bigger change, and one with a redundant timer & transition. With this change, the response would now be: P154 L39 Add the following definitions to 149.4.4.2, before minwait_timer: max_silent_timer A timer used to determine the maximum amount of time the PHY Control stays in the SILENT state. This timer shall expire 40 msec after being started. In Figure 149-33 Insert “start max_silent_timer” to the SILENT state Add arc exiting SILENT state and re-entering SILENT state with condition “max_silent_timer_done” Editorial license to conform to IEEE 802.3 style. I’d like to hear any feedback so we can have a consensus position. -george George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications 310-920-3860 To unsubscribe from the STDS-802-3-NGAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1 |