1. 为什么还要折腾 Vivado 与 VCS 联合仿真如果你平时用 Vivado 自带的仿真器跑功能验证小规模模块还凑合一旦设计里塞进几个 DDR 控制器、多路 AXI 互联或者带时序约束的门级网表仿真速度就会慢到让人怀疑人生。我最早做图像处理流水线的时候一个 1080p 帧的仿真跑了四十多分钟还没出结果后来换成 VCS 编译同一份 RTL同样的激励不到三分钟就跑完了。这就是为什么很多团队在 FPGA 项目进入中后期都会把仿真主力从 Vivado Simulator 切到 VCS再配 Verdi 看波形。这篇内容面向的是已经能跑通基本 Vivado 工程、但对 Linux 下编译仿真库和联合仿真流程还不太熟的 FPGA 开发者。我会把 Vivado 2025.1 搭配 VCS 2024.SP1 的整套流程拆开讲从编译 Xilinx 仿真库、生成仿真脚本到用 Verdi 加载 FSDB 波形做调试每一步都给出可复现的命令和踩坑记录。整套流程在 CentOS 7 和 Ubuntu 20.04 上都验证过工具版本虽然新但核心逻辑和几年前的老版本是相通的理解了原理换版本也不慌。需要提前说明的是联合仿真的本质是让 Vivado 负责“提供器件相关的仿真模型”VCS 负责“编译和执行仿真”Verdi 负责“波形查看和调试”。三者各司其职中间靠编译好的库文件和仿真脚本衔接。搞清楚了这条链路后面遇到任何报错你都能定位到是哪一环出了问题。2. 环境准备与工具版本匹配2.1 版本搭配不是随便选的工具版本搭配这件事我踩过的坑比想象中多。Vivado 2025.1 是较新的版本它编译出来的仿真库对 VCS 的版本有最低要求。VCS 2024.SP1 属于 2024 系列和 2025.1 的库编译脚本兼容性比较好。如果你手上是 VCS 2020 甚至更早的版本编译 Xilinx 的某些 IP 库尤其是带 SystemVerilog 断言的时大概率会报语法不支持的错。一个实用的判断原则Vivado 的版本年份不要比 VCS 领先太多领先一到两年通常没问题领先三年以上就要小心。另外VCS 的安装路径里不要带空格和中文Verdi 同理这是很多新手第一次配置就翻车的地方。工具推荐版本作用注意事项Vivado2025.1提供仿真库、IP 模型、生成脚本安装时勾选完整器件库VCS2024.SP1编译 RTL 与库、执行仿真需配置 licenseVerdi随 VCS 同版本查看 FSDB 波形、调试与 VCS 版本保持一致操作系统CentOS 7 / Ubuntu 20.04运行环境避免用最新内核兼容性优先2.2 环境变量配置要点环境变量是联合仿真的“地基”配错了后面全是玄学问题。我习惯把工具路径统一写进一个setup.sh每次开终端 source 一下。核心是三个变量VCS_HOME、VERDI_HOME、PATH以及 license 相关的LM_LICENSE_FILE或SNPSLMD_LICENSE_FILE。export VCS_HOME/opt/synopsys/vcs/2024.06-SP1 export VERDI_HOME/opt/synopsys/verdi/2024.06-SP1 export PATH$VCS_HOME/bin:$VERDI_HOME/bin:$PATH export SNPSLMD_LICENSE_FILE27020your_license_server注意license 服务器地址一定要用实际可用的配置完先用lmstat确认能连上否则 VCS 编译到一半才报 license 错误白白浪费时间。Vivado 这边如果你是在图形界面里操作环境变量会自动带上但如果要在纯命令行下用compile_simlib需要先 source Vivado 的settings64.sh。我一般会在同一个终端里先 source Vivado 环境再 source Synopsys 环境顺序不要反否则 PATH 里 Vivado 的某些工具可能被覆盖。2.3 磁盘空间与权限的隐形坑编译 Xilinx 仿真库是个“吃磁盘”的活。全器件库编译下来几十 GB 是常态。我建议单独挂一块数据盘把库编译到非系统盘路径下。另外编译过程会生成大量临时文件如果/tmp分区太小中途会报“No space left on device”这个报错很隐蔽因为看起来像是编译错误实际是磁盘满了。权限方面如果你用的是公司服务器库目录最好放在自己有写权限的路径下比如/home/yourname/sim_lib。放在/opt下虽然看起来规范但每次编译都要 sudo反而麻烦。我个人的习惯是每个项目单独建一个sim_lib目录虽然占空间但项目之间互不干扰换 Vivado 版本时也不用担心库被覆盖。3. 编译 Xilinx 仿真库的完整流程3.1 图形界面编译与命令行编译怎么选Vivado 提供了两种编译仿真库的方式图形界面Tools - Compile Simulation Libraries和命令行compile_simlib。图形界面适合第一次操作、想看清楚每一步在干什么的人命令行适合需要批量编译、或者要在无图形界面的服务器上操作的场景。我两种都用过结论是第一次建议用图形界面熟悉流程后全部转命令行。原因是图形界面编译大库时如果中途卡住你很难判断是死机了还是在慢慢跑命令行有明确的进度输出而且可以写成脚本重复执行。图形界面里几个关键选项要选对Simulator 选 VCSLanguage 根据你的设计选 Verilog 或 SystemVerilog混合设计选后者Library 选择你实际用到的器件系列。不要图省事选“All”全编译一次可能要一两个小时而且大部分库你根本用不到。3.2 命令行编译库的实操命令命令行编译的核心命令是compile_simlib它需要在 Vivado 的 Tcl 环境下执行。我通常写一个compile_lib.tcl脚本然后用vivado -mode batch -source compile_lib.tcl执行。compile_simlib -simulator vcs_mx \ -simulator_exec_path /opt/synopsys/vcs/2024.06-SP1/bin \ -family kintex7 \ -family zynq \ -language verilog \ -library unisim \ -library simprim \ -dir /home/yourname/sim_lib/vivado2025.1 \ -no_systemc_compile这里有几个参数值得展开说。-simulator vcs_mx表示用 VCS 的 MX 模式支持混合语言如果你只跑纯 Verilog用vcs也行但 MX 模式兼容性更好。-simulator_exec_path指向 VCS 的 bin 目录这个必须准确否则编译出来的库可能和实际 VCS 版本不匹配。-family指定器件系列我一般只编译项目实际用到的比如 Kintex-7 和 Zynq。-no_systemc_compile是跳过 SystemC 库编译除非你做 SystemC 联合仿真否则没必要编能省不少时间。编译完成后目录下会生成一堆.vdb、.so和映射文件。最关键的是modelsim.ini的等价物——VCS 用的是synopsys_sim.setup文件里面记录了库名到实际路径的映射。这个文件后面在仿真脚本里要引用。3.3 编译过程中的常见报错与处理编译库时最容易遇到的是两类问题一是 VCS 版本不兼容导致的语法报错二是环境变量缺失导致的工具找不到。前者通常表现为某个.v文件编译失败报“SystemVerilog keyword not supported”之类后者会直接提示“vlogan: command not found”。遇到版本不兼容最直接的解决办法是换 VCS 版本或者只编译你真正需要的库。有时候某个 IP 的仿真模型用了新语法你可以单独把这个 IP 的库排除掉用行为级模型替代。环境变量问题就简单了检查PATH里有没有 VCS 的 bin 目录which vlogan能不能找到。还有一个隐蔽的坑编译库时如果同时开了多个终端在跑可能会因为临时文件冲突导致编译失败。我一般会确保同一时间只有一个编译任务在跑编译前先清理一下临时目录。4. 生成仿真脚本与联合仿真配置4.1 从 Vivado 导出仿真脚本Vivado 可以自动生成 VCS 的仿真脚本路径是 File - Export - Export Simulation。这里要选 VCS 作为目标仿真器并指定之前编译好的库路径。导出的脚本通常包括compile.sh、elaborate.sh、simulate.sh三个分别对应编译、精化和仿真三个阶段。不过自动生成的脚本往往比较“通用”里面会包含很多你不需要的库引用。我的做法是把它作为起点然后手动精简。比如它会默认引用所有器件的库你只需要保留实际用到的。精简后的脚本跑起来更快也更容易排查问题。导出时还有一个关键选项是否包含-debug_access参数。如果你要用 Verdi 看波形必须确保编译时加了调试信息。VCS 的-debug_accessall或者-kdb参数就是干这个的。自动生成的脚本有时会漏掉需要手动补上。4.2 手写仿真脚本的骨架自动生成的脚本看懂了之后我更推荐手写一份精简版这样每个参数都心里有数。一个典型的 VCS 联合仿真脚本分三步vlogan编译 Verilog 源文件和库vcs精化生成可执行文件simv执行仿真。# 第一步编译库和源文件 vlogan -full64 -sverilog v2k -timescale1ns/1ps \ -work work \ -f filelist.f \ -y $SIM_LIB/unisim \ libext.v.sv \ -l compile.log # 第二步精化 vcs -full64 -debug_accessall -kdb \ -timescale1ns/1ps \ -top tb_top \ -l elaborate.log # 第三步仿真 ./simv -l sim.log fsdbautoflush-full64表示 64 位模式现在基本是标配。-sverilog和v2k让 VCS 支持 SystemVerilog 和 Verilog-2001 语法。-timescale要和你的设计一致否则时序会对不上。-y指定库搜索路径libext指定库文件扩展名。-debug_accessall和-kdb是给 Verdi 用的前者生成调试信息后者生成 Verdi 的知识数据库缺一不可。提示fsdbautoflush让仿真过程中波形自动刷新到 FSDB 文件这样即使仿真中途崩溃已经产生的波形也不会丢。做长仿真时这个参数能救命。4.3 库映射文件与路径管理VCS 通过synopsys_sim.setup文件来定位库。这个文件可以放在当前工作目录也可以放在$VCS_HOME/bin下作为全局配置。我倾向于放在项目目录下每个项目独立管理。文件内容大致是这样WORK DEFAULT DEFAULT : ./work UNISIM : /home/yourname/sim_lib/vivado2025.1/unisim SIMPRIM : /home/yourname/sim_lib/vivado2025.1/simprimWORK是默认的工作库UNISIM和SIMPRIM指向编译好的 Xilinx 库。路径一定要用绝对路径相对路径在不同终端下容易出问题。如果项目里用了多个 IP每个 IP 的库也要在这里加一行映射。路径管理的一个经验是把所有库路径写进一个环境变量脚本里引用变量而不是硬编码路径。这样换机器或者换库版本时只改一个地方就行。5. Verdi 波形调试与 FSDB 加载5.1 生成 FSDB 波形的两种方式Verdi 看波形的前提是有 FSDB 文件。生成 FSDB 有两种方式一种是在 Testbench 里直接调用$fsdbDumpfile和$fsdbDumpvars系统函数另一种是用 VCS 的-fsdb编译选项自动 dump。第一种方式更灵活可以精确控制 dump 哪些信号、从什么时间开始 dump。我通常会在 Testbench 的 initial 块里加initial begin $fsdbDumpfile(wave.fsdb); $fsdbDumpvars(0, tb_top); end$fsdbDumpvars的第一个参数是层级深度0 表示 dump 所有层级。如果设计很大全 dump 会让 FSDB 文件巨大这时候可以指定只 dump 某个模块比如$fsdbDumpvars(1, tb_top.u_dut)。第二种方式是在编译时加-fsdb和-P参数让 VCS 自动插入 dump 逻辑。这种方式适合不想改 Testbench 的场景但控制粒度不如第一种。5.2 Verdi 加载波形的实操步骤Verdi 启动命令是verdi -ssf wave.fsdb-ssf表示加载 FSDB 文件。如果同时要看 RTL 代码可以加-sv和-f filelist.f这样 Verdi 会把源代码也加载进来方便做信号追踪。Verdi 里几个高频操作Get Signal把信号加到波形窗口Trace Driver追踪信号驱动源Trace Load追踪信号负载。做调试时我习惯先用Trace Driver找到信号是被哪个模块驱动的再顺着看逻辑对不对。还有一个很实用的功能是nWave里的Analog显示模式。看总线信号或者计数器时用模拟波形显示比数字波形直观得多。右键信号选Analog就能切换。5.3 用 Verdi 做后仿真的技巧后仿真门级仿真和 RTL 仿真最大的区别是时序信息。后仿真时Verdi 里可以看到门级网表的延迟这时候Trace Driver可能会追到标准单元内部看起来比较乱。我的做法是先用 RTL 仿真确认功能正确再做后仿真确认时序。后仿真时 FSDB 文件会非常大因为每个门都有信号变化。这时候要控制 dump 范围只 dump 关键模块。另外后仿真跑得慢建议先用小激励跑通再上完整激励。注意后仿真时如果发现 X 态传播先检查 memory 初始化。很多后仿真的 X 态问题都是 memory 没有正确初始化导致的RTL 仿真时 memory 默认是 X但行为级模型可能掩盖了这个问题。6. 常见问题排查与避坑经验6.1 编译阶段的典型报错编译阶段最常见的问题是库找不到和语法不兼容。库找不到的报错通常是“module not found”这时候要检查synopsys_sim.setup里的路径对不对以及-y参数有没有指向正确的库目录。语法不兼容的报错会具体指出哪个文件哪一行通常是 SystemVerilog 的新特性在旧版 VCS 里不支持。还有一个坑是timescale不一致。如果 Testbench 和设计模块的timescale不同仿真时间会错乱。我一般会在编译时统一指定-timescale1ns/1ps覆盖源文件里的设置。6.2 仿真阶段的常见异常仿真跑起来之后常见的问题有仿真卡死、结果不对、FSDB 文件为空。仿真卡死通常是死循环或者握手信号一直不满足这时候可以用 Verdi 打开 FSDB 看最后时刻的信号状态。结果不对要先确认激励有没有正确加载再看时序对不对。FSDB 为空多半是$fsdbDumpfile没执行或者-debug_access没加。问题现象可能原因排查方法编译报 module not found库路径错误检查 synopsys_sim.setup仿真卡死死循环或握手不满足Verdi 看最后时刻信号FSDB 文件为空dump 函数未执行检查 Testbench 和编译选项后仿真 X 态传播memory 未初始化检查 memory 初始化逻辑Verdi 无法加载源码未加 -sv 或 filelist补上源码加载参数6.3 我踩过的几个印象深刻的坑第一个坑是 license 超时。有一次跑长仿真跑到一半 VCS 报 license 失效仿真直接中断。后来发现是 license 服务器设置了空闲超时解决办法是在脚本里加licqueue参数让 VCS 排队等 license而不是直接失败。第二个坑是 FSDB 文件太大导致磁盘满。一个后仿真跑了两个小时FSDB 文件涨到 80 多 GB直接把磁盘写满。后来我改成只 dump 关键信号并且用$fsdbDumpoff和$fsdbDumpon控制 dump 时间段只在关键窗口 dump。第三个坑是 Verdi 版本和 VCS 版本不一致。有一次 VCS 是 2024 版Verdi 是 2022 版加载 FSDB 时报格式不兼容。后来统一了版本就没事了。所以前面强调版本匹配真的是血泪教训。7. 联合仿真的效率优化建议7.1 编译缓存与增量编译VCS 支持增量编译第二次编译时只重新编译改动的文件。开启方式是加-Mupdate参数。对于大项目增量编译能省很多时间。不过增量编译有时会出玄学问题如果结果不对先试试全量编译排除缓存问题。库编译也可以缓存。编译好的 Xilinx 库可以复用不用每次换项目都重编。我一般把库放在一个固定路径所有项目共用。只有换 Vivado 版本时才重新编译。7.2 并行仿真与资源分配VCS 支持多核并行仿真加-j参数指定核数。比如-j8用 8 个核。不过并行仿真对某些设计效果不明显因为仿真本身是串行的并行主要加速编译阶段。真正加速仿真要靠优化激励和减少 dump 信号。资源分配上编译阶段吃 CPU 和内存仿真阶段吃内存和磁盘 IO。如果服务器内存不够仿真会频繁 swap速度反而更慢。我一般确保仿真时至少有 16GB 可用内存。7.3 波形 dump 策略的取舍波形 dump 是仿真速度的最大影响因素之一。全 dump 和只 dump 关键信号速度可能差好几倍。我的策略是功能调试阶段 dump 关键模块回归测试阶段只 dump 错误时刻。用$fsdbDumpoff在仿真开始时关闭 dump检测到错误时再$fsdbDumpon打开这样 FSDB 文件小仿真也快。还有一个技巧是用$fsdbDumpvars的深度参数控制 dump 层级。比如只 dump 顶层和第一层子模块深度设为 1这样既能看整体信号又不会 dump 太多内部信号。8. 写在最后的几句实在话这套 Vivado 2025.1 加 VCS 2024.SP1 的联合仿真流程我从第一次配置到跑通大概花了两天其中大部分时间耗在库编译和版本兼容上。现在回头看最值得花时间的是把环境变量和库路径管理好这两件事做扎实了后面换项目、换版本都能快速迁移。如果你刚开始接触联合仿真建议先用一个小设计比如一个计数器加 Testbench把整个流程跑通确认编译、仿真、波形查看三个环节都没问题再上大项目。大项目直接上出了问题很难定位是流程问题还是设计问题。另外工具版本不要盲目追新。Vivado 2025.1 和 VCS 2024.SP1 这个组合我实测下来比较稳但如果你团队里其他人用的是老版本最好统一否则脚本和库文件互相不兼容协作起来很痛苦。工具是拿来干活的稳定比新更重要。
1. 为什么还要折腾 Vivado 与 VCS 联合仿真如果你平时用 Vivado 自带的仿真器跑功能验证小规模模块还凑合一旦设计里塞进几个 DDR 控制器、多路 AXI 互联或者带时序约束的门级网表仿真速度就会慢到让人怀疑人生。我最早做图像处理流水线的时候一个 1080p 帧的仿真跑了四十多分钟还没出结果后来换成 VCS 编译同一份 RTL同样的激励不到三分钟就跑完了。这就是为什么很多团队在 FPGA 项目进入中后期都会把仿真主力从 Vivado Simulator 切到 VCS再配 Verdi 看波形。这篇内容面向的是已经能跑通基本 Vivado 工程、但对 Linux 下编译仿真库和联合仿真流程还不太熟的 FPGA 开发者。我会把 Vivado 2025.1 搭配 VCS 2024.SP1 的整套流程拆开讲从编译 Xilinx 仿真库、生成仿真脚本到用 Verdi 加载 FSDB 波形做调试每一步都给出可复现的命令和踩坑记录。整套流程在 CentOS 7 和 Ubuntu 20.04 上都验证过工具版本虽然新但核心逻辑和几年前的老版本是相通的理解了原理换版本也不慌。需要提前说明的是联合仿真的本质是让 Vivado 负责“提供器件相关的仿真模型”VCS 负责“编译和执行仿真”Verdi 负责“波形查看和调试”。三者各司其职中间靠编译好的库文件和仿真脚本衔接。搞清楚了这条链路后面遇到任何报错你都能定位到是哪一环出了问题。2. 环境准备与工具版本匹配2.1 版本搭配不是随便选的工具版本搭配这件事我踩过的坑比想象中多。Vivado 2025.1 是较新的版本它编译出来的仿真库对 VCS 的版本有最低要求。VCS 2024.SP1 属于 2024 系列和 2025.1 的库编译脚本兼容性比较好。如果你手上是 VCS 2020 甚至更早的版本编译 Xilinx 的某些 IP 库尤其是带 SystemVerilog 断言的时大概率会报语法不支持的错。一个实用的判断原则Vivado 的版本年份不要比 VCS 领先太多领先一到两年通常没问题领先三年以上就要小心。另外VCS 的安装路径里不要带空格和中文Verdi 同理这是很多新手第一次配置就翻车的地方。工具推荐版本作用注意事项Vivado2025.1提供仿真库、IP 模型、生成脚本安装时勾选完整器件库VCS2024.SP1编译 RTL 与库、执行仿真需配置 licenseVerdi随 VCS 同版本查看 FSDB 波形、调试与 VCS 版本保持一致操作系统CentOS 7 / Ubuntu 20.04运行环境避免用最新内核兼容性优先2.2 环境变量配置要点环境变量是联合仿真的“地基”配错了后面全是玄学问题。我习惯把工具路径统一写进一个setup.sh每次开终端 source 一下。核心是三个变量VCS_HOME、VERDI_HOME、PATH以及 license 相关的LM_LICENSE_FILE或SNPSLMD_LICENSE_FILE。export VCS_HOME/opt/synopsys/vcs/2024.06-SP1 export VERDI_HOME/opt/synopsys/verdi/2024.06-SP1 export PATH$VCS_HOME/bin:$VERDI_HOME/bin:$PATH export SNPSLMD_LICENSE_FILE27020your_license_server注意license 服务器地址一定要用实际可用的配置完先用lmstat确认能连上否则 VCS 编译到一半才报 license 错误白白浪费时间。Vivado 这边如果你是在图形界面里操作环境变量会自动带上但如果要在纯命令行下用compile_simlib需要先 source Vivado 的settings64.sh。我一般会在同一个终端里先 source Vivado 环境再 source Synopsys 环境顺序不要反否则 PATH 里 Vivado 的某些工具可能被覆盖。2.3 磁盘空间与权限的隐形坑编译 Xilinx 仿真库是个“吃磁盘”的活。全器件库编译下来几十 GB 是常态。我建议单独挂一块数据盘把库编译到非系统盘路径下。另外编译过程会生成大量临时文件如果/tmp分区太小中途会报“No space left on device”这个报错很隐蔽因为看起来像是编译错误实际是磁盘满了。权限方面如果你用的是公司服务器库目录最好放在自己有写权限的路径下比如/home/yourname/sim_lib。放在/opt下虽然看起来规范但每次编译都要 sudo反而麻烦。我个人的习惯是每个项目单独建一个sim_lib目录虽然占空间但项目之间互不干扰换 Vivado 版本时也不用担心库被覆盖。3. 编译 Xilinx 仿真库的完整流程3.1 图形界面编译与命令行编译怎么选Vivado 提供了两种编译仿真库的方式图形界面Tools - Compile Simulation Libraries和命令行compile_simlib。图形界面适合第一次操作、想看清楚每一步在干什么的人命令行适合需要批量编译、或者要在无图形界面的服务器上操作的场景。我两种都用过结论是第一次建议用图形界面熟悉流程后全部转命令行。原因是图形界面编译大库时如果中途卡住你很难判断是死机了还是在慢慢跑命令行有明确的进度输出而且可以写成脚本重复执行。图形界面里几个关键选项要选对Simulator 选 VCSLanguage 根据你的设计选 Verilog 或 SystemVerilog混合设计选后者Library 选择你实际用到的器件系列。不要图省事选“All”全编译一次可能要一两个小时而且大部分库你根本用不到。3.2 命令行编译库的实操命令命令行编译的核心命令是compile_simlib它需要在 Vivado 的 Tcl 环境下执行。我通常写一个compile_lib.tcl脚本然后用vivado -mode batch -source compile_lib.tcl执行。compile_simlib -simulator vcs_mx \ -simulator_exec_path /opt/synopsys/vcs/2024.06-SP1/bin \ -family kintex7 \ -family zynq \ -language verilog \ -library unisim \ -library simprim \ -dir /home/yourname/sim_lib/vivado2025.1 \ -no_systemc_compile这里有几个参数值得展开说。-simulator vcs_mx表示用 VCS 的 MX 模式支持混合语言如果你只跑纯 Verilog用vcs也行但 MX 模式兼容性更好。-simulator_exec_path指向 VCS 的 bin 目录这个必须准确否则编译出来的库可能和实际 VCS 版本不匹配。-family指定器件系列我一般只编译项目实际用到的比如 Kintex-7 和 Zynq。-no_systemc_compile是跳过 SystemC 库编译除非你做 SystemC 联合仿真否则没必要编能省不少时间。编译完成后目录下会生成一堆.vdb、.so和映射文件。最关键的是modelsim.ini的等价物——VCS 用的是synopsys_sim.setup文件里面记录了库名到实际路径的映射。这个文件后面在仿真脚本里要引用。3.3 编译过程中的常见报错与处理编译库时最容易遇到的是两类问题一是 VCS 版本不兼容导致的语法报错二是环境变量缺失导致的工具找不到。前者通常表现为某个.v文件编译失败报“SystemVerilog keyword not supported”之类后者会直接提示“vlogan: command not found”。遇到版本不兼容最直接的解决办法是换 VCS 版本或者只编译你真正需要的库。有时候某个 IP 的仿真模型用了新语法你可以单独把这个 IP 的库排除掉用行为级模型替代。环境变量问题就简单了检查PATH里有没有 VCS 的 bin 目录which vlogan能不能找到。还有一个隐蔽的坑编译库时如果同时开了多个终端在跑可能会因为临时文件冲突导致编译失败。我一般会确保同一时间只有一个编译任务在跑编译前先清理一下临时目录。4. 生成仿真脚本与联合仿真配置4.1 从 Vivado 导出仿真脚本Vivado 可以自动生成 VCS 的仿真脚本路径是 File - Export - Export Simulation。这里要选 VCS 作为目标仿真器并指定之前编译好的库路径。导出的脚本通常包括compile.sh、elaborate.sh、simulate.sh三个分别对应编译、精化和仿真三个阶段。不过自动生成的脚本往往比较“通用”里面会包含很多你不需要的库引用。我的做法是把它作为起点然后手动精简。比如它会默认引用所有器件的库你只需要保留实际用到的。精简后的脚本跑起来更快也更容易排查问题。导出时还有一个关键选项是否包含-debug_access参数。如果你要用 Verdi 看波形必须确保编译时加了调试信息。VCS 的-debug_accessall或者-kdb参数就是干这个的。自动生成的脚本有时会漏掉需要手动补上。4.2 手写仿真脚本的骨架自动生成的脚本看懂了之后我更推荐手写一份精简版这样每个参数都心里有数。一个典型的 VCS 联合仿真脚本分三步vlogan编译 Verilog 源文件和库vcs精化生成可执行文件simv执行仿真。# 第一步编译库和源文件 vlogan -full64 -sverilog v2k -timescale1ns/1ps \ -work work \ -f filelist.f \ -y $SIM_LIB/unisim \ libext.v.sv \ -l compile.log # 第二步精化 vcs -full64 -debug_accessall -kdb \ -timescale1ns/1ps \ -top tb_top \ -l elaborate.log # 第三步仿真 ./simv -l sim.log fsdbautoflush-full64表示 64 位模式现在基本是标配。-sverilog和v2k让 VCS 支持 SystemVerilog 和 Verilog-2001 语法。-timescale要和你的设计一致否则时序会对不上。-y指定库搜索路径libext指定库文件扩展名。-debug_accessall和-kdb是给 Verdi 用的前者生成调试信息后者生成 Verdi 的知识数据库缺一不可。提示fsdbautoflush让仿真过程中波形自动刷新到 FSDB 文件这样即使仿真中途崩溃已经产生的波形也不会丢。做长仿真时这个参数能救命。4.3 库映射文件与路径管理VCS 通过synopsys_sim.setup文件来定位库。这个文件可以放在当前工作目录也可以放在$VCS_HOME/bin下作为全局配置。我倾向于放在项目目录下每个项目独立管理。文件内容大致是这样WORK DEFAULT DEFAULT : ./work UNISIM : /home/yourname/sim_lib/vivado2025.1/unisim SIMPRIM : /home/yourname/sim_lib/vivado2025.1/simprimWORK是默认的工作库UNISIM和SIMPRIM指向编译好的 Xilinx 库。路径一定要用绝对路径相对路径在不同终端下容易出问题。如果项目里用了多个 IP每个 IP 的库也要在这里加一行映射。路径管理的一个经验是把所有库路径写进一个环境变量脚本里引用变量而不是硬编码路径。这样换机器或者换库版本时只改一个地方就行。5. Verdi 波形调试与 FSDB 加载5.1 生成 FSDB 波形的两种方式Verdi 看波形的前提是有 FSDB 文件。生成 FSDB 有两种方式一种是在 Testbench 里直接调用$fsdbDumpfile和$fsdbDumpvars系统函数另一种是用 VCS 的-fsdb编译选项自动 dump。第一种方式更灵活可以精确控制 dump 哪些信号、从什么时间开始 dump。我通常会在 Testbench 的 initial 块里加initial begin $fsdbDumpfile(wave.fsdb); $fsdbDumpvars(0, tb_top); end$fsdbDumpvars的第一个参数是层级深度0 表示 dump 所有层级。如果设计很大全 dump 会让 FSDB 文件巨大这时候可以指定只 dump 某个模块比如$fsdbDumpvars(1, tb_top.u_dut)。第二种方式是在编译时加-fsdb和-P参数让 VCS 自动插入 dump 逻辑。这种方式适合不想改 Testbench 的场景但控制粒度不如第一种。5.2 Verdi 加载波形的实操步骤Verdi 启动命令是verdi -ssf wave.fsdb-ssf表示加载 FSDB 文件。如果同时要看 RTL 代码可以加-sv和-f filelist.f这样 Verdi 会把源代码也加载进来方便做信号追踪。Verdi 里几个高频操作Get Signal把信号加到波形窗口Trace Driver追踪信号驱动源Trace Load追踪信号负载。做调试时我习惯先用Trace Driver找到信号是被哪个模块驱动的再顺着看逻辑对不对。还有一个很实用的功能是nWave里的Analog显示模式。看总线信号或者计数器时用模拟波形显示比数字波形直观得多。右键信号选Analog就能切换。5.3 用 Verdi 做后仿真的技巧后仿真门级仿真和 RTL 仿真最大的区别是时序信息。后仿真时Verdi 里可以看到门级网表的延迟这时候Trace Driver可能会追到标准单元内部看起来比较乱。我的做法是先用 RTL 仿真确认功能正确再做后仿真确认时序。后仿真时 FSDB 文件会非常大因为每个门都有信号变化。这时候要控制 dump 范围只 dump 关键模块。另外后仿真跑得慢建议先用小激励跑通再上完整激励。注意后仿真时如果发现 X 态传播先检查 memory 初始化。很多后仿真的 X 态问题都是 memory 没有正确初始化导致的RTL 仿真时 memory 默认是 X但行为级模型可能掩盖了这个问题。6. 常见问题排查与避坑经验6.1 编译阶段的典型报错编译阶段最常见的问题是库找不到和语法不兼容。库找不到的报错通常是“module not found”这时候要检查synopsys_sim.setup里的路径对不对以及-y参数有没有指向正确的库目录。语法不兼容的报错会具体指出哪个文件哪一行通常是 SystemVerilog 的新特性在旧版 VCS 里不支持。还有一个坑是timescale不一致。如果 Testbench 和设计模块的timescale不同仿真时间会错乱。我一般会在编译时统一指定-timescale1ns/1ps覆盖源文件里的设置。6.2 仿真阶段的常见异常仿真跑起来之后常见的问题有仿真卡死、结果不对、FSDB 文件为空。仿真卡死通常是死循环或者握手信号一直不满足这时候可以用 Verdi 打开 FSDB 看最后时刻的信号状态。结果不对要先确认激励有没有正确加载再看时序对不对。FSDB 为空多半是$fsdbDumpfile没执行或者-debug_access没加。问题现象可能原因排查方法编译报 module not found库路径错误检查 synopsys_sim.setup仿真卡死死循环或握手不满足Verdi 看最后时刻信号FSDB 文件为空dump 函数未执行检查 Testbench 和编译选项后仿真 X 态传播memory 未初始化检查 memory 初始化逻辑Verdi 无法加载源码未加 -sv 或 filelist补上源码加载参数6.3 我踩过的几个印象深刻的坑第一个坑是 license 超时。有一次跑长仿真跑到一半 VCS 报 license 失效仿真直接中断。后来发现是 license 服务器设置了空闲超时解决办法是在脚本里加licqueue参数让 VCS 排队等 license而不是直接失败。第二个坑是 FSDB 文件太大导致磁盘满。一个后仿真跑了两个小时FSDB 文件涨到 80 多 GB直接把磁盘写满。后来我改成只 dump 关键信号并且用$fsdbDumpoff和$fsdbDumpon控制 dump 时间段只在关键窗口 dump。第三个坑是 Verdi 版本和 VCS 版本不一致。有一次 VCS 是 2024 版Verdi 是 2022 版加载 FSDB 时报格式不兼容。后来统一了版本就没事了。所以前面强调版本匹配真的是血泪教训。7. 联合仿真的效率优化建议7.1 编译缓存与增量编译VCS 支持增量编译第二次编译时只重新编译改动的文件。开启方式是加-Mupdate参数。对于大项目增量编译能省很多时间。不过增量编译有时会出玄学问题如果结果不对先试试全量编译排除缓存问题。库编译也可以缓存。编译好的 Xilinx 库可以复用不用每次换项目都重编。我一般把库放在一个固定路径所有项目共用。只有换 Vivado 版本时才重新编译。7.2 并行仿真与资源分配VCS 支持多核并行仿真加-j参数指定核数。比如-j8用 8 个核。不过并行仿真对某些设计效果不明显因为仿真本身是串行的并行主要加速编译阶段。真正加速仿真要靠优化激励和减少 dump 信号。资源分配上编译阶段吃 CPU 和内存仿真阶段吃内存和磁盘 IO。如果服务器内存不够仿真会频繁 swap速度反而更慢。我一般确保仿真时至少有 16GB 可用内存。7.3 波形 dump 策略的取舍波形 dump 是仿真速度的最大影响因素之一。全 dump 和只 dump 关键信号速度可能差好几倍。我的策略是功能调试阶段 dump 关键模块回归测试阶段只 dump 错误时刻。用$fsdbDumpoff在仿真开始时关闭 dump检测到错误时再$fsdbDumpon打开这样 FSDB 文件小仿真也快。还有一个技巧是用$fsdbDumpvars的深度参数控制 dump 层级。比如只 dump 顶层和第一层子模块深度设为 1这样既能看整体信号又不会 dump 太多内部信号。8. 写在最后的几句实在话这套 Vivado 2025.1 加 VCS 2024.SP1 的联合仿真流程我从第一次配置到跑通大概花了两天其中大部分时间耗在库编译和版本兼容上。现在回头看最值得花时间的是把环境变量和库路径管理好这两件事做扎实了后面换项目、换版本都能快速迁移。如果你刚开始接触联合仿真建议先用一个小设计比如一个计数器加 Testbench把整个流程跑通确认编译、仿真、波形查看三个环节都没问题再上大项目。大项目直接上出了问题很难定位是流程问题还是设计问题。另外工具版本不要盲目追新。Vivado 2025.1 和 VCS 2024.SP1 这个组合我实测下来比较稳但如果你团队里其他人用的是老版本最好统一否则脚本和库文件互相不兼容协作起来很痛苦。工具是拿来干活的稳定比新更重要。
