企业官网建设流程全解析

VCS 的编译选项和仿真选项，平时都埋在上百行的 Makefile 或者脚本里，跑得顺的时候没人会多看一眼，一旦出问题，就得花大半天去猜每一个带减号、带加号的开关到底是干什么的。我接手过好几个别人交接的验证环境，最典型的情况就是编译选项堆了三四十个，能跑但状态很微妙——改一个+define+就得全量重编，一编十几分钟；换台机器跑，波形又出不来。后来我干脆把这些选项按“编译期”和“仿真期”重新梳理了一遍，环境才真正变得可控。这篇就把我日常用得最多、也最容易踩坑的那些编译选项和仿真选项逐个讲清楚：它们分别在哪个阶段生效、底层在做什么、为什么这么写，以及什么情况下会把人坑住。刚入行看脚本一头雾水的、做了几年但一直照抄同事选项没系统梳理过的，都能从里面找到对得上号的东西。

1. VCS 的两段式流程：选项必须先分清“编译”还是“仿真”

很多人对 VCS 的困惑，根源其实不在选项本身，而在于没意识到 VCS 是两段式的。你敲的那条vcs命令，做的事是“把一堆*.v、*.sv文件翻译并链接成一个可执行程序”；真正跑仿真的是它生成出来的那个叫simv的可执行文件。这两个阶段是完全割裂的，各自有一批只属于自己的选项。把编译选项写到simv后面，或者把仿真选项写到vcs后面，轻则被静默忽略，重则直接报错退出。

1.1 vcs 和 simv 各自负责什么

vcs阶段的核心产物是simv，以及一个叫simv.daidir的目录。前者是可执行的仿真内核，后者是编译过程中产生的中间数据库，增量编译、Verdi 的 KDB 库、覆盖率的一些元信息都放在这里面。这个阶段要解决的是语法解析、宏展开、模块例化关系建立、UVM 库链接、代码优化等一整套“翻译”工作，所以文件列表、宏定义、头文件路径、语言标准、优化等级这类选项全都属于编译期。

simv阶段做的事就纯粹是“运行”。它读入外部的激励、驱动时序、跑 testbench、dump 波形、记录日志。随机种子、仿真时间控制、波形文件名、UVM 测试名、覆盖率数据输出路径这些，全都是运行时才确定的东西，所以放在simv后面。理解这条分界线之后，你会发现很多“选项不生效”的问题其实都源于放错了位置。

1.2 选项放错阶段会发生什么

最隐蔽的一种情况是选项被静默忽略。比如你在vcs后面写了+ntb_random_seed=123，VCS 编译时看到它，不认识，但它可能只是当普通参数吞掉，不报错；等仿真跑起来，随机种子根本没生效，每次跑出来的结果都不一样，你还以为是自己代码里有随机没约束好。另一种是-l这种日志选项，编译和仿真都可以用，但输出的日志是两码事，编译日志记录的是解析过程，仿真日志记录的是运行时打印，混在一起看会误导排查方向。

实际排查这类问题的办法很简单：在vcs命令和simv命令各自的末尾都加上-l <logfile>，让两个阶段的日志分开落盘。当某个选项“看起来没起作用”时，先去对应阶段的日志里 grep 一下这个选项名，看它有没有被识别、有没有被忽略的告警。这一步能省掉大量瞎猜的时间，我个人几乎是条件反射式地先做这件事。

2. 编译期选项：代码是怎么被翻译成 simv 的

编译期选项决定了 VCS 怎么理解你的代码。同一个文件列表，选项不同，编译出来的simv行为可能完全不一样。这一部分按“文件怎么找、宏怎么传、性能怎么提、调试怎么开”四条线来讲，基本覆盖了实际环境里最常出现的那批选项。

2.1 语言标准、文件列表与库搜索

文件列表是编译的入口。最常见的写法是-f filelist.f或者-F filelist.f，两者看着一样，差别在网络化路径解析上：-f里写的相对路径是相对于你当前执行 vcs 命令的工作目录来解析的；-F里的相对路径是相对于这个 filelist 文件自己所在的目录来解析。这个差异在大型项目里非常关键。如果你的目录结构是多层的，脚本在某一层调用 filelist，而 filelist 里写的是../rtl/xxx.v这种相对路径，用-f和-F得到的结果可能完全不同。我吃过这个亏：本地跑得好好的，换到 CI 上路径就全错，最后发现是-f依赖工作目录导致的。

语言标准方面，-sverilog是老环境里几乎必写的选项，用来开启 SystemVerilog 支持。现在多数 VCS 版本默认就支持 SV，脚本里保留它更多是历史习惯，写了也不会有坏处。真正的老古董是+v2k，专门用来按 Verilog-2001 解析，现在基本只在维护非常老的 RTL 时才会遇到。

库搜索相关的两个选项是-y和+libext+，配合使用。-y <dir>告诉 VCS“去这个目录里找模块定义”，+libext+.v+.sv告诉它“只找这些扩展名的文件”。这两个选项在 RTL 代码分散、没有统一 filelist 的场景下很有用，但现代工程基本都用完整的 filelist，反而很少用到。值得一提的是，-y搜索是惰性的——只有某个模块没有在 filelist 里被显式列出来时，VCS 才会去-y目录里找，这个机制我建议保留在 code review 清单里，避免出现“某个文件没加进 filelist，但因为-y撞上了另一个同名文件”这种很难查的隐蔽问题。

2.2 宏、头文件路径与时间精度

宏定义用+define+MACRO或+define+MACRO=VALUE，等价于在代码最前面加了一行`define。这个选项是环境里改动最频繁的，因为它经常被用来做条件编译，比如`ifdef FSDB_GEN控制要不要 dump 波形、`ifdef DEBUG控制打印等级。也正因如此，它是增量编译失效的头号元凶——改一个宏，理论上会影响所有引用了这个宏的文件，VCS 只能保守地把相关文件全部重编。

头文件搜索路径用+incdir+<dir>，也可以写成-incdir+<dir>，作用是让`include能在指定目录里找到文件。多个路径可以连写，+incdir+a+b+c。这里的一个实操心得是：把自己工程用到的头文件目录统一放在一个变量里，编译时一次性追加，而不是让不同文件各自去拼路径。否则头文件名一旦重复（比如两个 IP 都有自己的defines.svh），谁先被搜到就取决于路径顺序，很容易出现“改了 A 文件，B 模块行为变了”的诡异现象。

时间精度是新手最容易忽略的一环。如果 RTL 和 testbench 里都没有显式声明`timescale，VCS 会使用一个默认值，不同版本默认值可能不同，这会导致延迟计算和波形对不上。稳妥的做法是编译时统一用-timescale=1ns/1ps指定全局默认，再在少数需要特殊精度的文件里单独声明。注意-timescale只是个默认值，文件里显式的`timescale优先级更高，所以不会覆盖掉你精心调过的模块。

2.3 编译性能与工程组织

大型项目全量编译动辄十几分钟，性能相关选项的价值就体现出来了。-j N开启并行编译，N 一般设为机器核数的 1 到 1.5 倍左右，比如 8 核机器用-j 8。这个选项在 RTL 文件上千个的项目里提速非常明显，但要注意它和增量编译的配合——并行编译本身不感知文件依赖，第一次全量编译用它是赚的，之后的日常编译更应该靠增量。

增量编译的核心是-Mupdate。第一次正常编译之后，VCS 会在simv.daidir里留下依赖信息；之后再编译时加上-Mupdate，VCS 只会重新解析那些被改动过的文件，其余沿用上次的结果。这个选项能把日常改一个 testcase 的编译时间从十几分钟压到几十秒。它的坑在于：-Mupdate对宏改动、头文件改动、filelist 顺序改动都相当敏感，一旦触发“保守重编”，你会觉得它时快时慢。所以我的习惯是把“改 RTL/改宏”和“只改 testbench”两类编译分开，后者才用-Mupdate，前者干脆老老实实全量，避免出现增量结果和全量结果不一致这种最难查的问题。

-o <name>用来指定输出可执行文件名，默认是simv。当你要同时维护多个不同配置的编译产物时，这个选项很有用，比如-o simv_cov和-o simv_fast并存。-l <logfile>则把编译日志写到指定文件。

2.4 调试能力与波形预处理

编译期还有一个大类是调试相关。-debug_access+all是比较现代、也比较推荐的写法，它开启完整的调试访问能力，是使用 UCLI 交互式调试、以及在 Verdi 里看信号层次的前提。老脚本里常见的-debug_all、-debug_pp是更早的写法，其中-debug_pp能力较弱，基本可以理解为只是开了个“能 dump 波形”的口子。如果你的环境里混着这两种写法，建议统一到-debug_access+all，功能更全，也避免不同版本行为差异。

调试访问有一个容易被忽视的代价：开得越全，编译越慢、simv 越大、运行越慢。-debug_access+all会保留大量符号信息，一个中等规模的设计可能会让 simv 体积翻倍。所以很多团队会准备两套编译配置——日常回归用轻量版，只有需要定位问题时才切到全调试版本。这个取舍没有标准答案，取决于你的回归时长和问题定位频率。

和 Verdi 联动还需要在编译期加上-kdb -lca。-kdb让 VCS 生成 Verdi 需要的 KDB 知识数据库，-lca是 Limited Customer Availability 授权相关的开关，很多增强特性需要它配合。这两个选项不加，后面verdi -ssf打波形时可能连信号层次都看不到，只能看到一堆扁平的名字。我见过不少人把波形打不开归咎于波形文件本身，折腾半天才发现是编译期没加-kdb。另外，-assert enable_diag这类断言相关选项也属于编译期，用来增强 SVA 的调试信息，排查断言失败时值得加上。

3. 仿真期选项：时间、随机、日志与运行时行为

编译产出的simv只是一个“通用引擎”，真正让它按你的意图跑起来的是仿真期选项。这一部分的东西大部分不是通过vcs传，而是跟在./simv后面，或者通过 testbench 里的系统函数触发。搞混这两个阶段，前面说过，是很多问题的根源。

3.1 时间尺度与延迟模式

仿真期和时序相关的选项，最常打交道的三个是+maxdelays、+mindelays、+typdelays。它们决定仿真读入 SDF（标准延迟格式）文件时，选择最大值、最小值还是典型值来建模延迟。做功能验证时一般用典型值或零延迟，做时序相关的后仿时才会在最大/最小之间切换。这几个选项配合-sdf <min|max|typ>:<module>:<sdf_file>使用，SDF 文件路径在仿真期指定，因为同一份网表可以搭配不同工艺角的 SDF。

+notimingcheck是另一个高频选项，作用是关闭时序检查，让仿真不去检查 setup/hold。它经常被用在“我只关心功能对不对，不关心时序”的场景，能显著提速。但它的名字有迷惑性——+notimingcheck关掉的是时序检查，不是延迟，延迟该有的还是有。如果连延迟都不想要，那是+delay_mode_zero这类选项的活。这几个选项很容易被当成一回事，实际含义差别很大，我建议在脚本里对它们的用途写一行注释，免得半年后自己都忘了为什么加。

3.2 随机种子与回归复现

+ntb_random_seed=<N>是我在仿真期选项里最看重的一个。它给$urandom这类随机函数设定种子，决定这一轮仿真的随机激励序列。回归时最怕的就是“某个 case 偶尔失败”，如果没有固定种子，你根本没法复现。所以标准做法是：每一个回归用例的日志和波形，都要记录它这一轮用的种子值，失败时用同一种子重跑，问题就能稳定重现。

+ntb_random_seed_automatic让 VCS 自动生成种子，适合大批量随机回归，能保证每轮种子不同；但它和“复现”是矛盾的，所以通常只在探索性回归里用。这里有个细节值得强调：UVM 里除了ntb_random_seed，还有各组件自己的get_seed和+UVM_TESTNAME配合的随机化，两套种子体系是独立的。只固定了ntb_random_seed，不代表整个环境完全确定——如果 testbench 里用了$random而不是$urandom，它走的是另一套种子。我踩过一次这样的坑：明明固定了种子，结果还是每次不一样，排查半天才发现是某段老代码里用了$random。

3.3 日志、license 与超时控制

仿真日志用-l <sim.log>落到文件里。除此之外，$display和uvm_info的输出等级由+UVM_VERBOSITY=<level>在仿真期控制，这个是 UVM 环境里调打印的常规手段，比改代码里的uvm_info参数方便得多。要注意UVM_LOW和UVM_HIGH的差别：日常回归一般用UVM_LOW或者UVM_MEDIUM，只有当你要定位某个uvm_info到底有没有执行、执行顺序对不对时，才临时开到UVM_DEBUG，否则日志会大到没法读。

+vcs+lic+wait处理的是 license 排队问题。当多个仿真并发跑、license 不够时，不加这个选项，拿不到 license 的仿真会直接退出；加上它，仿真会等待直到拿到 license 再开始。这个选项在回归脚本里几乎是必加的，否则半夜跑回归可能一半任务因为 license 抢占而失败。相似的还有+UVM_TIMEOUT=<time>,<override>，用来设置 UVM 的全局超时，防止某个 case 挂死导致回归卡住。设超时的时候有个经验值参考：设为正常跑完时间的 2 到 3 倍，太短会误杀慢 case，太长起不到保护作用。

3.4 运行时波形控制：UCLI 与 $fsdbDumpfile

波形的生成方式大致有两类。一类是在 testbench 代码里直接调用系统函数，典型的如$fsdbDumpfile("wave.fsdb")配合$fsdbDumpvars(0, tb_top)，属于代码控制。另一类是编译时开好调试访问，运行时用 UCLI 脚本控制，写法是./simv -ucli -i dump.tcl，其中dump.tcl里写fsdbDumpfile、fsdbDumpvars、run这些命令。UCLI 方式的好处是波形控制从代码里解耦出来，改波形范围不用重新编译，调试期非常灵活。

我个人的习惯是：日常回归跑精简波形或者干脆不 dump，只有调试特定 case 时才用 UCLI 精细地 dump 相关层次。原因很简单，全量 dump 一个复杂 SoC 的波形文件几个 G 起步，磁盘和 IO 都会被拖垮。UCLI 里还可以配合-ucli的交互模式和fsdbDumpoff/fsdbDumpon，只在特定时间段或特定事件前后打开 dump，这个技巧在处理“跑了很久才出问题”的 case 时特别好用。需要提醒的是，$fsdbDumpfile这类系统函数依赖 Verdi 提供的 PLI，环境和库路径没配好时会报undefined system task，这是另一类需要单独排查的配置问题。

4. 覆盖率与 Verdi 联动：验证收尾阶段绕不开的选项

功能验证做到后期，绕不开两件事：覆盖率收集和波形查看。这两块各自有一批固定搭配的选项，写错了要么覆盖率收不上来，要么 Verdi 打不开波形。这一章单独拎出来讲，因为它们和前面的常规编译仿真选项在使用节奏上有明显区别——覆盖率是“编译时使能、运行时收集、结束后合并”三段式的。

4.1 覆盖率编译选项：-cm 与 -cm_dir / -cm_name

覆盖率的采集类型由-cm指定，常见组合是-cm line+cond+fsm+tgl+branch+assert，分别对应行覆盖率、条件覆盖率、状态机覆盖率、翻转覆盖率、分支覆盖率和断言覆盖率。这个选项编译期和仿真期都要写，因为编译时要插入对应的统计逻辑，运行时才知道要收集哪些。只写了编译期没写仿真期，数据是空的；只写仿真期没写编译期，VCS 会在运行时提示覆盖率模块未编译进去。

输出目录和用例命名用-cm_dir和-cm_name。典型写法是运行./simv -cm line+cond+fsm+tgl+branch -cm_dir ./cov.vdb -cm_name tc_smoke_001。这里的关键在于-cm_name要唯一，它决定了这份数据在合并时是一个独立的用例。如果回归脚本里所有 case 都用了同一个名字，合并出来的覆盖率会互相覆盖，你根本分不清是哪个 case 贡献的。我在脚本里见过有人把-cm_name写死成一个常量，结果几十个 case 合并后覆盖率奇低，查了很久才发现是命名冲突导致的互相覆盖。后来又有人用-cm_dir每个 case 一个目录来规避，也可以，但目录会很多，占用空间大，需要定期清理。

还有个-cm_hier <config_file>选项用来指定覆盖率收集的层次范围，通过配置文件精确控制哪些模块收集、哪些不收集。在大型设计里这个很有必要，因为把整个 SoC 所有层次都收满，仿真会慢到无法接受。通常只对 DUT 收覆盖率，testbench 和第三方 IP 排除在外。

4.2 从 VCS 到 Verdi：-kdb -lca 到 verdi -ssf

生成波形之后，查看波形一般走 Verdi。前面编译期提到的-kdb -lca是第一步，它让 VCS 在simv.daidir里生成 KDB 库，这是 Verdi 能识别信号层次、模块结构的基础。第二步是仿真期生成 FSDB 波形，也就是前面$fsdbDumpfile或 UCLI 那套。第三步才是打开 Verdi：verdi -dbdir simv.daidir/kdb -ssf wave.fsdb &，其中-dbdir指向 KDB 库，-ssf加载波形文件。这三步缺一不可，而且顺序上 KDB 是编译期产出的，波形是仿真期产出的，两者必须来自同一次编译运行，否则信号层次对不上。

常见的“波形打开了但看不到信号”问题，多数是-kdb没加，或者verdi加载的 KDB 和波形不是同一次运行的。还有一种情况是命名空间问题：如果设计里用了-top显式指定顶层，Verdi 的层次树会和 testbench 里的引用方式一致；如果没指定，VCS 自动推断顶层，有时会多出一层包装，让人找不到信号。-top <module>这个编译选项就是为了明确顶层模块，建议在环境里显式写出来，避免自动推断带来的不确定性。

4.3 覆盖率合并与查看：urg 的基本用法

收集到一堆cov.vdb之后，用urg合并查看。基本写法是urg -dir ./cov.vdb -dir ./cov2.vdb -report ./urgReport，把多个目录或文件合并成一个 HTML 报告。这个工具里比较有用的选项是-format both（同时生成文本和 HTML）和-metric line+cond+fsm+tgl+branch（只报告关心的指标）。真正实操里最容易出问题的不是 urg 本身，而是前面-cm_name命名和-cm_dir组织没做好，导致合并结果不可信。

这里分享一个实际经验：回归里的覆盖率数据建议按天或者按 run 批次分目录存放，而不是所有历史数据堆在一个大目录里。原因是一旦某个 case 的覆盖率数据损坏（仿真中途被 kill、磁盘写满等），合并时 urg 可能报错退出，把整个目录的数据都带崩。分批存放，至少能保证大部分数据可用。另外，增量回归时可以先合并历史数据、再合并增量，urg支持多次-dir叠加，这个用法在长时间项目里能省掉重复合并的开销。

5. 一套可复用的 Makefile 组织方式与选项速查

讲完单个选项，最终还是要落到“怎么把它们组织起来”。我见过的最乱的环境是所有选项平铺在一行，改一个参数要在一百多字符里找位置。比较舒服的组织方式是把编译段和运行段彻底分开，各自维护一份选项变量，再用目标（target）来组合。

5.1 编译段和运行段分开写

参考结构大致如下。注意这里只是展示组织思路，具体值要按你的设计规模调整。

# 编译期选项 VCS_COMPILE_OPTS = -full64 -sverilog -timescale=1ns/1ps \ -debug_access+all -kdb -lca \ -f filelist.f \ +define+FSDB_GEN \ +incdir+./include \ -ntb_opts uvm-1.2 \ -l compile.log # 仿真期选项 SIM_RUN_OPTS = +UVM_TESTNAME=$(TEST) \ +UVM_VERBOSITY=UVM_LOW \ +ntb_random_seed=$(SEED) \ +vcs+lic+wait \ -l sim.log compile: vcs $(VCS_COMPILE_OPTS) -o simv run: ./simv $(SIM_RUN_OPTS) cov_compile: vcs $(VCS_COMPILE_OPTS) -cm line+cond+fsm+tgl+branch -cm_dir ./cov.vdb -o simv_cov cov_run: ./simv_cov $(SIM_RUN_OPTS) -cm line+cond+fsm+tgl+branch -cm_dir ./cov.vdb -cm_name $(TEST)

这种写法的好处是一目了然：VCS_COMPILE_OPTS里全是编译期的东西，SIM_RUN_OPTS里全是仿真期的。当有人问“这个+ntb_random_seed为什么不生效”，你一眼就能看出它有没有被放到正确的变量里。同时TEST、SEED这类参数用$(...)变量传递，回归脚本调用时从外部注入，不用改 Makefile 本身。

5.2 常用选项速查表

下面这张表是我按“阶段 + 用途 + 常见写法”整理的高频选项，可以直接当作速查用。

这张表里最容易被写错阶段的就是-cm和+UVM_*系列：-cm两阶段都要，UVM 相关的都在仿真期。

5.3 几个反直觉的踩坑记录

第一个坑：增量编译 + 宏改动。前面提过，这里再强调一次。有一次同事改了一个+define+的值，用-Mupdate编译，结果仿真行为和改之前完全一样。查到最后是增量编译没有正确感知宏变化。结论：改动任何+define+或者被广泛引用的头文件之后，务必全量重编一次，别指望增量。

第二个坑：-debug_access+all和性能。一个跑 40 分钟的 case，去掉全调试访问之后 25 分钟就跑完了。原因是调试信息保留了太多信号的可访问性，仿真内核需要维护更多状态。这个代价在回归阶段是纯损失，所以日常回归的编译配置和调试配置建议物理分开。

第三个坑：-cm_name在并行回归里冲突。并行跑 20 个 case，如果并行度是 8，同时有 8 个仿真往同一个-cm_dir里写，且-cm_name有重复，数据会互相覆盖。正确做法是让-cm_name带上唯一的用例 ID 或进程号，或者每个并行任务用独立的-cm_dir。

6. 版本差异与那些“文档里不写”的细节

VCS 的选项在不同版本之间有一些细微差异，尤其是调试和覆盖率相关的那批。-debug_pp之类的老选项在新版本里还能用，但行为和-debug_access+all不完全等价，建议新环境一律用带_access的新写法。UVM 库版本通过-ntb_opts uvm-1.2指定，这个选项要和环境里实际用的 UVM 源码版本对上，否则可能出现接口不兼容的编译错误。有些团队会同时维护两套环境，一套用 VCS 自带的 UVM 库，一套链接外部 UVM 源码，切换时最容易忘记改的就是这个选项。

关于数字 IC 用哪套仿真器这件事，实际工作中 VCS、Xcelium、Questa 各有使用场景，同一个团队也可能因为项目历史原因混用。不同工具的同名选项语义未必一致，比如固定随机种子这件事，VCS 的+ntb_random_seed对应到别的工具是完全不同的选项名。这也是为什么我在前面反复强调要理解“选项在做什么”，而不是背选项名——理解了随机的种子机制，换个工具你也能快速找到对应的开关。

最后再分享一个我自己踩过、也见过别人反复踩的细节：-l指定的日志文件，如果编译和仿真用了同一个路径，后一次会覆盖前一次。排查问题时如果只保留了仿真日志，编译期的告警信息就丢了，而很多隐蔽问题恰恰藏在编译告警里（比如隐式线网、位宽不匹配）。我的习惯是编译日志固定叫compile.log、仿真日志固定叫sim.log，两个都保留，出问题时一起看。另外，VCS 编译时的-notice、+lint、-suppress这类告警控制选项也值得花点时间去配，把真正有价值的告警留下、把噪音压掉，长期看能挡掉不少后期才发现的设计问题。