64b/66b encoding

<h2 id="function">Function</h2>
<p>As its scheme name suggests, 64 payload <a href="/facts/Bit/RwfjaYSv">bits</a> are encoded as a 66-bit entity. The 66-bit entity is made by prefixing one of two possible 2-bit preambles to the 64 payload bits. This 66-bit entity is now of two possible states.
</p>
<ul><li>If the preamble is 012, the 64 payload bits are data.</li>
<li>If the preamble is 102, the 64 payload bits hold an 8-bit Type field and 56 bits of control information and/or data.</li></ul>
<p>The preambles 002 and 112 are not used and indicate an error if seen.
</p><p>The use of the 012 and 102 preambles guarantees a bit transition every 66 bits, which means that a continuous stream of 0s or 1s cannot be valid data.  It also allows easier clock/timer synchronization, as a transition must be seen every 66 bits.
</p><p>The 64-bit payload is then scrambled using a self-synchronous <a href="/facts/Scrambler_(randomizer)/7w50xTmw">scrambler</a> function.  Scrambling is not intended to encrypt the data but to ensure that a relatively even distribution of 1s and 0s are found in the transmitted data. The scrambler cannot guarantee that output data will never have a long run-length of 0s or all 1s, or other undesirable properties in communications, but does allow strong statistical bounds to be put on the probability of such events. Practical designs will choose system parameters such that a bit-error due to long run-lengths is vanishingly unlikely. This method is different from the code-book based approach of <a href="/facts/8b%2f10b_encoding/bxnMBwaC">8b/10b encoding</a>.
</p><p>The encoding and scrambling are normally implemented entirely in hardware, with the scrambler using a <a href="/facts/Linear-feedback_shift_register/22pktBbX">linear-feedback shift register</a>. Upper layers of the software stack need not be aware that the link layer is using these methods.
</p>
<h2 id="properties-and-application">Properties and application</h2>
<p>64b/66b's design goals are clock recovery, stream alignment, DC balance, transition density and run length. 8b/10b encoding guarantees strict bounds on DC balance, transition density and run length, whereas 64b/66b provides statistical bounds on these properties.
</p>
<h3>Run length</h3>
<p>Most clock recovery circuits designed for SONET OC-192 and 64b/66b are specified to tolerate an 80-bit run length.  Such a run cannot occur in 64b/66b because transitions are guaranteed at 66-bit intervals, and in fact long runs are very unlikely. Although it is theoretically possible for a random data pattern to align with the scrambler state and produce a long run of 65 zeroes or 65 ones, the probability of such an event is equal to flipping a <a href="/facts/Fair_coin/vTBk29k7">fair coin</a> and having it come up in the same state 64 times in a row.  At 10 Gigabits per second, the expected event rate of a 66-bit block with a 65-bit run-length, assuming random data, is 66×264÷1010÷2 seconds, or about once every 1900 years.
</p><p>The run length statistics may get worse if the data consists of specifically chosen patterns, instead of being random. An earlier scrambler used in <a href="/facts/Packet_over_SONET%2fSDH/V7RSvI5c">Packet over SONET/SDH</a> (<a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc1619">1619</a> (1994)) had a short polynomial with only 7 bits of internal state which allowed a malicious attacker to create a <a href="/facts/Denial-of-service_attack/6nkoK02J">Denial-of-service attack</a> by transmitting patterns in all 27−1 states, one of which was guaranteed to de-synchronize the clock recovery circuits.  This vulnerability was kept secret until the scrambler length was increased to 43 bits (<a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc2615">2615</a> (1999)) making it impossible for a malicious attacker to jam the system with a short sequence.
</p><p>64b/66b avoided this vulnerability by using a scrambling polynomial with enough random internal state (58 bits) so that a dedicated attacker using a crafted Ethernet packet can only create a 64-bit run-length in the scrambler output once in about 29 years.<a class="footnote-ref" id="fnref:1" href="#fn:1"><sup>1</sup></a>: 11–13  This creates 66-bit blocks containing 65-bit runs at a rate similar to using random data.
</p>
<h3>DC balance</h3>
<p>The DC balance of 64b/66b is not absolutely bounded.  However, it can be shown that the scrambler output closely approximates a sequence of random binary bits.  Passing such a sequence through an AC-coupled circuit produces a baseline wander noise that follows a <a href="/facts/Gaussian_distribution/UapjjPyQ">Gaussian distribution</a>, and the impact on the system error rate can be statistically quantified.  In practice, a modest coupling capacitor value of 1 nF in a 100 Ω system is sufficient to guarantee that a DC drift of more than 2.5% will occur less often than once per 1022 bits (about 31,700 years at 10 Gbit/s). [1]:15–16
</p>
<h3>Hamming distance</h3>
<p><a href="/facts/10_Gigabit_Ethernet/FvxUohpf">10 Gigabit Ethernet</a> has a strict charter requiring a Mean Time to False Packet Acceptance (MTTFPA) to be on the order of 1 billion years for a single operating link. To achieve this at normal bit error rates requires at least a 4-bit <a href="/facts/Hamming_distance/MgdtbYPo">Hamming distance</a> protection for all packet data.  In other words, all combinations of 3 randomly spaced bit-flips within a packet boundary must be detected and result in an invalidated packet. Several strategies were combined to achieve the 4-bit Hamming distance for 64b/66b packets: 1) strong type fields were chosen with 4-bit Hamming distance, 2) the scrambler polynomial was chosen to be compatible with the CRC-32 used for packet protection and 3) protocol violations adjacent to the packet boundaries are required to invalidate the packet.  The combination of CRC-32 and the chosen scrambler polynomial were evaluated by exhaustively enumerating all 4-bit error patterns for all possible packet sizes with an optimized C program.
</p>
<h3>Observations</h3>
<p>The main contribution of 64b/66b is the observation that deterministic run length and transition density of 8b/10b are not always worth a 25% code overhead, and that solid robust systems could be designed using statistically bounded methods. At some point, practical risks, whether from <a href="/facts/Mean_time_between_failures/lWCg38LX">MTBF</a> of components such as power supplies or from phenomena such as <a href="/facts/Cosmic_ray/uxCVdTKd">cosmic rays</a> or <a href="/facts/Solar_flare/6kCvPKxD">solar flares</a>, dominate the reliability of both 8b/10b and 64b/66b systems.
</p>
<h3>Variations</h3>
<p>The <a href="/facts/Interlaken_(networking)/md4ALM0w">Interlaken</a> protocol improves the DC balance further by trading off more coding bits. Its 64b/67b encoding extends 64b/66b with explicit DC balancing. This may be beneficial for some applications, such as using smaller on-chip coupling capacitors.
</p><p><a href="/facts/PCI_Express/ADhsLCUK">PCI Express</a> 3.0 introduced 128b/130b encoding, which is similar to 64b/66b but has a payload of 128 bits instead of 64 bits, and uses a different scrambling polynomial: <i>x</i>23 + <i>x</i>21 + <i>x</i>16 + <i>x</i>8 + <i>x</i>5 + <i>x</i>2 + 1.  It is also not self-synchronous and so requires explicit synchronization of seed values, in contrast with 64b/66b.
</p><p><a href="/facts/USB_3.1/WTnYm1IS">USB 3.1</a> and <a href="/facts/DisplayPort_2.0/rJSvGhBN">DisplayPort 2.0</a> use 128b/132b encoding, which is identical to 64b/66b, but duplicates each of the preamble bits to reduce the risk of undetected errors there.
</p>
<h3>Successors</h3>
<p>For each {<i>n</i>}b/{<i>n</i>+2}b encoding, the symbol/data ratio is always below 1. With a ratio of 0.985 for 128b/130b encoding, there is no real margin for improvement.
</p><p>The following approaches are available to further increase the data rate:
</p>
Higher symbol rates combined with <a href="/facts/Forward_error_correction/cLUTUJrA">FEC</a>

<p>Very common are 512b/514b encodings combined with <a href="/facts/Reed%25E2%2580%2593Solomon_error_correction/HPc3Qj6N">Reed–Solomon error correction</a>. 
The following variants are often used:
</p>
<ul><li>RS(528,514,07,10), adding 14 correction bits to the 512b/514b code word, allowing to correct up to 07 corrupted bits. Overhead is 3%, same as 64b/66b encoding</li>
<li>RS(544,514,14,10), adding 30 correction bits to the 512b/514b code word, allowing to correct up to 15 corrupted bits. Overhead is 6%.</li></ul>
<p>The FEC allows symbol error rates of 2.3 · 10−5 or 2.2 · 10−4 to achieve a <a href="/facts/Bit_error_rate/ovAAPFjV">bit error rate</a> of less than 10−15 in the transmitted data.
</p>
Multi-level encoding combined with FEC

<p>Further improvements are possible by switching from PAM-2 to <a href="/facts/PAM-4/Y30VmMJI">PAM-4</a> or <a href="/facts/Differential_signaling/jusjFQKo">Ensemble</a> <a href="/facts/Non-return-to-zero/8f3cfm9r">NRZ</a> coding.
</p>
<a href="/facts/Trellis_modulation/QqfUccMq">Multi-level Trellis modulation</a> combined with FEC

<h2 id="technologies-that-use-64b66b-encoding">Technologies that use 64b/66b encoding</h2>

<ul><li><a href="/facts/100_Gigabit_Ethernet/DRV0aeNu">100 Gigabit Ethernet</a></li>
<li><a href="/facts/10G-EPON/jjfUuBL0">10G-EPON</a>, 10 Gbit/s Ethernet Passive Optical Network</li>
<li><a href="/facts/10_Gigabit_Ethernet/FvxUohpf">10 Gigabit Ethernet</a> (most varieties)</li>
<li><a href="/facts/Aurora_(protocol)/XrW0hDDR">Aurora</a>, from <a href="/facts/Xilinx/rbXfxqqG">Xilinx</a></li>
<li>Camera Link HS</li>
<li><a href="/facts/Common_Public_Radio_Interface/P7AbdhXB">Common Public Radio Interface</a></li>
<li><a href="/facts/Fibre_Channel/C7C0yreb">Fibre Channel</a> 10GFC and 16GFC</li>
<li><a href="/facts/InfiniBand/6CUz47wQ">InfiniBand</a></li>
<li><a href="/facts/Thunderbolt_(interface)/x6pqMKHY">Thunderbolt</a></li>
<li>JESD204C</li></ul>

<h2 id="technologies-that-use-128b1xxb-encoding">Technologies that use 128b/1xxb encoding</h2>

<ul><li><a href="/facts/NVLink/l5RGqeba">NVLink</a> 1.0</li>
<li><a href="/facts/PCI_Express/ADhsLCUK">PCIe 3.x</a></li>
<li><a href="/facts/PCI_Express/ADhsLCUK">PCIe 4.x</a></li>
<li><a href="/facts/PCI_Express/ADhsLCUK">PCIe 5.x</a></li>
<li><a href="/facts/SATA/dW8yAMm8">SATA</a> 3.2</li>
<li><a href="/facts/Serial_Attached_SCSI/ekU6NmqQ">SAS</a> 4</li>
<li><a href="/facts/USB_3.0/WTnYm1IS">USB 3.1 Gen2</a></li>
<li><a href="/facts/USB4/RfJPVG3X">USB4</a></li>
<li><a href="/facts/DisplayPort/rJSvGhBN">DisplayPort 2.0</a></li></ul>

<h2 id="technologies-that-use-256b257b-encoding">Technologies that use 256b/257b encoding</h2>

<ul><li><a href="/facts/Fibre_Channel/C7C0yreb">Fibre Channel</a> 32GFC "Gen 6" and higher</li></ul>

<h2 id="external-links">External links</h2>
<ul><li><a href="https://grouper.ieee.org/groups/802/3/10G_study/public/jan00/walker_1_0100.pdf">64b/66b low-overhead coding proposal for serial links</a></li></ul>
Note that this is the original proposal to the IEEE, and some changes were made for the final, agreed standard. The circuit diagram for the 58-bit scrambling polynomial described in the proposal is identical to the one adopted in the standard. However, the proposal numbers the registers in reverse order such that the x58+x19+1 polynomial in the proposal is the same as the one labelled x58+x39+1 in the standard.
<ul><li><a href="https://patents.google.com/patent/US6650638">US Patent/US6650638: Decoding method and decoder for 64b/66b coded packetized serial data</a></li>
<li><a href="https://patents.google.com/patent/US6718491">US Patent/US6718491: Coding method and coder for packetized serial data with low overhead</a></li>
<li><a href="https://patents.google.com/patent/US7055073">US Patent/US7055073: Coding method for coding packetized serial data with low overhead</a></li>
<li><a href="https://web.archive.org/web/20070310192256/http://gauss.ffii.org/PatentView/EP1133123">PatentView/EP1133123 Software Patent: 64b/66b decoding, for packetized serial data</a></li>
<li><a href="https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1556959">ERROR CORRECTION ON 64/66 BIT ENCODED LINKS</a></li>
<li><a href="http://www.iol.unh.edu/services/testing/10gec/training/10GbE_Cl49.pdf#search=%2264B%2F66B%20encoding%22">Introduction to 10 Gigabit 64b/66b (Clause 49)</a></li>
<li><a href="http://www.xilinx.com/support/documentation/application_notes/xapp775.pdf">A reference design by Xilinx on 64b/66b encoding and scrambling</a></li>
<li><a href="https://web.archive.org/web/20100513022320/http://www.xilinx.com/products/ipcenter/aurora64b66b.htm">Aurora 64B66B IP core using 64b/66b encoding</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>R.C. Walker; R. Dugan (January 18–20, 2000). "64b/66b low-overhead coding proposal for serial links" (PDF). IEEE 802.3 High Speed Study Group. <a href="/wiki/R" target="_blank">/wiki/R</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
</ol>

64b/66b encoding open-in-new

64b/66b encoding