Hi Wei,
Thank you again for your prompt answer to my question about tx_tdd_active.
My next question is what is the difference between the pcs_tx_mode variable and the tx_mode variable?
It looks to me like they are conveying the exact same information, but only use different names for the states, with T_2p5G instead of SEND_TS, etc. Am I misunderstanding something?
Do I understand correctly that SEND_TA always uses 3Gsps PAM2 signaling, and that for 5Gbps and 10Gbps the change to higher symbol rate happens in the transition to SEND_TA, and then the transition to PAM4
for 10Gbps happens in SEND_TA_EXT?
Ragnar
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Monday, July 7, 2025 1:23 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] [EXTERNAL] Re: [802.3_ISAAC] Question on Baseline Text Proposal for TDD Based 802.3dm PHY
What I mean by support is the normal 802. 3
definition of autoneg, such as clause 28, or clause 98. This is the function which allows selection between phy types, generally of a family based on media type. The baseline text I see in https: //www. ieee802. org/3/dm/public/0525/Baseline_Text_TDD_051125. pdf
|
Prioritize security for external emails:
|
|
Confirm sender and content safety before clicking links or opening attachments
|
|
|
What I mean by support is the normal 802.3 definition of autoneg, such as clause 28, or clause 98. This is the function which allows selection between phy types, generally of a family based on media type.
The baseline text I see in
https://www.ieee802.org/3/dm/public/0525/Baseline_Text_TDD_051125.pdf proposes TDD phy types, where you can negotiate the speed and the end of the directionality, but I didn’t see any mechanism to negotiate to phy types outside of clause 200, specifically
those for other automotive single-lane media. Did I somewhere miss this?
Perhaps I should have said support clause 98 autoneg (or a similar phy independent autoneg) That's where the confusion comes from. If that’s right, it sounds as though the TDD-proposers are suggesting not to have negotiate outside of the
dm-clause TDD PHYs…
George,
what do you mean by support?
For me, the functionality of Autoneg is not needed as it is included TDD for 802.3dm.
Thanks,
Mehmet
On Jul 5, 2025, at 12:57 PM, George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:
Thanks Wei Lou -
When auto-neg is not supported, I don't see an issue with the naming of link_fail_inhibit_timer. It wasn't clear to me that the TDD-based dm proposal does not support autoneg at all. With that clarification, I don't see any issue with
naming.
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications
george@xxxxxxxxxxxxxxxxxxxx
310-920-3860
-----Original Message-----
From: Wei Lou <000047a3c8c56bbe-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Saturday, July 5, 2025 12:37 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] [EXTERNAL] Re: [802.3_ISAAC] Question on Baseline Text Proposal for TDD Based 802.3dm PHY
Hi, Ragnar and George,
Thank you both for the valuable feedback and detailed review.
Ragnar – I agree that naming is important for clarity. Using something like timer_active instead of training_active would better reflect the variable’s purpose. If the Task Force supports that direction, I’m happy to make the change. I’ll
add this variable to Section 200.6.4.1 (PMA state diagram variables) on page 59 of the text proposal.
As for tx_tdd_active, it represents an active state combining SEND_TS, SEND_TA, SEND_TA_EXT, and SEND_N. Right now, it’s equivalent to tx_mode != SEND_Z, as you noted. If others supporting the TDD proposal agree, I’m open to removing it
for simplification.
George – Regarding link_fail_inhibit_timer, while it’s commonly associated with autonegotiation, it’s also used in link synchronization/force mode in 802.3bp and 802.3ch. In those cases, the timer starts after autoneg or link sync completes,
and it ensures that training doesn’t continue indefinitely. If training fails to reach Link_status = OK before the timer expires, the system will revert to autoneg/link sync and restart the identification process.
In the TDD-based 802.3dm proposal, we remove both autoneg and link sync. The symmetric training stage serves both purposes, operating at the lowest speed and allowing negotiation via InfoFields. Since 802.3dm is a new standard that doesn’t
need to interoperate with .bp or .ch via autoneg, we believe reusing the name link_fail_inhibit_timer won’t cause confusion. We also considered maxwait_timer defined in 802.3 bp, but in 802.3 .dm, this timer behavior differs from .802.3 bp (where both sides
start the maxwait_timer after leaving PHYC TRANSMITTER_DISABLE). In .dm, we need a common (or near-common) timer starting point due to potential power-up/reset delays between MASTER and SLAVE. In both 802.3 bp and 802.3ch, this common starting point is the
time when Link sync/autoNeg is finished. In TDD 802.3 dm, this common starting point is the time when the SLAVE sending its first burst. That said, we’re open to renaming it if the Task Force prefers.
Thank you
Wei
________________________________________________________________________
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
|