Adee – thank you for monitoring! – getting insight from experts in other areas almost always helps progress.
You are correct that bounding the baseline wander (disparity control) is generally considered necessary in these industrial applications. We have objectives to not preclude use in intrinsically
safe applications, and to support line powering – similar to 10BASE-T1L. In order to bound the voltage (sum of power and data), we need to control the dc balance.
In 10BASE-T1L we used a disparity control scheme on the 4B3T PAM-3 encoding. 8B10B is being proposed as an alternative. You raise a few good points, and I thank you for pointing to the interlaken
protocol. I found a reference to it at
https://interlakenalliance.com/wp-content/uploads/2019/12/Interlaken_Protocol_Definition_v1.2.pdf . I note I can’t post the document because it is copyrighted, but also note that various sources claim it is royalty free. You describe the technique fairly
well below, for those who want to see more, see section 5.4.2 of the above document. It looks like that is the essential piece. This would involve a 64 bit encoding and hence a 64 bit latency, but it appears the technique should be extensible to other block
lengths if desired. I admit to not being intimately familiar with Interlaken, so I could be mistaken.
You also raise the point not only of bandwidth efficiency, but of low frequency content. This is a very good point, especially because we are on long (high insertion loss) links, and one that I
think may have been overlooked in some of the phy discussions. Those looking at balanced encodings in the PCS should look at the effect on the actual output spectrum of the transmitter. Many of these act as highpass filters on the symbol stream, and as a
result, cut out low frequency content (which has lower transmission loss) and reduce the SNR available at the receiver. We need to consider how much of the low frequency content is lost in order to determine the impact on performance. Higher efficiency encodings
usually correspond to less loss bandwidth at the low end as well, which is likely to have a performance impact against fixed noise. Losing 3 or more dB on 20% of the Nyquist bandwidth (approximation to the 20% overhead of 8B10B) is more than half a dB in
Salz margin and could start to add up in terms of performance and should be accounted for. And, because the higher frequencies are more attenuated, the effect is likely slightly larger.
Thanks again for paying attention, and for spurring the thought!
-george
From: stds-802-3-spep2p@xxxxxxxxxxxxxxxxx <stds-802-3-spep2p@xxxxxxxxxxxxxxxxx>
On Behalf Of Adee Ran (aran)
Sent: Friday, January 12, 2024 1:25 AM
To: STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx
Subject: RE: 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
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
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
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