[802.3_ISAAC] Discussion on comment #368 and #369

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

All,

During training PHY Capability bits are exchanged. These bit among other things indicate what the PHY sending it is capable of doing.

In particular both devices tell each other whether it supports OAM and also exchanges VendorSpecificData.

Furthermore, PHY_D tells PHY_S what PHY_D’s receiver would like to see. This would be InterleaverDepth and PrecodeSel setting.

Comment #368 is in 191.5.2.4 – the HS_PATH

The proposed response says

“The HS_PATH PHY control bits are sent by PHY_D to PHY_S on the LS_PATH to control the transmitter settings on the HS_PATH.”

I believe this should be

“The capability bits set in PHY_S are sent to PHY_D over the HS_PATH. ”

Comment #369 is in 191.5.2.5 – the LS_PATH

The proposed response says

“The LS_PATH PHY control bits are sent by PHY_S to PHY_D on the HS_PATH to control the transmitter settings on the LS_PATH.”

I believe this should be

“The capability bits set in PHY_D are sent to PHY_S over the LS_PATH to control the transmitter settings on the HS_PATH.”

So the complete response would be.

#368

Change the title of Table 191-7 to:
PHY capability bits, HS_PATH

Change title of 191.4.2.4.5 to:
PHY capability bits, HS_PATH

Add as a new first sentence in 191.5.2.4.5
The capability bits set in PHY_S are sent to PHY_D over the HS_PATH.

#369
Change title of 191.4.2.5.4 to:
PHY capability bits, LS_PATH

Add as a new first sentence in 191.5.2.5.4
The capability bits set in PHY_D are sent to PHY_S over the LS_PATH to control the transmitter settings on the HS_PATH.

Thanks,

William

From: William Lo
Sent: Monday, July 6, 2026 3:58 PM
To: 'Natalie Wienckowski' <natalie@xxxxxxxxxxxxxxxxxxx>; 'STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx' <STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: RE: [802.3_ISAAC] IEEE P802p3dm D2p0 proposed responses available on website

Hi Natalie,

You asked for comments to discuss during meeting ahead of time. Here are some that I would like to address if we have time.

I like to do them in the order listed. The first 5 should be treated as a group.

CommentID

CommenterName

CommenterCo

Clause

Subclause

Page

Line

CommentType

Comment

SuggestedRemedy

Response

Topic

Discussion Points

494

Cheng, Xiaoyue

Infineon

191

191.5.2.4.5

112

"The format of PHY capability bits is Oct10<2:1> = InterleaverDepth[1:0], Oct10<4:3> = PrecodeSel[1:0],

Oct10<7> = OAMen, Oct8<7:0> = VendorSpecificData[7:0], and Oct9<7:0> = VendorSpecificData[15:8].

OAMen indicates MultiGBASE-T1 OAM capability is enabled.

The optional MultiGBASE-T1 OAM capability..."

For HS_PATH, there is no Interleave or Precode. Also, better to change the speed description into consistent format with 191.5.2.5.4 in LS_PATH

change into:

"The format of PHY capability bits is Oct10<7> = OAMen, Oct8<7:0> = VendorSpecificData[7:0], and Oct9<7:0> = VendorSpecificData[15:8].

OAMen indicates MultiG+100MBASE-T1/V1 OAM capability is enabled.

The optional MultiG+100MBASE-T1/V1 OAM capability…"

PROPOSED ACCEPT IN PRINCIPLE.

See #369 which clarifies this.

191_Infofields

#369 does not address this. #369 is incorrect.
Propose accept this comment as is.

368

Lasry, Ariel

Qualcomm Technologies, Inc.

191

191.5.2.4.5

113

Table 191-7 should show the fields described on lines 48, 49 of page 112.

It seems that the content of this table should be swapped with the content of Table 191-10.

Replace Table-191-7 with the content of Table 191-10 and add ",HS_PATH" to the table title

PROPOSED ACCEPT IN PRINCIPLE.

Change the title of Table 191-7 to:

PHY control bits, HS_PATH

Change title of 191.4.2.4.5 to:

PHY control bits, HS_PATH

Add as a new first sentence in 191.5.2.4.5

The HS_PATH PHY control bits are sent by PHY_D to PHY_S on the LS_PATH to control the transmitter settings on the HS_PATH.

191_Infofields

PROPOSED ACCEPT IN PRINCIPLE.

Change the title of Table 191-7 to:

PHY control bits, HS_PATH

Change title of 191.4.2.4.5 to:

PHY control bits, HS_PATH

Add as a new first sentence in 191.5.2.4.5

The HS_PATH PHY control bits are sent by PHY_S to PHY_D on the HS_PATH to control the transmitter settings for the LS_PATH.

369

Lasry, Ariel

Qualcomm Technologies, Inc.

191

191.5.2.5.4

115

Table 191-10 has fields for InterleaverDepth and PrecodeSel. However, there is no FEC interleaving and no PreCoder on the LS_PATH.

Table 191-10: bits 1,2,3 and 4 should be changed to Reserved.

PROPOSED ACCEPT IN PRINCIPLE.

Change the title of Table 191-10 to:

PHY control bits, LS_PATH

Change title of 191.4.2.5.4 to:

PHY control bits, LS_PATH

Add as a new first sentence in 191.5.2.4.5

The LS_PATH PHY control bits are sent by PHY_S to PHY_D on the HS_PATH to control the transmitter settings on the LS_PATH.

191_Infofields

Table 191-10 is correct. Low speed path is telling link partner what PHY_D wants for its high speed receiver.
The proposed change here is to parallel comment # 368

PROPOSED ACCEPT IN PRINCIPLE.

Change the title of Table 191-10 to:

PHY control bits, LS_PATH

Change title of 191.4.2.5.4 to:

PHY control bits, LS_PATH

Add as a new first sentence in 191.5.2.4.5

The LS_PATH PHY control bits are sent by PHY_D to PHY_S on the LS_PATH to control the transmitter settings on theHS_PATH.

370

Lasry, Ariel

Qualcomm Technologies, Inc.

191

191.5.2.5.4

115

Delete "Oct8<2:1> = InterleaverDepth[1:0], Oct8<4:3> = PrecodeSel[1:0]," as there is no FEC interleaving and no precoder on the LS_PATH

See comment

PROPOSED ACCEPT IN PRINCIPLE.

See #369 which clarifies this.

191_Infofields

See comment #494.
#369 does not address this

373

Lasry, Ariel

Qualcomm Technologies, Inc.

191

191.5.2.5.4

115

Remove the sentence "InterleaverDepth indicates the requested data mode interleaving depth. PrecodeSel indicates the requested precoder, available for 10G only." As there is no 10G on the LS_PATH

see comment

PROPOSED ACCEPT IN PRINCIPLE.

See #369 which clarifies this.

191_Infofields

See comment #494.
#369 does not address this

108

Huber, Thomas

Nokia

191

191.5.2.8

122

Figure 191-33 is not entirely clear. The text at the bottom right "LEADER stops…" doesn't seem to align with the period of time that the brace to which the text relates indicates, since the Leader is still transmitting.. Maybe the "LEADER stops…" and "FOLLOWER mimics…" labels got transposed (and if so, maybe the line from "FOLLOWER mimics..." really should be pointing to the last block in the LEADER row)?

Revise the figure to better illustrate the intended behavior. As the comment notes, one option would be to switch the "LEADER stops…" and "FOLLOWER mimics…" labels, and change the line that would say "LEADER stops…" to point to the last block in the LEADER row rather than the last block in the FOLLOWER row.

PROPOSED ACCEPT IN PRINCIPLE.

TFTD

191_link_sync

As the person who drew up the diagram, I agree that the commentor's remedy is correct

513

Razavi, Alireza

Eliyan

191

191.5.2.4.8

114

Table 191-9 maps “Receive fault” ? PMA_receive_fault, but PMA_receive_fault is not defined in 191.5.2.x variable lists; the variable appears only in this mapping table. PMA_transmit_disable needs definition too

use lower case for PMA in PMA_transmit_disable, and add the definition to p118, L32 pma_transmit_disable : When pma_transmit_disable set to TRUE, the average power of transmitted signal at MDI is nominally zero, and the transmitted signal shall be less than -36 dBm. use lower case for PMA in PMA_receive_fault, and add the definition to p118, L32 pma_receive_fault When pma_receive_fault set to TRUE, it indicates that training in phy control state machine is not successful.

PROPOSED ACCEPT IN PRINCIPLE.

Table 191-8: Remove "PMA control variable" column.

Table 191-9: Remove "PMA status variable" column.

late - 191_faults

Removing the column does not make sense since then we are not mapping anything.

Need to keep table 191-9 since comment #111 needs it.

We never really defined what transmit disable is and what receive fault is. My recommendation is to delete theTransmit disable and Receive fault rows from the table. These are not really needed and are holdovers copy and pasted from past SERDES standards. The BASE-T1 view is simple. If you want transmit disable, power down the device. The equivalent of receiver fault is link down.

514

Razavi, Alireza

Eliyan

191

191.5.2.2

110

Table 191-4 gives DME timing T1 = 8.53 ns and T2 = 4.26 ns. T2 is not exactly half of T1 (T2 should be 4.265 ns if T1 = 8.53 ns, or T1 should be 8.52 ns if T2 = 4.26 ns). The two values disagree at the third decimal place.

Resolve the rounding inconsistency in Table 191-4: either set T1 = 8.533 and T2 = 4.267 (matching 25.6/3 ns), or state explicitly that T2 = T1/2 and give the controlling value, with the dependent value derived in a NOTE.

PROPOSED ACCEPT.

TFTD which option is preferred

late - DME

Propose Reject:
We put the bar on top of 3 and 6

500

Razavi, Alireza

Eliyan

191

191.5.2.4.4

112

The Message Field uses the bit timing_lock_OK for the FOLLOWER (Oct7<4>), but timing_lock_OK is not defined as a state diagram variable in 191.5.2.6.1 and does not appear in the PHY Control state diagram (Figure 191–31) .

timing_lock_OK bit does not carry any information. replace timing_lock_OK bit with a reserved bit

PROPOSED ACCEPT IN PRINCIPLE.

TFTD

late - 191_PHY_Cntrl

It may be useful to convey this bit expecially if the follower is crystal-less and for some reason loses timing lock during training.

Proposed text to address this:
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.

Ran, Adee

Cisco Systems

191

191.14

153

The delay constraints are given in terms of HS_PATH delay and LS_PATH delay, but the way these are defined is a sum of delay in the transmitter and the receiver of the same rate - and these are in two different devices, which are differnt PHY types and possibly from different vendors. The "shall" statement addressing the delays cannot be fulfilled or verified by a single vendor. No vendor can claim compliance to such a "shared" requirement.

Other Base-T PHYs have either defined the requirement using the sum of the transmit and receive delays of a specific implementation (e.g. 55.11, 97.10, and 149.10) or specified separate delays for the transmit and receive path (e.g. 40.11 and 96.10).

In this case it seems that the latter option is preferable because loopback is not possible so the delays must be measured separately anyway. But specifying the sum on the delays of a specific implementation would still be acceptable.

Annex 191A provides recommendations but it is informative, and does not solve the problem that the specification is split between two vendors.

Also possibly in clause 192.

Change the delay constraints to either of the following:

- Separate transmit delay and receive delay maximum values for a specific implementations, splitting the budget e.g. according to the recommendations in Annex 191A (preferred)

- Sum of transmit delay and receive delay for a specific implementation.

Implement in clause 192 if appropriate.

PROPOSED ACCEPT IN PRINCIPLE.

TFTD

191_delay

Propose Reject
Annex 191A is informative because this is difficult to practically measure on a single PHY. Otherwise we would have made it normative.

However, if you built a system where there are 2 PHYs (same or different vendors it does not matter) the system path delay becomes measurable and this is normative.

Annex 191A is there in the spirit that vendors will voluntary meet this so that the system integrator can meet the normative spec. It also eliminates uncertainty for PHY vendors on how much delay to target. If you meet the target voluntarily, you would know you will be compliant in a system when working with another vendor who meets the number voluntarily.

Thanks,

William

From: William Lo
Sent: Monday, July 6, 2026 12:19 PM
To: 'Natalie Wienckowski' <natalie@xxxxxxxxxxxxxxxxxxx>; STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_ISAAC] IEEE P802p3dm D2p0 proposed responses available on website

Hi Natalie,

I found issues with the following in the EZ bucket. Please pull.

All -

In the interest of time please see the last column in the table below as to the issues I see so we are prepared to discuss them.

CommentID

CommenterName

CommenterCo

Clause

Subclause

Page

Line

CommentType

Comment

SuggestedRemedy

Response

Topic

Why remove from EZ

184

Wienckowski, Natalie

IVN Solutions LLC; Ethernovia & Bosch

45.2.1.244.1

missing register that needs to be updated for 191

Bring in this section from 802.3, as modified by 802.3cy and add references to 191.3.2.2.14, 191.5.2.4.5 and 191.5.2.5.4, with editorial license.

PROPOSED ACCEPT.

What exactly are we bringing in?

185

Wienckowski, Natalie

IVN Solutions LLC; Ethernovia & Bosch

45.2.1.245.1

missing register that needs to be updated for 191

Bring in this section from 802.3, as modified by 802.3cy and add references to 191.3.2.2.14, 191.5.2.4.5 and 191.5.2.5.4 , with editorial license.

PROPOSED ACCEPT.

What exactly are we bringing in?

186

Wienckowski, Natalie

IVN Solutions LLC; Ethernovia & Bosch

45.2.1.246

missing register that needs to be updated for 191

Bring in this section from 802.3, as modified by 802.3cy and add appropriate references, with editorial license.

PROPOSED ACCEPT.

What exactly are we bringing in?

Ran, Adee

Cisco Systems

191

191.1.2

The right side of Figure 191-2 shows the -V1 stack with an AN block, referred to as optional, and the text above the figure points to clause 98 for the whole family (including -V1). Also in 191.1.3 AN is mentioned for both T1 and V1, and there are numerous other mentions of AN in the clause.

However, in 191.8.1 it is stated that -V1 PHYs do not support AN.

Delete the AN block from the right-hand stack and delete the -V1 family from references to AN.

Conside how to clarify that AN is not supported (even as an option) in -V1, in the other mentions of AN.

PROPOSED ACCEPT IN PRINCIPLE.

See #158 which deletes the text in question.

Propose Reject
Do not change the diagrams because V1 is supporting AN.

285

van Dyck, Peter

Infineon

191

191.3.2.2

Figure 191-11: For 10G, a RS-FEC superframe always has L x 1800 PAM4 symbols. A Training frame always has 7200 PAM2 symbols. The training frame symbols match the data path symbols for a case with L=4

Replace:
RS-FEC superframe (L × 1800 × u symbols)
With:
RS-FEC superframe (L × 1800 symbols) / Training Frame (u x 1800 symbols)

Replace:
For PAM2 path, V=2 and u=2
With:
For PAM2 path, V=2 and u=4

PROPOSED ACCEPT.

Propose Reject:
The remedy is not correct.
Expanding this out all the cases
10G, L = 1 1800 symbols
10G, L = 2, 3600 symbols
10G, L = 4, 7200 symbols
5G, L = 1, 3600 symbols
5G, L = 2, 7200 symbols
2.5G, L = 1, 3600 symbols
So the current text is correct
RS-FEC superframe (L × 1800 × u symbols)

The training frame is always 7200 symbols
. There is no need to state it here since it is claer from figures 191-15 and 191-16

286

van Dyck, Peter

Infineon

191

191.3.2.2

Figure 191-12: For 2.5G and 5G, a RS-FEC superframe always has L x 3600 PAM2 symbols. A Training frame always has 7200 PAM2 symbols. The training frame symbols match the data path symbols for a case with L=2

Replace:

RS-FEC superframe (L × 1800 × u symbols)

With:

RS-FEC superframe (L × 3600 symbols) / Training Frame (7200 symbols)

Replace:

For PAM2 path, V=2 and u=2

With:

For RS-FEC Frame u=1. For Training Frame u=2.

Replace:

PAMVu x 1800-1

With:

PAM2u x 3600-1

PROPOSED ACCEPT.

287

van Dyck, Peter

Infineon

191

191.3.2.2

Figure 191-13: Same as comment for Figure 191-11

Replace:

For PAM2 path, V=2 and u=2

With:

For PAM2 path, V=2 and u=4

PROPOSED ACCEPT.

288

van Dyck, Peter

Infineon

191

191.3.2.2

Figure 191-14: Same as comment for Figure 191-12

Replace:

For PAM2 path, V=2 and u=2. For PAM4 path, V=4 and u=1.

With:

For RS-FEC Frame u=1. For Training Frame u=2.

Replace:

rx_PAMVn+(u x 1800-1)

With:

rx_PAM2n+(u x 3600-1)

PROPOSED ACCEPT.

113

Lo, Willliam

Axonne Inc.

191

191.5.2.5.4

115

Various capabilities are defined but not mapped to a register.

The InterleaverDepth request is set in bits 1.2311.12:11.

The received InterleaverDepth request is reported in bit 1.2312.12:11 of the link partner.

When bit 1.2311.5 is set to 1, the PrecodeSel request is set in bits 1.2311.3:2, otherwise the PHY determines the precoder setting. The actual setting transmitted is reflected in bit 1.2310.4:3.

The received PrecodeSel request is reported in bit 1.2312.3:2 of the link partner

The OAMen is advertised in bit 1.2311.1.

The advertised status is reported in bit 1.2312.1 of the link partner.

The VendorSpecificData to send is set via bits 1.2316:15:0 and received on the link partner bits 1.2317:15:0.

PROPOSED ACCEPT IN PRINCIPLE.

Add new paragraph on P115L47

The InterleaverDepth request the PHY sends to its link parter is bits 1.2311:12:11 (see 45.2.1.244.1). The InterleaverDepth request reported by the link partner is bits 1.2312:12:11 (see 45.2.1.245.1).

When bit 1.2311.5 (see 45.2.1.244.2) is set to one, the PrecodeSel request is set in bits 1.2311.3:2 (see 45.2.1.244.4); otherwise, the PHY determines the precoder setting. The actual setting transmitted is reflected in bit 1.2310.4:3 (see 45.2.1.243.5).

The received PrecodeSel request is reported in bit 1.2312.3:2 (see 45.2.1.245.3) by the link partner.

Incomplete implementation
1.2311.1 and 1.2317.15:0 not implemented

Muma, Scott

Microchip

191

191.5.2.6

116

The literal number would be more clear than an equation in this table

Change 20 - 0.384 to 19.616

PROPOSED ACCEPT.

Task force to discuss
I think the intent is to show a relatioship between the 20 and 0.384. Merging this into one number may mess with this intent.

Muma, Scott

Microchip

191

191.5.2.6

117

The literal number would be more clear than an equation in this table

Change 20 - 0.384 to 19.616

PROPOSED ACCEPT.

Task force to discuss
I think the intent is to show a relatioship between the 20 and 0.384. Merging this into one number may mess with this intent.

Thanks,

William

From: Natalie Wienckowski <natalie@xxxxxxxxxxxxxxxxxxx>
Sent: Thursday, June 25, 2026 2:40 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: [802.3_ISAAC] IEEE P802p3dm D2p0 proposed responses available on website

Dear colleagues,

Proposed responses for all 519 comments received, including the 25 late comments, have been loaded to our website.

You will find a pdf sorted by clause/subclause, an Excel file sorted by page/line, and an EZ bucket pdf. The EZ bucket includes comments that were received late and deemed EZ. Please note - some comments are marked as "WITHDRAWN" as I received an email from the commenter that they would like to withdraw their comment.

Please send all requests to remove comments from the EZ bucket by July 5th AOE.

Agenda for July 9th call:

Motion to include "late" comments.

Confirmation of comments to remove from the EZ bucket.

Motion to approve remaining comments in the EZ bucket.

Review of comments that may need consensus prior to the Plenary.

Comment resolution of requested comments.

General comment resolution.

If there are specific comments you would like to review during this meeting because you won't be at the Plenary or will be in other TF meetings, please let me know and we can look at these on July 9th.

I also uploaded additional files to support comments. These can be found on the July Plenary meeting page.

Thanks,

Natalie Wienckowski

In-Vehicle Networking Solutions LLC

IEEE P802.3dm Chair and Chief Editor

natalie@xxxxxxxxxxxxxxxxxxx

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