企业官网建设流程全解析

简介：面向IC设计与验证工程师、高校微电子相关专业学生的VCS用户手册，对应Synopsys VCS S-2021.09版本，系统讲解Verification Continuum工具的使用方法，帮助读者搭建仿真环境、完成数字与混合信号设计的自动化验证。资源包共1个文件，为11.36MB的PDF文档，内容涵盖仿真器配置、许可证获取、synopsys_sim.setup文件创建、库概念与库名映射等入门章节，并延伸至命令行与图形界面配置、日志排查与调试思路，目录结构完整、便于按章节检索。该手册已有4335人学习下载，适合作为日常查阅的案头参考。读者可从中获得从环境搭建到仿真运行的完整流程说明，理解VCS各组件的职责划分，掌握常见问题的定位方法，从而减少摸索成本，提升验证效率。

1. 从一份 2021.09 版手册说起：VCS 环境搭建到底卡在哪

第一次在服务器上跑 VCS，很多人以为装完软件就完事了，结果vcs敲下去，终端甩回来一句 license 报错，或者synopsys_sim.setup找不到，仿真直接卡在编译阶段。这份 S-2021.09 版用户手册把 Getting Started 放在第一章不是没有道理——VCS 的坑几乎全在环境层，不在语法层。IC 设计里验证环节占的工时越来越重，VCS 作为编译型仿真器，装不好就是整条验证流水线停摆。这篇笔记按手册的 Getting Started 和 VCS Flow 两章展开，把版本选择、license、setup 文件、两步流和三步流一次讲透，适合刚接手验证环境搭建的开发者，也适合从旧版本迁移过来、想核对参数差异的熟手。

2. 装前把环境列清：版本、license 与系统配置核对

2.1 版本选择：S-2021.09 适合谁，和旧版差在哪

手册封面写得很明确，S-2021.09，2021 年 9 月发布。这个版本号不是随便挑的，它决定了你后面能用哪些编译选项。选版本时我一般看三件事：设计里用到的 SystemVerilog 特性、验证方法学库的兼容性、以及团队现有脚本依赖的选项名。

S-2021.09 这一代在-debug_access上的能力划分比早期版本细，手册第 4 章专门用一整节讲怎么用-debug_access在调试可见性和仿真性能之间取舍，还提到可以按设计区域（region）指定调试能力。如果你的验证环境重度依赖 Verdi 波形调试，这个版本的-debug_access+region和 tab 文件机制值得用上；如果只是跑回归、不看波形，就别开全量调试，编译时间和内存都会明显上涨。

版本差异上有个容易忽略的点：手册里-debug_access的增量移除能力（Incrementally Removing Debug Capabilities）是这一代比较完整的功能，旧脚本里如果写死了-debug_all这类粗放选项，迁到 S-2021.09 后建议改成按需组合，否则编译产物会偏大。常见做法是先在测试用例上对比-debug_access+all和按 region 指定的编译时间，再决定回归环境的默认参数。

系统配置这块，手册 1-5 节叫 Verifying Your System Configuration，意思是装完先别急着编译设计，先确认机器撑得住。我一般会先看三样：内存、磁盘、以及 shell 的资源限制。编译大型 SoC 设计时ulimit -s栈大小不够会直接段错误，这个报错很玄学，堆栈信息指不到真正原因。

# 装完先核对基础资源，别等编译到一半才发现不够 free -g # 看物理内存，编译大设计建议 64G 起步 df -h /opt # 安装路径所在分区剩余空间 ulimit -s # 栈大小，单位 KB，建议调到 65536 以上 ulimit -n # 打开文件数上限，大设计编译容易撞到

free -g用 GB 显示，方便快速判断；ulimit -s如果显示 8192，编译深层例化的设计时容易栈溢出，可以在登录脚本里ulimit -s unlimited或设成 65536。ulimit -n默认 1024 在并行编译多文件时不够，调到 65536 比较稳。这些不是 VCS 特有的要求，但装完不核对，后面出的错都长得不像环境问题。

2.2 license 获取与环境变量：三行配置决定能不能跑起来

手册 1-6 节 Obtaining a License 和 1-7 节 Setting Up Your Environment 是连着的。VCS 是商业工具，没有 license 文件或 license 服务器地址，vcs命令连版本号都打不出来。license 的获取走公司内部的授权流程，这里不展开，重点说环境变量怎么配。

我见过最常见的翻车是：license 服务器地址配了，但LM_LICENSE_FILE和SNPSLMD_LICENSE_FILE两个变量混用，或者路径里多了空格。VCS 读 license 的顺序有讲究，配错一个变量，工具会去连一个不存在的端口，超时后报的错跟 license 无关，排查方向直接跑偏。

# 典型的环境变量配置，写进 ~/.bashrc 或项目 env 脚本 export VCS_HOME=/opt/synopsys/vcs/S-2021.09 export PATH=$VCS_HOME/bin:$PATH export LM_LICENSE_FILE=27020@license-server # 端口@主机，按实际授权信息填 export SNPSLMD_LICENSE_FILE=$LM_LICENSE_FILE export VCS_ARCH_OVERRIDE=linux64 # 明确架构，避免自动探测出错

VCS_HOME指向安装根目录，bin加进 PATH 后vcs、vlogan、vhdlan才能直接调用。LM_LICENSE_FILE的格式是端口@主机名，多个 license 源用冒号分隔。VCS_ARCH_OVERRIDE在混合架构机器上很有用，自动探测偶尔会选错 32/64 位，显式指定省事。配完执行source ~/.bashrc，然后which vcs确认路径对，再vcs -ID看版本输出——能打出 S-2021.09 说明 license 和环境变量都通了。

提示：vcs -ID只验证工具可执行和 license 可达，不代表你的设计能编译。license 特性（feature）是按模块授权的，仿真大设计时可能还需要额外的 verification feature，这个要跟授权管理员确认。

2.3 synopsys_sim.setup：库映射写错，后面全白搭

手册 1-8 到 1-12 节全在讲synopsys_sim.setup，这是 VCS 的库映射文件，地位相当于编译器的 include 路径配置。VCS 里的“库”（library）是逻辑概念，设计单元（design unit）编译进库，仿真时按库名查找。setup 文件就是把逻辑库名映射到物理目录。

默认情况下 VCS 会读三个位置的 setup：安装目录下的、用户 home 下的、当前工作目录下的，优先级从低到高。我一般只在项目根目录放一份，用SYNOPSYS_SIM_SETUP环境变量显式指定，避免不同项目互相污染。

# synopsys_sim.setup 最小可用内容 WORK > DEFAULT DEFAULT : ./work IEEE : $VCS_HOME/linux64/lib/ieee

WORK > DEFAULT表示把 WORK 库设为默认库，编译时没指定-work的设计单元都进这里。DEFAULT : ./work把默认库映射到当前目录的work文件夹，这个目录 VCS 会自动创建。IEEE那行指向 VCS 自带的 IEEE 库，VHDL 设计必须要有，路径里的linux64按实际平台改。手册 1-11 节 Library Name Mapping 讲的就是这套映射规则，写错方向（比如把:写成>）会导致库找不到，报错信息往往只说“library not found”，不告诉你哪一行错了。

还有个细节：setup 文件支持INCLUDE引入其他文件，手册 1-12 节提到可以用SYNOPSYS_SIM_SETUP环境变量指定主 setup 路径。团队协作时我习惯把公共库映射放一份基础 setup，各人项目目录再 include 它，改公共配置只改一处。

3. 跑通第一条仿真：两步流与三步流的命令拆解

3.1 两步流：vcs 一条命令编译加 elaboration

手册第 2 章 VCS Flow 把流程分成两步流和三步流。两步流是vcs一条命令完成编译（compilation）和 elaboration，适合纯 Verilog/SystemVerilog 设计、迭代快的场景。三步流把分析（analysis）、elaboration、仿真拆开，适合混合语言设计或者需要增量编译的大项目。

先看两步流的最小例子。假设有一个tb_top.sv和design.sv：

# 两步流：编译 + elaboration 一步到位，产出 simv 可执行文件 vcs -full64 -sverilog -debug_access+all \ -timescale=1ns/1ps \ -f filelist.f \ -o simv_top \ -l compile.log

-full64生成 64 位可执行文件，现在基本必带。-sverilog开启 SystemVerilog 支持，纯 Verilog 设计可以不加。-debug_access+all打开全量调试能力，配合 Verdi 看波形时需要；如果只跑回归，换成-debug_access+none能省编译时间和内存。-timescale=1ns/1ps设默认时间单位和精度，手册 1-21 节专门讲过默认时间单位，设计里没写`timescale时就用这个。-f filelist.f从文件读源文件列表，比命令行堆一长串文件名好维护。-o指定输出可执行名，-l把编译日志落盘，出问题先翻这个日志。

编译成功后当前目录会有simv_top，直接跑：

# 运行仿真，+plusarg 传给测试平台，-l 记录运行日志 ./simv_top +TESTNAME=smoke_test -l sim.log

+TESTNAME=smoke_test是 plusarg，测试平台里用$value$plusargs读取，这是 VCS 运行期传参的标准做法。-l sim.log把仿真输出同时写文件，回归时批量收集日志靠它。手册 2-21 节 Commonly Used Runtime Options 列了一批常用运行选项，比如+ntb_random_seed控制随机种子、-ucli进交互模式，这些在调试随机失败时很有用。

3.2 三步流：vlogan/vhdlan 分析、vcs elaboration、simv 仿真

三步流的第一步是分析。Verilog/SystemVerilog 用vlogan，VHDL 用vhdlan，手册 2-4 和 2-7 节分别讲了这两个命令。分析阶段把源文件解析成中间形式存进库，后面 elaboration 只读库，所以改一个文件只需重新分析那一个，大项目增量编译优势明显。

# 第一步：分析，把设计单元编进 WORK 库 vlogan -full64 -sverilog -work WORK \ -f filelist.f \ -l vlogan.log # VHDL 部分用 vhdlan，注意 -work 指向同一个逻辑库 vhdlan -full64 -work WORK \ -f vhdl_filelist.f \ -l vhdlan.log

-work WORK指定目标逻辑库，要和synopsys_sim.setup里的映射对上。vlogan和vhdlan可以往同一个库分析，混合语言设计就靠这一步把 VHDL 和 Verilog 单元放进同一命名空间。分析日志里如果有 warning 说某个 module 重复定义，多半是 filelist 里同一个文件被列了两次，或者库映射指到了旧目录。

# 第二步：elaboration，从库里的单元构建仿真模型 vcs -full64 -debug_access+all \ -timescale=1ns/1ps \ WORK.tb_top \ -o simv_three \ -l elab.log

注意这里传给vcs的是WORK.tb_top，即“库名.顶层单元名”，不是源文件。这是三步流和两步流最直观的区别：两步流喂源文件，三步流喂库里的单元。-debug_access在 elaboration 阶段生效，手册第 4 章讲-debug_access的 region 用法就是在这个阶段配。

# 第三步：仿真，和两步流一样跑 simv ./simv_three +TESTNAME=regression_01 -l sim_three.log

三步流的代价是命令多、脚本长，收益是增量编译和混合语言支持。我一般在新项目上先用两步流快速验证环境通不通，确认 license、setup、源文件都没问题后，再切三步流搭正式回归脚本。手册 2-2 节到 2-20 节把两种流的适用边界讲得比较清楚，值得对着自己的项目规模选。

3.3 编译选项取舍：-debug_access 与性能的平衡

手册第 4 章开头就点明，-debug_access是在调试可见性和仿真性能之间做权衡。全量开（+all）编译慢、产物大、仿真也慢，但波形里什么都能看；全关（+none）跑得快，但出了问题没法看信号。

S-2021.09 的细化能力在于可以按设计区域指定。比如只关心某个子模块的内部信号：

# 只对指定模块开调试能力，其余保持精简 vcs -full64 -sverilog \ -debug_access+all+region:tb_top.u_dut.u_core \ -f filelist.f -o simv_region -l compile_region.log

+region:后面跟层次路径，只对这个区域打开全量调试。手册 4-13 节 Specifying Design Regions for -debug_access Capabilities 讲的就是这个语法。实际用的时候，层次路径写错不会报错，只是调试能力没生效，波形里看不到信号——这个坑很隐蔽，建议编译后翻日志里的 debug capability 诊断信息（手册 4-9 节 Reporting Global Debug Capability Diagnostics）确认。

另一个常被忽略的是 tab 文件机制，手册 4-21 节 Using -debug_access With Tab Files。tab 文件记录哪些对象需要 dump，配合$fsdbDumpvars用，可以在不改 RTL 的前提下控制波形范围。我一般把 tab 文件和 region 结合：region 定大范围，tab 文件做精细裁剪。

4. 避坑与排查：五条装环境时真踩过的记录

4.1 现象：vcs 报 license 超时，但 license 服务器是通的

原因：LM_LICENSE_FILE里配了多个源，VCS 按顺序尝试，第一个源连不上会一直等到超时，后面的源根本没轮到。或者变量值里混进了不可见字符，从网页复制授权信息时很常见。

解决：先用lmutil lmstat -c 27020@license-server单独验证 license 服务器可达，再echo $LM_LICENSE_FILE | cat -A看有没有多余字符。多个源时把确定可用的放最前面，或者干脆只留一个。

4.2 现象：编译报 “library not found”，但 setup 文件明明写了

原因：synopsys_sim.setup的查找顺序是安装目录、home、当前目录，当前目录优先级最高。如果项目目录下有一份旧 setup，它会覆盖你以为在生效的那份。另外SYNOPSYS_SIM_SETUP环境变量如果指向了不存在的路径，VCS 会静默回退到默认查找，不报错。

解决：echo $SYNOPSYS_SIM_SETUP确认路径存在，再在项目目录ls -la synopsys_sim.setup看有没有残留旧文件。手册 1-14 节 Displaying Setup Information 提到可以用命令打印当前生效的 setup 内容，装完先打一遍，比猜靠谱。

4.3 现象：两步流编译通过，仿真一跑就 segfault

原因：栈大小不够。深层例化的设计在 elaboration 和仿真初始化阶段递归很深，ulimit -s默认 8MB 撑不住。这个报错没有任何有用堆栈，看起来像工具 bug。

解决：ulimit -s unlimited或设 65536，写进环境脚本。同时检查ulimit -v虚拟内存限制，有些集群默认限制很严。

4.4 现象：三步流里 vhdlan 分析成功，elaboration 找不到 VHDL 单元

原因：vhdlan和vlogan用了不同的-work库名，或者 VHDL 单元名大小写和 elaboration 时引用的不一致。VHDL 标识符不区分大小写，但 VCS 的库查找在某些配置下区分。

解决：统一-work WORK，elaboration 时用WORK.顶层名。手册 1-15 节 Displaying Design Information Analyzed Into a Library 可以用命令列出库里实际有哪些单元，对着名字抄，别手打。

4.5 现象：-debug_access+region 配了，波形里还是没有目标信号

原因：层次路径写错，或者 region 语法拼错（比如+region和+region:混用）。VCS 对无效 region 不报错，只是静默忽略。

解决：编译后看日志里的 debug capability 诊断段，确认 region 被识别。路径从顶层往下逐级核对，别跳级。手册 4-9 节到 4-15 节这一段的诊断输出就是为这个场景准备的。

5. 装完怎么验证：从版本号到一条能跑的仿真

环境装没装好，不看安装日志，看能不能跑通一条最小仿真。我习惯按四步验证，每步都有明确的通过标准，任何一步不过就停在那里排查，不往下走。

第一步，工具可达性。which vcs输出路径在$VCS_HOME/bin下，vcs -ID打出 S-2021.09 和 license 信息。这一步不过，后面全是空谈。

第二步，setup 生效性。在项目目录执行手册 1-14 节的 setup 信息打印命令，确认WORK和DEFAULT映射到了你预期的目录，IEEE库路径存在。可以顺手ls一下映射的物理目录，确认有写权限。

第三步，最小设计编译。别拿正式项目试，写一个十行的计数器加一个空测试平台，走两步流编译。通过标准是生成simv且编译日志里没有 error。这一步能过滤掉 license feature 不足、timescale 冲突、filelist 路径错这几类问题。

第四步，仿真跑通并出波形。跑./simv +TESTNAME=smoke，日志里看到测试平台打印的 pass 信息；如果开了-debug_access，用 Verdi 打开波形确认能看到信号翻转。波形能出来，说明调试能力和 dump 流程都通了。

这套四步验证我一般写成一个check_env.sh，新机器装完先跑一遍，比人肉核对快。有一次迁移到新集群，前三步都过，第四步波形死活出不来，最后发现是-debug_access的 region 路径里多了一个空格，工具静默忽略——从那以后我每次配 region 都强制把编译日志里的 debug 诊断段翻一遍，确认 region 被识别再往下走。希望这套流程能帮你少走几个弯路。

本文还有配套的精品资源，点击获取