干验证这行的人基本都绕不开 VCS。我第一次碰它还是在学校实验室导师丢给我一套 RTL 代码和一个安装包没有文档、没有教程我自己硬生生折腾了小一周才把第一个仿真跑通。后来到公司里发现很多刚入行的同事也卡在同一个地方安装环境乱、环境变量配不对、VCS 和 Verdi 的联调搞不清楚。网上的资料又东一篇西一篇要么太老要么只讲了半截。所以这篇我想一次讲透从装 VCS 开始到环境配置再到和 Verdi 的联合仿真把整条链路串起来。VCS 是 Synopsys 家的编译型 Verilog/SystemVerilog 仿真器在数字 IC 前端 RTL 仿真、后端的门级仿真、UVM 验证环境搭建这些环节里几乎是无处不在。它和 Cadence 的 Xcelium、Siemens EDA 的 Questa 属于同一个赛道但论行业占有率VCS 加上 Verdi 这套组合基本是很多团队默认的选择。所谓编译型就是它会把你的 Verilog 代码编译成一个可执行的二进制仿真程序仿真时直接运行这个二进制文件比解释型仿真器更快这对大规模 SoC 验证来说差别非常明显。这篇内容比较适合几类人刚开始学数字 IC 验证的在校学生、准备搭建个人验证环境的转行朋友、以及在 Linux 服务器上接手验证环境的新手工程师。文章里没有任何跳过流程的捷径操作就是一套正规、稳定、能长期用的安装与联调方法。1. 安装前的系统准备环境不对后面全白干很多人装 VCS 失败不是命令敲错而是安装之前没把系统环境收拾干净。VCS 本身是商业化 EDA 工具对操作系统、库文件、内核版本都有要求而且在多个 Linux 发行版上的表现差异很大。这一节先把这些前置条件讲清楚后面安装时你就不用一边装一边补系统依赖了。1.1 操作系统与硬件要求VCS 官方支持的操作系统主要是 RHEL、CentOS、Oracle Linux 这类企业级发行版以及 SUSE Linux Enterprise。Ubuntu 虽然也能跑但毕竟不是 Synopsys 官方主推的平台依赖库的坑会多一些下面第 6 章会专门讲。先说硬件。VCS 对 CPU 的要求反倒不算高主流的 x86_64 架构四核以上即可满足日常中等规模仿真。真正吃配置的环节往往在后端综合、门级仿真或者跑大型 SoC 验证用例时编译本身倒还好。内存建议至少 16GB如果要仿真比较大的设计32GB 起步是常态。至于磁盘空间VCS 安装包解开之后加上 Verdi整个工具链占用通常在 20GB 到 50GB 之间但这里有个很多人忽略的问题仿真运行过程中会产生波形文件VPD、FSDB以及一堆中间编译产物这些文件动辄几个 GB所以你还得给项目目录预留足够空间。如果你是在本地虚拟机或者 WSL 里装建议直接把虚拟磁盘给到 80GB 以上否则做到一半磁盘满了删除重来特别折腾。1.2 共用库和基础工具缺一不可这是安装前最容易忽略的一环。VCS 在编译和运行时依赖大量动态库和基础工具系统里少了任何一个安装器虽然能正常走完但跑仿真时会莫名其妙报lib 找不到的错误。我遇到过的情况包括缺少libXext、libX11、libXft、libstdc、libgomp等库这些都是 X11 图形界面和 OpenMP 并行库相关的依赖。在 RHEL/CentOS 以及兼容发行版上可用 yum 统一补齐sudo yum install -y glibc-devel libX11-devel libXext-devel \ libXft-devel libXmu-devel libXt-devel \ libstdc-devel gcc gcc-c make \ motif-devel xterm csh kshUbuntu/Debian 系的对应命令sudo apt-get install -y libx11-dev libxext-dev libxft-dev \ libxmu-dev libxt-dev g gcc make \ libmotif-dev xterm csh ksh这里要特别说明一下csh和ksh。很多教程不吭声但 Synopsys 的安装器、VCS 的启动脚本里有大量 C Shell 语法如果系统里没有 csh安装和初始化环境时直接报错。所以不管你是用 bash 还是 zsh 作为日常 shell这两样都建议装上。另外检查一下系统里有没有可用的gcc和make版本不要太新也不要太老。VCS 内部会调用系统编译器来完成一些编译任务gcc 版本太新有时反而和 VCS 不兼容报出一些奇怪的编译错误。如果遇到通常装一个 gcc 8 或 gcc 9 这样的中古版本就稳了具体在下文排错里细说。1.3 提前规划 License 环境变量VCS 是商业软件启动和运行时需要连接 Synopsys License 服务器。安装之前需要确认三件事License 服务器的 IP 或主机名、端口号通常是27000license_server这样的格式当前网络是否能访问该服务器License 里包含的 Feature 是否覆盖 VCS 和 Verdi规划环境变量时比较稳妥的做法是在用户主目录下新建一个环境变量配置文件比如~/.synopsys_env.sh把 License 信息集中写进去。常用变量有两个SNPSLMD_LICENSE_FILE和LM_LICENSE_FILE。前者是 Synopsys 自己的 license 管理工具用的后者是 FlexLM 通用变量。实际使用中我两个都会设上但这里有个优先级的问题SNPSLMD_LICENSE_FILE优先被 Synopsys 工具读取如果设置不对后面那个配得再好也没用。所以两个值最好保持一致避免排查时精神分裂。2. 安装流程从安装包到可执行程序前面环境准备完毕现在进入安装环节。Synopsys 的 EDA 工具安装不是直接解压就行它们采用统一的 Synopsys Installer安装器来管理安装过程。VCS 和 Verdi 是同一个安装器体系所以流程是基本一致的。2.1 安装器准备与启动先把 VCS 和 Verdi 的安装包拷贝到 Linux 机器上然后解压。通常会有一个SynopsysInstaller目录里面包含安装器的压缩包比如SynopsysInstaller_v5.4.tar另外还有 VCS 主程序的 tar 包以及 Verdi 的 tar 包。把它们都解压到同一个临时目录比如~/eda_installmkdir -p ~/eda_install tar -xvf SynopsysInstaller_v5.4.tar tar -xvf vcs-mx_vO-2018.09-SP2.tar # 假设的VCS包名 tar -xvf verdi-2018.09-SP2.tar # 假设的Verdi包名解压完成之后进入安装器目录启动安装器cd ~/eda_install ./setup.sh这里要注意Synopsys 安装器是通过图形界面方式运行的所以在纯命令行服务器上需要保证有 X11 转发能力。如果你是通过 SSH 连接服务器SSH 命令要加上-X选项本机要有 X ServerWindows 下可以用 MobaXterm 或 Xming。如果实在没有图形环境安装器也有命令行静默安装模式不过参数比较繁琐还是推荐用图形界面至少每一步你能看到它到底在干什么。安装器启动后会让你指定安装根目录。我一般习惯放在统一的目录下比如/home/yourname/eda/synopsys。这个路径后面会用到建议选一个自己好记住的。安装器会依次让你选择要安装的组件这时分别选择 VCS 和 Verdi然后一路确认安装路径和组件列表。整个过程大概十几分钟主要耗时在解压文件和复制文件上。2.2 安装完成后的目录结构装完之后去看一眼安装目录结构确认所有关键子目录都已经生成。一个典型的 VCS 安装目录大概是这样的~/eda/synopsys/ ├── vcs/mx/ │ ├── bin/ │ ├── etc/ │ ├── lib/ │ └── linux64/ ├── verdi/ │ ├── bin/ │ ├── lib/ │ ├── share/ │ └── platform/ └── scl/ # License 客户端工具vcs/mx/bin目录里能找到vcs主命令verdi/bin里有verdi命令scl目录提供lmgrd、lmstat等 License 管理工具。如果这些目录都存在说明安装器的文件拷贝过程正常。安装完成到这一步还不算结束真正决定能否跑通的是环境变量配置。3. 环境变量配置让工具能被你找到EDA 工具不像很多软件那样装完自动往 PATH 里注册你需要手动告诉系统 VCS 和 Verdi 装在哪里、License 去哪找、临时文件放哪。这一步是新手最容易翻车的地方。3.1 核心变量设置在~/.bashrc或者~/.cshrc取决于你的默认 shell末尾加上下面这段# Synopsys VCS and Verdi environment export VCS_HOME~/eda/synopsys/vcs/mx export VERDI_HOME~/eda/synopsys/verdi export PATH$VCS_HOME/bin:$VERDI_HOME/bin:$PATH # License settings export SNPSLMD_LICENSE_FILE27000your_license_server export LM_LICENSE_FILE27000your_license_server # VCS runtime temporary directory export VCS_ARCH_OVERRIDElinux64逐行解释一下这里面的坑。VCS_HOME是 VCS 自身的根目录后面 VCS 的很多内部子脚本会引用这个变量不设置的话编译阶段可能报 Cannot find vcs 或者 VCS_HOME is not set 这类错误。VERDI_HOME同理是 Verdi 的根目录。VCS_ARCH_OVERRIDElinux64这个变量很多教程不提但对新版本 VCS 来说挺关键。它显式指定 VCS 以 64 位架构模式运行。如果不设置VCS 会尝试自动检测在某些系统上会误判成 32 位导致链接库时找不到对应的 64 位库文件。这个变量我一般在做环境模板时都会默认加上。设置完之后记得让配置生效source ~/.bashrc然后验证一下 vcs 能否被找到which vcs which verdi正常情况下会分别输出 VCS 和 Verdi 可执行文件的完整路径。如果这一步没有输出说明 PATH 没有生效可能是路径写错也可能是没有 source。切换到对应的 shell 配置文件再 source 一次多半就解决了。3.2 临时文件目录与权限问题VCS 在编译和仿真过程中会在/tmp下创建大量临时文件。如果/tmp空间不足或者当前用户没有写权限编译会卡在中间状态报出 Cannot create temp directory 或类似信息。遇到这种情况可以在环境变量里指定 VCS 使用用户自己的临时目录export VCS_TMPDIR~/tmp/vcs mkdir -p ~/tmp/vcs这样 VCS 的中间文件就不会去挤系统的/tmp了。尤其在公司共用服务器上/tmp经常被其他人塞满独占一个临时目录反而更稳。3.3 验证安装跑一个最小仿真环境变量配置完先不急着拿大型工程试水。用一个小到不能再小的设计验证整条链路是否打通。先建一个测试目录mkdir -p ~/test_vcs cd ~/test_vcs创建两个文件一个 RTL 文件一个 testbench// top.v module top(input wire a, b, output wire y); assign y a b; endmodule// tb.v module tb; reg a, b; wire y; top u_top(.a(a), .b(b), .y(y)); initial begin a 0; b 0; #10; a 1; b 0; #10; a 1; b 1; #10; $display(Test done.); $finish; end endmodule然后执行编译和仿真vcs -sverilog v2k -debug_accessall -o simv tb.v top.v -l compile.log ./simv -l run.log如果看到终端输出Test done.恭喜整个安装闭环已经通了。-sverilog是让 VCS 支持 SystemVerilog 语法v2k是兼容 Verilog-2001 的旧选项新版本里即使不加也能自动识别但加上能减少一部分兼容性报警。-debug_accessall是联合 Verdi 调试的关键参数现在先不加也能跑但后续要做波形分析就必须要。到这一步VCS 本体的安装与基本运行已经验证完毕。接下来是重点中的重点和 Verdi 的联合仿真。4. VCS 与 Verdi 联合仿真验证工程师的日常工作流如果说 VCS 是仿真引擎那 Verdi 就是仪表盘。两者一前一后配合使用是数字验证里最经典的组合。Verdi 主要负责波形查看、原理图追踪、状态机调试而 VCS 负责把你写的 RTL 代码变成能执行的仿真程序。很多人安装完 VCS 后单独跑仿真没问题一旦要打开 Verdi 看波形就抓瞎原因就在于编译时没有生成调试用的数据库文件。4.1 编译阶段生成 VCS 与 Verdi 通用的调试数据库要用 Verdi 看 VCS 仿真的波形和信号核心在于编译 VCS 时开启调试信息。这里的关键参数是-debug_accessall它会告诉 VCS 在编译时保留完整的设计层级信息、源码映射关系和信号可访问性。配合 Verdi 时还可以额外加一个-kdb参数让 VCS 同时生成一个更高效的 Knowledge DatabaseVerdi 加载这个数据库后能快速索引整个设计打开大型工程时的响应速度差距非常明显。一条典型的联调编译命令是这样的vcs -sverilog v2k \ -debug_accessall \ -kdb \ -f filelist.f \ -top tb_top \ -l compile.log \ -o simv-f filelist.f是从文件列表读入所有 RTL 文件的参数在实际工程项目里几乎是必备的因为设计文件通常有几十上百个。-top tb_top是指定顶层模块防止 VCS 在多顶层设计时报错。4.2 在 Verdi 中打开并加载设计仿真编译完成并且跑完至少一次仿真之后就可以用 Verdi 打开设计了。这里的目标是让 Verdi 识别同一套设计源文件和层次结构。命令如下verdi -sv v2k -f filelist.f -top tb_top 如果你还想让 Verdi 直接加载 VCS 编译产生的仿真数据库比如保存了设计层级信息的.vpd文件可以加上 VPD 文件的路径。VPD 是 VCS 自家的波形格式Verdi 完全支持打开。而如果你想导出通配性更强的 FSDB 格式那就需要额外挂载 FSDB 相关的 PLI 库参数。这里展开讲一下两种格式的取舍波形格式生成方调试集成度文件大小使用场景VPDVCS 原生高可直接被 Verdi 加载较大VCS 单工具链、快速调试FSDB通过 PLI 导出高Verdi 压缩效率高较小大规模回归、跨工具共享FSDB 的生成方式可以在 VCS 编译命令里加这两个参数-P $VERDI_HOME/share/PLI/VCS/LINUX64/novas.tab \ $VERDI_HOME/share/PLI/VCS/LINUX64/pli.a其中novas.tab是 VCS 与 Verdi 之间 PLI 调用的映射文件pli.a是编译好的静态库Verdi 安装目录里自带不需要额外编译。不过要注意不同版本 Verdi 下这两个文件的相对路径可能不同建议安装后用find $VERDI_HOME -name novas.tab确认一下实际路径。4.3 Testbench 中导出 FSDB 波形的标准写法即使编译参数都对了如果你在 testbench 里没有声明 FSDB 文件的生成调用Verdi 里照样看不到任何信号。在 testbench 的 initial 块里加上下面几行initial begin $fsdbDumpfile(tb_top.fsdb); $fsdbDumpvars(0, tb_top); end$fsdbDumpvars(0, tb_top)的含义是从顶层tb_top开始递归导出所有层级的所有信号。第一个参数0表示层级数限制为无限如果你想只导出顶层往下一层可以改成1。这个函数是 PLI 库提供的所以前面编译时-P novas.tab pli.a这两个参数必须存在否则 VCS 编译到这一句会直接报 undefined task。跑完仿真目录下会生成tb_top.fsdb文件。然后再打开 Verdi用它加载这个文件verdi -ssf tb_top.fsdb -ssf是 single source file 的缩写表示加载一个波形数据库文件。这时 Verdi 的波形窗口会显示所有已导出信号随时间变化的曲线。配合源码窗口点击信号就能高亮追踪到对应的 RTL 代码位置这就是验证工程师日常调试的基本姿势。4.4 关于 Xcelium 和 VCS 的选择问题最近经常有入行没多久的小伙伴问我Xcelium 和 VCS数字 IC 验证到底该学哪个我的看法是如果不是公司明确要求用某一种优先学 VCS Verdi 这个组合。原因不复杂。VCS 在性能上对大规模设计的回归测试有优势而 Verdi 的调试体验在业界口碑很稳两者配合后的操作熟练度可以平移到绝大多数公司。Xcelium 作为 Cadence 的工具链在部分团队和高校里也有使用但整体生态和资料丰富程度略逊一筹。更实际的策略是先把 VCS Verdi 这套组合玩到闭眼能操作再花半天熟悉 Xcelium 的命令差异基本就能两个工具都上手。5. 常见问题与排查实录工具装多了就发现90% 的问题不是出在工具本身而是出在环境和配置的细节上。下面列出的几个问题是我在 VCS 安装和联调过程中真实遇到过、并且反复出现的整理成速查表遇到问题直接对号入座。5.1 编译时报缺少共享库这是最常见的拦路虎。错误信息大多是error while loading shared libraries: libX11.so.6或者类似形式。排查思路很直接先确认系统里到底有没有这个库。用ldconfig -p | grep libX11查看。如果没有就回到第 1 节的依赖安装部分把对应库补上。如果库存在但还是编译不过多半是库的位数不对。64 位 VCS 只能加载 64 位动态库系统里装的是 32 位版本的库就会报这个错。用file /usr/lib64/libX11.so.6确认一下位数。5.2 License 连接失败报错信息通常是 Can t get license 或 Invalid license key。这类问题分几种原因License 服务器地址写错。检查SNPSLMD_LICENSE_FILE变量是否准确我见过有人把端口号写成 27000 但实际服务器监听的是 27020 的。网络不通。用telnet license_server 27000测试端口连通性。License 客户端工具和服务器版本不兼容。Synopsys 的 License 服务版本如果太老新的 VCS 连接时可能会协商失败。这个情况在混合版本环境里比较典型最好将sclLicense 客户端工具也升级到与 VCS 匹配的版本。License 本身不包含 VCS 的 Feature。这种情况只能找管理员确认 Feature 授权光改环境变量没用。5.3 GCC 版本不兼容导致的编译异常VCS 在仿真编译阶段偶尔会调用系统 gcc 来链接生成的 C 代码。如果 gcc 版本太新比如在 Ubuntu 22.04 上默认的 gcc 11VCS 较旧版本比如 2018、2020 早期的版本可能会在链接阶段报错或者是 warning 太多导致编译流程被干扰。解决办法有两条路。一是给 VCS 指定旧版本 gcc比如系统里装了 gcc-9可以在环境变量里加export VCS_GCC/usr/bin/gcc-9二是用较新版本的 VCS新版本2022 之后通常对 gcc 11、gcc 12 的兼容性已经明显改善。如果条件允许升级 VCS 比降级 gcc 更省心。5.4 Ubuntu 下安装额外注意事项前文说过Ubuntu 不是 VCS 官方主推平台主要问题集中在图形库路径差异和缺库上。Ubuntu 的 64 位库目录是/usr/lib/x86_64-linux-gnu而 VCS 的部分脚本会固定的去/usr/lib64下找库。解决方法是做一个软链接sudo ln -s /usr/lib/x86_64-linux-gnu /usr/lib64另外 Ubuntu 自带的 dash 作为/bin/sh的默认解释器有时也会和 VCS 的 shell 脚本不兼容。遇到奇怪的脚本执行问题可以把默认 shell 改回 bashsudo dpkg-reconfigure dash在弹出的界面里选择否也就是不将 dash 作为默认 sh。这个操作对很多 EDA 工具都有帮助不止 VCS 一个。5.5 仿真跑完但 FSDB 文件是空的这种情况通常不是安装问题而是 testbench 里$fsdbDumpvars调用的位置不对或者编译时没有把$fsdbDumpfile识别为合法系统任务。检查两步确认编译命令里包含-P novas.tab pli.a参数确认 testbench 中$fsdbDumpfile和$fsdbDumpvars在 initial 块的最前面。如果是在$finish之后才调用那当然啥也导不出来。6. 一键式环境脚本省去重复劳动工具链装完、跑通一个最小仿真之后我强烈建议你把环境变量配置收敛成一个独立脚本不管是在自己电脑上还是团队服务器上都方便复用。下面是一个我实际在用的模板你把它存成setup_vcs_env.sh以后每次打开新终端只需要 source 一下。#!/bin/bash # VCS / Verdi environment setup export VCS_HOME/your/path/to/synopsys/vcs/mx export VERDI_HOME/your/path/to/synopsys/verdi export PATH$VCS_HOME/bin:$VERDI_HOME/bin:$PATH # License export SNPSLMD_LICENSE_FILE27000your_license_server export LM_LICENSE_FILE27000your_license_server # Arch override export VCS_ARCH_OVERRIDElinux64 # Temp directory export VCS_TMPDIR/your/home/tmp/vcs mkdir -p $VCS_TMPDIR echo VCS and Verdi environment ready. echo VCS version: $(vcs -id | head -1)这个脚本每次运行时会自动打印当前 VCS 版本号方便排查是不是出现了多版本环境变量互相污染的问题。在团队共用的服务器上如果多个人各自 source 不同的版本而 PATH 里同时存在多个 VCS 的 bin 目录which vcs的结果不一定指向你想用的那个。遇到这种情形用which vcs加vcs -id双重确认最靠谱。7. 一些个人经验和收尾建议安装这套工具链我前前后后踩过不少坑总结下来最核心的一条建议是不要跳过前面任何一步看起来多余的检查。尤其是 csh 这种看似和仿真无关的依赖缺失时报错信息特别迷惑让你误以为是 VCS 本身的问题排查方向完全跑偏。另一个建议是安装完第一件事不要急着跑大工程一定要先用最小设计验证一遍全链路。我在团队里见到的很多环境问题都是因为一上来编译大型 SoC报错信息被淹没在上百行日志里新手根本找不到关键线索。先用一个几十行的 testbench 跑通再慢慢扩大范围效率反而更高。最后再分享一个实用技巧VCS 编译时养成加编译日志的习惯也就是-l compile.log仿真时同样用-l run.log记录输出。遇到诡异问题第一件事永远是翻日志文件的末尾部分绝大多数错误信息都会明确指向真正的原因。配合grep -i error compile.log快速定位比在终端里大海捞针强得多。工具装好了剩下的就是多跑、多写、多试。VCS 这套工具链虽然入门曲线略陡但环境一旦通了后面所有验证工作都会顺畅很多。祝你能在一个清爽的环境里把精力放在设计和验证本身而不是和安装过程死磕。