| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Scott,
Thank you for the detailed and thoughtful response, and for pointing me to the updated preview documents. I have reviewed Muma_3dm_02_0926.pdf, and the changes in the draft text are clearly an improvement over the text in chini_3dm_02a_D2d0_1G_comments-preview.pdf. The adoption of RS-FEC(130,124) for the 1 Gb/s LS path, the clarification of the padding bits, and the added description of scrambler behavior during padding are all positive steps.
However, I do not believe the text is yet ready for SA ballot. As I detail below, several normative gaps remain.
More fundamentally, I want to state clearly that my principal objection is not to the quality of any particular draft — it is to the inclusion of the 1 Gb/s LS option at all. Adding 1 Gb/s LS increases the relative cost and complexity of any PHY that supports it, and it does so without a clear benefit to the automotive end-node camera use case that 802.3dm must optimize for. I still believe that the 1 Gb/s LS option is out of scope for 802.3dm under the terms of the PAR.
Your email provides the following key clarification:
"The unused RS-FEC superframes are appended after the RS-FEC superframes that carry the 64B65B blocks, and the padding bytes are appended after the unused RS-FEC superframes."
This is precisely the information that was missing from chini_3dm_02a_D2d0_1G_comments-preview.pdf, and it is good that Muma_3dm_02_0926.pdf has added updating instructions for the figures to reflect this. The normative text in §192.3.2.2 says only that the content is "vendor specified and outside the scope of IEEE 802.3." It is not clear to me exactly what this means for implementers.
I appreciate the new editing instructions for the PCS block diagrams (Figures 192-5, 192-6, 192-12, and 192-13), and I appreciate that this appears to be a direct response to my earlier comments. At the same time, the scope of the required changes to those figures illustrates how much the 1 Gb/s modes add to the existing block diagrams:
The additional blocks and conditional signal paths required to support 1 Gb/s LS will be clearly visible in the updated figures. I raise this not as a criticism of the proposed edits, but because the visual complexity of those figures is a faithful representation of the implementation complexity that I have been arguing increases the relative cost of the PHY.
You are correct that my calculation of 1,171.2 blocks for the 7.5G+1G HS case was in error: I divided the raw RS-FEC payload bits by 65 without accounting for the 1-bit OAM field appended to each group of 15 blocks. The correct calculation gives exactly 1,170 blocks (26 superframes × 3 frames × 15 blocks/frame), which is an integer. I apologize for the error and withdraw that specific claim.
While the 64B/65B block count within the RS-FEC data portion is always an integer, the subsequent vendor-specified padding is not. The 200 bytes of PAM4 padding in the 7.5G+1G case corresponds to 1,600 bits, which is not a multiple of 65 bits (1,600 / 65 = 24.6 blocks). Similarly, the 8 bytes of PAM2 padding in the 1G LS case = 64 bits, also not a multiple of 65.
This means there is no straightforward alignment between the padding region and the 64B/65B block structure. The normative text should state explicitly that the 64B/65B block sequence does not extend into the padding region, and that the padding carries no block-coded data. Your email implies this is the intent, but the normative text does not say so.
§192.3.2.2 of Muma_3dm_02_0926.pdf adds the sentence: "The scrambler continues running and scrambles the extended burst payload RS-FEC superframes and padding." This addresses my earlier concern about signal level during the padding period. I accept that scrambled padding should not result in all-zero PAM3 symbols, and I withdraw that specific concern.
I want to address a misunderstanding that appears to underlie several of your responses. My claim was not that the 1 Gb/s LS option cannot be implemented. I have no doubt that it can. My claim was that it increases the relative cost and complexity of any PHY that supports it compared to a PHY optimized for the 100 Mb/s LS use case. I believe your responses actually demonstrate this rather than refute it.
On modulation switching: You explain that the rate negotiation happens during the symmetric training phase, and that there are at least 100 TDD intervals in the asymmetric training phase before the PHY enters data mode. I accept that there is adequate time to switch — but the existence of this switching requirement is itself the added complexity I was describing. A 7.5 Gb/s PHY that only supports 100 Mb/s LS always uses PAM3. A PHY that also supports 1 Gb/s LS must inspect the outcome of rate negotiation and configure its encoder accordingly. That is additional logic, additional verification, and additional test coverage. The fact that it is achievable does not mean it is free.
On padding: You note that the padding is appended after an integer number of RS-FEC superframes and is "not significantly different from normal burst mode transmission." I agree it is not entirely unlike other burst-mode mechanisms, but the comparison is not exact. In all existing modes without 1 Gb/s LS, the burst payload is exactly filled by an integer number of RS-FEC superframes with zero padding. The 1 Gb/s LS modes introduce padding of varying sizes (8, 200, or 726 bytes depending on mode) that must be injected at the correct position in the transmit datapath and stripped at the correct position on receive. This is additional state and logic that does not exist in the baseline design.
On the "it is optional" argument — and what it reveals about scope: You note, in response to the baud rate and AFE concerns, that "1 Gb/s is optional, so no camera is required to support an option it doesn't need." I want to highlight this statement, because I believe it is the clearest answer yet to the scope question I have raised.
The 802.3dm PAR defines the scope of this standard as developing a PHY that is "optimized for the automotive end-node cameras." If cameras do not need to implement the 1 Gb/s LS option — as you state — then the 1 Gb/s LS option is not optimizing for cameras. By the PAR's own language, a feature that camera end-nodes are not expected to implement does not belong in a standard whose purpose is to optimize for those cameras.
I want to be clear that I am not disputing the technical usefulness of a 1 Gb/s return path in some applications. I am observing that those applications are not the automotive end-node camera, and that 802.3dm is not the right vehicle to standardize them. If there is a genuine need for a 1 Gb/s TDD return path in automotive infrastructure or ECU-to-ECU links, that is a valid and interesting use case — but it belongs in a standard whose PAR covers that use case, not in one explicitly scoped to camera end-nodes.
The optionality argument also does not resolve the ECU-side relative cost concern. An ECU PHY that must interoperate with both 100 Mb/s cameras and 1 Gb/s cameras, must implement all of the above logic. Optionality in the standard does not reduce the relative cost for a PHY that is required to support both options in practice. And as noted in my earlier email, the absence of a mandatory common LS mode creates a two-axis interoperability matrix that is entirely new to 802.3dm.
To summarise: I was not claiming the 1 Gb/s LS option is impossible to implement. I was claiming — and continue to claim — that it increases the relative cost of supporting it compared to a design optimized for 100 Mb/s LS only. That increase in relative cost, applied to a feature that — as you yourself noted — cameras are not expected to implement, is why I believe it is out of scope for 802.3dm.
One thing I did not discuss in my earlier email is the impact of 1 Gb/s LS on the transmit buffer memory required at both ends of the link.
In TDD operation, a PHY must buffer data arriving continuously from the MAC during the periods when it is not transmitting. The minimum transmit buffer size is determined by the data rate and the duration of the non-transmit period (QUIET period plus the partner's transmission time). Calculated from the TDD timing values in the draft (Tables 192-7, 192-9a, 192-9b):
| Mode | HS TX buffer | LS TX buffer |
|---|---|---|
| 100M LS + 5G HS | 567 bytes | 113 bytes |
| 100M LS + 7.5G HS | 850 bytes | 113 bytes |
| 1G LS + 5G HS | 1,657 bytes | 913 bytes |
| 1G LS + 7.5G HS | 2,485 bytes | 913 bytes |
The 1 Gb/s LS option increases the required HS transmit buffer by approximately 2.9× (from 850 to 2,485 bytes for the 7.5G case) and increases the required LS transmit buffer by approximately 8.1× (from 113 to 913 bytes). The HS buffer grows because the HS transmission window is shortened to make room for the larger LS burst; the LS buffer grows because the LS data rate is ten times higher while the LS silent period is only slightly shorter.
In addition to the transmit buffers, the RS-FEC interleaving buffer for the LS path doubles: the 1 Gb/s LS path uses L=2 interleaving (compared to L=1 for 100 Mb/s LS), requiring the encoder and decoder each to buffer two RS-FEC(130,124) frames simultaneously — 260 bytes — rather than one (130 bytes).
The HS TX buffer increase falls on the ECU (PHY_S) side: the ECU must buffer more HS data during the extended QUIET period while the 1 Gb/s LS burst completes. The LS TX buffer increase and the FEC interleaving buffer increase fall on a camera that implements the 1 Gb/s LS option. A camera implementing only 100 Mb/s LS is not directly affected by the LS buffer figures above, consistent with the optional nature of the 1 Gb/s LS mode.
However, the ECU-side HS TX buffer increase is unavoidable for any ECU that supports 1 Gb/s LS, regardless of which camera it is connected to at any given moment. An ECU serving a mixed fleet must provision for the worst case. A nearly 3× increase in the HS TX buffer on a device that may have 8 to 16 camera ports represents a meaningful increase in relative cost for the ECU silicon, and this cost is incurred in support of a feature that — as noted above — provides no direct benefit to the camera end-node the standard is designed to optimize for.
The addition of the 1 Gb/s LS option increases the complexity of the implementation and the relative cost of the PHY, and is therefore out of scope for 802.3dm under the terms of the PAR. Furthermore, the normative text describing the 1 Gb/s implementation is not yet complete, and adopting it in its current state would delay the 802.3dm project.
Best regards,
Ragnar
Hi Ragnar,
Thanks for sharing your questions on the preview changes to D2.0 from June. The updated preview changes for D2.1 are now available:
https://www.ieee802.org/3/dm/public/0926/Muma_3dm_01_0926.pdf
https://www.ieee802.org/3/dm/public/0926/Muma_3dm_02_0926.pdf
I hope that will resolve some of these concerns, and I would like to respond to your points since the preview of changes proposed to D2.1 was not available before.
The unused RS-FEC superframes are appended after the RS-FEC superframes that carry the 64B65B blocks, and the padding bytes are appended after the unused RS-FEC superframes. In other words, the burst payload consists of a specified number of 64B65B RS-FEC superframes, followed by a specified number of unused RS-FEC superframes, followed by a specified number of padding bytes.
The alignment of 64B65B blocks to RS-FEC frames is as described in the existing text, there is no change to this, and the description of the alignment is very similar to Clause 149 or 191. The start of a 64B65B block is always aligned to the start of the RS-FEC frame and there is an OAM field appended to a group of 64B65B blocks to fill out the message to an even number of RS-FEC symbols. Your calculation of 64B65B payload capacity is ignoring the OAM fields. There are always an integer number of 64B65B blocks in an RS-FEC superframe and a burst and so they are always aligned with the RS-FEC frame.
The padding fields are vendor specified and are appended prior to scrambling, so the padding bits may be all-zeros or any other content prior to scrambling, but this doesn’t result in all zeros PAM3 symbols. The Total gap time per cycle is consistent in all modes.
Regarding your concerns on PHY complexity, I would respond to those one by one:
For example, at 7.5 Gb/s, if the link partner requested a 100 Mb/s return path, the PHY turns on a PAM3 encoder. If the link partner requested a 1 Gb/s return path, it must instantly switch to a PAM4 encoder.
The startup symmetric training phase is always 3 Gbd PAM2 in both directions. The data rate in each direction is determined in this phase. Once the rate is agreed there is time before transition to the asymmetric training phase, and the asymmetric training phase will be using 6 Gbd PAM2 for the 7.5 Gb/s path whether the data mode uses PAM3 or PAM4. The state machine stays in the asymmetric training phase for at least 100 TDD intervals, so there is significant time for switching and setup of anything required. This is much like the selection between 7.5 Gb/s PAM3 and 10 Gb/s PAM4, both using 100 Mb/s return path. 1 Gb/s is not changing how startup operates.
Anopther example is that the logic must now compute the negotiated mode and inject highly specific, arbitrary byte padding (e.g., exactly 726 bytes for 5G/1G or 200 bytes for 7.5G/1G) into the middle of the datapath to make the fractional superframes perfectly align with the 9.6 µs TDD cycle boundaries.
The padding is added to the end of each burst payload after an integer number of RS-FEC superframes, there are no fractional superframes. This is not significantly different from normal burst mode transmission which sends a specific number of RS-FEC superframes every burst and then waits a specific number of QUIET symbols before starting the next burst.
The third example is that the receiver must lock onto either a 3 GBd signal (for a 2.5G camera) or a 6 GBd signal (for 5G/7.5G/10G cameras).
This point is unclear to me, but I will assume the concern is the receiver in the camera. If the camera only supports 100 Mb/s receive it’s 3 GBd no matter what the high-speed rate is. 1 Gb/s is optional, so no camera is required to support an option it doesn’t need and can implement a receiver optimized for the single receive rate.
The fourth example is that the transmitter must be capable of driving both a 3 GBd signal (for 100M LS) and a 6 GBd signal (for 1G LS).
Here I assume you mean a PHY_D (SoC/switch-side) 1 Gb/s must support a 6 GBd transmit mode in addition to 3 GBd. Again the 1 Gb/s option is not mandatory to implement when not needed in the use case. If the PHY is reversible and supports operation as a 5G/7.5G/10G PHY_S, then it already has 6 GBd capability and 1 Gb/s is not putting additional requirements on the transmitter.
The fifth example is that designing an AFE that performs efficiently across multiple baud rates is significantly more complex than an optimized solution for a single baud rate.
This seems similar to the 3rd example. The definition of 1 Gb/s LS mode doesn’t eliminate the ability to optimize for a single baud rate if 100 Mb/s is sufficient. Providing optional capabilities above the minimum does not force their implementation but gives system implementers and end users the choice of what “optimized” means for their use case.
I’d be happy to discuss more with you in person.
Best regards,
Scott
From: Ragnar Jonsson <ragnar.jonsson@xxxxxxxxx>
Sent: Thursday, September 10, 2026 4:37 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Question abut Schedl_etal_3dm_01_0926.pdf
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
All,
I like to thank Steve for clarifying the intent with the RS-FEC for 1Gbps. I would agree that it is better to use RS-FEC(130,124).
It appears to me that there is a significant interoperability problem in the current specification for 1Gbps modes, related to the "padding bits". Page 206 of chini_3dm_02a_D2d0_1G_comments-preview.pdf states "there is capacity remaining in the last RS-FEC block of the data payload area. The content of the unused RS-FEC block payload bits and the padding fields are user defined and outside the scope of IEEE 802.3".
The first obvious problem with this statement is the lack of description regarding how the "unused RS-FEC block payload bits" are distributed within the burst: Are they all in the beginning of the burst, all at the end, or somehow distributed throughout the burst. Without a clear specification of this distribution of the "unused RS-FEC block payload bits" the chances of interoperability are low.
The second problem is that there is no description of how 64B/65B blocks should align within the RS-FEC frames, or more precisely, whether they should be aligned at all. For example, the 7.5G over 1G FEC capacity per burst is 26 superframes of RS(128,122) L=3 provide exactly 76,128 bits of payload capacity. This equals 1171.2 64B/65B blocks, meaning each burst will not contain an integer number of blocks. How should the implementation handle this misalignment? Should the next burst begin in the middle of the "user defined padding," or should the next burst start with a new aligned 64B/65B data block?
The third problem relates to the padding fields being undefined. In the 5G over 1G case, which uses PAM3, would it be allowed for a transmitter to transmit all zeros for the padding field. This would mean that the receiver would see the signal "disappear" early, and the "Total gap time per cycle" would now be different from what is specified. This in turn could cause interoperability problems.
Besides obvious interoperability problems like the ones above, the new 1Gbps rates will significantly complicate PHY designs. For example, at 7.5 Gb/s, if the link partner requested a 100 Mb/s return path, the PHY turns on a PAM3 encoder. If the link partner requested a 1 Gb/s return path, it must instantly switch to a PAM4 encoder. Anopther example is that the logic must now compute the negotiated mode and inject highly specific, arbitrary byte padding (e.g., exactly 726 bytes for 5G/1G or 200 bytes for 7.5G/1G) into the middle of the datapath to make the fractional superframes perfectly align with the 9.6 µs TDD cycle boundaries. The third example is that the receiver must lock onto either a 3 GBd signal (for a 2.5G camera) or a 6 GBd signal (for 5G/7.5G/10G cameras). The fourth example is that the transmitter must be capable of driving both a 3 GBd signal (for 100M LS) and a 6 GBd signal (for 1G LS). The fifth example is that designing an AFE that performs efficiently across multiple baud rates is significantly more complex than an optimized solution for a single baud rate.
After analysing the 1Gbps LS proposal in detail, it is clear that this will significantly complicate the PHY design compared to a design optimized for the camera application. It also apears to me that the "unused-bits" are going to lead to sigificant interoperability issues. Therefore, I still believe the 1Gbps LS is out of scope for 802.3dm because it does not satisfy the requirement of being "optimized for the automotive end-node cameras".
Ragnar
On Thu, Sep 10, 2026 at 7:41 PM <Steve.Gorshe@xxxxxxxxxxxxx> wrote:
Dear Ragnar,
Since I had prepared the figure you reference below, I’ll respond with the clarification.
The use of RS-FEC(128-22) for the LS burst in the figure is a typo. Some of us had considered using that one but decided that RS-FEC(130,124) was a better choice, and I forgot to update the draft figure. If you look at subclause 192.3.2.2.16 in the chini_3dm_02a_D2d0_1G_comments-preview.pdf file on the web site for June 2 TF Ad Hoc, where the RS FEC codes are actually defined, you will see that the LS had indeed used RS-FEC(130,124) for the proposed 1G LS. As is mentioned and apparent in that subclause, both of these RS-FEC codes use the same base polynomial (i.e., different shortening of the same base FEC). Consequently, it is straightforward to use the same FEC engine for both.
My apologies for the typo and resulting confusion!
Best regards,
Steve
From: Ragnar Jonsson <ragnar.jonsson@xxxxxxxxx>
Sent: Thursday, September 10, 2026 12:06 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: [802.3_ISAAC] Question abut Schedl_etal_3dm_01_0926.pdf
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
Dear Tony, Chao, Scott, and Mehmet,
I have a question regarding your proposed 1Gbps LS modulation in Schedl_etal_3dm_01_0926.pdf. On slide 8 it is stated that the changes are provided in chini_3dm_02a_D2d0_1G_comments-preview.pdf, but slides 9 through 11 propose a different RS-FEC for the 1Gbps link. Can you please clarify whether the intention is to update the RS-FEC, or keep the description in chini_3dm_02a_D2d0_1G_comments-preview.pdf?
The following is my understanding of the RS-FEC description in the two documents:
The Previous Description (Chini Document)
Inchini_3dm_02a_D2d0_1G_comments-preview.pdf(Figure 192-hh), the 1 Gb/s LS path uses the RS-FEC(128,122) encoder—which is the FEC currently used for the HS path:
- FEC: 6 × RS-FEC(128,122) superframes (with L=2 interleaving) = 12,288 PAM2 symbols
- Padding: 32 Bytes = 256 PAM2 symbols
- Total LS Burst: 12,544 PAM2 symbols
The New Description (Schedl, et al. Proposal)
InSchedl_etal_3dm_01_0926.pdf(Slides 8-11), the 1 Gb/s LS path is changed to use the RS-FEC(130,124) encoder—which is the FEC already used by the 100 Mb/s LS path:
- FEC: 6 × RS-FEC(130,124) superframes (with L=2 interleaving) = 12,480 PAM2 symbols
- Padding: 8 Bytes = 64 PAM2 symbols
- Total LS Burst: 12,544 PAM2 symbols
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