在（常规）软件中，我曾在使用 gcc 选项 -Wall 显示所有警告的公司工作。然后他们需要被处理。在 Verilog 或 VHDL 中进行非平凡的 FPGA/ASIC 设计时，通常会有很多警告。我应该担心所有这些吗？你有什么具体的技巧可以推荐吗？我的流程主要针对 FPGA（尤其是 Altera 和 Xilinx），但我假设相同的规则也适用于 ASIC 设计，可能更适用于在构建后无法更改设计。
2010 年 4 月 29 日更新：我最初考虑的是综合和 P&R（Place & Route）警告，但模拟警告也是有效的。
这是我对 ASIC 世界的看法（99% Verilog，1% VHDL）。
我们努力消除日志文件中的所有警告，因为一般来说，我们将警告解释为告诉我们不应期待可预测结果的工具。
由于有许多类型的工具可以生成警告（模拟/调试器/linter/synthesis/equivalence-checking 等），因此我将重点讨论模拟器编译器警告。
我们分析警告并将它们分为两大类：我们认为不会影响模拟结果的警告，以及可能影响结果的其他警告。首先，我们使用工具的选项来显式启用尽可能多的警告。对于第一组，我们然后使用工具的选项来选择性地禁用这些警告消息。对于第二组，我们修复 Verilog 源代码以消除警告，然后将警告提升为错误。如果稍后在这些类别中引入任何警告，我们会在允许模拟之前强制自己修复它们。
上述方法的一个例外是第三方 IP，我们不允许修改其 Verilog 代码。
这种方法在 RTL 模拟中效果很好，但是当我们使用反向注释 SDF 运行门模拟时，它变得更加困难。根本没有足够的时间来分析和消除数以百万计的警告。我们能做的最好的事情是使用脚本（Perl）来解析日志文件并对警告进行分类。
总之，我们尽最大努力消除警告，但这样做并不总是可行的。
这是我做的，供参考。我检查了工具中的所有日志文件。
对于包含映射、拟合和合并报告的 Altera Quartus II。我还打开了设计规则检查 (DRC) 选项并检查该文件。对于一些易于修复的消息，例如实例化中缺少端口或不正确的常量宽度，我会修复它们。我调查的其他人。对于核心中的那些，例如宽度不匹配，因为我没有故意使用完整的输出，我将它们标记为在 .srf 文件中被抑制。我只压制特定消息，而不是所有“类似消息”，因为现在或将来可能还有其他问题。
我编写了一个脚本，它将一组正则表达式应用于日志文件以丢弃我“知道没问题”的行。它有帮助，但你必须对正则表达式有点小心——jwz 对它们说了什么:)
我能想到的最重要的原因是模拟综合不匹配。综合工具做了很多优化（他们理应如此），如果你在设计中留下漏洞，你就是在自找麻烦。有关综合标准的详细信息，请参阅 IEEE 1364.1-2002。
无需删除所有警告，但应审查所有警告。为了使大型设计成为可能，可以通过其类型或 id 抑制一些警告。
例如，如果parameter定义了 Verilog 并且在模块实例化期间未分配任何值，则某些综合工具会发出警告。对我来说，这个警告只是一个使用建议localparam。最好通过它的 id 来抑制它（例如 LINT-01）。
在某些情况下，我希望看到警告并且不压制它们。例如，每当我通过约束定义虚拟时钟时，我的工具都会发出警告。该警告并不意味着存在问题，但我可以发现source一个不应该是虚拟的时钟丢失。
有时不存在警告会指出问题。例如，如果我更改应用程序变量，应该会有警告。
案例太多了。有时警告是不可避免的。有时很高兴有警告能够审查一些关键的东西。如果设计师知道他/她做什么，就没有问题。
一些警告是预期的，如果您没有收到警告，则会出现问题。
例如，如果您真的想要一个锁存器，但没有关于推断锁存器的警告，那么您的综合可能没有达到您的预期。
所以不，您并不总是想“处理”所有警告。