4. CRC生成与校验的硬件实现原理

在星载FPGA或ASIC中，CRC几乎不会用软件逐位异或的方式实现，而是直接映射为线性反馈移位寄存器（LFSR）。理解LFSR的抽头结构、并行展开方式和流水线插入位置，是判断一个CRC实现能否同时满足星载平台资源约束与吞吐率要求的关键。

一、串行LFSR：CRC的硬件原型

以CRC-16/CCITT（生成多项式 G(x)=x¹⁶+x¹²+x⁵+1，即0x1021）为例，其串行实现是一个16位移位寄存器，每个时钟沿输入1 bit数据，最高位与输入位异或后反馈到抽头位置。反馈逻辑可写为：

feedback = data_in ^ crc[15];
crc[15] <= crc[14];
crc[14] <= crc[13];
...
crc[12] <= crc[11] ^ feedback;   // 对应 x^12 抽头
crc[5]  <= crc[4]  ^ feedback;   // 对应 x^5 抽头
crc[0]  <= feedback;             // 对应 x^0 抽头

这种结构每周期只处理1 bit，逻辑深度小、资源占用低，但吞吐率极低。若星载数据率为100 Mbps，串行LFSR需要100 MHz时钟且每周期仅1 bit，几乎无法在低时钟频率的航天级器件上实现。因此，串行LFSR通常只用于低速遥测通道或作为理解并行展开的基准模型。

二、并行CRC：把N位输入一次算完

并行CRC的核心思想是：把N个时钟周期的串行递推关系在数学上合并，得到“当前状态 + N位输入 → 下一状态”的组合逻辑。对于位宽W的数据通路，常用W=8、16、32或64。以W=8为例，设当前CRC寄存器为C[15:0]，输入字节为D[7:0]，则下一状态C'[i]可表示为C的若干位与D的若干位的异或组合。

工程上通常不手工推导这些表达式，而是用脚本或工具生成。例如用Python的crcmod或自写矩阵法，把生成多项式转换为16×16的状态转移矩阵T，再计算T⁸，得到8位并行递推矩阵。综合工具会把矩阵乘法展开成异或树。对于CRC-16/CCITT，8位并行大约需要几十个异或门，关键路径深度约4～6级异或，资源远小于一个16位乘法器。

并行度越高，吞吐率越高，但组合逻辑面积和关键路径也越大。下表给出同一CRC-16在Xilinx Kintex-7上综合的典型趋势（示例数据，用于说明权衡关系，非实测）：

可以看到，位宽翻倍时吞吐率翻倍，但LUT用量也近似翻倍，关键路径逐渐成为限制时钟频率的瓶颈。星载平台通常时钟资源有限，若一味提高并行度，反而可能因时序不收敛而降低实际频率。

三、流水线设计：在面积与速度之间取平衡

当并行异或树过深导致时序违例时，可以在异或树中间插入寄存器，把长组合路径切分为多级流水线。代价是CRC结果会延迟若干周期输出，但吞吐率不变（每周期仍处理W位）。对于星载数据流，这种延迟通常可以接受，因为CRC校验位于数据帧尾部，接收端只需在整帧结束后比对即可。

流水线插入位置应选在异或树的对半分割点。例如32位并行CRC的关键路径为6级异或，可在第3级后插入一级寄存器，把路径切为3+3，时钟频率可提升约40%～60%。但要注意，流水线会改变CRC的“当前状态”含义：中间级寄存器保存的是部分计算结果，必须等所有级都填满后，输出才是有效CRC。因此控制逻辑需要配合valid信号或帧计数，避免在流水线未填满时误判。

四、校验侧的实现差异

生成侧和校验侧的LFSR结构相同，但初值和结果处理不同。生成时通常将CRC寄存器初始化为全1或全0（取决于标准），数据输入完毕后输出取反或异或常数。校验时，接收端把数据连同CRC字段一起送入LFSR，若最终余数为固定常数（如CRC-16/CCITT的0x1D0F），则判定通过。硬件上只需在帧尾比较余数，无需额外减法器。

下图给出一个32位并行CRC-16/CCITT的流水线结构示意，包含输入寄存器、两级异或树、流水线寄存器和余数比较逻辑，可用于理解数据流与状态更新关系。

实际编码时，建议先用脚本生成并行异或表达式，再在RTL中例化。综合后重点检查三项：一是时序报告中的WNS是否为正；二是LUT和寄存器用量是否在预算内；三是CRC结果是否与软件参考模型逐位一致。星载平台还应考虑单粒子翻转对CRC寄存器的影响，必要时对CRC寄存器加三模冗余或周期性重载初值。

总结来看，串行LFSR是理解CRC硬件行为的起点，并行展开是满足星载吞吐率的关键手段，流水线则是在时序与面积之间取得平衡的工程选择。三者并非互斥，而是同一设计在不同约束下的不同取舍。掌握这些结构后，才能根据具体星载任务的数据率、器件资源和可靠性要求，快速确定合适的CRC实现方案。