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