6
\$\begingroup\$

Some background/research: for various reasons, many protocols use 8b/10b encoding, which encodes 8 bits of data in 10 bits of line code. However, doing so adds 25% overhead to the number of bits transmitted. To reduce this overhead, 64b/66b encoding was developed, which has only about 3% overhead. This technique was extended to 128b/130b encoding, which improves over 64b/66b by halving the overhead.

However, it seems that there is a 128b/132b encoding as well, and this doesn't seem to be a typo for 128b/130b. I have had some difficultly finding specific details about it, distinct from 64b/66b and 128b/130b. Wikipedia groups protocols that use it under the heading "128b/1XXb" which implies it has something in common with 128b/130b. One source says:

It uses the same polynomial that the 128b/130b for PCI Express 3.0, but with duplicated preamble bits.

My question is: why use it? What advantage does 128b/132b offer over 64b/66b and 128b/130b?

\$\endgroup\$
6
  • 2
    \$\begingroup\$ Welcome. In general, new encodings are either easier to do, or more resistant to some variety of noise. As your linked Wikipedia page puts it: "duplicates each of the preamble bits to reduce the risk of undetected errors there." \$\endgroup\$
    – jonathanjo
    Commented Oct 13, 2022 at 16:18
  • \$\begingroup\$ That's a good catch, I missed it on a first read of the page. However, the full quote from Wikipedia confuses me (or maybe it's just wrong?). If 128b/132b is 64b/66b with duplicated preamble bits, wouldn't it be more accurately called 64b/68b? \$\endgroup\$
    – kbolino
    Commented Oct 13, 2022 at 16:26
  • 1
    \$\begingroup\$ @jonathanjo, In general, new encodings are either easier to do, or more resistant to some variety of noise That's not true, new encodings, such as those discussed here, are not developed primarily for those reasons. The progression from 8/10b to 64/66b to 128/130b etc. was for increased efficiency, giving increased data transfer rates for the same bitrate with multibyte protocols like PCIe, USB etc. They're harder to implement, not easier, and not developed or moved to for increased noise resilience. \$\endgroup\$
    – TonyM
    Commented Oct 13, 2022 at 16:52
  • 1
    \$\begingroup\$ @Tonym ... of course you're right to make that explicit: I nearly wrote a) more efficent, b) faster, c) easier, d) more resistant. The particular question I understood was being asked was in contrast to "over 64b/66b and 128b/130b" \$\endgroup\$
    – jonathanjo
    Commented Oct 13, 2022 at 17:02
  • 1
    \$\begingroup\$ @jonathanjo, sure and no problem :-) I hope this question gets a clear and specific answer, I've done a data comms and encoding designs. Loads of us can come up with a convincing guess but there will have been a specific reason back on that decision day and that's sought here. \$\endgroup\$
    – TonyM
    Commented Oct 13, 2022 at 18:47

1 Answer 1

Reset to default
2
\$\begingroup\$

The payload data rate of 64b/66b is identical to 128b/132b, but since it uses 128 bit blocks and 4 preamble bits for the block header, it can be used for locking and detecting the block type from the preamble bits more robustly with error correction.

So in short, the 128b/132b encoding can use the 4-bit block header as a robust packet type determination mechanism between two different types of 128-bit blocks (e.g. data and control blocks), as the 4 bits provide enough error detection and correction information for the block header to correct one-bit errors and detect two-bit errors, providing a Hamming distance of 4.

The other line codes (64b/66b and 128b/130b) only allocate two bits for the block preamble, making it possible to only have a header for data or control block with error detection but without error correction. So it can only detect single bit errors and flag the blocks as invalid, as there is not enough information to correctly determine the block type if one of the preamble bits are corrupt. If both preamble bits are corrupt, then it swaps the type of block without error.

So as per the Wikipedia quote in the comments already, compared to 128b/130b, 128b/132b just duplicates the block header bits. And by expanding from 2 bits to 4 bits, it provides better error detection and error correction. 128b/132b still has exactly same overhead as 64b/66b which still uses only 2 block header bits, and just slightly worse througput than 128b/130b.

\$\endgroup\$
5
  • 1
    \$\begingroup\$ Commenting on the revised answer: You're now saying that the sync' bits (you call them block preamble here) are actually ECC bits. But they're for sync' and block type. Internet articles and an Intel patent merely mention the idea of using the 4 extra bits in 128/132b as ECC for FEC - there's nothing on any application actually doing so. Whereas you're almost saying that's those bits' prime purpose. Real examples of USB 3.2 and USB 4 both use 128/132b with the 4 bits for sync/type. So the answer's still up the wall but for a different reason, I'm afraid :-) \$\endgroup\$
    – TonyM
    Commented Oct 13, 2022 at 22:02
  • \$\begingroup\$ I did say they determine sync and block type. Kind of implicit if the 4 preamble bits are always before the 128 block bits. The two block types have patterns 0011 and 1100 for example. You may think of the extra 2 bits how you like, as ECC or something simpler like duplicates. Change one bit and see which three bits still match 0011 or 1100, the error gets corrected and block type can be determined even with 1 erroneous bit. That's very simple form of ECC. If two bits are erroneous, block type can't be determined but it is known to have errors. \$\endgroup\$
    – Justme
    Commented Oct 13, 2022 at 22:16
  • 1
    \$\begingroup\$ That's not what your answer is saying and your comment seems to be just imagining ways of using the 4 bits, unfortunately. \$\endgroup\$
    – TonyM
    Commented Oct 13, 2022 at 23:26
  • \$\begingroup\$ Well I can edit the answer with quotes from sources. But how the two extra bits in the header are used for redundancy determining the packet type is a fact, not my imagination. Can you please specify what exactly I am imagining, maybe you know something I don't? You did read the patent for 128b/132b? \$\endgroup\$
    – Justme
    Commented Oct 14, 2022 at 11:46
  • \$\begingroup\$ I have read it, see my comment, but better for you to read through what you've written and my comments rather than me writing a further lengthy justification, it's already all there. \$\endgroup\$
    – TonyM
    Commented Oct 14, 2022 at 13:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.