Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[802.3_50G] Fwd: [802.3_50G] Link Training Coefficient Update State Diagram Ambiguity...?

Thanks Jeff & Adee for your responses & confirmation of FSM behavior under this circumstance. Some of the folks on my team were asking me about this scenario - And ultimately the root cause of confusion was whether or not updates output by the ENCODE_STS function are always transmitted to the link partner. My conclusion was that there is no transmission requirement, & your confirmation of this point is very helpful. I guess that based on this scenario & the question I received, is it worth considering adding a note to the definition of ENCODE_STS (appearing in 136.8.11.7.2 Functions) that such output may not always be transmitted...?

Thanks and Regards,

---------- Forwarded message ---------
From: Ran, Adee <adee.ran@xxxxxxxxx>
Date: Tue, Oct 2, 2018 at 7:20 AM
Subject: RE: [802.3_50G] Link Training Coefficient Update State Diagram Ambiguity...?
To: Adrian Butter <adrian.butter@xxxxxxxxxxxxxxxxxxx>, STDS-802-3-50G@xxxxxxxxxxxxxxxxx <STDS-802-3-50G@xxxxxxxxxxxxxxxxx>


Hi Adrian,

 

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]
Sent: Thursday, September 27, 2018 20:39
To: STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: [802.3_50G] Link Training Coefficient Update State Diagram Ambiguity...?

 

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,

 

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