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

Re: [802.3_ISAAC] Question abut Schedl_etal_3dm_01_0926.pdf

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)
In chini_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)
In Schedl_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