3. 线速率与编码方案：线速率计算、8B/10B编码、64B/66B编码、扰码器原理
各位好，咱们今天聊聊高速收发器里一个绕不开的话题——线速率与编码方案。说实话，我刚入行那会儿，总觉得这些编码啊、扰码啊，都是些理论上的花架子。直到有一次，我调试一块25Gbps的板子，眼图怎么都睁不开，最后发现是编码方案选错了，导致DC平衡没做好。嗯，从那以后，我再也不敢小看这些“花架子”了。
3.1 线速率计算：别被数字唬住
线速率，说白了就是信号在物理链路上实际跑的比特率。它跟咱们常说的数据速率可不是一回事。你想想看，数据速率是有效载荷的速率，而线速率还得算上编码开销。
公式其实很简单：
线速率 = 数据速率 × (编码后比特数 / 编码前比特数)举个例子，我做过一个10Gbps的以太网项目。数据速率是10Gbps，用的是64B/66B编码。那么线速率就是：
10 Gbps × (66 / 64) = 10.3125 Gbps你看，多了312.5Mbps的开销。这可不是小数目。我在项目中遇到过有人直接把10Gbps当线速率去选器件，结果链路死活跑不通。所以啊，选型的时候一定要算清楚。
3.2 8B/10B编码：经典但有点“胖”
8B/10B编码，是SerDes领域的老前辈了。它的原理很简单：把8位数据映射成10位码字。多出来的2位干嘛用？保证DC平衡，提供时钟恢复信息。
我个人习惯把8B/10B编码的优缺点总结成一张表：
| 优点 | 缺点 |
|---|---|
| DC平衡好，适合AC耦合 | 20%的开销，效率低 |
| 有专用控制字符（K码） | 实现复杂，需要查找表 |
| 游程长度可控（最长5个连续相同位） | 线速率高时功耗大 |
我记得在PCIe Gen1/Gen2时代，8B/10B编码是标配。但现在嘛，到了25Gbps以上，20%的开销就有点吃不消了。所以后来有了64B/66B编码。
3.3 64B/66B编码：更高效的“瘦身”方案
64B/66B编码，顾名思义，每64位数据只增加2位开销。效率从80%提升到了约97%。这多出来的17%可不是小数目，在高速链路里，这意味着一大笔带宽。
它的工作原理是这样的：
- 每64位数据块前加2位同步头（Sync Header）
- 同步头“01”表示数据块，“10”表示控制块
- 没有专用的K码，控制信息嵌入在数据块中
我做过一个100G以太网的项目，用的就是64B/66B编码。说实话，刚开始调的时候挺头疼的。因为它的同步头只有2位，误判概率比8B/10B的K码要高。后来我加了一个同步头校验状态机，才把误锁率降下来。
3.4 扰码器原理：让数据“随机化”
扰码器，名字听着挺玄乎，其实原理很简单。它就是用伪随机序列对数据进行异或处理，让数据看起来更“随机”。为什么要这么做？
- 避免长串的0或1，保证时钟恢复
- 减少EMI（电磁干扰）
- 改善DC平衡
常用的扰码器多项式有：
// 用于64B/66B编码的扰码器
// 多项式: x^58 + x^39 + 1
// 实现方式: 线性反馈移位寄存器 (LFSR)
// 伪代码示例
reg [57:0] lfsr;
always @(posedge clk) begin
if (reset) begin
lfsr <= 58'h1; // 不能全0
end else begin
lfsr <= {lfsr[56:0], lfsr[57] ^ lfsr[38]};
end
end
// 加扰: data_out = data_in ^ lfsr[57];我建议你在实现扰码器时，注意两个坑：
- 初始值不能全0——全0的LFSR会一直输出0，等于没加扰
- 收发双方的扰码器必须同步——否则解扰出来的数据全是错的
3.5 知识体系总览
说了这么多，咱们用一张图来总结一下本章的核心逻辑。这张图是我自己画的，把线速率、编码方案和扰码器的关系理清楚了。
这张图把咱们今天讲的内容串起来了。从上往下看：先算线速率，再选编码方案，最后用扰码器兜底。三者缺一不可。
好了，关于线速率与编码方案，咱们就聊到这儿。记住一句话：编码方案决定了链路的效率，扰码器决定了链路的可靠性。两者相辅相成，缺一不可。
可可精品资料库