1. 为什么工程上要折腾VCSVerdi这套组合先聊点实际的。用Vivado做FPGA开发时自带的XSim仿真器其实已经很方便了点两下鼠标就能跑波形。但如果你真正进过ASIC、SoC或者大点规模的FPGA项目组就会发现一个现象大家嘴上说用Vivado实际跑仿真却几乎清一色是VCSVerdi或者Questa等商业仿真工具。这不是矫情而是工程需求逼出来的选择。1.1 XSim和VCS的真实差距很多刚接触数字IC验证的同学会问XSim免费、集成度高、上手快为什么还要费劲去搭VCSVerdi这里我不讲虚的直接说几个我实际遇到的痛点。第一个痛点是编译速度。项目规模稍微上来以后比如整个子系统带CPU核、带DDR控制器、带一堆AXI总线IPXSim在编译SystemVerilog时是真的吃力。我印象很深的一次一个中等规模的testbenchXSim编译跑了快二十分钟而同样的代码VCS编译不到四分钟。验证工程师的工作节奏是不断改代码、编译、跑用例、调试编译时间直接决定了每天的迭代次数这个差距在时间紧的项目里就是致命的。第二个痛点是SystemVerilog特性支持度。VCS对UVM、对SystemVerilog的各种语法特性支持非常完善而XSim在部分SV高级特性上总有些小坑比如某些类的约束写法、随机化特性、覆盖率收集相关的语法结构XSim偶尔会报出让人摸不着头脑的编译错误。我在跑UVM验证环境时基本上默认VCS才是完整支持的那套。第三个痛点是调试体验。Vivado的波形界面适合做单模块、单IP的信号观测但一旦要调试复杂的类对象关系、事务级通信、队列数据内容XSim的交互能力就明显不够用了。1.2 Verdi在调试中的核心价值Verdi的价值简单概括就是它能把你从“信号海洋”里捞出来。做过验证的人都有这种体验跑完仿真波形文件几百兆甚至几个GB你发现在Vivado的波形窗口里找一条内部信号滚动条拉得手都酸了波形渲染慢得让人崩溃。而Verdi对超大FSDB波形的加载和渲染性能非常强几千个信号同时显示也不会明显卡顿。Verdi的另一个杀手锏是nWave和State Schematic联动。你可以直接在波形的某个时刻跳转到对应的事务级流程图看到这个周期到底触发了什么逻辑哪条状态机路径被激活了甚至可以通过逻辑追踪直接前向/后向追信号驱动源。这个效率比对着波形一条条点Signal Tap要高出太多。所以结论很直接如果你只是做小规模IP验证、FPGA原型验证只求把功能跑对那XSim完全够用。但如果你是做芯片项目的前期验证或者FPGA项目要和UVM验证环境对接那VCSVerdi基本是绕不开的标配。2. 搭建前的环境准备与版本选择环境搭建这件事80%的坑都出在版本配套和环境变量上。Vivado、VCS、Verdi这三套工具的版本如果搭配不合理后面编译库的阶段会冒出各种千奇百怪的错误。我先把这个最基础也最关键的部分讲透。2.1 工具链版本配套关系先看一个我自己的推荐搭配供参考工具推荐版本搭配说明Vivado2022.2 / 2023.1编译VCS库时对VCS版本有官方兼容列表VCS2021.06-SP2 / 2022.06与Vivado 2022.2及以上版本配套良好Verdi对应VCS同版本线VCS和Verdi共用同套安装和License务必同版本操作系统CentOS 7 / RHEL 8 / Ubuntu 20.04 LTS64位系统工具本身在CentOS系上兼容性最稳这里要强调一个容易踩的误区VCS和Verdi不是两个独立安装的工具它们属于同一套Synopsys工具链下的不同组件安装方式和License体系完全互通。所以你下载VCS安装包时一般会包含Verdi组件安装时一起装即可。我在最初搭环境时曾经分别下了不同的版本结果VCS是2020年的构建Verdi是2021年的构建跑仿真时VCS生成的FSDB波形Verdi加载总报版本不兼容。后来统一成同一版本的构建号才彻底解决。版本配套这件事我的经验是Vivado年份不要比VCS旧太多。因为Vivado在生成仿真库编译脚本时会检测VCS的版本并把版本信息写进脚本里如果VCS版本太老脚本里某些编译选项可能不识别最后报的错会让你怀疑是哪个环节出的问题。2.2 环境变量与License配置要点工具装好后环境变量是第一个硬门槛。我说明一下常规配置方式。在~/.bashrc或者~/.cshrc中取决于你用的shell需要配置以下几项# VCS/Verdi 安装路径 export VCS_HOME/opt/synopsys/vcs/R-2021.06-SP2 export VERDI_HOME/opt/synopsys/verdi/R-2021.06-SP2 export PATH$VCS_HOME/bin:$VERDI_HOME/bin:$PATH # License配置 export SNPSLMD_LICENSE_FILE27020license-server export LM_LICENSE_FILE27020license-server # 32位兼容库64位系统上跑32位工具需要 export LD_LIBRARY_PATH$VCS_HOME/linux/lib:$VCS_HOME/lib:$VERDI_HOME/share/PLI/VCS/LINUX64:$LD_LIBRARY_PATH这里的27020license-server替换为你实际的License服务器地址。如果你是单机版License文件就改成export SNPSLMD_LICENSE_FILE/path/to/license.dat。配置完之后验证是否生效vcs -ID verdi -ID两个命令都能正常打印出版本号说明基础环境没问题。如果vcs命令提示libvcs.so找不到或者gcc版本不兼容说明LD_LIBRARY_PATH没配置对或者系统的gcc版本与VCS不匹配。VCS对gcc版本很敏感我建议用VCS自带的gcc而不是系统自带的这是后面编译报错的一个高频点。Vivado那边的环境变量就不用多说了用的是/opt/Xilinx/Vivado/2022.2/settings64.sh。注意在当前shell里source它同时source好Synopsys的环境变量让两个工具链的环境变量共存。3. 仿真库编译整个流程的第一个坎环境变量搞定了接下来就是联合仿真最核心也最容易出问题的一步编译Xilinx仿真库。3.1 为什么必须编译Xilinx仿真库Vivado里的所有IP核从最简单的FIFO到复杂的MIG DDR控制器它们的仿真模型默认都是加密的、面向Vivado自带仿真器XSim以及特定仿真器做了映射。VCS不会直接认识Xilinx的IP核仿真模型需要先把这些模型编译成VCS能读取的形式也就是生成.so动态库或者编译好的库单元文件。这个过程的本质是预先把Xilinx的UNISIM、UNIMACRO、SECUREIP这些库的仿真原语primitive转换成VCS的格式。如果不做这个编译你在VCS编译设计文件时一旦遇到IP核就会碰到类似Unknown module type: blk_mem_gen_v8_4这种错误根本不知道是哪个IP没被支持。3.2 批量模式编译VCS库的完整流程Vivado提供了一个命令行工具compile_simlib专门负责给第三方仿真器编译库。但我个人更推荐用Vivado的批量模式Batch Mode去跑因为输出信息更清晰、参数控制更灵活。直接上命令这是我在Vivado 2022.2下的实测命令cd /edatools/xilinx/compile_lib vivado -mode batch -source compile_vcs_lib.tcl其中compile_vcs_lib.tcl内容如下# compile_vcs_lib.tcl set output_dir /edatools/xilinx/compile_lib/vcs_lib set simulator_engine vcs set family all compile_simlib \ -force \ -directory $output_dir \ -simulator $simulator_engine \ -family $family \ -language all \ -library all \ -no_default_libraries \ -log compile_simlib.log这里我需要解释几个关键参数因为很多人就是在这几个参数上栽的跟头-force是强制重新编译不检查时间戳。改动了IP版本或者换了VCS版本后一定要加这个参数否则Vivado可能会跳过某些库的重新生成导致后面的编译连不上。-family all表示编译所有FPGA器件家族。如果项目只用了7系列和UltraScale你可以只写-family {artix7 kintex7 virtex7 zynq7000 ultrascale ultrascale_plus}能省不少时间。-simulator vcs用于指定VCS作为目标仿真器也可以写成-simulator vcs_mxVCS MX是带混合语言支持的版本如果设计中混合了VHDL和Verilog就选这个。一个常见的坑是用了vcs参数但设计里有VHDL文件编译库的时候其实没有问题真正到VCS编译设计时才需要确认VCS MX的编译命令。所以如果你有VHDL的IP或者模块建议从一开始就用vcs_mx。跑完后在$output_dir下会生成一个vcs_lib目录里面按器件家族分好了各个库的编译结果还有对应的simprims等子目录。记下这个路径后面VCS编译时要用。3.3 编译时间与硬件资源评估编译全系列库不是个轻快活。我实测过在8核16线程、32GB内存的机器上编译Vivado 2022.2全家族VCS库大约需要40~60分钟。如果只编译单个家族比如只编xilinx_vcs_lib下的virtex7十几分钟就能搞定。所以建议按需编译不要一步到位全都编。另外注意磁盘空间全家族库编译完大概会占用15~25GB空间确保你的工作目录够用。4. 联合仿真的工作流配置库编译完成后就到了真正“联合仿真”的环节。这部分的本质就是把RTL设计文件、Xilinx IP仿真模型、testbench文件交给VCS编译生成可执行的仿真二进制然后跑仿真生成FSDB波形文件最后用Verdi打开波形调试。4.1 文件列表组织与宏定义工程上我不会把VCS命令行写成一条巨长的命令而是用文件列表filelist来组织。项目结构大概长这样project_root/ ├── rtl/ │ ├── top.sv │ ├── module_a.sv │ └── ip_cores/ │ └── clk_gen/clk_gen.xci (IP核XCI文件) ├── tb/ │ ├── tb_top.sv │ └── tb_pkg.sv ├── sim/ │ ├── run_sim.mk │ ├── rtl.f │ ├── tb.f │ └── vcs_run.shrtl.f里列设计的RTL文件tb.f里列testbench和验证环境文件VCS用-f参数读取。但IP核的处理比较特殊不能直接把.xci文件丢给VCS去编译。需要先在Vivado里打开工程依次右键IP核选择“Generate Output Products”把IP核生成出仿真模型和仿真文件清单。之后在工程的project.gen/sources_1/ip/ip_name/sim目录下能看到生成了一个文件名类似ip_name.v的仿真模型文件。把这些生成的仿真模型文件加进rtl.f注意IP生成时的语言IP核输出模型可能是Verilog或VHDL对应VCS的混合语言编译。我们的rtl.f内容示例../rtl/top.sv ../rtl/module_a.sv ../rtl/ip_cores/clk_gen/sim/clk_gen.vtb.f内容示例../tb/tb_pkg.sv ../tb/tb_top.sv4.2 VCS编译仿真命令解析编译命令是联合仿真的核心执行环节我直接给出一个经过验证的完整命令模板vcs -full64 -sverilog v2k \ -debug_accessall \ -timescale1ns/1ps \ -f rtl.f -f tb.f \ -lca \ defineFSDB_DUMP \ defineXILINX_SIMULATOR \ -v /edatools/xilinx/compile_lib/vcs_lib/unisim_ver/unisim_ver.v \ -y /edatools/xilinx/compile_lib/vcs_lib/unisim_ver libext.v \ -y /edatools/xilinx/compile_lib/vcs_lib/secureip_ver libext.v \ -y /edatools/xilinx/compile_lib/vcs_lib/xpm_ver libext.v \ -P ${VERDI_HOME}/share/PLI/VCS/LINUX64/novas.tab \ ${VERDI_HOME}/share/PLI/VCS/LINUX64/pli.a \ -l compile.log \ -o simv逐项解释一下这些参数因为理解参数能帮你少走很多弯路-full64以64位模式运行这是标配。现代工具链里不写它基本走不动。-sverilog v2k开启SystemVerilog和Verilog-2001支持设计里混合两种语言时必须有。-debug_accessall生成完整的调试信息Verdi里要做波形追踪、变量监视全靠它。如果只想要波形可以用-debug_accesspp编译速度会快一点但很多Verdi的高级功能用不了。-lca开启Limited Customer Availability的某些特性。当你用UVM或者一些较新的SystemVerilog库时可能会需要这个选项。一般加上不出错。defineFSDB_DUMP在testbench代码里用ifdef FSDB_DUMP来控制是否生成FSDB波形文件。工程上常用这种做法需要出波形时就打开不需要时编译命令里去掉这个宏定义省掉波形生成的额外仿真时间。-v加-y加libext.v这一组选项是VCS查找Xilinx库单元的方式。-v指定单文件库-y指定库目录libext.v限制只查找.v后缀的库模块。如果某些老IP用到VHDL的UNISIM组件还需要把unisim_vhdl库加上格式类似但VCS MX模式下可以混用。-P ... novas.tab pli.a这是Verdi和VCS之间的PLI接口必须在编译时链接进去否则VCS跑仿真时根本识别不了FSDB相关的系统任务比如$fsdbDumpfile和$fsdbDumpvars。这里的路径对应你的Verdi安装目录和VCS的LINUX64架构需要按实际环境修改。编译完成后会生成一个可执行文件simv接下来运行仿真./simv -l sim.log fsdbautoflushfsdbautoflush是个很实用的运行时选项它的作用是每个时间戳都把FSDB缓冲区内容刷到文件里。如果不加这个选项遇到仿真中途崩溃、kill或者其他异常退出时FSDB波形就只有前面一小段后面全丢了到时候追问题什么都看不到非常痛苦。4.3 Verdi波形生成与调试在testbench中加波形生成的代码一般是这样的initial begin \ifdef FSDB_DUMP \$fsdbDumpfile(test.fsdb); \$fsdbDumpvars(0, tb_top, all); \endif end$fsdbDumpvars(0, tb_top, all)里的0表示dump设计中所有层次tb_top是起点顶层。all表示连设计内部的一些中间信号也一起dump方便深度调试代价是文件更大、仿真速度慢一些。仿真跑完后用Verdi打开波形verdi -ssf test.fsdb 或者先打开Verdi界面再通过File - Open FSDB的方式加载。加载后你会看到nWave窗口列出信号。此时可以在左侧的实例树中选需要的信号拖到nWave窗口观察波形。调试效率的关键在于合理使用Verdi的几个功能用“添加信号到波形”前先通过g键搜索信号名比逐层展开实例树快得多鼠标悬停在波形上按x可以在多个信号之间交叉追踪追source、追load打开“State Schematic”面板可以直接看到某个时序周期的状态机跳转路径用n键快速跳到下一个transition配合信号源追踪查找毛刺和时序问题非常高效5. 搭完环境之后的效率提升技巧环境用顺手之后别满足于一条条命令敲工程上一定要把流程固化下来否则每次换个工程、换台机器都得重新摸索太浪费时间。5.1 用Makefile把流程固化我用Makefile管理联合仿真的几个核心步骤写出来可以当模板参考# run_sim.mk VIVADO : /opt/Xilinx/Vivado/2022.2/bin/vivado VCS : vcs VCS_OPTS : -full64 -sverilog v2k -debug_accessall -timescale1ns/1ps -lca FSDB_OPTS : defineFSDB_DUMP XILINX_LIB : /edatools/xilinx/compile_lib/vcs_lib all: compile_sim compile_sim: $(VCS) $(VCS_OPTS) -f rtl.f -f tb.f $(FSDB_OPTS) \ defineXILINX_SIMULATOR \ -v $(XILINX_LIB)/unisim_ver/unisim_ver.v \ -y $(XILINX_LIB)/unisim_ver libext.v \ -y $(XILINX_LIB)/secureip_ver libext.v \ -P $(VERDI_HOME)/share/PLI/VCS/LINUX64/novas.tab \ $(VERDI_HOME)/share/PLI/VCS/LINUX64/pli.a \ -l compile.log -o simv echo COMPILE DONE run: ./simv -l sim.log fsdbautoflush echo SIM DONE verdi: verdi -ssf test.fsdb clean: rm -rf simv simv.daidir csrc ucli.key novas.* *.fsdb *.vpd compile.log sim.log echo CLEAN DONE有了这个Makefile日常工作就是make compile_sim、make run、make verdi三条命令来回切。它把VCS编译参数、库路径、PLI都固化到一处换工程只需要改rtl.f和tb.f。5.2 增量编译与回归测试VCS支持增量编译如果只改了部分RTL文件不用每次全量编译。在vcs命令基础上加-Mupdate参数它就会自动做增量编译只重编改动过的文件编译时间能缩短到原来的1/3甚至1/5。不过要注意如果改了rtl.f里的文件列表或者IP核版本最好还是要做一次全量编译否则增量编译有时会引用到旧的组件信息。回归测试这块如果项目里已经用了UVM可以在Makefile里再加一个regress目标遍历测试用例列表逐个跑仿真并检查pass/fail日志。基础逻辑就是循环调用./simv test_namexxx然后把log里TEST PASSED或TEST FAILED的关键字抓出来汇总。这里有个小坑VCS跑UVM用例时如果同时跑多个用例一定要确保每个用例用独立的仿真目录或加-ntb_random_seed随机种子否则多个进程会在同一个目录下写仿真中间文件互相踩踏报出随机崩溃。6. 常见问题与排查技巧实录这部分最有含金量基本都是我自己踩过坑之后总结出来的。按阶段分类后面你可以直接当排查手册用。6.1 仿真库编译阶段的问题我在编译VCS库时遇到的最典型问题是第一个是systemc安装路径找不到。编译过程中突然报错Cant find systemc installation。这通常是因为VCS依赖的SystemC路径没配好。解决办法是在编译前设置SYSTEMC_HOME或者SYSTEMC环境变量指向VCS自带的systemc目录一般在$VCS_HOME/include/systemc或$VCS_HOME/linux/etc/systemc下。第二个是内存不足导致编译中断。编译库时Vivado会启动并行度较高的编译默认可能会直接用掉几十GB内存。如果机器内存只有16GB建议在compile_simlib命令里显式控制并行度加上-jobs 4限制为4个并行任务虽然慢一些但稳定不会崩。第三个是IP版本与库版本不对应。如果你在Vivado里更新了IP核版本旧的仿真库可能不识别。这是最常见的综合/仿真行为不一致的来源之一。解决方法是把IP核在Vivado里重新Generate Output Products再重新编译仿真模型文件同时用-force参数重新编译对应IP所使用的仿真库。6.2 VCS编译仿真中的常见报错VCS编译设计文件时报错主要集中在下面几种错误一Unknown module type: xxx这个错误说明VCS在编译链接阶段找不到某个模块定义。最常见的场景是某个Xilinx IP的仿真模型没有加入文件列表或者UNISIM库路径没有用-v/-y正确指定。排查路径是先确认这个模块是Xilinx原语还是IP核生成模型。如果不是原语去IP核的sim目录看是否有生成.v文件如果有把它加进rtl.f如果是原语确认unisim_ver的-v/-y路径是否正确。错误二Cant find license or Invalid license这种我遇到过两类情况一类是License服务器确实没配通另一类是license过期后所有工具都报license错。排查方式就是先lmstat -a看看服务状态。但还有一个容易被忽略的场景当同时安装了多个版本的工具时LM_LICENSE_FILE环境变量被某个工具的设置脚本覆盖了。我建议在.bashrc里只保留一个SNPSLMD_LICENSE_FILE和LM_LICENSE_FILE不要装多个Synopsys工具后让后装的环境脚本覆盖前面的。错误三Cannot open VCS interface file / PLI mismatch这类错误出在-P参数指向的PLI文件与VCS版本不匹配。排查路径是检查verdi安装目录下share/PLI/VCS/LINUX64/里是否有novas.tab和pli.a并且确认这份Verdi版本和VCS版本是同期的。如果版本不匹配VCS会报各种诡异的接口错误解决办法只有换一致版本的工具链修改环境变量。6.3 Verdi调试阶段的问题联合仿真跑到Verdi这步最常见的几个问题第一个是波形文件打开后是空的。如果FSDB文件有大小但打开后没有信号多半是$fsdbDumpvars里的顶层例化名写错了dump的起点不对。还有一种可能是fsdbautoflush没加文件缓冲区没刷干净文件虽然生成了但内容不完整。强制建议运行时一定带上fsdbautoflush。第二个是Verdi能打开波形但看不到RTL源码。这是因为编译时用了-debug_accesspp或者精简的调试选项没有把RTL源码和行号信息写到更完整的调试数据库。解决方法是改用-debug_accessall重新编译再重新跑仿真。第三个是仿真时间太长波形文件巨大。这个不算是bug但很影响调试体验。工程上常用的优化手段是分层dump在初跑时只dump顶层信号和关键总线等条件命中后再用更为精细的fsdb dump配置或者在某个触发条件后$fsdbDumpon/$fsdbDumpoff控制dump窗口。比如加一段initial begin #0; #1000; // 等前1000ns不dump跳过初始化阶段 $fsdbDumpoff; wait (tb_top.dut.state 4hA); // 等状态机跑到某个状态 $fsdbDumpon; end这样图形阶段只记录关键时间段的波形文件小、调试快效果立竿见影。7. 一些个人体会环境搭建这种事情看起来是体力活但本质是在整理你的工程基础设施。VCS和Verdi这一套方案之所以在工业界能成为事实标准并不是因为哪一个人选择了它而是因为芯片验证这个场景下仿真速度、调试深度、团队协同这些需求倒逼出来的结果。我第一次搭这套环境时前前后后折腾了两天大部分时间都耗在版本不匹配、库编译失败和License路径绕圈圈上。后来我也帮其他同事搭过不少次总结下来的核心经验就三条第一版本配套问题不值得花时间硬解直接问同事要一套验证过的组合第二环境变量这种东西一定要写成文件管理起来不要每次临时export第三库编译看起来慢但它是一劳永逸的投资编好一次整个项目周期都在受益。最后再多说一句有时候我也会遇到朋友问是不是一定要用Verdi不用行不行。答案当然不是必须的如果你对XSim和Vivado自带的波形工具足够熟悉小项目用它完全没有问题。但如果你准备走数字验证这条路或者项目规模已经大到辗转于不同模块的调试中那VCSVerdi这套环境早晚要搭起来。早搭早享受晚搭就自己加班补课吧。
