【WT2.1.0】番外篇：Lint 和他的小伙伴们（转帖）

番外篇：Lint和他的小伙伴们

作者 @吴杉

前文WT2.1是WT中写Lint的内容，并没有展开，有些之前的工具，如解决“验什么”的重汇聚模型，Janick没有继续应用，多多少少给人一些遗憾。

Lint的rules

Lint的rules指其规则列表，如果违反了其rules列表，Lint就会报Error或者Warning。

以Novas的nLint为例，其可以检查的类型包括（但不限于以下类型）：

simulation，可能导致仿真结果出错的代码，如组合逻辑循环，无限循环等；

synthesis，可能导致逻辑不可综合的代码，如task，force，release，如过长的参数位宽等；

dft，可能导致DFT设计出问题的代码，如组合逻辑循环，信号多驱动，时钟信号作为控制输入等；

design style，一些不推荐的设计形式，如信号没有驱动或负载，复位信号作为组合逻辑输入，时钟信号被表达式驱动等；

language construct，一些不推荐的语言结构，如比较等式两端的信号位宽不匹配，函数的某些分支没有返回语句等；

hdl translation，一些导致混合语言（verilog/vhdl）程序的问题；

coding style，一些不推荐的代码形式，使用table作为缩进，一行代码过长（我看到会比较头疼的代码规范问题）等；

naming convention，一些不推荐的命名规范，信号、变量名过长，时钟、复位信号的前后缀不规范等。

而Synopsys公司的SpyGlass也是Lint，它除了一般的规则检查外，对跨时钟域的检查尤为突出，而跨时钟域的设计检查，也应为流程中的特定环节。

有关Lint的血泪史

这里顺带继续说个血泪史吧（WT1.4.0曾说过血泪史让人成长）。

一般来说，设计工程师交付代码都是经过SpyGlass检查才会提交给验证的，在任务不是很紧急的情况下，按部就班的执行都不会出什么问题。但是，某个项目到了中后期，任务安排非常紧，设计工程师忘记做SpyGlass就提交了代码，而版本经理也鬼使神差的忘了检查其SpyGlass报告，版本就这样发布了。幸好，幸好这个子系统由于是接口模块，还是安排了FPGA测试的，发现这个模块在某模式下，采样数据比较混乱。最后查问题，发现“跨时钟域的单bit指示信号，在该版本修改过程中，忘记打拍了”。这就很尴尬了！对于这样的低级失误，团队整体（包括设计工程师、版本经理、设计经理等）实在没啥好说的，虽然模块复杂，功劳苦劳都很大，可是，依然很尴尬啊！最后的处理，就不提了，提了伤心。但是，要说一句，验证该子系统的验证工程师也蛮冤。为解决跨时钟域采样亚稳态的问题，这个信号在网表仿真（后仿真）阶段，是做了特殊处理的。但是，既然特殊处理了，怎么就不能顺带看到呢？验证工程师也蛮尴尬的！所以我给验证工程师的建议是，虽然Lint不是由你来执行的，多提醒一句对自己没坏处，毕竟一荣俱荣，一损俱损，很难说清楚自己没责任的事情，不如大家一起努力，把质量把控做好。

Lint与编译

Janick非常鸡贼的在文章中夹带私货（我也一样），为其新东家Synopsys推销了一把VCS。原话是：“Linting may be built in simulators”，这个“may be”相当的不厚道。容易让本就不清晰的概念混淆。Janick说，如果在VCS仿真时，加上“+race”参数，VCS就可以在编译时，同时判断代码是否可能会出现“竞争冒险”。其实，Janick在这里反而证明了“Lint不是编译，也不是编译的子集”。因为如果是的话，就不需要多余的加一个“+race”参数了。大部分的验证工程师，不希望在编译时的同时做Lint，因为Lint会拖慢编译的速度。

Lint的目标：通过对代码结构的分析，将设计中潜在可能出错的点报出来，以提升代码质量；

编译的目标：通过词法语法分析，将verilog等硬件描述语言，转换为机器可以执行的机器码

编译举例：Cadence的三步法中，第一步ncvlog完成词法语法分析，产生可执行的代码段，ncelab完成类似于“链接”的功能，将片段的代码段组织起来，形成可执行的库文件，在INCA中；如果是Synopsys的VCS，编译结果为可执行的simv。

Lint希望通过深度的代码结构分析，发现更“多”的问题；

编译希望通过各种手段，如增量编译，更“快”的产生可执行的文件。

一个倾向于“多”，一个倾向于“快”。目标不一致，方法也不一致。这就是VCS的“+race”参数比较尴尬的地方，缺少应用的场景。

如果做Lint，就好好做Lint，如果Lint检查不通过不让设计工程师提交代码版本；

如果做编译，就专心做编译，越快得到可执行文件，越快启动仿真。

职责清晰，干净利索！

至于Janick在WT中给的例子，“counter＜255”，编译自然不会报错；但是，在Lint看来，你让一个byte，数值范围[－128, 127]的值与255比较，有些不可理喻罢了。

Lint与形式验证

我们要应用之前提到的工具——重汇聚模型，来看看Lint与形式验证都“验什么”了。

在第1章中，Janick给出了形式验证的重汇聚模型，他的解释是“形式验证（特性检查）”基于人为对设计需求的解释，设计出断言等检查属性，通过静态验证的数学方法，检查这些特性是否满足。

而Lint与形式验证（特性检查）最大的差别在于Lint没有人为对需求进行解释的过程。Lint是通过已经定义好的“设计规范”对设计代码产品进行检查的。是一个自环检查结构，仅对设计代码负责，不对Specification负责。

不过，Lint与形式验证也有相似之处：

1.它们都是通过“静态验证”的方式进行检查，不需要验证平台，不需要人为构造激励；

2.它们都可以纳入“白盒验证”的范畴，关注的都是代码层面，比较底层的信息。

是否需要区别Lint与形式验证？

我觉得只需要清晰的区分出Lint即可，因为Lint是应由设计工程师执行的。至于由验证工程师执行的，可以不用区分的特别仔细，都是静态验证，都是白盒验证。

Lint由设计工程师执行的好处是“反馈环较短”，发现问题，立即解决，不需要其它人反馈。

总结

1.Lint是基于rules来执行的；

2.虽然Lint一般不是验证工程师做，多提醒一句没有坏处；

3.编译不是Lint，Lint也不是编译，让他们各司其职比较好；

4.区分Lint与形式验证，主要是从流程层面考虑，主要是因为，Lint必须设计工程师来做，而形式验证（特性检查）则既可以由设计工程师做，也可以由验证工程师做。