Hi Tony, Chao, and Scott,
Thanks for the presentation today.
Here are the questions I brought up during the meeting. Since we had limited time, I wanted to give you an opportunity to respond.
As stated, I see plausible use cases, but I have not yet seen quantitative evidence that a 1 Gbps low-speed path is necessary within 802.3dm.
Here are 3 questions I raised after your presentation.
- For the proposed use cases, what requirement cannot be satisfied by existing 802.3ch using directional EEE? You mentioned
there are already production applications in China. Please provide the relevant throughput, latency, wake time, and power.
- Slide 17 – What percentage of projected 802.3dm camera links requires 1Gbps LS – compared with the much larger population
that only requires 100Mbps
- Slide 16 – shows only approximately 0.85Mps over I2C and 8-40Mbps over SPI. What is the evidence that the 100 Mbps LS
path is the limiting factor rather than the endpoint bus or flash write time? These updates are done before starting the vehicle and parked in the garage or connected to WiFi for (OTA), giving the application time to upload the flash, as these are not required
every boot-up.
Additional:
Why have adhocs not been used to help accelerate these discussions? The chair offered to schedule if needed, since May to make the appropriate updates
Best Regards,
TJ
From: Akin, Sami, Dr. (TX-DN) <sami.akin@CARIAD.TECHNOLOGY>
Sent: Monday, September 14, 2026 8:51 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Architectural inefficiency and PAR alignment of the 1 Gb/s proposal
|
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.
|
Dear colleagues,
I would like to share my concern and perspective.
In the camera-related discussions in which I participate, the missing finalization of the IEEE asymmetric Ethernet specification is already a significant concern. Programs need sufficient certainty
regarding specification availability, implementation, and validation. Where that certainty is missing, alternative technologies are more likely to be favored.
I recognize that the proposed 1 Gb/s low-speed option may offer value for certain applications, and I appreciate the technical work invested in the proposal.
Nevertheless, introducing this option at the present stage creates a schedule risk that I cannot disregard. The recent technical discussions also indicate that further review and specification work
would be necessary before the text could be considered mature.
Even a limited delay in finalizing the specification may affect technology decisions in automotive programs. Once an alternative technology has been selected, completing the IEEE specification at
a later point may not reverse that decision.
For this reason, my primary concern is the timely completion of the currently defined specification and maintaining the planned transition to SA ballot. The 1 Gb/s option could still be studied separately
without exposing the current project schedule to additional risk.
This is not a judgment against the technical concept. It is a prioritization based on the timing and planning needs of potential automotive users.
Best regards,
Sami
INTERNAL
I would also like to share a quick summary of my view on this topic.
1- As we all know, the choice of the data rates affect every aspect of the PHY specifications. Any discussion about a new data rate should belong to the very early phases of
standard development and not at the stage that text opens up for SA balloting. This is particularly true if the new rate is an order of magnitude higher than the baseline.
2- Additionally, for this task force, which is formed with the sole goal of optimality of the PHY for asymmetric traffic, there are even more reasons to think twice about introducing
a new data rate which pushes the traffic more towards symmetry.
3- On top of all this, even if we have to move ahead and introduce the option of 1G for upstream, I highly doubt that anybody can make a reasonable argument for TDD to be the
right choice to achieve the PHY optimality that is the center requirement for this asymmetric PHY type. As you know, I have had many contributions showing that TDD is not an optimal asymmetric PHY choice. All those arguments are much stronger when the upstream
is 1G and data rates are less asymmetric. Here is a summary of those arguments:
a) Equalization becomes a much tougher problem in TDD, especially if data rates are less asymmetric
b) The dynamic range of the analog receive signal path becomes increasingly a bottleneck in TDD when the traffic is more symmetric
c) Transmitter linearity is more challenging when TDD needs to support a more symmetric throughput
c) PLL jitter tolerance budget is tighter with the excessive bandwidth requirements that come with TDD, particularly for more symmetric data rates
d) Meeting EMC requirements become increasingly harder with the inefficiently wider bandwidth needed to support TDD for more symmetric traffic
e) TDD is inherently not the right choice for small delay, particularly if the data rates are less asymmetric
Our colleagues affiliated with OEMs have told us many times that there was an immediate need for asymmetric PHY in the market which, in turn, argued for the urgency in ratifying
an asymmetric spec to achieve the optimality goals for a PHY. To me, bringing up a new higher data rate with questionable applications with less asymmetry while we are about to open up the SA ballot goes against this urgency.
IEEE 802.3 has chosen full duplex schemes over and over for every symmetric PHY spec. Given all this precedence, it's hard to image TDD can be the optimal PHY when the data
rate is less asymmetric. As William said in this email below, unless proven otherwise, 8023.ch with EEE should be the default choice for these applications.
All,
I’m looking at the reflector going back and forth going into technical details.
I have a couple of simple questions.
Is 1G back channel needed all the time? If so what is the use case?
If it is only needed once in a while what is the use case?
What is the market size needing 1G vs market size of not needing 1G.
We already have a solution with 5GBASE-T1 or 10GBASE-T1 with EEE if you need
burst of high speed reverse traffic from time to time. If a small fraction of the market requires 1G
backchannel, then just use the existing solution today.
Looking at what Ragnar pointed out, I tend to agree that the 1G modulation is not fully thought through.
Given that we want to go to SA in Nov, I recommend that we do not include the 1G.
In my opinion, there is too much risk with the 1G proposal as it stands as I
believe the working group is going to poke a lot of holes with this to prevent us from getting to SA.
Thanks,
William
Dear 802.3dm colleagues,
I have been conducting a thorough review of the proposed 1 Gb/s addition to Clause 192. I have already shared my concerns regarding whether a 1 Gb/s return path is justified for camera applications (and hence
whether it aligns with the 802.3dm project scope), as well as noting that the current text is not mature enough for SA ballot without risking project delays.
In this email, I want to highlight an equally fundamental issue:
the proposed framing structure is technically unoptimized, regardless of how one views the scope.
As defined in our approved Project Authorization Request (PAR), the explicit scope of IEEE P802.3dm is to specify Physical Layer standards that are:
"optimized for automotive end-node camera links for operation up to 10 Gb/s in one direction and with a lower data rate in the other direction."
When reviewing the technical details in the draft text and proposals, the framing mechanisms required to force the 1 Gb/s return path into the 9.6 µs TDD grid depart significantly from an optimized PHY architecture:
- Excessive Byte Padding: To force transmission times into the rigid 9.6 µs TDD
cycle, the datapath relies on substantial arbitrary byte padding outside the RS-FEC boundaries. Specifically, 5G+1000 requires
726 bytes (5,808 bits) of end-of-burst padding, 7.5G+1000 requires
200 bytes (1,600 bits), and the 1 Gb/s LS path requires
8 bytes (64 bits). Transmitting thousands of dummy padding bits per burst wastes channel time and transmitter power without carrying
client data.
- Severe OAM Bandwidth Squandering: In the 1 Gb/s LS path, aggregating six interleaved
(L=2) RS-FEC(130,124) superframes transmits 170 bits across the 17-bit OAM positions in the five standard superframes. However,
because Clause 192.3.7 strictly defines OAM exchange as a single 10-bit symbol per TDD burst,
160 out of the 170 transmitted bits (over 94%) are permanently unutilized and reserved. Carrying this dead-weight overhead solely
to avoid reformatting the 100 Mb/s frame structure is remarkably inefficient.
- Standardization of "Dark Capacity": The proposal introduces unallocated RS-FEC
superframes (1 extra superframe for 1 Gb/s LS and 7.5G+1000 HS; 2 extra superframes for 5G+1000 HS), designating them as "vendor-specific" and explicitly
"outside the scope of IEEE 802.3" (subclauses 192.3.2.2 and 192.3.4). Allocating standard PHY line bandwidth to proprietary,
non-interoperable data simply to make the math fit the cycle timing is contrary to traditional 802.3 architectural practices.
- Avoidable Escalation of Modulation Orders: This framing overhead inflates the
symbol load, forcing the forward path to jump to higher-order modulations—from PAM2 to PAM3 for 5 Gb/s, and from PAM3 to PAM4 for 7.5 Gb/s. Sacrificing receiver SNR and link margin to transmit thousands of dummy padding bits and unused OAM positions is not
an optimal engineering tradeoff for cost- and power-constrained automotive links.
While I understand the desire to reuse existing PCS building blocks, the resulting datapath layers ad-hoc shims and non-standard dark fields onto an architecture originally designed for a 100 Mb/s return path.
Given our explicit PAR mandate to develop an
optimized specification, I believe the Task Force should not adopt the 1 Gb/s proposal in its current form. Standardizing a framing structure with this degree of built-in inefficiency does not serve
the long-term interests of the automotive Ethernet ecosystem.
Best regards,
Ragnar
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
|