您应该删除Verilog或VHDL设计中的所有警告吗?为什么?为什么?

以下是我对ASIC世界的看法(99%Verilog,1%VHDL)。

我们努力消除日志文件中的所有警告,因为通常,我们将警告解释为一种工具,告诉我们不应该期望可预测的结果。

由于有许多类型的工具可以生成警告(仿真/调试器/linter/合成/等价性检查等),我将重点讨论 模拟器编译器 警告。

我们分析警告并将其分为两大类:一类是我们认为不会影响模拟结果的警告,另一类是可能影响结果的警告。首先,我们使用工具的选项来显式地启用尽可能多的警告。对于第一组,然后我们使用工具的选项选择性地禁用这些警告消息。对于第二组,我们修复verilog源代码以消除警告,然后将警告升级为错误。如果以后在这些类别中引入了任何警告,我们将强制自己在允许模拟之前修复它们。

上述方法的一个例外是第三方IP,我们不允许修改其verilog代码。

这种方法在RTL模拟中相当有效,但是当我们使用反注释的SDF运行门模拟时会变得更加困难。根本没有足够的时间来分析和消除数以百万计的警告。我们能做的最好的事情就是使用脚本(Perl)来解析日志文件并对警告进行分类。

总之,我们尽力消除警告,但这样做并不总是实际的。

这是我的工作,供参考。我检查工具中的所有日志文件。

对于Altera Quartus II,包括地图、拟合和合并报告。我还打开设计规则检查(DRC)选项并检查该文件。对于一些容易修复的消息,例如实例中缺少端口或常量宽度不正确,我会修复它们。其他我调查的。对于内核中的那些,例如宽度不匹配,因为我没有故意使用完整输出,所以我将它们标记为在.srf文件中被抑制。我只抑制特定的消息,而不是所有“相似的消息”,因为现在或将来可能会有其他问题。

我编写了一个脚本,将一组regexps应用于日志文件,以丢弃我“知道行”的行。这是有帮助的,但是你必须对regexps小心一点——jwz是怎么说的:)

我能想到的最重要的原因是模拟合成不匹配。合成工具做了很多优化(正如他们应该做的那样),如果你在设计中留下漏洞,你就会自找麻烦。有关合成标准的详细信息,请参阅IEEE 1364.1-2002。

不需要删除所有警告,但应检查所有警告。为了使大型设计能够做到这一点,一些警告可以通过其类型或ID加以抑制。

例如,一些合成工具会在verilog parameter 在模块实例化期间未定义任何值。对我来说,这个警告只是一个建议 localparam . 最好通过它的ID(例如lint-01)来抑制它。

在某些情况下,我希望看到警告,而不抑制它们。例如,每当我通过约束定义虚拟时钟时,我的工具都会发出警告。这个警告并不意味着有问题,但我能找到一个失踪者 source 不是虚拟的时钟。

有时不存在警告会指出一个问题。例如,如果我更改了一个应用程序变量,应该会有一个警告。

案件太多了。有时警告是不可避免的。有时候,能看到一些重要的东西,发出警告是件好事。如果设计师知道他/她在做什么,那就没问题了。

需要一些警告,如果没有收到警告,则会出现问题。

例如,如果您真的想要一个闩锁,但是没有关于推断闩锁的警告,那么您的合成可能没有得到您想要的。

所以不,你并不总是想“处理”所有的警告。