夜雨聆风今春四月，微信公众号“AI驱动FPGA”的作者（以下称“原作者”）做了一个非常有意义的研究：尝试用AI在FPGA上实现一个LDPC译码器。原作者进行了两次尝试，分别使用两种范式，得到了不同的结果，完整实验过程见两篇微信公众号文章(用AI在FPGA上自主实现一个LDPC译码器的全记录、让AI用Python探索硬件架构，1.356 Gbps高吞吐量的LDPC译码器就做成了)。
这是我们看到的第一个公开分享的、尝试用AI实现LDPC译码器的研究。LDPC译码器属于通信基带处理中复杂度较高的模块，也是实现难度相当大的环节，将其作为AI辅助硬件设计的测试用例，为行业提供了十分有价值的参考。
在征得原作者同意的基础上，本文将对以上研究工作进行归纳理解，并探讨一个我们所有同行都关心的问题：AI是否已经可以替代人工进行LDPC译码器开发？
本文纯属技术讨论。如有对原作者工作解读不准确之处，或其它不严谨的方面，恳请各位批评指正；也欢迎各位留言，提供您的看法或问题。
一、第一次尝试：全权交给AI
原文链接（用AI在FPGA上自主实现一个LDPC译码器的全记录）
原作者研究的目标是802.11n标准中的QC-LDPC译码器，参考设计吞吐量为1260Mbps。AI工具为Claude Code，从零开始在FPGA上实现。
在23个版本的迭代过程中，AI展现了在某些维度上令人惊喜的能力。时序方面，从初始的93.9MHz逐步优化至261.8 MHz，方法包括阅读时序报告、插入流水线寄存器等常规手段。面积方面，通过分解81路MUX等操作，LUT消耗从71K降至19.7K，资源削减约72%。这两个指标的优化路径是可复现的，说明AI在处理局部优化问题时是非常有实用价值的。
但吞吐量始终是短板。最终版本仅达到278Mbps，与参考设计的1260Mbps存在约4.5倍差距。
原作者分析，吞吐量未达标的原因在于AI在起始阶段独立做出了错误的架构选择。参考设计使用延迟线架构，每个数据条目的处理周期约1.26个周期。AI参照MATLAB原型算法，选择了两阶段回放架构，处理周期变为5.2个周期。两种架构的逻辑资源消耗接近，但吞吐量上限在架构选定那一刻就已被决定。
这个结果并不令人意外。因为AI缺乏对硬件架构的全局判断力，从现有代码或算法描述中提取的"经验"未必适合目标平台。当决策发生在项目早期、且后续难以回溯修正时，单次错误就足以锁定整体性能。
二、第二次尝试：Python辅助AI
原文链接（让AI用Python探索硬件架构，1.356 Gbps高吞吐量的LDPC译码器就做成了）
在第一次尝试未达预期后，原作者调整了策略，改为"先架构，后实现"的流程。核心变化在于：由人完成架构设计和周期精确的Python建模，AI仅负责将Python模型翻译为可综合的Verilog代码。
该方法定义了三条操作规则：
•规则一：先写Python，再写Verilog。
Python模型需达到周期精确级别，可逐周期导出中间状态。之后与AI生成的Verilog仿真结果进行逐周期比对，定位偏差。
•规则二：一个结构体走到底。
流水线中所有传递信号（数据、控制标志、迭代计数等）统一封装为单个结构体，避免多路控制信号在流水线不同层级之间错位。
•规则三：用最难的测试打头阵。
放弃全零码字，直接使用16-QAM随机编码的复杂激励，最终覆盖396种不同配置。
在这个流程下，AI的角色从"设计者"转变为"翻译器"，任务边界清晰，可检验性强。
两次尝试的量化对比：
*笔者与原作者交流得知，时钟频率为布局布线实现后的频率，不是仅有综合的时钟频率，非常赞同这种扎实的实验结果。
三、实现结果分析
从实际应用角度看，第一次与第二次实验的对比给了我们一些有益的启示：
第一，AI辅助硬件设计的瓶颈不在代码生成环节，而在架构决策环节。第一次尝试中，AI同样完成了代码编写、时序优化、面积优化等一系列工作，单看每项局部任务都有成果，但合在一起无法形成有效设计。第二次将架构决策保留在人的手中，AI的执行效率得以释放。
第二，周期精确的Python模型起到了"可执行规格书"的作用。传统开发中，规格书是自然语言文档，天然存在歧义空间，设计与验证脱节。Python模型将设计意图沉淀为可运行、可对比的代码，信息传递的损耗明显降低。
第三，测试方法对AI生成代码的质量验证至关重要。简单测试向量（如全零码字）会掩盖时序对齐错误，复杂激励才能暴露真实问题。这一点在传统开发中也成立，但在AI生成代码的场景下更加关键——因为没有人在逐行写代码时就完成了边界条件的推演。事实上，此要求并不是对AI生成代码的挑剔和区别对待，而是“古法”人工编程也同样要遵循的测试和验证原则。
四、AI可能存在的局限性
从以上分析来看，尽管原作者第二次尝试取得了可观的进步，但我们认为该实验结果至少目前尚不支持 “AI已经可以替代人工进行LDPC译码器开发”的愿景。以下从技术角度逐项讨论。
4.1 AI的角色边界：辅助而非主导
该实验所使用的方法中，AI承担的是从Python到Verilog的确定性转换，以及局部逻辑优化（如MUX分解、扇出调整、流水线寄存器插入）。这些工作理论上也可以由高级综合工具完成，AI的优势在于对非结构化优化模式的探索效率更高。但架构层面的所有决策——数据流方向、流水线层级划分、存储结构选择、软信息更新策略、迭代环路结构——均由人完成。这意味着该方法的输出质量严格受限于输入质量：写出"硬件级"周期精确Python模型的人，当他能够写出这种Python模型，本质上已经也完成了硬件架构设计，只是将编码环节外包给了AI。
对我们的启示是，这套流程“似乎”降低了Verilog编码的门槛，但实际上提高了对架构设计能力和Python建模能力的要求。此外，又引申出新的问题：Python建模能否通过AI实现？笔者认为非常值得探索。
4.2 码型依赖性：QC-LDPC的结构红利
本实验的目标码型是QC-LDPC，其校验矩阵由循环移位子块构成。这种规整结构使地址生成、节点更新、互联网络都可以模板化实现，非常适合流水线处理。该实验其实受益于码型本身的结构红利。
对于非QC-LDPC，例如随机结构的LDPC码型，校验矩阵的连接关系无统一规则。硬件实现前需要由设计者手动分析矩阵的结构特征，寻找可硬件化的规律，然后重新构建地址生成与互联网络。这个分析过程依赖设计者对纠错码理论和硬件架构的双重理解，是硬件实现架构设计过程中极具挑战的环节——至少笔者目前是这样认为的。或许将来，也能够被AI轻而易举的突破？
4.3 模块完整度：核心环路不等于可用译码器
当前实现聚焦于迭代译码核心环路，以下关键模块尚未纳入：
•输入/输出缓存（Ping-Pong Buffer）
实现码块间的连续流水处理。缺失时译码器只能以突发方式工作，无法接入连续数据流系统，进而导致核心迭代环路的吞吐率完全无法发挥出来。
•提前终止判决
检测译码收敛后跳出迭代。对实际功耗影响显著——特别是在高信噪比条件下，多数码块只需少数几次迭代即可收敛，固定全迭代次数会浪费大量功耗，这一模块在LDPC译码器中是业界共识标配模块。
•接口与调度逻辑
参数配置、调制方式适配、标准总线协议接入等，这些模块单从设计难度看并不高，但集成后会引入新的时序路径、验证场景和状态机复杂度。目前的结果应理解为"核心算法的硬件实现验证"，距离完整的工程交付物还有相当距离。
从笔者视角来看，核心译码环路确实是LDPC译码器设计的难点和重要工作量，但是确实不代表有了核心译码环路就有了可交付的译码器。
4.4 存在于23级流水线的隐忧：收敛性能与误码平层
为达到312.5MHz目标频率，译码器插入了23级流水线。从吞吐量和时序角度看这是合理的，但从译码算法和完整模块硬件实现角度看需要审慎评估。
LDPC迭代译码的核心机制是软信息在变量节点和校验节点之间不断交换更新。信息的新鲜度直接影响收敛速度：刚更新的软信息越快被下一次迭代使用，收敛效率越高。深流水线人为增加了信息传递的延迟，可能导致迭代收敛变慢，收敛所需迭代次数增加。
更隐蔽的风险在性能回退和低误码率区域的误码平层问题[1][2]。硬件实现中，深流水带来的信息滞后可能在纠错性能曲线的高信噪比端引发误码平层（Error Floor）提前出现——即误码率曲线偏离瀑布区的快速下降趋势，过早趋于平缓。这类问题很难在常规仿真深度下暴露，通常需要仿真到BER=10E-9甚至更低才能确认，验证成本极高。
笔者并非质疑原作者验证不充分，更不是认为深度流水技术一定就会导致巨大的性能回退或是很高的误码平层，而是希望分享：该潜在的风险点真实存在。
4.5 时序目标与器件约束：312.5 MHz在690T上的挑战
在Xilinx 690T上，逻辑单元规模大、布线资源复杂。当目标频率推高到312.5 MHz（周期约3.2 ns）时，留给逻辑和布线的余量非常紧张。工具为解决少量关键路径违例，会采取逻辑复制、强力布局等手段，容易在局部制造布线拥塞，进而恶化原本已收敛的路径。典型症状就是时序报告中的违例路径数量反复跳动。
更重要的是，在690T器件上以312.5MHz部署复杂设计，极易陷入优化拥塞与时序回退的矛盾，从方案spec决策层面是高风险目标。
五、小结
原作者在AI辅助硬件设计方面的探索，具有很高的参考价值。这项工作没有停留在“AI能不能写Verilog”的笼统讨论，而是通过两次可控对比实验，给出了一个相对清晰的能力边界画像：AI在当前阶段可以“着手尝试”承担从周期精确模型到RTL的翻译和局部优化工作，但架构决策、结构分析、全局权衡仍需设计者主导。
尤其是，选择LDPC译码器这类有真实复杂度的模块作为实验对象，而非停留在教科书级示例，也没有因为第二次的结果改善而回避短板，这使实验结论更加宝贵。
对于行业而言，这类从一线实践中来的记录，比抽象的能力预测更具讨论价值。AI辅助硬件设计的有效范式仍在探索中，该工作提供了一个经过验证的操作路径，也标出了这条路径当前无法覆盖的地段。两者同样具有参考意义。
参考文献：
[1] Petrovi V L , Markovic M M , Mezeni D M E ,et al.Flexible High Throughput QC-LDPC Decoder With Perfect Pipeline Conflicts Resolution and Efficient Hardware Utilization[J].Circuits and Systems I: Regular Papers, IEEE Transactions on, 2020, 67(12):5454-5467.DOI:10.1109/TCSI.2020.3018048.
[2]韩国军,杨伟泽,叶震亮,等.基于帧交错的LDPC译码器流水结构设计[J].电子科技大学学报, 2024(002):053.
END
\\ 开发工具
LDPC编译码器自动化开发工具
\\推荐阅读
点击这里☝️☝️关注我们🫶
