国产 FPGA 低温低压测试问题反思与总结

并让 clk 来驱动 dsp_mult 模块。资深大佬看了之后直摇头，并给出了如下的方案。

reg [1:0] clk_count;
always @(posedge Clk_o or negedge rst_N) 
    if (!rst_N) clk_count <= 2'b00; 
    else clk_count <= clk_count + 1'b1; 
wire Clk;
assign Clk = clk_count[1]; 

改完代码后的效果为：

（只改动了这部分的代码，因此工程师只提供了这部分改动后的效果截图。）

本来吧，到这里，工程师认为故事也能结束的。但是吧，依旧出意外了。

3.2.2、新的问题

• 问题 1、尝试在 Questasim 上跑 RTL 仿真，但 DSP 输出结果为不定态。

工程师设置好 do 文件中的文件路径后，打开 Questasim，并执行 do questasim.do 命令。运行结果并无语法报错，也可查看波形。但波形里面显示，vmb 模块没读取到 dat 文件，导致没有数据输入 DSP，进而导致 DSP 输出结果为不定态。

• 问题 2、在 Questasim 上跑通 RTL 仿真后，常温、常压下，上板测试的时候，输出引脚上的信号显示 DSP 的输出结果与预期结果不一致，而其他信号符合预期。

此时，并没看到时序分析报告上有任何异常，且有尝试在工程中加 debug 信号来进行信号抓取。但是，由于未知因素，加入 debug 信号后，工程在编译的过程中会报错，卡在了布局布线那一步。

4、问题的解决、分析与反思

4.1、新问题的解决

4.1.1、解决新问题 1

• 1、尝试在 Questasim 上跑 RTL 仿真，但 DSP 输出结果为不定态。

由于通过波形判断出 vmb 模块没读取到 dat 文件，那么是不是说在设置 vmb 的 IP 核调用时，没有写好相对路径。但这一步使 EDA 软件工具自己识别的，按理说也不会出错的。vmb_v1.v、mb_v2.v、vmb_v3.v、vmb_v4.v、vmb_v5.v 中的相对路径自动设置如下。

那么，继续查看 questasim.do 文件，也没发现 questasim.do 文件中列出 vmb 文件的相对路径出问题。

而且，工程师事先还调整过 FPGA 工程与 Questasim 仿真目录的相对路径，放在了同一目录下，为的就是路径的对齐与一致。

但是，经过大佬提示，问题还真就出现在了这里。EDA 软件工具默认的相对路径起始是 FPGA 工程下的根目录，而 Questasim 仿真工程中的相对路径的起始是该文件的所在目录。

恰巧，vmb_v1.v、mb_v2.v、vmb_v3.v、vmb_v4.v、vmb_v5.v 在目录 dsp_18x18_add_18x18_carry_u_cascade/src。也就是说，Questasim 仿真工程 vmb_v1.v、mb_v2.v、vmb_v3.v、vmb_v4.v、vmb_v5.v 中的相对路径想要指向目标文件，就得在这些文件中的相对路径中再增加一个'../'，多一级返回。即，如下图所示：

其实，根据工程师自己的回忆来看，最初事先进行的路径的对齐与一致，也是为了规避比这个，只不过不是因为 vmb 模块，而是为了其他模块。

最后的解决办法是，工程师拷贝了一份 vmb_v1.v、mb_v2.v、vmb_v3.v、vmb_v4.v、vmb_v5.v 到仿真工程 questasim_dsp_18x18_add_18x18_carry_u_cascade 目录下，并修改了 questasim.do 文件中的文件与路径。

4.1.2、解决新问题 2

针对问题 2，工程师有些不知所措了。有尝试过做以下更改：

assign Clk = Clk_o ; // Clk_o clk_count[1]; 

即，此时将内部 OSC 的输出 Clk_o 传递给 Clk，由 Clk_o 来驱动 dsp_mult 模块。此前的测试中，常温、常压下，上板验证可以的。很庆幸的是，这个更改现在也可使代码在板子上跑起来了。

那么，问题就很清晰了，那就是时钟驱动信号出了问题。但是，那部分代码，并不复杂，又会是哪里出了问题呢。经过资深大佬的指点，先看了一眼复位信号。

乍一看，没啥大问题，就是同步释放、异步释放嘛！rst_N_d2 信号，就是用于 dsp_mult 模块的复位输入。那么，再看一眼 dsp_mult 模块的时钟信号。

就会注意到了：dsp_mult 模块的时钟信号是 Clk，dsp_mult 模块的复位信号是由 Clk_o 驱动的。

那么，所谓的同步释放、异步释放就是个空摆设。rst_N_d2 信号会先于 Clk 信号进入到 dsp_mult 模块中，造成 DSP 初始计算结果出错，并与预期结果比对，进而引脚信号报错。

4.2、原有问题的分析

按照<4.1、新问题的解决>以及更前面的章节分析，可以解决内部 OSC 输出时钟信号频率过高导致 dsp_mult 模块功能出错的问题。那么，为什么时钟信号的频率过高就会导致 dsp_mult 模块功能出错呢？

如果看的足够仔细，就会发现<2.2、运算实现>中有提到：'为了使输入数据对其，输入 C_L、A_L、C_U、A_U 到级联输出 C_L_CAS_OUT、A_L_CAS_OUT、C_U_CAS_OUT、A_U_CAS_OUT 过程，以及级联输出 C_U_CAS_OUT、A_U_CAS_OUT 到 C_L、A_L 的过程，均没有开启寄存器。否则，这是一个 FIR 滤波器，必须要给 D、U 打节拍进行数据对齐才能确保各个 DSP 的输出与预期相符，而且随着级联数越多，所需寄存器就越多。'。

事实就是如此，C、A 信号输入到各级 C_L、A_L、C_U、A_U 上的过程就是一个较长的信号串联传递过程，且没有任何寄存器。并且，随着级联数目的增加，串联的长度也会按比例增加，那么在真实电路中，C、A 信信号到达最后一级 C_L、A_L、C_U、A_U 所需要的时间就越长。因此，不能承受过高频率时钟的驱动；否则，就会代码跑飞。

也看过时序分析，但很巧的是，时序报告并没有将这个路径给报告出来，因此在看完时序报告后就在常温、常压下进行了上板测试。直到低温、低压测试时，才被暴露出来。

4.3、反思与总结

通过与工程师的交流，并把这个过程给分享了出来，并不是真的只是为了公开处刑。只是站在工程师的角度来看：

• 1、新问题 1，实际上已经遇到过，却依旧顾此失彼，依旧翻车了。
• 2、新问题 2，在笔者写《复位信号的同步与释放（同步复位、异步复位、异步复位同步释放）》与《翻译：How do I reset my FPGA?》期间，就已经探讨过同步释放、异步复位，但也还是翻车了。
• 3、关于原有问题，很明显一开始就注意到了这个数据传输路径是没有寄存器的，因为是自己设置的参数配置，关闭了寄存器选项，但也承认确实没有意识到这一点会带来时序上的问题，从某种意义上来说这是可以避免的。
• 4、分析与总结，不是为了批判，而是为了更好的进步。

最后，感谢一下提供的亲身素材。