| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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>
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:
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 |