Re: [802.3_SPEP2P] Question on 8b10b to PAM4

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

Hi Adee,

I agree with a lot of what you said. I thought about the Interlaken approach, but one constraint here is

latency and with each bit time being 10ns and a hard constraint of 1.5us it takes too much bit accumulation

to figure out the inversion. The second issue is how to error correct the inversion control bit if it gets corrupted.

As for your last point on controlling PAM4 inversion, I am working on a variant of that idea and will present during the interim.

This scheme uses more bandwidth than the Interlaken approach, but it is FEC friendly.

You made a good point that extreme disparity has not been observed on scrambled 64/65 or 64/66 coding.

This articulates a point I’m asking the group as whether we really need to worry about disparity with a good

scrambler in place since disparity protection is expensive. I guess if it comes down to increasing bandwidth

to guarantee no industrial plant ever goes boom in our lifetime because of energy accumulation

on the line it may be worth it.

Thanks,

William

From: Adee Ran (aran) <0000147b29386f6c-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, January 12, 2024 01:25
To: STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_SPEP2P] Question on 8b10b to PAM4

Hello P802.3dg,

I happened to see this discussion on the reflector, though I’m haven’t tracked this task force activity before.

I understand that 8B10B is suggested to be added to a bit pattern which has been scrambled by the PCS, for the purpose of maintaining DC balance. I assume this is required, despite the fact that extreme disparity has not been an issue in other flavors of Ethernet that use scrambled 64B/65B or 64B/66B encoding.

I’d like to raise a concern about using 8B10B encoding for this purpose, from my experience with this encoding in older technologies such as 1000BASE-X and PCS express gen1/2.

In addition to being very wasteful in bandwidth (25% overhead), the output of 8B10B encoding has poor spectral properties. Even with a random input into the mapper (due to scrambling), the run length is limited to 5 bits, and thus there is no low frequency content. This is part of the benefit when AC coupling is assumed, but it can have unexpected bad effects when adaptive equalization is attempted, and on Baud-rate CDR architectures which are common at high data rates.

It may be interesting to note that Ethernet and other technologies (PCI express, USB, Fibre Channel and InfiniBand are the ones I’m aware of) have abandoned 8B10B when transitioning from early generations without bandwidth limitations – where equalization was not assumed and CDR was the main challenge – to higher rates where bandwidth became a concern. I’m not aware of any successful implementation of adaptive equalization in those early generations.

I don’t know much about your applications and channel assumptions but if PAM4 is used I assume that bandwidth is limited and thus equalization is likely required. Adding a 25% bandwidth overhead in a scheme that uses PAM4 seems questionable. The concerns about adaptation with 8B10B add to that; I know I’m just handwaving here, but I suggest that you look into this issue.

If disparity control is important for your application, an alternative to 8B10B encoding could be adding a disparity control bit in the PCS blocks. This has been done in the Interlaken protocol, as one example, which uses 64B/67B block (64B/66B plus a disparity control bit, which enables inversion of a block to maintain DC balance). This technique is much more bandwidth efficient, and maintains the white spectrum of the scrambler output, making it friendly to adaptive equalization. A similar approach can be taken with other block encodings such as the one used in SPE. If PAM4 is used, it may be better to add a disparity control PAM4 symbol that would invert the PAM4 polarity; it can also be used for framing, since it needs only two values.

</Adee>

From: William Lo <will@xxxxxxxxxx>
Sent: Friday, January 12, 2024 10:13 AM
To: STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_SPEP2P] Question on 8b10b to PAM4

Hi Tingting,

Thanks for clarifying.

This is a very clever way to not just to suppress DC but guarantee a bound on the PAM4 disparity.

There is one issue I see with this and that is if one PAM4 symbol

gets damaged, both 8/10 symbols can potentially be corrupted

meaning two RS-symbols are corrupted instead of just 1.

This severely weakens the FEC protection given that there are

only 6 parity symbols in most of the proposals (I agree that 6 RS symbols is

a good number). If 2 PAM4 symbols are corrupted in the same

RS frame and it propagates to 4 RS symbol errors then the frame

is uncorrectable.

If there is a way to contain the PAM4 symbol corruption to only one RS symbol error

then it would be good.

Thanks,

William

From: zhangtingting (O) <zhangtingting59@xxxxxxxxxx>
Sent: Thursday, January 11, 2024 19:10
To: William Lo <will@xxxxxxxxxx>; STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx
Subject: 答复: Question on 8b10b to PAM4

Hi William,

Each PAM4 symbol has two bits (LSB and MSB), which are separately encoded by 8B/10B before the binary symbol mapper instead of the commonly used Gray mapper. In this way, DC components should be well suppressed. Let me know if you have any further questions.

Best wishes,

Tingting

发件人: William Lo [mailto:will@xxxxxxxxxx]
发送时间: 2024年1月12日 2:17
收件人: STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx
主题: [802.3_SPEP2P] Question on 8b10b to PAM4

Hi Tingting,

You mentioned in the ad hoc that my assumptions on doing the

8b/10b to PAM4 conversion was incorrect. I tried using that method

and the PSD near DC didn’t look very good. Can you show me the

right way to do the conversion.

Thanks,

William

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