1. 上板联调概述：什么是上板联调、联调在卷积加速器开发中的位置、常见问题分类

大家好，我是你们的讲师。今天咱们聊聊上板联调。说实话，很多刚入行的朋友觉得仿真跑通了，板子就能一次点亮。嗯，我当年也是这么想的，结果被现实狠狠教育了一顿。

上板联调，说白了就是把写好的RTL代码下载到FPGA板子上，接上真实的数据和时钟，让硬件真正跑起来。仿真环境再完美，那也是理想化的。你想想看，仿真里你给的数据是干干净净的，时钟是完美无缺的，可实际板子上呢？信号有抖动，电源有噪声，时序有偏差——这些仿真都模拟不出来。

我个人习惯把上板联调分成三个阶段：

核心观点：上板联调不是仿真的替代品，而是仿真的补充。仿真帮你验证功能对不对，联调帮你验证硬件能不能用。

咱们先看看卷积加速器的开发流程，我画了一张图帮你理解：

从这张图你能看出来，上板联调是整个开发流程的最后一关，也是最关键的一关。前面算法设计、RTL编码、功能仿真做得再好，联调过不去，一切都是白搭。

我记得有一次，一个项目在仿真阶段跑了上千个测试用例，覆盖率99%以上，结果上板后连最基本的图像识别都做不了。查了三天，最后发现是DDR控制器和卷积核之间的数据位宽没对齐——仿真里用的理想内存模型，根本不会暴露这个问题。

我的建议：别等到所有模块都写完了再上板。我习惯每完成一个关键模块，就立刻上板跑一跑。哪怕只是点个灯、读个寄存器，也能提前发现很多问题。

根据我这些年踩过的坑，上板联调的问题大致可以分成三类。咱们一个一个说。

功能问题是最容易发现的，也是最容易让人头疼的。说白了就是：代码逻辑错了，计算结果不对。

数据通路错误：比如卷积核的权重加载顺序反了，或者激活函数的阈值设错了。我曾经遇到过，卷积计算出来的特征图全是黑的，查了半天发现是数据符号位处理错了——有符号数当无符号数用了。
状态机跑飞：状态机在某个条件下跳到了非法状态，导致整个加速器卡死。这种情况在仿真里很难复现，因为仿真时钟是理想的，而实际板子上信号有毛刺。
握手信号异常：valid和ready信号配合不好，导致数据丢失或重复。我建议你在联调时，先用ILA抓一下握手信号，看看有没有数据被吞掉。

注意：功能问题往往不是单一原因造成的。比如数据通路错误，可能是RTL写错了，也可能是综合工具优化出了问题。别急着下结论，先抓波形看看。

时序问题，说白了就是你的电路跑不到目标频率。仿真里1ns的时钟周期跑得欢，上板后setup time违例，直接罢工。

我记得有一次，卷积加速器在100MHz下跑得好好的，一上到150MHz就随机出错。用Vivado的时序报告一看，有一条路径的slack只有-0.02ns。加了一级流水线，问题就解决了。

避坑指南：我曾经在时序问题上吃过亏。当时觉得仿真能过就行，没仔细看时序报告。结果板子跑起来，偶尔出个错，查了整整一周。从那以后，我每次综合完第一件事就是看时序报告，slack为负的路径一条一条过。

接口问题是最隐蔽的，因为它往往不是RTL代码的问题，而是板级设计的问题。

接口问题有个特点：它可能不是每次都会出现。比如DDR接口，有时候初始化成功，有时候失败。这种间歇性问题最让人抓狂。我建议你多做几次上电测试，记录每次的成功率。

总结一下：功能问题靠仿真和ILA抓波形，时序问题靠时序报告和约束优化，接口问题靠示波器和逻辑分析仪。三种问题往往交织在一起，比如接口时序不好会导致功能错误。所以排查时要有耐心，一步一步来。

好了，这一章的内容就到这里。记住，上板联调不是终点，而是验证你设计是否真正可用的起点。下一章咱们聊聊联调环境的搭建，包括硬件平台、调试工具和测试用例的设计。