[802.3_ISAAC] Aw: Re: [802.3_ISAAC] Response for comments 77 and 78

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

Hi Scott,

Thanks for a refresh of an earlier presentation.

The point of this presentation as I understand it are:

XGMII to XGMII delays are measurable
Constant latency is achieved with help from FIFOs on both sender and receiver in the TDD system to absorb latency variation.

What it does not address is how much to budget TX delay and RX delay if the PHYs are from different vendors. For example, you can have FIFOs with large delay or small delays and still have constant XGMII to XGMII latency. But depending on how much latency the FIFO introduces, the total latency will vary depending on implementation. So how do you budget how much latency each FIFO is permitted if the PHYs on each side of the link are from different vendors? This presentation does not address this issue.

More practically, it is unclear to me from the presentation on how to measure the delay from XGMII to MDI and the delay from MDI to XGMII in silicon.

Currently in Clause 191.14 we specify the TX + RX delay (XGMII to XGMII).

Annex 191A shows a consistent measurement method and informative targets on

XGMII to MDI and MDI to XGMII delay. But we still have the issue on how to measure this delay

in silicon. The PHY vendors can measure these numbers in simulation using the methodology

in Annex 191A.

Thanks,

William

From: Scott Muma <00003414ca8b162c-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, September 15, 2026 8:57 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Response for comments 77 and 78

Just to give some more background/understanding on the method for the delay constraint specification here is a previous presentation on a similar topic:

https://www.ieee802.org/3/dm/public/0725/Hutchison_Arunarthi_3dm_01_07272025.pdf

In gPTP it’s necessary to measure the PHY delay in each direction live before using each value, while for PAUSE operation specifying the combined Tx and Rx delay is sufficient, so completely different but makes use of some similar concepts.

Thanks
Scott

From: Scott Muma <00003414ca8b162c-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, September 15, 2026 11:29 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: [802.3_ISAAC] Response for comments 77 and 78

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

Hi Natalie and all,

Comments 77 and 78 were made for the specification of delay constraints which is also relevant to Clause 192.

In addition to any other response I would propose changing 192.12 as follows:

Replace text and table on page 292 with:

The combined transmit and receive data delay for an implementation of the PHY in a given mode shall not exceed the limits shown in Table 192–27. Transmit data delay is estimated from the input of a specified unit of data at the XGMII to the presentation of the same unit of data by the PHY to the MDI. Receive data delay is estimated from the input of a specified unit of data at the MDI to the presentation of the same unit of data by the PHY to the XGMII. Following the recommendations of 90A.7 for repeating delay variation patterns, the maximum intrinsic delay value is allocated to the transmit PHY and the minimum intrinsic delay value is allocated to the received PHY. For this purpose, the specified unit of data is the byte of data on the XGMII interface that corresponds to the first byte of data at the start of a TDD burst payload.

NOTE—The physical medium interconnecting two PHYs introduces additional delay in a link.

Table 192–27—Combined PHY Delay constraints

Operating mode Maximum delay (ns)

PHY_S 5 120

PHY_D 11 776

Thanks

Scott

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