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

Caution: This email originated outside of Semtech.

Hi Mark,

Thanks for your comments. We agree with your observations. My colleague Xiang has a contribution focusing on the bypass options of concatenated code for the Tuesday meeting. Hope we can discuss more.

https://www.ieee802.org/3/dj/public/23_01/23_0206/he_3dj_02_230206.pdf

Regards!

Xinyuan

发件人: Mark Kimber <MKimber@xxxxxxxxxxx>
发送时间: 2023年2月7日 10:07
收件人: Wangxinyuan(Xinyuan); STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
主题: 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,

I also share your concern over the baudrate increase. I have suggested that the concatenated FEC be optional so that for less challenging links such as DR4, the concatenated FEC can be bypassed.

Many thanks for bringing this to everyone's attention.

Best regards

Mark Kimber

Sent from Outlook for Android

From: Wangxinyuan(Xinyuan) <000017911298164d-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Sunday, February 5, 2023 7:47:40 PM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx <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

Caution: This email originated outside of Semtech.

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

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.

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