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