Why do we need bit scrambling when using 8b/10b?

I want to ask the opposite of this question.

Here are the purpose of the bit scramblers:

• Encrypt, but LFSR (and other used) bit-scramblers are breakable.
• Clock recovery, but it is done by the 8b/
• DC offset, but it is done by the 8b/10b.
• (Are there any?)

Why do we need bit scrambling when using 8b/10b?

• Scrambling improves resistance to loss of several bits in a row, due to a single noise event? – tomnexus Oct 11 '18 at 10:22
• @tomnexus I don't believe so. For example, CRCs can detect longer burst sequences than distributed errors. It would help for distributing burst errors between separate data blocks (such as used in CD-ROMs) but in such situation there is no advantage to scrambling - you can just use a fixed interleaving pattern. Might be some form of error detection/recovery I am overlooking though. – Jon Oct 11 '18 at 10:31

To refer to the original question, in SATA it is used to reduce the EMI emitted by the bus. If you look at the way 8b/10b encoding works, you'll see that it is entirely possible to have the same 10b word encoded throughout the message for certain 8b input values.

For example, the input 00100011 always encodes to 1001110001. So a message that consists entirely of 0x23 bytes will create a repeating sequence of:

1001110001100111000110011100011001110001...


This periodic sequence concentrates the signal energy into a small number of harmonics. Given the way EMC tests are conducted (looking at emissions within narrow bands) you are basically making life harder for yourself by allowing the overall energy to concentrate like this. By scrambling the data you statistically eliminate these sorts of periodic occurrences, and ensure that the signal energy is always spread out evenly across the available channel bandwidth.

• There are byte sequences, which results the same effect also using bit-scrambling. (Descramble a byte sequence of same bytes.) But it is probably true, that we send same bytes more often than sending this special byte sequences. – betontalpfa Oct 11 '18 at 11:03

I have found another aspect in the UG476 Xilinx's document.

DFE mode must be carefully considered in 8B/10B applications or where data scrambling is not employed. To properly adapt to data, the auto adaptation in DFE mode requires incoming data to be random. For example, in a XAUI application, the user payload data is non-scrambled and 8B/10B encoded. While the user payload is generally random, the frequency content of the data is inherently limited by the encoding, and there is nothing defined in the protocol to prevent repeated patterns from occurring. These repeated patterns can cause the auto adapting algorithms to drift away from the ideal equalization setting.