VIVADO 各类报错（随时更新）

一、引言

        记录下使用vivado过程中遇到的问题，学习，成长。

二、遇到的问题

1.  The debug port 'u_ila_0' has 36 unconnected channels 

       原因分析：应该是因为有些新抓取的信号没给可用时钟，vivado自动生成的xdc文件中有新信号但没有时钟，因此报错。使用mark debug抓信号很容易出现此类问题，建议使用ILA。

        解决方法：

（1）把vivado自动生成的xdc文件里的内容全部清空；

（2）然后进行综合；

（3）待综合完成后，点击 set up debug，给没有时钟域的信号加上时钟，保存，最后一定要保存，ctrl + s；

（4）最后再次生成比特文件。

2. 生成比特文件时报错 multiply drivers

        原因分析：这是因为一个output信号被赋值超过一次，也就是有大于等于两个信号赋值给了同一个输出信号，因此报错。

        解决方法：检查哪些信号被多次赋值，修改信号名字，或者删除多余的信号，只传一个信号给一个output信号。

3. procedural assignment to a non-register PrSl_DoneDly_s is not permitted 

        原因分析：在always中给非reg信号赋值，而always中只能给reg信号赋值。在always中，wire类型的信号只能用作判断条件，或者赋给reg信号。

        解决方法：把报错的信号的类型改为reg。

4. 快要生成比特文件，到write_bitstream时顶层信号报错，报错信息很长，忘记复制了

        原因分析：顶层的输入输出信号都需要在xdc文件中进行引脚约束，信号没有约束或者顶层中的名字和xdc中的名字不一致，找不到顶层信号对应的引脚，到最后就会报错。我这里是因为后面在顶层新改了名字，而xdc中的名字没有改过来，名字不一致，找不到顶层信号的约束，所以报错了。

        解决方法：把名字改成一样的。

5. 使用SDK时，SDK路径与工程所在路径不一致

        原因分析：SDK也需要硬件信息，应该在JTAG连接上FPGA芯片之后再launch SDK.

6. 报时序错误，而且数字还很大，如下图所示

         原因分析：把不同时钟域下的信号用同一个ILA抓，也就是用同一个时钟，所以时序错误很大。 

        解决方法：要么用mark debug抓，要么分成不同的ILA抓，每一个ILA只能用一个时钟。

7. 严重警告： [Vivado 12-4430] You are lowering the severity from an ERROR. This can potentially lead to board damage or other functionality issues on hardware. If this is not desired, please run 'reset_property SEVERITY [get_drc_checks REQP-49]' to undo this change.

        原因分析：可能和license有关，发送tcl命令：reset_property SEVERITY [get_drc_checks REQP-49]试了一下，看下次生成比特文件还会不会有这个critical warning。

8.警告：[Timing 38-316] Clock period '10.000' specified during out-of-context synthesis of instance 'decData_fifo_inst' at clock pin 'clk' is different from the actual clock period '5.000', this can lead to different synthesis results.

        FIFO、ROM和RAM都有可能报这类警告。这些IP都有默认时钟，比如这个FIFO默认时钟是100MHz，而我给的是200MHz，所以就报这个警告了。但是当我们生成IP核的时候并没有约束时钟大小的接口，说明官方也知道这个事，只是它不影响其他操作，所以可以忽略。

        不会影响生成比特文件，也不会产生时序问题，可以忽略。

9. 生成比特文件时，产生十几万大小的时序问题

        查看时序报告，有一个统计错误比特的信号出了问题。下面是我刚开始时的代码，报了很大的时序问题。

decData_check_wrong_cnt <= decData_check_wrong_cnt + dec_error_nor[0 ] + dec_error_nor[1 ] + dec_error_nor[2 ] + dec_error_nor[3 ] + dec_error_nor[4 ] + dec_error_nor[5 ] + dec_error_nor[6 ] + dec_error_nor[7 ] 
                                                                       + dec_error_nor[8 ] + dec_error_nor[9 ] + dec_error_nor[10] + dec_error_nor[11] + dec_error_nor[12] + dec_error_nor[13] + dec_error_nor[14] + dec_error_nor[15] 
                                                                       + dec_error_nor[16] + dec_error_nor[17] + dec_error_nor[18] + dec_error_nor[19] + dec_error_nor[20] + dec_error_nor[21] + dec_error_nor[22] + dec_error_nor[23]
                                                                       + dec_error_nor[24] + dec_error_nor[25] + dec_error_nor[26] + dec_error_nor[27] + dec_error_nor[28] + dec_error_nor[29] + dec_error_nor[30] + dec_error_nor[31];

刚开始以为是在同一拍下，对这个位宽为32位的信号的每一位分别进行相加造成的，所以尝试的方法就是把它们拆开。比如，每四个每四个的相加，第0到第3位的和用一个信号表示，第4到第7位的和用一个信号表示，诸如此类，一共8个求和信号，最后再把它们加到计数器中。

结果是，时序问题报的数字小了，但还是有，通过进一步分析，我觉得应该是因为计数器是不断累加的，累加能力有限。然后我变成每8个相加求和，一共4个求和信号，再把这4个求和信号加到计数器中，就不报时序问题了。如下图所示：

decData_check_wrong_cnt <= decData_check_wrong_cnt + dec_error_sum_4 + dec_error_sum_3 + dec_error_sum_2 + dec_error_sum_1;