做基带和存储控制器的同行大概都遇到过一个尴尬标准码表里的码长永远是 2^m-1 这种数字15、31、63、255、511、1023可你手里的数据块偏偏是 188 字节、512 字节、1KB怎么凑都对不上。要么塞一堆填充位白白浪费带宽要么干脆换一套码。截短循环码、BCH码、RS码这三样东西基本就是解决这类“尺寸不匹配”问题的完整工具箱——截短负责把码长掰成你想要的尺寸BCH负责在二进制域上把随机错误一个个摁死RS负责在符号级上兜住成片出现的突发错误。这篇不打算照抄教材上的定理证明而是按我这些年做编码仿真、写译码器、跟硬件对齐波形的顺序把这三块内容重新捋一遍重点讲清楚每一步“为什么这么设计”“哪里容易算错”“仿真和实现为什么对不上”。1. 从循环码到截短码码长对不上时到底在动什么理解截短这件事前提是把循环码那套结构记牢。因为截短的所有操作都是在循环码的矩阵和多项式表示上做减法你要是对生成多项式的地位没吃透后面看矩阵删行删列就会觉得莫名其妙。这一节先把底子打实再谈截短到底动了哪块。1.1 循环码的三个性质决定后面所有玩法循环码最核心的定义是一个 (n,k) 线性码如果任意码字的循环移位还是码字那它就是循环码。这个看起来平淡的性质等价于说这个码在多项式环 GF(q)[x]/(x^n-1) 里构成一个理想而理想必然由一个多项式生成——这就是生成多项式 g(x) 的来历。由此推出三条在工程上天天要用的性质。第一条g(x) 必须是 x^n-1 的因式deg g(x) n-k。这条决定了你能构造出哪些码长的码也解释了为什么码长总是卡在 2^m-1 附近只有这种长度x^n-1 才能分解成漂亮的本原多项式乘积g(x) 才好挑。第二条所有码字多项式 c(x) 都是 g(x) 的倍数写成 c(x) g(x)u(x)deg u(x) ≤ k-1。第三条系统码可以通过“移位取余”一步到位把信息多项式 m(x) 左移 n-k 位得到 x^{n-k}m(x)对 g(x) 取余得到校验多项式 r(x)码字就是 c(x) x^{n-k}m(x) r(x)。第三条是实操里用得最多的因为它直接给出编码器的移位寄存器结构——一个 (n-k) 级的线性反馈移位寄存器输入信息位从高到低进来走完 k 拍之后寄存器里剩下的就是 r(x)。我见过不少人第一次写编码器时想用矩阵乘法能跑但资源吓人换成 LFSR 之后资源直接掉一个数量级这个差别在后续做高速编码的时候非常致命。还有一条容易忽略的循环码的校验矩阵 H 也很规整H 的行是 x^{n-ki} mod g(x) 之类的循环移位本质上就是 g(x) 的互反多项式的系数循环排列。记不住具体形式没关系记住“H 也是循环结构”就够了后面截短的时候要用到这个规整性。1.2 截短的操作对象是高位信息位不是码元本身现在说正题。假设你有一个 (n,k) 循环码最小距离 d但你的数据块只需要 k-s 个信息位其中 s k。最直接的想法是把码长改成 n-s那这时候该怎么办截短的标准做法是这样的把原码的信息位分成两段前 s 位强制置零后 k-s 位装真实数据。这样得到的码字集合前 s 位永远是 0把它们直接删掉不发送剩下 n-s 位就是截短码的码字。形式化一点写C_s { (c_{n-s-1}, ..., c_0) : (c_{n-1}, ..., c_0) ∈ C, c_{n-1} ... c_{n-s} 0 }这里有一个特别容易搞混的点删掉的是 s 个信息位以及由它们产生的校验影响不是随意删任意 s 个码元。因为前 s 位固定为 0删掉它们不会丢失任何信息但剩下的位里已经隐含了这 s 个零位对校验位的贡献。所以截短之后码字的校验结构还是完整的只是“起点”变了。从矩阵角度看更清楚。把生成矩阵化成系统形式 G [I_k | P]k 行 n 列。前 s 位信息位固定为 0意味着我们只用后 k-s 行同时输出的码字里也不含前 s 列那些列对应的就是被删掉的位。所以截短码的生成矩阵就是G_s G 去掉前 s 行、去掉前 s 列得到 (k-s) × (n-s) 的矩阵形式仍然是 [I_{k-s} | P]。校验矩阵更简单只删列不删行H_s H 去掉前 s 列得到 (n-k) × (n-s)。行数不变因为校验方程的个数没变——这个细节非常关键它直接说明了截短码付出了什么代价。代价是什么校验位数还是 n-k但信息位数从 k 降到了 k-s。也就是说你用同样的校验开销只传输了更少的信息。码率从 k/n 掉到 (k-s)/(n-s)一定是下降的。拿 (15,7) 码举例码率 0.467截短成 (12,4)码率变成 0.333掉了将近三成。这是截短的必然代价天下没有免费的尺寸适配。1.3 截短之后哪些性质保住了哪些丢了这是我在带新人的时候被问得最多的问题截短码还是循环码吗答案是一般情况下不是。因为循环移位的封闭性依赖码长 n 和 x^n-1 这个环结构你把长度改成 n-sx^{n-s}-1 完全是另一个多项式原来的 g(x) 未必还能整除它循环性质自然就断了。但有两个性质是保住的而且是最值钱的两个性质是否保持说明线性保持零位约束和删位都是线性操作截短码仍是线性码最小距离不减小通常相等d_s ≥ d实践中最常见 d_s d循环性一般丢失码长变了环结构不成立系统码形式保持G_s 仍是 [I | P] 形式编码器可以直接复用校验位数量保持仍是 n-k这是代价所在最小距离不减小这点值得多说两句。因为截短码的码字集合是原码字集合的子集补零之后一一对应所以两个不同码字之间的汉明重量关系完全不变距离分布是原分布的“截取”。实践中最关心的是最小距离能不能维持住只要原码里存在一个前 s 位全零、重量为 d 的最小重量码字那 d_s 就等于 d。绝大多数常用的 BCH 码和 RS 码都满足这个条件所以在工程设计上我们一般直接按 d_s d 来算纠错能力。还有一个隐含的好处不太有人提截短之后码字变短了同样纠 t 个错误错误在图样里的“密度”变高了但对译码算法本身没有影响。真正的影响在于短码的译码复杂度按码长指数下降如果你用穷举或者查表类译码截短能省不少资源。这也是为什么很多存储控制器明明可以用长码却偏偏选一个截短过的中等长度码——译码延迟和面积都是实打实的成本。2. 截短循环码的矩阵构造与译码改动点知道原理是一回事真把矩阵写出来、把译码器跑通是另一回事。这一节给具体的构造步骤以及工程上最省事的那条路——补零复用原译码器。2.1 生成矩阵与校验矩阵的同步删列先说构造流程按顺序走不会错。第一步确定原码参数 (n, k, d)拿到生成多项式 g(x)。这一步通常查表比如 (15,7,5) 的 g(x) x^8 x^7 x^6 x^4 1。第二步构造系统形式的生成矩阵。方法是让信息向量取单位向量 e_i编码得到码字作为第 i 行。对 (15,7) 码来说就是 7 行 15 列。第三步确定截短量 s目标码长 n n - s目标信息位 k k - s。第四步删行删列。G_s 取 G 的第 s1 到 k 行、第 s1 到 n 列。H_s 取 H 的第 s1 到 n 列行全保留。这里有个实操上的小坑如果你的 G 不是严格系统形式比如是从多项式直接展开的循环矩阵删列的位置必须和“哪些信息位被置零”严格对应否则编出来的码字校验关系是错的。我建议不管原矩阵什么形式先化成系统形式再截短多花一步化简约但省掉后面所有的调试时间。还有一点H_s 的行数虽然是 n-k但它的秩可能小于 n-k——因为删列之后某些校验方程可能线性相关。这不影响译码正确性但如果你要用 H_s 做伴随式计算得接受“伴随式向量可能有冗余分量”这个事实。实际实现里我们一般不做 H 的降秩处理因为冗余带来的只是少量无效计算降秩反而增加逻辑复杂度。2.2 伴随式译码在截短码上的等价性这一小节是整篇文章里最实用的部分我把它单独拎出来讲是因为它能让你的工作量减少一大半。截短码的译码最省事的做法是不写新译码器直接补零复用原码译码器。具体操作收到 n-s 位的接收向量 r在它前面补 s 个 0凑成 n 位送进原 (n,k) 码的译码器。为什么这样是对的因为截短码的每一个合法码字补零之后都是原码的合法码字。而信道错误只可能发生在实际传输的 n-s 位上补上去的 s 位错误值恒为 0。所以“补零后的接收向量”和“原码码字加错误图样”在形式上完全一致原译码器自然会把它当成一个前 s 位无错的原码字来处理。这个等价性有一个前提需要确认错误图样的重量不能超过原码的纠错能力 t。这一点在截短码上是自动满足的因为截短码的纠错能力就是 t由最小距离决定错误图样本来就在这个范围内。所以补零方案在理论上是严格的不是近似。实际收益很直观。假设你有一个已经验证过的 BCH 译码器 IP现在要支持一个短了 51 个符号的变体按传统思路要重算 BM 迭代次数、重做钱搜索的域元素表工作量不小用补零方案只需要在输入端加一个零填充逻辑输出端把对应位置的结果丢弃一两天就能改完。我在几个项目里都是这么干的稳定性比重新写一遍高得多。代价是译码器内部还是在按 n 的长度算伴随式计算、BM 迭代、钱搜索的循环次数都没减少功耗和延迟没有优化。如果你的场景对这块不敏感大多数低速控制信道都是这样补零就是最优解如果是高速链路才值得专门做变长译码优化。2.3 手算一个 (12,8) 截短码的例子抽象讲完走一遍具体数字心里才踏实。取 (15,11) 汉明码最小距离 3纠 1 位错生成多项式 g(x) x^4 x 1。现在数据只需要 8 位截短 s 3得到 (12,8) 码。生成矩阵取系统形式前 11 列是单位阵后 4 列是校验部分。截短后取第 4 到 11 行、第 4 到 15 列得到 8×12 的 G_s左边 8×8 是单位阵右边 8×4 是校验块 P。编码时信息向量 m8 位乘以 G_s 得到 12 位码字。等价的多项式做法是把 m(x) 看成 11 次多项式但高 3 位系数为 0乘 x^4 后对 g(x) 取余得到 4 位校验拼成 15 位码字再去掉高 3 位。两种做法结果完全一致我通常用多项式做法写参考模型用矩阵做法写硬件两边互相校验。译码时收到 12 位前面补 3 个 0 变成 15 位算伴随式 S r(α)汉明码只需一个伴随式分量。如果 S 0认为无错如果 S α^i说明第 i 位出错翻转它。注意位置索引要按 15 位算翻转完之后再去掉前 3 位得到 12 位的译码结果。这个流程里唯一的“新东西”就是补零和去零这两步其余全部复用。我建议第一次实现的时候把补零前后的向量都打印出来用一个小脚本穷举所有单比特错误确认 12 个位置的错误都能被正确定位——这个验证花不了半小时但能省掉后面几天的怀疑人生。3. BCH码把纠错能力当成可调参数来点菜循环码里最实用的一支就是 BCH因为它把“纠几个错”变成了一个可以直接填的参数。你要纠 2 位就填 t2要纠 8 位就填 t8码长和信息位会自动跟着算出来。这种“点菜式”的设计思路是它在存储和通信里铺开的关键原因。3.1 从最小多项式到生成多项式的拼接逻辑BCH 码的构造本质上是把“码字在若干个域元素上取值为零”这个约束翻译成生成多项式。具体来说本原 BCH 码的码长 n 2^m - 1取 GF(2^m) 的本原元 α如果我们要求所有码字多项式 c(x) 都满足c(α) c(α^3) c(α^5) ... c(α^{2t-1}) 0那么这个约束就能保证码的最小距离至少是 2t1也就是能纠 t 个错。这个结论来自 BCH 界是这套码的理论基石。要让 c(x) 在这些点上为零g(x) 必须包含每个 α^{2i-1} 的最小多项式 m_{2i-1}(x)。因为二进制域上的多项式系数只能是 0 或 1共轭元素的根必须成组出现所以最小多项式的次数可能大于 1这也解释了为什么实际校验位数 n-k 常常小于 m·t 这个上界。写成公式g(x) LCM( m_1(x), m_3(x), ..., m_{2t-1}(x) )取最小公倍数是为了去掉重复的因式——不同 α^i 的最小多项式可能相同直接乘会把次数算大生成的码就不是最优的。这一步在手工推导时经常被略过导致算出来的 k 比实际小白白浪费信息位。举个具体例子(15,7,5) 码m4t2。需要 m_1(x) 和 m_3(x)两个都是 4 次且互不相同所以 g(x) 是 8 次n-k8k7。展开之后 g(x) x^8 x^7 x^6 x^4 1。这个多项式建议直接背下来调试的时候经常要用。3.2 参数表与多纠一位的真实成本工程上没人每次都从头推 g(x)都是查现成的参数表。下面这张表是我常用的几组覆盖了从短码到 255 长度的常见配置(n, k)tn-k典型用途(15, 11)14短帧控制信道(15, 7)28教学与短块保护(31, 21)210中等长度信令(63, 45)318传感器数据帧(127, 106)321中速链路(255, 239)216光传输、存储页保护(255, 223)432高可靠存储从这张表能直接读出一个规律在同一个码长下每多纠一位错大约要多付 m 个校验位。255 长度m8的码t 从 2 涨到 4校验位从 16 涨到 32正好是 8 的倍数关系。这个规律来自上界 n-k ≤ m·t实际值可能因为最小多项式合并而略小于这个数但量级是对的。这个成本账在做方案时特别重要。假设你的链路误码率是 1e-3一个 255 位的块平均有 0.255 个错误t1 就能覆盖大部分情况但尾部概率不够t2 之后误块率能压到 1e-6 量级t4 能压到 1e-10 以下但校验开销翻倍。到底选哪个得结合你的重传机制算——如果上层有 ARQt1 加偶尔重传往往比 t4 更划算因为省下来的校验位可以直接换成有效吞吐。3.3 BM迭代译码的每一步在做什么BCH 译码是四步走算伴随式、求错误位置多项式、找根、翻转。中间那步用 Berlekamp-Massey 迭代是整套流程里最绕的地方我按自己的理解拆一遍。伴随式好理解就是把接收多项式 r(x) 在 α^1, α^3, ..., α^{2t-1} 这些点上求值。如果全为零说明没有错误或者错误刚好在码的零化集里概率极低。只要有一个非零就进入纠错流程。BM 迭代的目标是找一个次数尽量低的 polynomial σ(x)使得它和伴随式序列满足一个线性递推关系。用人话说就是“用最少的系数去解释观测到的伴随式序列”。迭代过程维护三个量当前的 σ(x)、一个辅助多项式 B(x)、以及当前的阶数 L。每一轮计算一个偏差量 Δ如果 Δ 为零说明当前 σ 已经能解释这一轮的伴随式直接把 B 左移一位如果 Δ 非零就用 Δ 和 B 去修正 σ并检查是否需要更新阶数。下面是核心循环的一个 Python 骨架跑在 GF(2^8) 上逻辑对 BCH 和 RS 通用def bm_iterate(S, t, gf_mul, gf_inv): sigma [1] [0] * t B [1] [0] * t L, m, b 0, 1, 1 for r in range(2 * t): delta S[r] for i in range(1, L 1): delta ^ gf_mul(sigma[i], S[r - i]) if delta 0: m 1 continue T sigma[:] coef gf_mul(delta, gf_inv(b)) for i in range(t 1 - m): sigma[i m] ^ gf_mul(coef, B[i]) if 2 * L r: L, B, b, m r 1 - L, T, delta, 1 else: m 1 return sigma[:L 1], L这段代码有几个容易写错的地方我按踩坑顺序列一下。第一delta的求和范围是 1 到 L不是 0 到 L因为 σ[0] 恒为 1单独处理。第二b记录的是上一次更新时的 delta 值用于归一化忘了这个会导致结果差一个常数因子表面上跑得通但根的位置全错。第三m是“距离上次阶数更新过了多少轮”它的更新时机和 B 的移位是绑定的写反了会死循环或者阶数算错。3.4 二进制BCH不需要福尼算法但RS必须要这一步是区分 BCH 和 RS 实现的关键。二进制 BCH 码的错误值只能是 1一个比特要么错要么不错所以钱搜索找到根之后直接把对应位置翻转就完事了不需要额外算错误幅值。但 RS 码不一样它的符号是 GF(2^m) 上的元素错误值可以是任意非零元素所以必须用福尼算法算出每个位置的错误幅值。公式是e_i ω(α^{-i}) / σ(α^{-i})其中 ω(x) S(x)σ(x) mod x^{2t} 是错误求值多项式σ(x) 是 σ(x) 的形式导数。在特征为 2 的域上形式导数有个化简偶数次项的导数系数是 0奇数次项的系数原样保留所以 σ(x) 其实就是 σ(x) 的奇次项按位取出来实现上只是一次掩码操作几乎不花资源。我之前在一篇记录里看到有人把福尼算法用在二进制 BCH 上跑是能跑但算出来的错误幅值恒为 1等于白算一遍除法。这个浪费在 FPGA 上可能就是一个除法器的面积值得避免。4. RS码符号级纠错与突发错误的处理逻辑RS 码在工程上的地位很大程度上不是因为它在随机错误上比 BCH 强而是因为它对突发错误的处理方式太对胃口了。存储介质的缺陷、无线信道的衰落、光盘的划痕这些错误都是成片出现的RS 的符号级纠错正好对路。4.1 RS码是GF(2^m)上的BCH码这句话的实际含义教材上说 RS 码是 BCH 码的特例很多人的理解停在“公式长得像”。实际上这句话的含义要具体得多RS 码的符号取自 GF(2^m)码长 n 2^m - 1生成多项式的根是 α, α^2, ..., α^{2t}注意是连续的 2t 个根不是 BCH 那样的奇数下标。这个“连续”是关键差别。BCH 只取奇数下标的根是因为二进制域上共轭结构会把偶数下标的约束自动满足RS 的符号域和系数域是同一个域没有这个共轭化简所以必须把 2t 个根全部列进去。这就导致 RS 的校验符号数正好是 2tn - k 2t一点不含糊。由此得到 RS 最重要的性质最小距离 d n - k 1。这个等式是取等号的不是不等式。满足这个等号的码叫 MDS 码极大距离可分码RS 是其中最典型的一类。它的意义是在给定码长和校验符号数的前提下RS 的纠错能力达到了理论上限没有比它更强的了。这个性质直接决定了参数选择的方式。你想要纠 t 个符号错就必须付出 2t 个校验符号没有讨价还价空间。RS(255,223) 的 n-k 32t 就只能是 16d 33。想要 t20那就得用 RS(255,215)校验符号 40 个。简单粗暴但也正因为如此工程上的计算从来不会出错。RS 配置n-ktd可纠连续比特错误m8(255, 247)84932 bit(255, 239)1681764 bit(255, 223)321633128 bit(255, 191)643265256 bit最后那列要解释一下一个符号是 8 位纠 t 个符号错最坏情况下这 t 个错误符号是连续排列的那就是 8t 个连续比特错误。所以 RS(255,239) 名义上纠 8 个符号实际能扛住 64 位的连续突发。这个数字在存储纠错里非常经典很多闪存控制器的纠错目标就是按这个量级定的。4.2 缩短RS码在真实系统里的用法RS 的码长也是 2^m - 1 这种数255、511、1023跟实际数据块还是对不上。这时候截短就派上用场了而且 RS 的截短比二进制码更常见因为 RS 的符号粒度大截短几个符号对码率的影响更明显需要精打细算。最典型的例子是数字广播传输里用的 (204,188) 码。它是由 RS(255,239) 截短 51 个符号得到的n 255 - 51 204k 239 - 51 188。188 正好是一个传输包的长度204 是加上 16 个校验符号之后的长度。纠错能力保持 t8 不变能扛 8 个符号错。这个设计非常讲究。为什么截短 51 而不是别的数因为 188 是业务层的包长改不了而 16 个校验符号是纠错能力的需求也不能减。两个约束一夹截短量就定死了。这就是截短码在工程上的真实定位它不是可选项而是被系统参数倒逼出来的必然结果。缩短 RS 码还有一个细节要提。截短之后那些“被删掉的符号位置”在译码时是补零处理的但补的零并不是真实传输的符号如果译码器把它们当成可能出错的位置去搜索会浪费算力甚至引入误判。正确的做法是在钱搜索阶段直接跳过这些位置只在实际传输的 n 个位置上找根。这一点在写硬件译码器时要特别注意搜索范围是 [0, n-1] 而不是 [0, n-1]。4.3 交织深度怎么算才不浪费单靠 RS 扛突发错误能力是有上限的——t 个符号就是天花板。要扛更长的突发就得靠交织把 I 个码字按符号轮流输出信道上的连续错误就被打散到 I 个码字里每个码字只承受大约 1/I 的错误密度。具体算法设目标突发长度 B单位是符号RS 的纠错能力是 t需要满足ceil(B / I) ≤ t即 I ≥ ceil(B / t)这个公式看着简单实际用的时候有两个坑。第一个坑是交织本身不增加纠错能力只做错误分布的重新安排。如果突发长度超过了 I × t那再深的交织也救不回来因为总纠错容量就那么多。所以交织深度不是越大越好它只是把 RS 的能力“摊平”到更长的距离上。第二个坑是交织带来的延迟。深度 I 的交织器至少要缓存 I 个码字才能输出完整的一组延迟是 I × n 个符号时间。在实时性要求高的链路上这个延迟可能直接超标。我见过一个方案为了扛 500 符号的突发把交织深度设到 32结果端到端延迟多了 20 毫秒被迫回退重做。后来改成两级交织加分组才在延迟和纠错之间找到平衡。还有一个变通方案叫卷积交织它不需要整块缓存用两组 RAM 做乒乓就能实现延迟只有 I × n / 2 左右代价是突发错误的分布不如块交织均匀。这个取舍在做方案时要提前想清楚别等实现了才发现延迟不达标。5. 工程落地参数选型、实现取舍与仿真对齐前面四节讲的是原理和构造这一节讲的是把东西做出来的过程中真正会卡住人的地方。这些东西教材上不会写但每一个都能让你多熬两个晚上。5.1 三个最容易被算错的指标做编码方案评审的时候我发现错误几乎总是集中在这三个指标上而且错的方式很一致。第一个是码率。很多人算码率直接用 k/n这没错但在截短码上就错了。截短之后应该用 (k-s)/(n-s)如果你拿原码的 k/n 去估算吞吐会高估一大截。我见过一个方案按 0.93 的码率做带宽预算实际截短后只有 0.87链路直接跑不满。正确的做法是把截短量显式写进预算表别偷懒。第二个是纠错能力对应的误块率。很多人只记“能纠 t 个错”就默认超过 t 个错一定失败t 个以内一定成功。前半句对后半句不完全对——超过 t 个错误时译码器不一定会报错它可能“纠”到一个错误的码字上这叫误纠。误纠的概率在短码上不能忽略尤其是在高信噪比下误纠往往会成为误块率的地板。做方案时要单独评估这个地板值别把理论曲线当实际性能。第三个是缩短码的实际纠错能力。虽然理论上 d_s ≥ d但在某些特定的截短量下最小重量码字可能被截掉了导致实际最小距离大于 d。这时候按 d 算纠错能力是保守的没问题但如果你反过来假设“截短后能力一定等于 d”去做性能预测会低估实际性能浪费了余量。这个偏差不大但在做精细的链路预算时会显现出来。指标常见错误算法正确算法后果码率k/n(k-s)/(n-s)吞吐高估 5%~10%纠错后误块率只看 t 以内加上误纠地板高信噪比性能预测偏乐观截短码纠错能力直接取原码 t按 d_s ≥ d 保守估计保守通常安全5.2 有限域乘法器的查表与逻辑实现之争这个选择题几乎每个做编码硬件的人都会遇到GF(2^m) 的乘法是用查找表还是用组合逻辑查表法的思路很直接把两个 8 位操作数的乘积预先算好存成 256×256 的表或者用对数表转成加法。资源占用上256 字节的 ROM 在现在的工艺下几乎不算什么延迟也只有一个 ROM 访问周期非常适合低速场景。但查表法有两个硬伤。一是表的大小随 m 指数增长m8 是 256 项还能接受m10 就是 1024 项m12 直接到 4096 项面积开始吓人。二是多路并行时表会被复制多份因为每个乘法器都要独立访问。在高速译码器里伴随式计算需要 2t 个并行的乘法表就要复制 2t 份面积一下就上去了。组合逻辑法也就是常说的位并行乘法器用异或网络实现m8 时大约需要 60 到 80 个异或门延迟 3 到 4 级。面积比单份表大但不随并行度线性膨胀因为逻辑可以共享。高速设计基本都走这条路代价是综合后的时序要仔细约束。我个人的经验分界线是时钟频率低于 100MHz、并行度不超过 4 路用查表超过这个范围用组合逻辑。中间地带可以混合——把乘法拆成“高位查表 低位逻辑”兼顾面积和速度。这个混合方案我在一个中等速率的控制器项目里用过综合下来面积比纯逻辑省三成时序还能跑到 150MHz。5.3 仿真跑通了但硬件对不上通常卡在哪这是最让人抓狂的一类问题Python 参考模型和 Verilog 仿真结果不一致或者 Verilog 仿真对了上板子跑出来误码率不对。按我的排查经验问题九成出在下面几个地方。第一是域元素表示约定不一致。同样是 GF(256)有人用 α 的幂次表示有人用多项式基表示有人用比特反转的顺序存。这三套表示混用乘法结果看着像随机的。排查方法很简单让两边都输出 α^0 到 α^7 的乘法表逐项对比第一处不一致就是问题所在。第二是缩短码的索引偏移。补零方案里补的零在数组的哪一端直接影响位置索引的计算。如果参考模型是“低位补零”而硬件是“高位补零”钱搜索找到的根位置会整体偏移 s翻转的位就全错了。这个 bug 特别隐蔽因为无错的时候完全正常一有错就崩。建议在参考模型里把补零位置写成显式参数两边对齐。第三是伴随式计算的起始下标。BCH 的伴随式从 α^1 开始算还是从 α^0 开始算不同教材写法不同实现时必须统一。这个错会导致 σ(x) 的系数整体错位表现是“能纠一部分错另一部分纠错后错误更多”。我一般会在代码里把起始指数定义成常量改的时候只改一处。第四是有限域的加法被误写成减法。特征为 2 的域里加减法都是异或这个大家都知道但在移植参考代码时如果原代码是通用有限域库里面可能保留了减法运算而减法在 GF(2^m) 上等于加法不会报错但逻辑是冗余的。更危险的是把“取负”当成“取反”在某些表示下这两者不等价。排查这类问题的标准流程我固定成四步先用全零输入验证无错通路再用单个已知位置的错误验证定位逻辑然后用两个错误验证 BM 迭代最后用随机错误跑统计。每一步都对比参考模型和硬件的中间变量别只比最终输出——中间变量对上了问题一定在后面的步骤中间变量对不上问题就在这一步的输入或算法本身。最后分享一个我觉得挺有用的小习惯每次做新的编码方案先在纸上把 (n, k, t, d, s) 这五个数写清楚贴在显示器边上。调试过程中每次怀疑参数抬头看一眼能省掉很多“我是不是把 255 记成 511 了”这类低级混乱。这套码的东西参数一错后面全错而且错得很隐蔽先把这个钉死剩下的都好办。 做基带和存储控制器的同行大概都遇到过一个尴尬标准码表里的码长永远是 2^m-1 这种数字15、31、63、255、511、1023可你手里的数据块偏偏是 188 字节、512 字节、1KB怎么凑都对不上。要么塞一堆填充位白白浪费带宽要么干脆换一套码。截短循环码、BCH码、RS码这三样东西基本就是解决这类“尺寸不匹配”问题的完整工具箱——截短负责把码长掰成你想要的尺寸BCH负责在二进制域上把随机错误一个个摁死RS负责在符号级上兜住成片出现的突发错误。这篇不打算照抄教材上的定理证明而是按我这些年做编码仿真、写译码器、跟硬件对齐波形的顺序把这三块内容重新捋一遍重点讲清楚每一步“为什么这么设计”“哪里容易算错”“仿真和实现为什么对不上”。1. 从循环码到截短码码长对不上时到底在动什么理解截短这件事前提是把循环码那套结构记牢。因为截短的所有操作都是在循环码的矩阵和多项式表示上做减法你要是对生成多项式的地位没吃透后面看矩阵删行删列就会觉得莫名其妙。这一节先把底子打实再谈截短到底动了哪块。1.1 循环码的三个性质决定后面所有玩法循环码最核心的定义是一个 (n,k) 线性码如果任意码字的循环移位还是码字那它就是循环码。这个看起来平淡的性质等价于说这个码在多项式环 GF(q)[x]/(x^n-1) 里构成一个理想而理想必然由一个多项式生成——这就是生成多项式 g(x) 的来历。由此推出三条在工程上天天要用的性质。第一条g(x) 必须是 x^n-1 的因式deg g(x) n-k。这条决定了你能构造出哪些码长的码也解释了为什么码长总是卡在 2^m-1 附近只有这种长度x^n-1 才能分解成漂亮的本原多项式乘积g(x) 才好挑。第二条所有码字多项式 c(x) 都是 g(x) 的倍数写成 c(x) g(x)u(x)deg u(x) ≤ k-1。第三条系统码可以通过“移位取余”一步到位把信息多项式 m(x) 左移 n-k 位得到 x^{n-k}m(x)对 g(x) 取余得到校验多项式 r(x)码字就是 c(x) x^{n-k}m(x) r(x)。第三条是实操里用得最多的因为它直接给出编码器的移位寄存器结构——一个 (n-k) 级的线性反馈移位寄存器输入信息位从高到低进来走完 k 拍之后寄存器里剩下的就是 r(x)。我见过不少人第一次写编码器时想用矩阵乘法能跑但资源吓人换成 LFSR 之后资源直接掉一个数量级这个差别在后续做高速编码的时候非常致命。还有一条容易忽略的循环码的校验矩阵 H 也很规整H 的行是 x^{n-ki} mod g(x) 之类的循环移位本质上就是 g(x) 的互反多项式的系数循环排列。记不住具体形式没关系记住“H 也是循环结构”就够了后面截短的时候要用到这个规整性。1.2 截短的操作对象是高位信息位不是码元本身现在说正题。假设你有一个 (n,k) 循环码最小距离 d但你的数据块只需要 k-s 个信息位其中 s k。最直接的想法是把码长改成 n-s那这时候该怎么办截短的标准做法是这样的把原码的信息位分成两段前 s 位强制置零后 k-s 位装真实数据。这样得到的码字集合前 s 位永远是 0把它们直接删掉不发送剩下 n-s 位就是截短码的码字。形式化一点写C_s { (c_{n-s-1}, ..., c_0) : (c_{n-1}, ..., c_0) ∈ C, c_{n-1} ... c_{n-s} 0 }这里有一个特别容易搞混的点删掉的是 s 个信息位以及由它们产生的校验影响不是随意删任意 s 个码元。因为前 s 位固定为 0删掉它们不会丢失任何信息但剩下的位里已经隐含了这 s 个零位对校验位的贡献。所以截短之后码字的校验结构还是完整的只是“起点”变了。从矩阵角度看更清楚。把生成矩阵化成系统形式 G [I_k | P]k 行 n 列。前 s 位信息位固定为 0意味着我们只用后 k-s 行同时输出的码字里也不含前 s 列那些列对应的就是被删掉的位。所以截短码的生成矩阵就是G_s G 去掉前 s 行、去掉前 s 列得到 (k-s) × (n-s) 的矩阵形式仍然是 [I_{k-s} | P]。校验矩阵更简单只删列不删行H_s H 去掉前 s 列得到 (n-k) × (n-s)。行数不变因为校验方程的个数没变——这个细节非常关键它直接说明了截短码付出了什么代价。代价是什么校验位数还是 n-k但信息位数从 k 降到了 k-s。也就是说你用同样的校验开销只传输了更少的信息。码率从 k/n 掉到 (k-s)/(n-s)一定是下降的。拿 (15,7) 码举例码率 0.467截短成 (12,4)码率变成 0.333掉了将近三成。这是截短的必然代价天下没有免费的尺寸适配。1.3 截短之后哪些性质保住了哪些丢了这是我在带新人的时候被问得最多的问题截短码还是循环码吗答案是一般情况下不是。因为循环移位的封闭性依赖码长 n 和 x^n-1 这个环结构你把长度改成 n-sx^{n-s}-1 完全是另一个多项式原来的 g(x) 未必还能整除它循环性质自然就断了。但有两个性质是保住的而且是最值钱的两个性质是否保持说明线性保持零位约束和删位都是线性操作截短码仍是线性码最小距离不减小通常相等d_s ≥ d实践中最常见 d_s d循环性一般丢失码长变了环结构不成立系统码形式保持G_s 仍是 [I | P] 形式编码器可以直接复用校验位数量保持仍是 n-k这是代价所在最小距离不减小这点值得多说两句。因为截短码的码字集合是原码字集合的子集补零之后一一对应所以两个不同码字之间的汉明重量关系完全不变距离分布是原分布的“截取”。实践中最关心的是最小距离能不能维持住只要原码里存在一个前 s 位全零、重量为 d 的最小重量码字那 d_s 就等于 d。绝大多数常用的 BCH 码和 RS 码都满足这个条件所以在工程设计上我们一般直接按 d_s d 来算纠错能力。还有一个隐含的好处不太有人提截短之后码字变短了同样纠 t 个错误错误在图样里的“密度”变高了但对译码算法本身没有影响。真正的影响在于短码的译码复杂度按码长指数下降如果你用穷举或者查表类译码截短能省不少资源。这也是为什么很多存储控制器明明可以用长码却偏偏选一个截短过的中等长度码——译码延迟和面积都是实打实的成本。2. 截短循环码的矩阵构造与译码改动点知道原理是一回事真把矩阵写出来、把译码器跑通是另一回事。这一节给具体的构造步骤以及工程上最省事的那条路——补零复用原译码器。2.1 生成矩阵与校验矩阵的同步删列先说构造流程按顺序走不会错。第一步确定原码参数 (n, k, d)拿到生成多项式 g(x)。这一步通常查表比如 (15,7,5) 的 g(x) x^8 x^7 x^6 x^4 1。第二步构造系统形式的生成矩阵。方法是让信息向量取单位向量 e_i编码得到码字作为第 i 行。对 (15,7) 码来说就是 7 行 15 列。第三步确定截短量 s目标码长 n n - s目标信息位 k k - s。第四步删行删列。G_s 取 G 的第 s1 到 k 行、第 s1 到 n 列。H_s 取 H 的第 s1 到 n 列行全保留。这里有个实操上的小坑如果你的 G 不是严格系统形式比如是从多项式直接展开的循环矩阵删列的位置必须和“哪些信息位被置零”严格对应否则编出来的码字校验关系是错的。我建议不管原矩阵什么形式先化成系统形式再截短多花一步化简约但省掉后面所有的调试时间。还有一点H_s 的行数虽然是 n-k但它的秩可能小于 n-k——因为删列之后某些校验方程可能线性相关。这不影响译码正确性但如果你要用 H_s 做伴随式计算得接受“伴随式向量可能有冗余分量”这个事实。实际实现里我们一般不做 H 的降秩处理因为冗余带来的只是少量无效计算降秩反而增加逻辑复杂度。2.2 伴随式译码在截短码上的等价性这一小节是整篇文章里最实用的部分我把它单独拎出来讲是因为它能让你的工作量减少一大半。截短码的译码最省事的做法是不写新译码器直接补零复用原码译码器。具体操作收到 n-s 位的接收向量 r在它前面补 s 个 0凑成 n 位送进原 (n,k) 码的译码器。为什么这样是对的因为截短码的每一个合法码字补零之后都是原码的合法码字。而信道错误只可能发生在实际传输的 n-s 位上补上去的 s 位错误值恒为 0。所以“补零后的接收向量”和“原码码字加错误图样”在形式上完全一致原译码器自然会把它当成一个前 s 位无错的原码字来处理。这个等价性有一个前提需要确认错误图样的重量不能超过原码的纠错能力 t。这一点在截短码上是自动满足的因为截短码的纠错能力就是 t由最小距离决定错误图样本来就在这个范围内。所以补零方案在理论上是严格的不是近似。实际收益很直观。假设你有一个已经验证过的 BCH 译码器 IP现在要支持一个短了 51 个符号的变体按传统思路要重算 BM 迭代次数、重做钱搜索的域元素表工作量不小用补零方案只需要在输入端加一个零填充逻辑输出端把对应位置的结果丢弃一两天就能改完。我在几个项目里都是这么干的稳定性比重新写一遍高得多。代价是译码器内部还是在按 n 的长度算伴随式计算、BM 迭代、钱搜索的循环次数都没减少功耗和延迟没有优化。如果你的场景对这块不敏感大多数低速控制信道都是这样补零就是最优解如果是高速链路才值得专门做变长译码优化。2.3 手算一个 (12,8) 截短码的例子抽象讲完走一遍具体数字心里才踏实。取 (15,11) 汉明码最小距离 3纠 1 位错生成多项式 g(x) x^4 x 1。现在数据只需要 8 位截短 s 3得到 (12,8) 码。生成矩阵取系统形式前 11 列是单位阵后 4 列是校验部分。截短后取第 4 到 11 行、第 4 到 15 列得到 8×12 的 G_s左边 8×8 是单位阵右边 8×4 是校验块 P。编码时信息向量 m8 位乘以 G_s 得到 12 位码字。等价的多项式做法是把 m(x) 看成 11 次多项式但高 3 位系数为 0乘 x^4 后对 g(x) 取余得到 4 位校验拼成 15 位码字再去掉高 3 位。两种做法结果完全一致我通常用多项式做法写参考模型用矩阵做法写硬件两边互相校验。译码时收到 12 位前面补 3 个 0 变成 15 位算伴随式 S r(α)汉明码只需一个伴随式分量。如果 S 0认为无错如果 S α^i说明第 i 位出错翻转它。注意位置索引要按 15 位算翻转完之后再去掉前 3 位得到 12 位的译码结果。这个流程里唯一的“新东西”就是补零和去零这两步其余全部复用。我建议第一次实现的时候把补零前后的向量都打印出来用一个小脚本穷举所有单比特错误确认 12 个位置的错误都能被正确定位——这个验证花不了半小时但能省掉后面几天的怀疑人生。3. BCH码把纠错能力当成可调参数来点菜循环码里最实用的一支就是 BCH因为它把“纠几个错”变成了一个可以直接填的参数。你要纠 2 位就填 t2要纠 8 位就填 t8码长和信息位会自动跟着算出来。这种“点菜式”的设计思路是它在存储和通信里铺开的关键原因。3.1 从最小多项式到生成多项式的拼接逻辑BCH 码的构造本质上是把“码字在若干个域元素上取值为零”这个约束翻译成生成多项式。具体来说本原 BCH 码的码长 n 2^m - 1取 GF(2^m) 的本原元 α如果我们要求所有码字多项式 c(x) 都满足c(α) c(α^3) c(α^5) ... c(α^{2t-1}) 0那么这个约束就能保证码的最小距离至少是 2t1也就是能纠 t 个错。这个结论来自 BCH 界是这套码的理论基石。要让 c(x) 在这些点上为零g(x) 必须包含每个 α^{2i-1} 的最小多项式 m_{2i-1}(x)。因为二进制域上的多项式系数只能是 0 或 1共轭元素的根必须成组出现所以最小多项式的次数可能大于 1这也解释了为什么实际校验位数 n-k 常常小于 m·t 这个上界。写成公式g(x) LCM( m_1(x), m_3(x), ..., m_{2t-1}(x) )取最小公倍数是为了去掉重复的因式——不同 α^i 的最小多项式可能相同直接乘会把次数算大生成的码就不是最优的。这一步在手工推导时经常被略过导致算出来的 k 比实际小白白浪费信息位。举个具体例子(15,7,5) 码m4t2。需要 m_1(x) 和 m_3(x)两个都是 4 次且互不相同所以 g(x) 是 8 次n-k8k7。展开之后 g(x) x^8 x^7 x^6 x^4 1。这个多项式建议直接背下来调试的时候经常要用。3.2 参数表与多纠一位的真实成本工程上没人每次都从头推 g(x)都是查现成的参数表。下面这张表是我常用的几组覆盖了从短码到 255 长度的常见配置(n, k)tn-k典型用途(15, 11)14短帧控制信道(15, 7)28教学与短块保护(31, 21)210中等长度信令(63, 45)318传感器数据帧(127, 106)321中速链路(255, 239)216光传输、存储页保护(255, 223)432高可靠存储从这张表能直接读出一个规律在同一个码长下每多纠一位错大约要多付 m 个校验位。255 长度m8的码t 从 2 涨到 4校验位从 16 涨到 32正好是 8 的倍数关系。这个规律来自上界 n-k ≤ m·t实际值可能因为最小多项式合并而略小于这个数但量级是对的。这个成本账在做方案时特别重要。假设你的链路误码率是 1e-3一个 255 位的块平均有 0.255 个错误t1 就能覆盖大部分情况但尾部概率不够t2 之后误块率能压到 1e-6 量级t4 能压到 1e-10 以下但校验开销翻倍。到底选哪个得结合你的重传机制算——如果上层有 ARQt1 加偶尔重传往往比 t4 更划算因为省下来的校验位可以直接换成有效吞吐。3.3 BM迭代译码的每一步在做什么BCH 译码是四步走算伴随式、求错误位置多项式、找根、翻转。中间那步用 Berlekamp-Massey 迭代是整套流程里最绕的地方我按自己的理解拆一遍。伴随式好理解就是把接收多项式 r(x) 在 α^1, α^3, ..., α^{2t-1} 这些点上求值。如果全为零说明没有错误或者错误刚好在码的零化集里概率极低。只要有一个非零就进入纠错流程。BM 迭代的目标是找一个次数尽量低的 polynomial σ(x)使得它和伴随式序列满足一个线性递推关系。用人话说就是“用最少的系数去解释观测到的伴随式序列”。迭代过程维护三个量当前的 σ(x)、一个辅助多项式 B(x)、以及当前的阶数 L。每一轮计算一个偏差量 Δ如果 Δ 为零说明当前 σ 已经能解释这一轮的伴随式直接把 B 左移一位如果 Δ 非零就用 Δ 和 B 去修正 σ并检查是否需要更新阶数。下面是核心循环的一个 Python 骨架跑在 GF(2^8) 上逻辑对 BCH 和 RS 通用def bm_iterate(S, t, gf_mul, gf_inv): sigma [1] [0] * t B [1] [0] * t L, m, b 0, 1, 1 for r in range(2 * t): delta S[r] for i in range(1, L 1): delta ^ gf_mul(sigma[i], S[r - i]) if delta 0: m 1 continue T sigma[:] coef gf_mul(delta, gf_inv(b)) for i in range(t 1 - m): sigma[i m] ^ gf_mul(coef, B[i]) if 2 * L r: L, B, b, m r 1 - L, T, delta, 1 else: m 1 return sigma[:L 1], L这段代码有几个容易写错的地方我按踩坑顺序列一下。第一delta的求和范围是 1 到 L不是 0 到 L因为 σ[0] 恒为 1单独处理。第二b记录的是上一次更新时的 delta 值用于归一化忘了这个会导致结果差一个常数因子表面上跑得通但根的位置全错。第三m是“距离上次阶数更新过了多少轮”它的更新时机和 B 的移位是绑定的写反了会死循环或者阶数算错。3.4 二进制BCH不需要福尼算法但RS必须要这一步是区分 BCH 和 RS 实现的关键。二进制 BCH 码的错误值只能是 1一个比特要么错要么不错所以钱搜索找到根之后直接把对应位置翻转就完事了不需要额外算错误幅值。但 RS 码不一样它的符号是 GF(2^m) 上的元素错误值可以是任意非零元素所以必须用福尼算法算出每个位置的错误幅值。公式是e_i ω(α^{-i}) / σ(α^{-i})其中 ω(x) S(x)σ(x) mod x^{2t} 是错误求值多项式σ(x) 是 σ(x) 的形式导数。在特征为 2 的域上形式导数有个化简偶数次项的导数系数是 0奇数次项的系数原样保留所以 σ(x) 其实就是 σ(x) 的奇次项按位取出来实现上只是一次掩码操作几乎不花资源。我之前在一篇记录里看到有人把福尼算法用在二进制 BCH 上跑是能跑但算出来的错误幅值恒为 1等于白算一遍除法。这个浪费在 FPGA 上可能就是一个除法器的面积值得避免。4. RS码符号级纠错与突发错误的处理逻辑RS 码在工程上的地位很大程度上不是因为它在随机错误上比 BCH 强而是因为它对突发错误的处理方式太对胃口了。存储介质的缺陷、无线信道的衰落、光盘的划痕这些错误都是成片出现的RS 的符号级纠错正好对路。4.1 RS码是GF(2^m)上的BCH码这句话的实际含义教材上说 RS 码是 BCH 码的特例很多人的理解停在“公式长得像”。实际上这句话的含义要具体得多RS 码的符号取自 GF(2^m)码长 n 2^m - 1生成多项式的根是 α, α^2, ..., α^{2t}注意是连续的 2t 个根不是 BCH 那样的奇数下标。这个“连续”是关键差别。BCH 只取奇数下标的根是因为二进制域上共轭结构会把偶数下标的约束自动满足RS 的符号域和系数域是同一个域没有这个共轭化简所以必须把 2t 个根全部列进去。这就导致 RS 的校验符号数正好是 2tn - k 2t一点不含糊。由此得到 RS 最重要的性质最小距离 d n - k 1。这个等式是取等号的不是不等式。满足这个等号的码叫 MDS 码极大距离可分码RS 是其中最典型的一类。它的意义是在给定码长和校验符号数的前提下RS 的纠错能力达到了理论上限没有比它更强的了。这个性质直接决定了参数选择的方式。你想要纠 t 个符号错就必须付出 2t 个校验符号没有讨价还价空间。RS(255,223) 的 n-k 32t 就只能是 16d 33。想要 t20那就得用 RS(255,215)校验符号 40 个。简单粗暴但也正因为如此工程上的计算从来不会出错。RS 配置n-ktd可纠连续比特错误m8(255, 247)84932 bit(255, 239)1681764 bit(255, 223)321633128 bit(255, 191)643265256 bit最后那列要解释一下一个符号是 8 位纠 t 个符号错最坏情况下这 t 个错误符号是连续排列的那就是 8t 个连续比特错误。所以 RS(255,239) 名义上纠 8 个符号实际能扛住 64 位的连续突发。这个数字在存储纠错里非常经典很多闪存控制器的纠错目标就是按这个量级定的。4.2 缩短RS码在真实系统里的用法RS 的码长也是 2^m - 1 这种数255、511、1023跟实际数据块还是对不上。这时候截短就派上用场了而且 RS 的截短比二进制码更常见因为 RS 的符号粒度大截短几个符号对码率的影响更明显需要精打细算。最典型的例子是数字广播传输里用的 (204,188) 码。它是由 RS(255,239) 截短 51 个符号得到的n 255 - 51 204k 239 - 51 188。188 正好是一个传输包的长度204 是加上 16 个校验符号之后的长度。纠错能力保持 t8 不变能扛 8 个符号错。这个设计非常讲究。为什么截短 51 而不是别的数因为 188 是业务层的包长改不了而 16 个校验符号是纠错能力的需求也不能减。两个约束一夹截短量就定死了。这就是截短码在工程上的真实定位它不是可选项而是被系统参数倒逼出来的必然结果。缩短 RS 码还有一个细节要提。截短之后那些“被删掉的符号位置”在译码时是补零处理的但补的零并不是真实传输的符号如果译码器把它们当成可能出错的位置去搜索会浪费算力甚至引入误判。正确的做法是在钱搜索阶段直接跳过这些位置只在实际传输的 n 个位置上找根。这一点在写硬件译码器时要特别注意搜索范围是 [0, n-1] 而不是 [0, n-1]。4.3 交织深度怎么算才不浪费单靠 RS 扛突发错误能力是有上限的——t 个符号就是天花板。要扛更长的突发就得靠交织把 I 个码字按符号轮流输出信道上的连续错误就被打散到 I 个码字里每个码字只承受大约 1/I 的错误密度。具体算法设目标突发长度 B单位是符号RS 的纠错能力是 t需要满足ceil(B / I) ≤ t即 I ≥ ceil(B / t)这个公式看着简单实际用的时候有两个坑。第一个坑是交织本身不增加纠错能力只做错误分布的重新安排。如果突发长度超过了 I × t那再深的交织也救不回来因为总纠错容量就那么多。所以交织深度不是越大越好它只是把 RS 的能力“摊平”到更长的距离上。第二个坑是交织带来的延迟。深度 I 的交织器至少要缓存 I 个码字才能输出完整的一组延迟是 I × n 个符号时间。在实时性要求高的链路上这个延迟可能直接超标。我见过一个方案为了扛 500 符号的突发把交织深度设到 32结果端到端延迟多了 20 毫秒被迫回退重做。后来改成两级交织加分组才在延迟和纠错之间找到平衡。还有一个变通方案叫卷积交织它不需要整块缓存用两组 RAM 做乒乓就能实现延迟只有 I × n / 2 左右代价是突发错误的分布不如块交织均匀。这个取舍在做方案时要提前想清楚别等实现了才发现延迟不达标。5. 工程落地参数选型、实现取舍与仿真对齐前面四节讲的是原理和构造这一节讲的是把东西做出来的过程中真正会卡住人的地方。这些东西教材上不会写但每一个都能让你多熬两个晚上。5.1 三个最容易被算错的指标做编码方案评审的时候我发现错误几乎总是集中在这三个指标上而且错的方式很一致。第一个是码率。很多人算码率直接用 k/n这没错但在截短码上就错了。截短之后应该用 (k-s)/(n-s)如果你拿原码的 k/n 去估算吞吐会高估一大截。我见过一个方案按 0.93 的码率做带宽预算实际截短后只有 0.87链路直接跑不满。正确的做法是把截短量显式写进预算表别偷懒。第二个是纠错能力对应的误块率。很多人只记“能纠 t 个错”就默认超过 t 个错一定失败t 个以内一定成功。前半句对后半句不完全对——超过 t 个错误时译码器不一定会报错它可能“纠”到一个错误的码字上这叫误纠。误纠的概率在短码上不能忽略尤其是在高信噪比下误纠往往会成为误块率的地板。做方案时要单独评估这个地板值别把理论曲线当实际性能。第三个是缩短码的实际纠错能力。虽然理论上 d_s ≥ d但在某些特定的截短量下最小重量码字可能被截掉了导致实际最小距离大于 d。这时候按 d 算纠错能力是保守的没问题但如果你反过来假设“截短后能力一定等于 d”去做性能预测会低估实际性能浪费了余量。这个偏差不大但在做精细的链路预算时会显现出来。指标常见错误算法正确算法后果码率k/n(k-s)/(n-s)吞吐高估 5%~10%纠错后误块率只看 t 以内加上误纠地板高信噪比性能预测偏乐观截短码纠错能力直接取原码 t按 d_s ≥ d 保守估计保守通常安全5.2 有限域乘法器的查表与逻辑实现之争这个选择题几乎每个做编码硬件的人都会遇到GF(2^m) 的乘法是用查找表还是用组合逻辑查表法的思路很直接把两个 8 位操作数的乘积预先算好存成 256×256 的表或者用对数表转成加法。资源占用上256 字节的 ROM 在现在的工艺下几乎不算什么延迟也只有一个 ROM 访问周期非常适合低速场景。但查表法有两个硬伤。一是表的大小随 m 指数增长m8 是 256 项还能接受m10 就是 1024 项m12 直接到 4096 项面积开始吓人。二是多路并行时表会被复制多份因为每个乘法器都要独立访问。在高速译码器里伴随式计算需要 2t 个并行的乘法表就要复制 2t 份面积一下就上去了。组合逻辑法也就是常说的位并行乘法器用异或网络实现m8 时大约需要 60 到 80 个异或门延迟 3 到 4 级。面积比单份表大但不随并行度线性膨胀因为逻辑可以共享。高速设计基本都走这条路代价是综合后的时序要仔细约束。我个人的经验分界线是时钟频率低于 100MHz、并行度不超过 4 路用查表超过这个范围用组合逻辑。中间地带可以混合——把乘法拆成“高位查表 低位逻辑”兼顾面积和速度。这个混合方案我在一个中等速率的控制器项目里用过综合下来面积比纯逻辑省三成时序还能跑到 150MHz。5.3 仿真跑通了但硬件对不上通常卡在哪这是最让人抓狂的一类问题Python 参考模型和 Verilog 仿真结果不一致或者 Verilog 仿真对了上板子跑出来误码率不对。按我的排查经验问题九成出在下面几个地方。第一是域元素表示约定不一致。同样是 GF(256)有人用 α 的幂次表示有人用多项式基表示有人用比特反转的顺序存。这三套表示混用乘法结果看着像随机的。排查方法很简单让两边都输出 α^0 到 α^7 的乘法表逐项对比第一处不一致就是问题所在。第二是缩短码的索引偏移。补零方案里补的零在数组的哪一端直接影响位置索引的计算。如果参考模型是“低位补零”而硬件是“高位补零”钱搜索找到的根位置会整体偏移 s翻转的位就全错了。这个 bug 特别隐蔽因为无错的时候完全正常一有错就崩。建议在参考模型里把补零位置写成显式参数两边对齐。第三是伴随式计算的起始下标。BCH 的伴随式从 α^1 开始算还是从 α^0 开始算不同教材写法不同实现时必须统一。这个错会导致 σ(x) 的系数整体错位表现是“能纠一部分错另一部分纠错后错误更多”。我一般会在代码里把起始指数定义成常量改的时候只改一处。第四是有限域的加法被误写成减法。特征为 2 的域里加减法都是异或这个大家都知道但在移植参考代码时如果原代码是通用有限域库里面可能保留了减法运算而减法在 GF(2^m) 上等于加法不会报错但逻辑是冗余的。更危险的是把“取负”当成“取反”在某些表示下这两者不等价。排查这类问题的标准流程我固定成四步先用全零输入验证无错通路再用单个已知位置的错误验证定位逻辑然后用两个错误验证 BM 迭代最后用随机错误跑统计。每一步都对比参考模型和硬件的中间变量别只比最终输出——中间变量对上了问题一定在后面的步骤中间变量对不上问题就在这一步的输入或算法本身。最后分享一个我觉得挺有用的小习惯每次做新的编码方案先在纸上把 (n, k, t, d, s) 这五个数写清楚贴在显示器边上。调试过程中每次怀疑参数抬头看一眼能省掉很多“我是不是把 255 记成 511 了”这类低级混乱。这套码的东西参数一错后面全错而且错得很隐蔽先把这个钉死剩下的都好办。