企业官网建设流程全解析

干验证这行的人，基本都绕不开 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 ksh

Ubuntu/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 或主机名、端口号，通常是27000@license_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_install：

mkdir -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 Server（Windows 下可以用 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_FILE=27000@your_license_server export LM_LICENSE_FILE=27000@your_license_server # VCS runtime temporary directory export VCS_ARCH_OVERRIDE=linux64

逐行解释一下这里面的坑。

VCS_HOME是 VCS 自身的根目录，后面 VCS 的很多内部子脚本会引用这个变量，不设置的话编译阶段可能报 "Cannot find vcs" 或者 "VCS_HOME is not set" 这类错误。VERDI_HOME同理，是 Verdi 的根目录。

VCS_ARCH_OVERRIDE=linux64这个变量很多教程不提，但对新版本 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_access+all -o simv tb.v top.v -l compile.log ./simv -l run.log

如果看到终端输出Test done.，恭喜，整个安装闭环已经通了。-sverilog是让 VCS 支持 SystemVerilog 语法，+v2k是兼容 Verilog-2001 的旧选项，新版本里即使不加也能自动识别，但加上能减少一部分兼容性报警。-debug_access+all是联合 Verdi 调试的关键参数，现在先不加也能跑，但后续要做波形分析就必须要。

到这一步，VCS 本体的安装与基本运行已经验证完毕。接下来是重点中的重点：和 Verdi 的联合仿真。

4. VCS 与 Verdi 联合仿真：验证工程师的日常工作流

如果说 VCS 是仿真引擎，那 Verdi 就是仪表盘。两者一前一后配合使用，是数字验证里最经典的组合。Verdi 主要负责波形查看、原理图追踪、状态机调试，而 VCS 负责把你写的 RTL 代码变成能执行的仿真程序。很多人安装完 VCS 后单独跑仿真没问题，一旦要打开 Verdi 看波形就抓瞎，原因就在于编译时没有生成调试用的数据库文件。

4.1 编译阶段：生成 VCS 与 Verdi 通用的调试数据库

要用 Verdi 看 VCS 仿真的波形和信号，核心在于编译 VCS 时开启调试信息。这里的关键参数是-debug_access+all，它会告诉 VCS 在编译时保留完整的设计层级信息、源码映射关系和信号可访问性。配合 Verdi 时，还可以额外加一个-kdb参数，让 VCS 同时生成一个更高效的 Knowledge Database，Verdi 加载这个数据库后能快速索引整个设计，打开大型工程时的响应速度差距非常明显。

一条典型的联调编译命令是这样的：

vcs -sverilog +v2k \ -debug_access+all \ -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 库参数。这里展开讲一下两种格式的取舍：

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 连接时可能会协商失败。这个情况在混合版本环境里比较典型，最好将scl（License 客户端工具）也升级到与 VCS 匹配的版本。
• License 本身不包含 VCS 的 Feature。这种情况只能找管理员确认 Feature 授权，光改环境变量没用。

5.3 GCC 版本不兼容导致的编译异常

VCS 在仿真编译阶段偶尔会调用系统 gcc 来链接生成的 C 代码。如果 gcc 版本太新，比如在 Ubuntu 22.04 上默认的 gcc 11，VCS 较旧版本（比如 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 改回 bash：

sudo 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_FILE=27000@your_license_server export LM_LICENSE_FILE=27000@your_license_server # Arch override export VCS_ARCH_OVERRIDE=linux64 # 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 这套工具链虽然入门曲线略陡，但环境一旦通了，后面所有验证工作都会顺畅很多。祝你能在一个清爽的环境里，把精力放在设计和验证本身，而不是和安装过程死磕。