| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Ragnar – I feel strongly that we should not put requirements on the setting of an indicator bit. If you need a requirement, put it on some identifiable behavior, rather than on the indication of a state. I would change the text as follows:
The follower sets timing_lock_OK to 1 when it has stable transmit clock, and otherwise timing_lock_OK is set to 0. The setting of timing_lock_OK value is implementation specific. The transmit clock should be such that timing_lock_OK is not set to 0 for more than 2ms during each training session.
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications
310-920-3860
From: Ragnar Jonsson <ragnar.jonsson@xxxxxxxxx>
Sent: Tuesday, July 14, 2026 1:14 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Discussion on comment #500
All,
I am not sure that we need the timing_lock_OK, but if we keep it, then I propose the following text:
The follower sets timing_lock_OK to 1 when it has stable transmit clock, and otherwize timing_lock_OK is set to 0. The setting of timing_lock_OK value is implementation specific, but is not set to 0 for more than 2ms during each training session.
The idea behind the proposed text is that timing_lock_OK should be set to 1 most of the training time, but may be set to 0 for a limited time. I would expect it to be most likely that we set timing_lock_OK to 0 just after the follower starts transmitting its training signal, but this assumption is not explicitly stated in the text above. The text does not have any shall statements, since the idea is that it is implementation specific, but we might consider "shall" for the maximum duration of timing_lock_OK set to 0.
Ragnar
On Mon, Jul 13, 2026 at 12:03 PM alireza razavi <alirezamajoomard@xxxxxxxxx> wrote:
Going this path opens the door for unnecessary complications because the timing is supposed to be locked in the half duplex and stay locked.is there any reason that we think phy may loose timing lock after half duplex?
The original comment was about removing this bit from the info-field exchange. Based on the definition, whenever this part of info-field is changed, phy has to transmit the bit so many times. This is an unnecessary extra delay. I don’t see any value while we already have a bit (loc_rcvr_status) that indicates the health of the leader receiver. loc_rcvr_status is well-integrated into our physical state machine.
Alireza
On Jul 13, 2026, at 2:40 PM, Peter vanDyck <00005eed8bd3e774-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Sure the definition by itself is fine.
Peter
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Monday, July 13, 2026 11:31 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Discussion on comment #500
Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guide to help you identify Phishing email.
I hear you – and see the issues you’re pointing out. The constraining of the messages though sounds like a different comment – something to make on a future draft. The nature of the information is what it is…. Not sure why you’d want to falsely represent timing lock is ok…
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications
310-920-3860
From: Peter.vanDyck@xxxxxxxxxxxx <Peter.vanDyck@xxxxxxxxxxxx>
Sent: Monday, July 13, 2026 2:15 PM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>; STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_ISAAC] Discussion on comment #500
My concern is e.g. 191.5.2.4.4 Message Field:
All possible Message Field settings are listed in Table 191–5 for the LEADER and Table 191–6 for theFOLLOWER. Any other value shall not be transmitted and shall be ignored at the receiver. The Message
Field setting for the first transmitted PMA frame shall be the first row of Table 191–5 for the LEADER and
the first or second row of Table 191–6 for the FOLLOWER. Moreover, for a given Message Field setting,
the next Message Field setting shall be the same Message Field setting or the Message Field setting
corresponding to a row below the current setting. When loc_rcvr_status = OK the Infofield variable is set to
loc_rcvr_status<5> = 1 and set to 0 otherwise.
To me that reads like any other Message Field (to me it is the whole row), is not permitted. That means a row where timing_lock_OK or loc_rcvr_status goes back to 0 is not possible.
Although I understand that loc_rcvr_status field is defined the same as your proposal for timint_lock_OK.
Thanks,
Peter
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Monday, July 13, 2026 10:56 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Discussion on comment #500
Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guide to help you identify Phishing email.
Yes, it isn’t an assumption – it is behavior. Timing lock can be lost after it has been required, and if it is, the bit flips from 1 to 0 (and hopefully back to 1 when it is reacquired again).
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications
310-920-3860
From: Peter vanDyck <00005eed8bd3e774-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, July 13, 2026 1:49 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Discussion on comment #500
Hi George,
is the assumption that timing_lock_OK could be lost after a “1” has already been transmitted to the link partner, and that loss would be transmitted again through the infofield? It’s not clear to me from the “is set to zero otherwise”.
Thanks,Peter
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Monday, July 13, 2026 10:34 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Discussion on comment #500
Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guide to help you identify Phishing email.
Ragnar – I was struggling with precise words for the implementation-specific nature of determining whether the follower was tracking... If you can provide some, I would be grateful.
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications
310-920-3860
From: Ragnar Jonsson <ragnar.jonsson@xxxxxxxxx>
Sent: Monday, July 13, 2026 1:17 PM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Discussion on comment #500
I agree with George's comment. I would expect the initial condition to be 0 (FALSE), and then transition to 1 (TRUE) when the follower has acquired the timing lock. Therefore it is more appropriate to talk about setting timing_lock_OK=1 when timing lock has been acquired and set to 0 otherwize. There should also be a statement about the implementation of the timing_lock_OK condition is implementation specific.
Ragnar
On Mon, Jul 13, 2026 at 8:18 AM George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:
William – I would rather suggest that we define the bit in the positive sense. Otherwise, if the FOLLOWER never acquires the timing reference, under your definition, timing_lock_OK would be set to 1, because you can’t lose what you never have. This is, however, not what I think we want. Also, style manual says you spell out zero & one, and I believe we have another comment to not put LEADER and FOLLOWER in all caps…
Insert text in 191.5.2.6 (page 116) after line 28.
The timing_lock_OK bit transmitted by the Follower in the infofield to indicate whether the Follower is currently tracking the Leader’s timing reference. This indicator bit is set to one to indicate that a Follower is tracking the Leader’s timing reference and is set to zero otherwise.
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications
310-920-3860
From: William Lo <00005d57449a68e9-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, July 13, 2026 11:05 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: [802.3_ISAAC] Discussion on comment #500
All,
I took an action to get some wording to define timing_lock_OK.
Insert text in 191.5.2.6 (page 116) after line 28.
Whenever a FOLLOWER loses the LEADER's timing reference it sets timing_lock_OK=0, which is communicated to the link partner via the InfoField. Otherwise, timing_lock_OK is set to 1.
Thanks,
William
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1