您是否应该删除 Verilog 或 VHDL 设计中的所有警告？为什么或为什么不呢？
在（常规）软件中，我曾在使用 gcc 选项 -Wall 来显示所有警告的公司工作。然后他们需要被处理。对于 Verilog 或 VHDL 中的重要 FPGA/ASIC 设计，通常会出现很多警告。我应该担心所有这些吗？您有什么具体的技巧可以建议吗？我的流程主要针对 FPGA（特别是 Altera 和 Xilinx），但我认为相同的规则也适用于 ASIC 设计，可能更是如此，因为设计构建后无法更改。
2010 年 4 月 29 日更新：我最初考虑的是综合和 P&R（布局与布线）警告，但模拟警告也是有效的。
In (regular) software I have worked at companies where the gcc option -Wall is used to show all warnings. Then they need to be dealt with. With non-trivial FPGA/ASIC design in Verilog or VHDL there are often many many warnings. Should I worry about all of them? Do you have any specific techniques to suggest? My flow is mainly for FPGAs (Altera and Xilinx in particular), but I assume the same rules would apply to ASIC design, possibly more so due to the inability to change the design after it is built.
Update 4/29/2010: I was originally thinking of synthesis and P&R (Place & Route) warnings, but the simulation warnings are valid too.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这是我对 ASIC 世界的看法（99% Verilog，1% VHDL）。
我们努力消除日志文件中的所有警告，因为一般来说，我们将警告解释为告诉我们不应期望可预测结果的工具。
由于有许多类型的工具可以生成警告（模拟/调试器/linter/综合/等价检查等），因此我将重点讨论模拟器编译器警告。
我们分析警告并将其分为两大类：我们认为不会影响模拟结果的警告，以及可能影响结果的其他警告。首先，我们使用工具的选项来显式启用尽可能多的警告。对于第一组，我们然后使用工具的选项来有选择地禁用这些警告消息。对于第二组，我们修复 Verilog 源代码以消除警告，然后将警告升级为错误。如果以后在这些类别中引入任何警告，我们会强制自己修复它们，然后才能进行模拟。
上述方法的一个例外是第三方 IP，我们不允许修改其 Verilog 代码。
该方法对于 RTL 仿真相当有效，但当我们使用反向注释的 SDF 运行门仿真时，它会变得更加困难。根本没有足够的时间来分析和消除数以百万计的警告。我们能做的最好的事情就是使用脚本（Perl）来解析日志文件并对警告进行分类。
总之，我们尽力消除警告，但这样做并不总是可行。
Here is my perspective from the ASIC world (99% Verilog, 1% VHDL).
We make an effort to eliminate all warnings from our log files, because in general, we interpret warnings as the tool telling us that we should not expect predictable results.
Since there are many types of tools which can generate warnings (simulation/debugger/linter/synthesis/equivalence-checking, etc.), I will focus this discussion on simulator compiler warnings.
We analyze warnings and categorize them into two main groups: ones which we deem will not affect the results of our simulation, and others which may affect the results. First, we use a tool's options to explicitly enable as many warnings as possible. For the first group, we then use a tool's options to selectively disable those warning messages. For the second group, we fix the Verilog source code to eliminate the warnings, then we promote the warnings to errors. If any warnings are later introduced in those categories, we force ourselves to fix them before we are allowed to simulate.
An exception to the above methodology is for third-party IP, whose Verilog code we are not allowed to modify.
That method works fairly well for RTL simulations, but it gets much more difficult when we run gate simulations using back-annotated SDF. There is simply not enough time to analyze and eliminate the literally millions of warnings. The best we can do is to use scripts (Perl) to parse the log files and categorize the warnings.
In summary, we try our best to eliminate the warnings, but it is not always practical to do so.
这是我做的，供参考。我检查工具中的所有日志文件。
对于 Altera Quartus II，包括映射、拟合和合并报告。我还打开设计规则检查 (DRC) 选项并检查该文件。对于一些易于修复的消息，例如实例化中缺少端口或恒定宽度不正确，我修复了它们。其他的我也在研究。对于核心中的那些，例如宽度不匹配，因为我没有故意使用完整输出，我将它们标记为在 .srf 文件中抑制。我只压制特定的消息，而不是所有“类似的消息”，因为现在或将来可能还有其他消息，这些消息都是问题。
Here's what I do, for reference. I inspect all the log files from the tool(s).
For Altera Quartus II that includes the map, fit and merge reports. I also turn on the Design Rule Check (DRC) option and check that file. For some messages that are easy to fix, e.g. port missing from the instantiation or incorrect constant width, I fix them. Other ones I look into. For ones that are in the cores, e.g. a width mismatch because I'm not using the full output deliberate, I mark them to be suppressed in the .srf file. I only suppress the specific messages, not all of the "similar messages" since there may be others, either now or in the future, which are problems.
我编写了一个脚本，它将一组正则表达式应用于日志文件，以丢弃我“知道没问题”的行。它有帮助，但你必须小心使用正则表达式 - jwz 对它们说了些什么:)
I wrote a script which applies a set of regexps to the logfile to throw away lines which I "know are OK". It helps, but you have to be a bit careful with the regexps - what did jwz say about them :)
我能想到的最重要的原因是模拟综合不匹配。综合工具会进行大量优化（它们理应如此），如果您在设计中留下漏洞，那么您就是自找麻烦。有关综合标准的详细信息，请参阅 IEEE 1364.1-2002。
The most important reason that I can think of is simulation-synthesis mismatch. Synthesis tools do a lot of optimizations (as they rightly should) and if you leave loopholes in your design you are asking for trouble. Refer to IEEE 1364.1-2002 for details about the synthesis standard.
无需删除所有警告，但应审查所有警告。为了使大型设计成为可能，一些警告可以通过其类型或 ID 来抑制。
例如，如果定义了 Verilog 参数并且在模块实例化期间未分配值，某些综合工具会发出警告。对我来说，这个警告只是使用
localparam的建议。最好通过其 ID 来抑制它（例如 LINT-01）。在某些情况下，我希望看到警告而不是抑制它们。例如，每当我通过约束定义虚拟时钟时，我的工具都会发出警告。该警告并不意味着存在问题，但我可以捕获不属于虚拟的时钟的缺失
源。有时，不存在警告就表明存在问题。例如，如果我更改应用程序变量，应该会出现警告。
案例太多了。有时警告是不可避免的。有时，有警告以便能够审查一些关键内容是件好事。如果设计师知道他/她做什么，那就没有问题。
There is no need to remove all warnings, but all should be reviewed. To make this possible for big designs, some warnings can be suppressed by its type or id.
For example, some synthesis tools give a warning if a Verilog
parameteris defined and no value assigned during the module instantiation. For me, this warning is just an advice to uselocalparam. It's a good idea to suppress it by its id (e.g. LINT-01).In some cases, I want to see the warnings and don't suppress them. For example, my tool gives a warning whenever I define a virtual clock by constraints. The warning doesn't mean there is a problem, but I can catch a missing
sourceof a clock that wasn't intended to be virtual.Sometimes non-existence of warnings points out a problem. For example, if I change an application variable, there should be a warning.
There are too many cases. Sometimes the warning is unavoidable. Sometimes it's nice to have warnings to be able to review some critical stuff. If the designer knows what he/she does, there is no problem.
一些警告是预期的，如果您没有收到警告，则存在问题。
例如，如果您确实想要一个锁存器，但没有关于推断锁存器的警告，那么您的综合可能不会达到您的预期。
所以不，你并不总是想“处理”所有警告。
Some warnings are expected and there is a problem if you don't get a warning.
for example if you really really want a latch but there is no warning about inferring a latch then your synthesis might not have made what you intended.
so no, you don't always want to 'deal' with all warnings.