FPGA工程的编译报告怎么读

　　一定要逐条阅读编译报告
　　规模稍微大一点的FPGA工程的警告和critical warning动辄两三千条，虽然其中包含大量的“无威胁”警告和重复警告，但是我觉得至少95%的程序隐患和设计问题都可以从这些报告中找到蛛丝马迹。
　　工作中有不少人问过我这些问题：这么多警告怎么看的过来呀？这个警告、还有那个到底是什么意思啊？这个警告我该怎么去掉？。..。..。.我能够理解问出这些问题的人的心情，因为我当初也被这些警告吓懵了，也退缩了一段时间。但是我不能够理解的是，为什么春天问过我，到了秋天还问我？后来我明白了，因为一点长进都没有啊！
　　逐条阅读编译报告是合格设计者的必须做到的！他能帮助我们在仿真或在线调试前：
　　发现绝大多数由于疏忽大意造成的低级错误，如位宽不匹配、信号名称拼错、未连接的端口等等；
　　发现较明显的设计错误，如无驱动源的信号、被移除的信号、被隐式声明的信号等等；
　　辅助我们复查代码，读报告的过程可以帮助或者督促我们在脑子里重新过一遍代码，有时候会不经意的发现一些问题。
　　熟悉工程的编译报告并形成一个轮廓。

　　阅读编译报告的两个阶段
　　我把阅读工程的编译报告分为两个阶段：细嚼慢咽阶段和一目十行阶段。
　　2.1 细嚼慢咽
　　这个阶段一般和工程的前几次（两三次就够了）迭代对应。在工程的前几次迭代过程中，建议每一次都认真的读每一条警告。这样做的主要目的包括修正设计中明显的问题和在大脑中形成本工程编译报告的轮廓。
　　在这个阶段，很多问题修正后警告就会消失，减少了警告的总数；脑中形成了本工程编译报告的轮廓后，再阅读编译报告时就可以快速略过熟悉的“无威胁”警告了，同时还会对新出现的警告更加敏感。因为当新警告出现后，你会更容易的发现编译报告的“长相”和你印象中的那个“她”不一样了。
　　需要格外注意的是，如果是初学者，不要遇到看不懂的就问。而是先尝试自己定位和修改，如果解决不了就去阅读相关的技术文档，然后使用搜索引擎。经过这些尝试，即使不能解决问题，相信你也会收获颇丰。这时候再去问别人才会有平等对话的机会。
　　2.2 一目十行
　　度过了细嚼慢咽阶段后，自然就可以一目十行了。现在我一般第一次阅读编译报告会用30分钟到1个小时（前提是不出现难以定位和比较诡异的警告），大概两次后，阅读报告并确定修改是否引入新问题就只需要30秒到2分钟了。

　　分析警告并判断其“威胁”程度
　　本章节将列出自己遇到的警告，以及分析定位警告的过程，供大家参考。
　　3.1 Literal value trunctated
　　如下图所示。这个警告我应该是最近才遇到的。
　　
　　可以看到这个警告非常有规律，都集中在vfg_cmp文件中，而且是很集中的几行，下图是代码部分。
　　出现警告的前几行分别是261、262、269、270、277.。..直到最后的302行，初看以下代码我其实挺懵的，感觉没什么问题。
　　
　　但是我发现，同样的写法，为什么警告只提示到第302行，302行以后反而没有？下面是最后两个case的条件。
　　同样是在给cmpl_in_d1_r1_and赋值时出现了固定值，为什么309和310没有警告呢？这时通过仔细观察和对比发现，由于疏忽，前面赋值时居然使用了6‘h111111、7’h1111111等等这种写法。7‘h1111111理所当然被trunctated到了7bits，这将导致cmpl_in_d1_r1_and在很多条件下的固定值部分出现错误，比如7’b1111111变成了7‘b0010001。而cmpl_in_d1_r1_or虽然也犯了同样的错误，但是由于写法是6’h000000，所以没有给出警告。
　　
　　永远不要忽视任何警告，因为设计错误或者功能异常很可能隐藏在这些警告中。
　　3.2 Unused sequential element removed
　　这个警告是指特定的寄存器被移除。个人人为这是一个威胁度很低，而且很难找到具体位置的警告。比如下面的警告，第一次遇到的时候，我仔细的检查了每一个被移除的sequential单元，但是一无所获。经过多次验证和实践，绝大多数这个警告都没有问题。我估计其主要原因有以下：
　　一些用户为了降低fanout而人为复制的信号被移除，这主要是因为编译器发现不需要这些复制也能实现时序收敛。
　　一些是编译器对用户电路进行优化过程中去掉了不需要的寄存器。
　　该寄存器对应的信号被其他单个信号替代，或者被多个信号的组合替代。
　　
　　3.3 Width does not match
　　下图所示的警告也很常见，这种警告最好逐条阅读并排除其威胁。位宽不匹配会导致该警告，比如32bits位宽的信号，在端口处连接到一个10bits的信号。下图的警告则是因为一个32bits的端口，其所在模块被例化的时候该端口被连接，但是连接该端口的信号没有被定义。没有定义的wire型信号被默认为1bit位宽。
　　
　　3.4 分析警告的步骤
　　前面列举了几个例子，本章节简单介绍以下自己分析警告的步骤。
　　认真阅读警告。对于警告内容清晰易懂的自然没有问题，有些警告会写的晦涩、很难定位，这时候需要细扣每一个句式、每一个单词和每一个术语。
　　与程序相互对照。警告一般都会给出文件的位置，这是需要认真对照警告和源码。有时候警告给出的位置不一定准，有可能是附近或者其他关联位置。
　　查询文档。有些警告中可能会涉及一些FPGA内部的一些特殊电路，这时候可能需要下载和阅读相关的文档。
　　在官方论坛查询。这是非常有效的手段，大部分少见和特殊的错误都能在这里找到。
　　在官方论坛提问。极少数问题在论坛上也找不到对应的回答，这时候需要在论坛上提问。运气不好的话，你发的贴子可能几天、几个星期没人理。这时候建议把帖子挪个论坛分区再发。
　　找技术支持。为什么把这个列在最后一步呢？因为通过前面的步骤，个人水平会有很大的进步，不要养成所有问题都依赖技术支持的习惯。
　　3.5 用不同的编译器编译
　　这是我最近才发现的解决疑难问题的方法之一。
　　我使用Vivado 2019.2版本时，总是会产生一个莫名的错误。我核对了不下10次，检查了相关的文件，都没能定位该问题，耽误了大概两天时间。后来经朋友提醒：多换几个编译器版本试试，甚至包括一些第三方编译器。
　　我使用Vivado 2019.1版本重新编译，果然给出了另一个错误，这个错误与2019.2给出的错误没有任何联系。我把2019.1给出的错误修改后，再回到2019.2编译，竟然再也没有任何错误产生了。
　　FPGA的编译器是非常复杂的EDA工具，不同版本之间存在差异或者个别版本有bug都是很正常的，所以换版本，甚至换不同EDA工具都是可行的方法。