Re: [802.3_B400G] Question and discussion of contributions next week mee

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

Hi Adee,

Sorry I didn't see you email before yesterday meeting.

Thanks for all of the detailed review, Yes, all of your comments are exactly right.

We think the following clarification and discussion based on yesterday's meeting could bring value to the Task Force, so we bring it to the reflector.

Considering the other two new proposals for Hamming(128,120) with padding yesterday, let’s name them as inner code E/F. I’ll list these proposals here to make it clear:

Code Option	Inner code	Code Rate	Codeword effective n bits	Message effective k bits	Baud Rate (GBd)	Bit Rate (Gb/s)	Multiple of 156.25MHz
A	Extended Hamming (128,120)	15/16	128	120	113.333…	226.666…	~725.333…
B	BCH(144,136)	17/18	144	136	112.5	225	720
C	Shortened BCH(76,68) from BCH(144,136)	17/19	76	68	118.75	237.5	760
D	Extended Hamming (128,120) shortened to (76,68) with XOR of message PAM-4 bits	17/18	144	136	112.5	225	720
E	Extended Hamming (128,120) shortened to (68,60) with XOR of message PAM-4 bits, with 384-b padding every 3264 Hamming codes	340/363	128	120	113.4375	226.875	726
F	Enhanced (128,120), with 20-b padding in every 3 Hamming codes and then removed before sending	85/91	128	120	113.75	227.5	728

Based on discussions for inner code E at Feb 6th meeting, I would like to summarize the padding related questions raised:

1, Using Padding as additional PHY feedback channel was proposed in the Task Force for the first time. Is this padding a new requirement/specification needed for Ethernet, or is it a patch-up for making Hamming(128,120) to achieve an integer PLL?

2, If the Task Force agrees to define this additional channel, any inner code can add some paddings to reach running at a higher baud rate to support this. We need more standard development work to define this channel which will further impact the progress.

3, It is clear that inner code B or D supports integer PLL without need for paddings, and thus no associated complexity or latency, with the same FEC performance.

Regards!

Xinyuan

发件人: Adee Ran (aran) <aran@xxxxxxxxx>
发送时间: 2023年2月6日 18:24
收件人: Wangxinyuan(Xinyuan); Hexiang
主题: RE: [802.3_B400G] Question and discussion of contributions next week meeting for inner code of Concatenated FEC for 200Gb/s per lambda Optical Standard

Hi Xinyuan, Xiang

Thanks for providing this presentation.

Looking at slide 7 I am a bit confused by the terms “Inner Code B or D”, “Inner code A”. The option letters A, B, C appear on slide 11 but apparently this is unrelated.

I suspect that these refer to the options listed in https://www.ieee802.org/3/df/public/22_11/bliss_3df_01b_%202211.pdf slide 4.

Also on slide 7 you have “Hamming(128, 120)” which is probably “Inner code A”.

Perhaps you could update the presentation to clarify.

Thanks

</Adee>

From: Wangxinyuan(Xinyuan) <000017911298164d-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Sunday, 5 February 2023 16:18
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: [802.3_B400G] Question and discussion of contributions next week meeting for inner code of Concatenated FEC for 200Gb/s per lambda Optical Standard

Dear Colleagues,

With all contributions for next week meeting posted, we received a couple of inquiries on the FEC performance statement in slide 7 of wangx_3dj_01_230206, and the overall performance degradation due to baud rate increase associated with concatenated code.

Data in he_3dj_01_230206.pdf shows the theoretical NCG for the RS(544,514)+Hamming(128,120) code is merely 0.014dB higher than using (144,136). But the final baud rate when using this (128,120) as the inner code with additional padding bits will be 113.4375 GBd comparing to 112.5 GBd for (144,136). And as shown in welch_3dj_01_230206.pdf slide 5, the degradation of increased baud rate from 112.5 GBd to 113.3 GBd seems to be about -0.1dB optical. The overall performance of (144,136) would be better than the (128,120) if we consider this degradation. ? Although I would also say this small difference in terms of performance is not noticeable in real applications. (Hope I did not mess up the direction of degradation. Please correct me if I am wrong about this.)

However, with higher baud rate, it will always have higher power. The additional power saved by using a lower baud rate code, such as (144,136) @ 112.5GBd instead of (128,120) + padding @ 113.4375 GBd in overall E2E optical PHY/link, can be better used to improve soft-decoding algorithm for more coding gain. Some basic ideas like using more LRPs or using more test patterns were mentioned in slides 5-6 of he_3dj_01_230206.pdf. Or, we could even use more sophisticated decoding algorithms than Chase-II (which we used for faster simulations) for better performance.

Given the challenges we are facing on 200Gb/s per lambda IM-DD optics, I am happy for more discussions about this on the reflector, and looking forward to more discussions in the Task Force.

Thanks,

Xinyuan

To unsubscribe from the STDS-802-3-B400G list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G&A=1

Re: [802.3_B400G] Question and discussion of contributions next week meeting for inner code of Concatenated FEC for 200Gb/s per lambda Optical Standard