4、编码与解码技术：8B/10B编码原理、64B/66B编码原理、前向纠错（FEC）基础

各位做高速收发器的朋友，咱们今天聊聊编码解码。说白了，这就是给数据“穿衣服”的过程。你想想看，原始数据在高速链路上裸奔，肯定不行——没有时钟信息，没有直流平衡，跑着跑着就丢了。我这些年调试过不少链路，有一半的坑都出在编码选择上。

8B/10B编码，说白了就是把8位数据映射成10位码字。为什么要多出2位？为了保证DC平衡和足够的跳变沿。

核心原理：

我记得第一次调PCIe Gen2的时候，链路就是起不来。后来发现是8B/10B编码的RD极性搞反了。嗯，这里要注意：RD初始值必须收发双方一致，否则解码全错。

  关键特性：
  最大游程长度：5位（保证有足够跳变）
DC平衡：长期来看0和1数量相等
编码效率：80%（10Gbps链路实际数据只有8Gbps）

特殊码字（K码）：

8B/10B预留了12个K码用于控制。我习惯用K28.5做逗号码，因为它有独特的“0011111010”模式，便于字节对齐。曾经有个项目，接收端对齐逻辑写错了，结果每128个字节就错位一次，查了整整两天。

// 8B/10B编码示例（Verilog）
// 数据：0x5A (01011010)
// 编码后：10'b1010101010 (假设RD=-1)
// 注意：实际编码需要查表，这里只是示意

8B/10B效率只有80%，对于100Gbps以上的链路来说太浪费了。64B/66B应运而生，效率提升到97%。

编码结构：

你可能会问：为什么不用8B/10B了？说白了，在25Gbps以上的速率，每浪费1%的带宽就是几百兆的损失。64B/66B用2位开销换64位有效数据，这笔账很划算。

我的经验：64B/66B的同步头检测一定要做“滑动窗口”匹配。我曾经遇到过连续3个错误同步头导致链路失锁的情况，后来加了容错机制才稳定。

加扰技术：

64B/66B通常配合加扰使用。我建议用自同步加扰（如X^58 + X^39 + 1多项式），这样接收端不需要额外同步。但要注意：加扰后的数据不能全0或全1，否则锁相环会失锁。

FEC，说白了就是给数据加冗余，让接收端能自己纠错。我刚开始做光通信时觉得FEC可有可无，直到有一次在实验室看到误码率10^-12的链路加上FEC后直接降到10^-15……嗯，从那以后我再也不敢小看FEC了。

常见FEC类型：

FEC带来的代价：

注意：FEC不是万能的。我曾经在一个项目中，误码率高达10^-6，以为加上FEC就能解决。结果FEC纠错能力饱和，反而引入了更多错误。记住：FEC只能处理随机错误，对突发错误效果有限。

我整理了一张对比表，方便大家选型：

特性	8B/10B	64B/66B	FEC
效率	80%	97%	视开销而定
DC平衡	优秀	需加扰	不保证
时钟恢复	容易	较容易	需配合编码
纠错能力	无	无	有
典型应用	PCIe, SATA	10G/25G以太网	光通信, 无线

我的选型建议：

最后说一句：编码选择没有银弹。我见过有人非要在低速链路上用64B/66B，结果资源消耗大、延迟高，得不偿失。合适的才是最好的。

可可精品资料库