4、增量编译技术：如何利用增量编译避免全量重编译，节省时间

做验证的兄弟，你们有没有这种经历？

改了一行代码，然后跑去泡杯咖啡。回来一看，编译还没完。我刚开始带项目那会儿，最怕的就是这种等待。一个大型SoC项目，全量编译动不动就半小时起步。你改了个小bug，等编译的时间比改bug的时间还长。这谁受得了？

其实，这个问题有解。就是我今天要聊的——增量编译。

说白了，就是「只编译改动的部分」。你想想看，一个验证环境里，成千上万个文件。你只改了其中一个模块的几行代码，为什么要让所有文件都重新编译一遍？

增量编译的核心思路就是：检测哪些文件发生了变化，只重新编译这些文件以及受它们影响的部分。没变动的部分，直接用上次编译的结果。

核心收益：

我画了个图，帮你理解它的工作流程。你看一下就明白了。

这个流程里，最关键的是「文件哈希比对」和「依赖关系分析」这两步。哈希比对决定了哪些文件要重编，依赖分析决定了哪些文件因为被引用也需要重编。

不同仿真器的用法不太一样。我列个表，你一看就清楚。

仿真器	增量编译命令	关键说明
VCS	`-Mupdate`	默认开启。检测文件时间戳变化，只重编修改的文件。我建议配合 `-Mdir=xxx` 指定缓存目录，方便管理。
Questa/ModelSim	`vcom -work work` + `-novopt`	库级别的增量编译。修改后重新 `vcom` 该文件即可，库内其他文件不受影响。
Xcelium	`-access +rwc` + `-status`	自动检测源文件变化。我习惯用 `-status` 查看哪些文件被重编了，心里有数。
Verilator	`--build` + `--Mdir`	基于make的增量编译。只重新编译修改的C++文件，速度极快。

光知道命令还不够。我在项目里踩过不少坑，总结了几条经验。

技巧一：合理划分编译单元

我个人习惯把验证环境按功能模块拆成多个库。比如：

这样改testcase时，DUT的库完全不用动。编译时间从20分钟降到30秒。

技巧二：善用缓存目录

仿真器会把编译中间结果存到缓存目录。我建议：

避坑指南：增量编译的陷阱

我曾经遇到过一个诡异的问题：改了一个头文件，结果仿真结果还是旧的。查了半天才发现，增量编译没检测到头文件的变化。

原因是什么？有些仿真器默认只检测 .v 和 .sv 文件的时间戳，不检测 .h 头文件。解决办法：

增量编译不是万能的。我一般在这几种情况下会做全量编译：

说个我亲身经历的事。去年有个项目，验证环境有300多个文件。每次全量编译要40分钟。团队5个人，每人每天改bug要编译10次。你算算，一天光等编译就浪费了多少时间？

后来我强制推行了增量编译。改了三条规则：

效果立竿见影。平均每次编译时间从40分钟降到了3分钟。团队士气都高了不少。说白了，验证工程师的时间应该花在找bug上，不是等编译上。

总结一下：

增量编译不是什么高深技术，但用好了能省下大量时间。核心就三点：

嗯，这些经验够你少走不少弯路了。