| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
The scenario you describe would be triggered by an event where the remote link partner sends a frame with (a) a change in the request to “hold” and (b) a change
in coef_sel, both with respect to the previous frame. This enables two transition arcs in series. If the changes are in different frames, then the transitions spaced accordingly. As stated in 136.8.11.7.5, “The notation used in the state diagrams follows the conventions of 21.5”. In 21.5 we find that “The actions inside a state block execute
instantaneously”. ENCODE_STS is defined to encode the status field but not to transmit a frame. So the intermediate status does not necessarily get transmitted before the second transition occurs. In practice, implementations will have some processing time inside states, and the intermediate status may be transmitted for some time. I would say that the two possible behaviors of the responding (local) device in this scenario are both compliant. If this creates ambiguity that the link partner
can’t handle, then it should avoid triggering this scenario (and frankly I don’t see why it should occur at all). Do you see a problem with any of these behaviors? </Adee> From: Adrian Butter [mailto:adrian.butter@xxxxxxxxxxxxxxxxxxx]
Hi Folks, I've been mulling over what appears to me to be a point of ambiguity in 802.3cd, & I'd like to solicit some feedback from other task force members about what "standards-compliant" behavior is expected to be in this case. The scenario involves
the link training process, and specifically is related to Figure 136–9—Coefficient update state diagram, when the local side in the NEW_REQUEST state. If a subsequent training frame receiver from the remote side specifies coef_req=hold AND coef_sel^=k, the
behavior of the Coefficient Update FSM would be to first transition to WAIT (with new coef_sts output by the ENCODE_STS function), & thereafter immediately transition to NEW_INDEX (due to coef_sel^=k, & with the new k value output by the ENCODE_STS function).
However, since there is no specified interlock between FSM transitions (with resulting status updates) & training frame transmission, is it possible the ENCODE_STS update captured in the WAIT state will not be transmitted, but instead be overwritten by the
ENCODE_STS update captured in the NEW_INDEX state? Or is it expected the "intermediate" ENCODE_STS update during WAIT will appear in at least one transmitted frame, followed by the "final" ENCODE_STS update in NEW_INDEX? Seems to me the intended behavior of the FSM in this case would be to bypass the "intermediate" status value, & instead transition directly from NEW_REQUEST to NEW_INDEX and transmit only the "final" status value. If this is the case, seems
an update to the Coefficient Update FSM is in order. Thoughts...? Thanks & Regards, Adrian S. Butter (adrian.butter@xxxxxxxxxxxxxxxxxxx) To unsubscribe from the STDS-802-3-50G list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-50G&A=1 To unsubscribe from the STDS-802-3-50G list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-50G&A=1 |