拓冰网站定制 
1. 为什么要自己折腾VCS与Verdi仿真工具链的现实选择先说说我入坑时的背景。在学校做数字IC相关课题用的还是ModelSim跑RTL仿真波形一多就卡得没法看。后来去了公司实习发现真实项目里几乎没人用那一套清一色是Synopsys的工具链。带我的老工程师直接甩给我一句话“以后你写验证环境编译、仿真、看波形全在VCS和Verdi里搞定赶紧把环境搭起来。”老实说我当时连VCS和Verdi到底是什么关系都没搞清以为是一个工具的两个名字。后来自己踩了一堆坑才慢慢明白VCS是仿真器负责任务是把Verilog/SystemVerilog代码编译成可执行文件并跑仿真Verdi是调试工具负责把仿真过程中产生的波形、信号变化以可视化的方式呈现出来。两者配合使用才是工业界数字IC验证的标准姿势。需要说明的是VCS负责的是逻辑仿真层次它和Verdi通过一套PLI编程语言接口机制做通信Verdi并不是VCS的插件它们更像是“前端跑数据的”和“后端看数据的”两个独立环节。这篇文章我打算从零开始把VCS和Verdi联合仿真的完整流程梳理一遍包括环境准备、编译选项怎么给、波形文件怎么产生、后仿里memory初始化怎么处理以及那些网络上搜半天也搜不到答案的坑。内容偏向实际动手适合刚接触数字IC验证方向的学生或者从其他仿真器转过来的工程师参考。我会用我实际调试过的场景来讲尽量少说空话。2. 环境准备工作许可证、路径和工具链版本搭配2.1 先搞清楚VCS和Verdi真正做什么很多人在第一步就被绕晕是因为没分清VCS和Verdi的分工边界以为搭环境就是装两个软件然后一起点开。实际上是两条相对独立的流程线VCS编译仿真写好的RTL代码经过vcs命令预处理、编译、链接生成一个可执行的simv文件。simv运行起来仿真器内部按照事件驱动机制推进仿真时间信号变化会被记录下来前提是使能了波形记录机制。Verdi波形分析仿真过程中通过调用Verdi的PLI接口把信号变化写进fsdb格式的数据库文件里。仿真结束后也可以实时打开Verdi加载这个fsdb文件就能像看示波器一样查看每一个信号在每个仿真时刻的跳变关系。FSDB是Verdi专用的波形格式它比通用的VCD文件小很多加载速度也快。Verdi之所以在调试阶段占据绝对优势除了波形查看流畅更关键的是它支持source code的层次化追踪点一个信号可以直接追溯到它被驱动的位置这个后面细说。2.2 环境变量和工具链搭配的一些经验我这里用的是Synopsys的VCS和Verdi具体版本就不写了不同版本编译选项上会有些许差异——但核心逻辑大同小异。环境配置上主要注意这几个点确保VCS和Verdi的bin目录都加入PATH否则命令找不到。许可证环境变量要同时覆盖两个工具。很多License问题都是因为只设置了VCS的许可证Verdi的feature没放进去。Verdi需要设置VERDI_HOME同时把$VERDI_HOME/bin加入PATH。环境变量LM_LICENSE_FILE或SNPSLMD_LICENSE_FILE根据所用License管理方式二选一或都设置。具体来说我的bashrc里大概长这样export VERDI_HOME/opt/Synopsys/verdi export VCS_HOME/opt/Synopsys/vcs export PATH$VCS_HOME/bin:$VERDI_HOME/bin:$PATH export LM_LICENSE_FILE27020license-server export SNPSLMD_LICENSE_FILE27020license-server注意License服务器的地址只是举例不要照抄。如果实在不清楚许可配置方式可以确认一个简单的检查命令——在终端分别输入vcs -ID和verdi -help能正常输出版本信息和帮助就说明工具路径没问题再跑一个小例子验证License。这里提醒一个问题终端解析PATH的顺序很影响使用体验。如果你机器上同时装了别的仿真器的命令比如某些开源EDA工具链里的iverilog而PATH里VCS的bin目录放在后面敲vcs时可能调到别的同名命令。检查时用which vcs确认到底调的是哪个路径下的可执行文件这是排查“命令找不到”和“版本不对”的第一步。2.3 目录组织与文件规划正规项目的代码量很大目录组织从一开始就要规划好。我的习惯是分几个目录sim/ ├── rtl/ # RTL源码 ├── tb/ # testbench和验证环境 ├── work/ # 放编译中间文件和simv └── log/ # 日志和波形输出把中间文件和源文件分开的好处是清掉work目录重编译时不会误删代码波形和日志目录独立方便回归时归档。尤其是跑大批量回归时每次都把波形输出到固定目录脚本只要按用例名拼接路径即可不会互相覆盖。这也是我吃亏之后学乖的——最开始把所有文件放在一个目录里后仿跑几组用例后simv、中间产物、波形混在一起根本分不清哪次跑到哪步了。3. 编译流程拆解从源文件到simv的完整过程3.1 VCS编译的三步曲VCS的编译过程官方叫法是三步分析Analysis、细化Elaboration、仿真Simulation。对应到命令执行上前两步被一条vcs命令封装了但仍然可以通过选项控制细节。第一步VCS会把verilog/VHDL/SystemVerilog源文件解析成中间表示。这一步只负责语法检查和初步语义检查。第二步是elaboration把各个module连接起来确定实例化的层次、信号的驱动关系并完成参数重定义和宏展开最终生成可执行文件simv。第三步才是真正跑仿真。所以你在命令里看到的各种编译选项有的管第一步有的管第二步要分清楚容易混淆的地方。比如-sverilog启用SystemVerilog语法支持必须加。v2k启用Verilog 2001特性老项目可能要加新代码一般被-sverilog覆盖。-debug_accessall允许生成波形和UCLI调试信息。这一步在编译时定了后面才能在仿真时用$fsdbDumpfile写波形。如果编译时没开调试权限运行时dump波形会失败或者干脆不产生文件。-timescale1ns/1ps指定时间单位和精度。后仿时这个尤其关键如果SDF文件里标注的时间精度比仿真精度小会告警甚至导致时序标注失败。我实际遇到过的情况是有一个模块的timescale写的是1ps/1ps另一个是1ns/1ps顶层没有统一设置结果VCS编译后产生的simv在某些场景下时序行为看起来怪怪的。后来统一在编译命令里指定-timescale1ns/1ps内部不一致的告警消停了后仿时序也更符合预期。3.2 文件列表和依赖顺序VCS对文件列表的处理相对灵活。你可以直接命令行把所有文件写出来但项目大了以后没人这么干一般是写一个filelist.f文件每行一个源文件然后命令行用-f filelist.f读入。这里有个细节值得注意文件顺序会影响部分宏定义和include的解析。如果你在A文件里用include defines.vh而defines.vh和A在同一个目录下VCS通常能通过incdir指定include目录才能正确找到。不指定的话VCS默认搜索当前目录和编译命令中列出的路径并不自动搜索文件所在目录。这个坑非常常见尤其是从Windows上的开发环境迁到Linux时一堆include找不到头文件的错就是这么来的。我的标准写法是这样vcs -sverilog -timescale1ns/1ps -debug_accessall \ -f filelist.f -o simv \ -l compile.log \ incdir../rtl-f filelist.f把源码文件列表读进去incdir指定include搜索目录-o simv指定输出可执行文件名默认就是simv但指定一下方便区分多组编译-l compile.log保存编译日志。filelist.f里也可以直接写编译选项VCS会读进去当成命令行参数处理。常见做法是在filelist最开头写// filelist.f incdir../rtl -sverilog ../rtl/defines.vh ../rtl/cpu_top.v ../tb/tb_top.sv注意源文件的\续行符在filelist里完全不需要每行一个就行。写文件列表时还要尽量避免写绝对路径否则整个目录转移到别的机器时要重写。相对路径是基于执行vcs命令的目录来解析的所以最好固定在一个work目录下执行编译命令filelist里用相对路径指向源码。3.3 Makefile设计把复杂命令固化下来联合仿真的命令比较复杂每次手敲容易出错而且文件一多编译选项很难记住。我的建议是写一个Makefile把编译、仿真、清理、打开波形分别封装成target。这样一条命令做一件事回归测试时也方便。一个简化的Makefile长这样WORK_DIR : work TOP : tb_top VCS_OPTS : -sverilog -timescale1ns/1ps -debug_accessall incdir../rtl .PHONY: comp sim wave clean comp: mkdir -p $(WORK_DIR) cd $(WORK_DIR) vcs $(VCS_OPTS) -f ../tb/filelist.f -o simv -l compile.log sim: cd $(WORK_DIR) ./simv -l sim.log wave: cd $(WORK_DIR) verdi -f ../tb/filelist.f -ssf $(TOP).fsdb clean: rm -rf $(WORK_DIR)注意Verdi打开时也传filelist原因是Verdi需要加载源代码来对应波形层次。如果你不给filelist打开波形后信号列表能看到但source code窗口是空的追踪信号也没法跳到源码调试体验大打折扣。记住打开Verdi时一定要带源码的filelist和同一个fsdb文件这样才能做到波形与RTL联动追踪。4. 波形生成机制与Verdi侧调试技巧4.1 fsdb波形是怎么来的很多刚接触的人会有个误解以为只要装了Verdi仿真结束就自动有fsdb文件。其实fsdb的产生依赖仿真器在仿真过程中调用Verdi提供的PLI函数库。VCS编译时通过指定PLI库路径把Verdi的$fsdbDumpfile等系统函数注册进去仿真运行中这些函数才会生效。从命令上看VCS编译时通常要加这些-P $VERDI_HOME/share/PLI/VCS/LINUX64/novas.tab \ incdir$VERDI_HOME/share/PLI/VCS/LINUX64/pli.a或者用新版Verdi提供的更简洁写法-v $VERDI_HOME/share/PLI/VCS/LINUX64/verilog/novas_verilog.v不过现在很多版本的VCS已经内置了对fsdb的支持。你只要编译时给了-debug_accessalltestbench里直接调用$fsdbDumpfile和$fsdbDumpvars运行完一般就能在目录下看到fsdb文件。如果怎么都出不来波形再去检查上述两个PLI相关选项多半能找到原因。4.2 波形dump的控制函数写法testbench里通常这么写initial begin $fsdbDumpfile(tb_top.fsdb); $fsdbDumpvars(0, tb_top, all); end这里的0表示dump整个设计层次所有信号不限层级。如果只dump某个子模块可以写$fsdbDumpvars(0, tb_top.u_cpu)。all选项用于额外记录一些Verdi能识别的信息比如状态机的状态寄存器原始编码等这个对调试状态机特别有用。再扩展一下仿真时间长、信号特别多时全量dump会让fsdb文件膨胀到几十GBVerdi打开都费劲。这时候可以控制dump时机initial begin $fsdbDumpfile(tb_top.fsdb); $fsdbDumpvars; #10000 $fsdbDumpoff; // 前10us关闭dump因为这段是复位过程 #500000 $fsdbDumpon; // 到500us再打开dump end$fsdbDumpoff和$fsdbDumpon配合使用可以精确控制只dump关心的时间段大幅压缩波形文件体积。这个技巧在跑长仿真时尤其好用谁都希望波形文件小一点、Verdi加载快一点。4.3 Verdi里真正有效的调试路径波形dump出来后在Verdi里的操作流程我是这么走的第一步打开波形文件。verdi -f ../tb/filelist.f -ssf tb_top.fsdb -ssf参数指定fsdb波形文件。如果不指定也可以进入Verdi后在GUI里菜单选择打开新波形。第二步从波形窗口找到感兴趣的信号右键选择“Get Signals”选“Add to Waveform”就能把信号拖到波形窗口。光标选中一段区域后按z键可以放大按x键可以缩小。第三步Verdi最有价值的功能之一层次追踪Trace。当你看到一个信号发生了异常跳变选中它按快捷键或者右键选择“Trace Input Load”Verdi会回到源码中高亮那些驱动该信号的逻辑。再选中驱动逻辑的输入继续tracer可以一级一级找到根本原因。这套机制比我以前用ModelSim“在波形里瞪着信号猜”效率高太多了尤其是跨模块的bug用trace链路很快就能锁到某个状态机跳转到非法状态。如果你要在Verdi里查看信号在某个时刻的前一个事件即信号是什么事件导致这拍的选中信号后右键“Get Drivers”可以弹出一个信号驱动关系图把组合逻辑和时序逻辑的关系画出来。这种能力在定位“为什么这个信号同时被多个源驱动”或者“为什么信号在仿真开始阶段是X态”时非常有用。4.4 处理仿真中的X态问题在数字IC验证里最令人头疼的问题是仿真里信号出现X态未知态。RTL仿真里X态一般有两类来源一类是寄存器没有初始化上电就是X另一类是组合逻辑里出现了未定义的赋值比如case没有default、级联信号同时在两个always块里驱动等。后一类问题在Verdi里可以用一个非常实用的功能来排查波形窗口中默认会用红色高亮X态信号。你可以在波形窗口的“Bus/Array”显示设置里把X态的颜色调得更明显然后快速扫描哪个信号在哪个时间段变成了红色。选中该红色区域点击TraceVerdi会引导你到驱动源。如果是两个always块同时驱动同一个寄存器Verdi会在源码里标记Multiple Driver警告这个问题在仿真阶段一般不报错但综合时会有严重风险。关于X态还有一种常见于后仿场景的情况就是memory没有初始化导致大面积的X态蔓延。这个我会在下一节专门展开说因为它是VCS后仿里非常典型的坑。5. 后仿与memory初始化VCS中容易踩的硬骨头5.1 前仿和后仿在VCS使用上的差别先简单区分一下前仿和后仿。前仿又叫RTL仿真直接拿RTL代码跑功能验证不看门级延迟速度快。后仿则是把综合后的门级网表和SDF时序文件一起放进仿真器验证电路在真实门延迟和布线延迟下能不能正常工作。从VCS使用角度后仿和前仿的差异集中在以下几处需要读入网表文件通常是v或者vg格式一般也用一个filelist描述。需要把SDF文件通过$sdf_annotate读进来。标准单元库的仿真模型里通常有specify块用来标注时间参数VCS编译时要用选项保证specify信息不被跳过。门级仿真对复位和初始化更敏感因为综合后的网表没有initial语句或者说综合工具不会把initial语句综合成电路如果源设计里没有可靠的复位逻辑门级仿真一开始很多寄存器就是X态。后仿时我的VCS编译命令一般长这样vcs -sverilog -timescale1ns/1ps -debug_accessall \ -f ../../rtl/filelist.f \ -f ./netlist.f \ -v $STDCELL/verilog/slow_vdd1v8_basic_cells.v \ definePOST_SIM \ neg_tck \ -o simv_post其中definePOST_SIM用于让RTL testbench在编译时加入后仿相关分支比如加载sdf的initial块。-v选项是让仿真器在该库文件中查找在源代码中未例化定义的模块网表里引用的标准单元正好需要这种方式被解析到。这里注意区分-v和-y-y是指定库目录搜索-v是指定单个库文件两个都常用但别搞混了。5.2 memory初始化为什么后仿里寄存器全是X后仿里memory初始化的坑网上搜vcs后仿memory初始化能找到一堆问题就知道它有多普遍。综合工具会把代码里抽象的memory转换成一个或多个标准单元RAM模型。在门级仿真中RAM模型的初始输出往往是X因为它没有上电和复位逻辑。如果设计里没有对memory做专门的初始化比如load boot代码到instruction memory那么CPU取指时读到X态数据指令解码全部乱掉后仿从第一条指令就开始挂。很多人在RTL前仿里写了一套testbench用$readmemh把调试用的二进制文件加载到指令memory里跑得很开心。把同一套benchmark拿到后仿里跑发现加载的路径找不到了或者直接用force的方式在simv里对memory赋值发现根本写不进去。原因很简单$readmemh在RTL仿真里可以直接作用到你设计的memory数组上但后仿中用到的memory已经变成网表里的实例。RTL里的memory层次和后仿中RAM实例的层次不同$readmemh里写死的层次路径自然找不到。另外标准单元的仿真模型里可能并没有开放写入接口直接对实例内部节点force也容易导致仿真器行为异常。5.3 实际采用的几种初始化方案及对比我在实践过程中试过好几种办法各自适用场景不同方案一通过层次路径force/deposit在仿真前初始化在testbench里某个initial块中通过层次化引用来强制设置memory内容。initial begin force tb_top.u_soc.u_ram.mem[0] 32h00000000; force tb_top.u_soc.u_ram.mem[1] 32h00000001; release tb_top.u_soc.u_ram.mem[0]; // 如果元素很多一般要循环force再release end这种办法在小容量memory、几十个字以内可行。但如果指令memory有64KB甚至更大靠逐字force完全不现实。另外force和release的方式在半途操作时如果UVM验证环境或设计本身存在多个驱动源force操作容易和仿真器事件队列产生冲突我遇到过force之后release没生效导致仿真结果和RTL仿真不符的情况。方案二修改netlist层次的initial块比较工程化的做法是在门级网表中找到RAM实例在RAM实例内部增加一段initial块或用Verilog行为描述方式直接给内部寄存器数组加载数据。// 在网表或封装wrapper里补充一段初始化逻辑 reg [31:0] mem_core [0:4095]; initial begin $readmemh(boot.hex, mem_core); end显然直接改网表会污染原文件而且每换一次工艺库或重新综合就白改了。更合理的做法是把RAM模型封装在一个wrapper模块里wrapper内部例化标准单元RAM同时把initial块放在wrapper层级上仿真时只编译wrapper而不修改工艺库文件。当然用initial块这种方式本来就不是综合可综合的但注意它只用于仿真目的。在后仿中仿真时可以通过definePOST_SIM来控制是否编译这段代码。需要说明的是这是基于常见实践的补充方案不同工艺库的RAM仿真模型写法差异很大如果RAM模型本身没有开放memory阵列的层次路径wrapper方案也会受到局限。方案三在UVM环境的config_db里传memory初值如果你的验证环境用SystemVerilog/UVM搭的还有一种做法是在环境层直接维护一个shadow memory模型仿真进入后通过总线功能模型逐个写入RAM。这在功能上最接近真实加载流程因为它是通过实际写端口写入的时序行为和后仿目标一致。缺点也很明显写一个完整的加载序列慢尤其memory有几KB、几十KB时逐周期打激励会让仿真时间边长。不过这类问题可以通过在测试用例中直接对总线序列做burst优化来解决。综合来说我个人的建议是需要精确验证加载流程时用方案三需要快速跑通后仿时用方案二。方案一只适合极小容量临时瞄一眼可以千万别当主力方案。5.4 用$readmemh和$readmemb时的路径细节这里再说一个具体的坑。教材上给的$readmemh例子很简单$readmemh(file.hex, mem);。但到了复杂层次或者UVM环境里路径解析经常出问题。最直接的问题是文件路径是相对于哪个目录解析的VCS仿真时相对路径是相对于模拟运行simv时所在的工作目录也就是你敲./simv那个目录。如果你把simv放在work目录下而hex文件在另一个data目录里那么你写的boot.hex可能在work目录下找不到文件。VCS会报一个类似“Cannot open file”的warning然后$readmemh什么都不加载memory保持X或全0调试半天才发现是文件没读到。正确做法是给完整相对路径或者绝对路径。如果项目目录要从一台机器搬到另一台机器用获取环境变量的方式更可靠initial begin string mem_file; if ($value$plusargs(MEM_FILE%s, mem_file)) begin $readmemh(mem_file, tb_top.u_soc.u_ram.mem); end else begin $readmemh(../data/boot.hex, tb_top.u_soc.u_ram.mem); end end加一个$value$plusargs之后运行仿真时就能用./simv MEM_FILE./data/boot.hex来指定文件位置。调试异常时不用重新编译就能换文件非常方便。这种在仿真阶段通过plusarg传递参数的方式在后仿脚本里也是常见做法。6. 排错思路与实际案例编译、波形和仿真阶段的典型坑6.1 排查思想的顺序先环境再代码后脚本作为一个把VCSVerdi流程用了很久的人我总结出一个排错顺序遇到问题先按这个流程走能省很多时间。第一层查环境。which vcs、which verdi路径对不对License检查是否通过编译时报的错是command not found还是license相关的feature不够第二层查编译选项。缺了-sverilog报SystemVerilog语法错incdir没加报include文件找不到-v库没加导致标准单元模块未定义。第三层查文件列表。filelist里的顺序、相对路径基准目录、是否存在重复定义模块。第四层查仿真运行阶段。simv运行时可能在UVM的phase里就卡住了也可能跑起来但波形没dump出来这里要区分是编译问题还是运行问题。第五层查脚本和路径。尤其要注意$readmemh这类文件读取操作以及临时目录空间是否够大大fsdb文件写满/tmp会导致仿真中途挂掉。6.2 案例一编译成功但fsdb文件没生成这是我第一次跑联合仿真时遇到的问题卡了快一整天。场景vcs编译通过simv运行正常UVM打印也没有报错但工作目录下就是找不到fsdb文件。排查链路先确认testbench里面确实调用了$fsdbDumpfile。一看有。再确认编译时加了-debug_accessall。一看也加了。那为什么没生成fsdb然后我想起来检查运行日志发现日志中间有一行Warning类似“*W,PLIUNKG: Unrecognized system task $fsdbDumpfile”。这个warning非常重要它说明仿真器在编译testbench时根本没有识别出$fsdbDumpfile这个系统函数把它当成未知任务跳过了。为什么没识别因为VCS在编译的时候没有链接Verdi的PLI库。新版VCS在一些默认安装里能自动找到但我的环境里VCS和Verdi是两个独立安装的目录VCS不会主动知道Verdi的PLI库在哪里。解决方法是编译时显式加PLI相关参数vcs -sverilog -debug_accessall \ -P $VERDI_HOME/share/PLI/VCS/LINUX64/novas.tab \ $VERDI_HOME/share/PLI/VCS/LINUX64/pli.a \ -f filelist.f -o simv注意-P参数后面必须跟着.tab文件这是PLI函数的注册表然后跟着实际的静态库或动态库路径。不同版本的Verdi目录结构可能不同建议在安装完Verdi后用find $VERDI_HOME -name novas.tab确认路径。配好以后重新编译运行fsdb顺利生成。6.3 案例二VCS后仿中memory始终为X另一个印象深刻的坑后仿时所有信号都有波形唯独指令memory的数据一直是XCPU从第一拍开始就跳不到正常流程。当时我的编译命令和testbench里都写了$readmemh路径通过plusarg传进去了文件也确实存在。为什么还是X后来我把目光放到网表里标准单元RAM模型的内部层次和RTL数组的层次完全不同。在RTL里signal name叫u_ram.mem但在netlist里RAM被综合成了类似u_ram/inst/mem_reg_0_这样的单元结构不再存在一个名为mem的二维数组。这时候你对着RTL里的层次路径去$readmemh当然什么也加载不到。解决方式我看网上有人直接在编译时把RTL文件里用于后仿的memory模型排在netlist之前让仿真器优先解析RTL view的memory行为模型通常在工艺库的verilog模型文件夹里有behavioral或functional view里面保留了类似mem [0:4095]的寄存器数组定义然后在这个行为模型上加载$readmemh。具体做法编译顺序先编译库中RAM的行为级模型functional view再编译门级网表。在fsdb dump之前的initial块里通过层次路径引用到行为级模型的mem数组执行$readmemh。这个方案的前提是工艺库的RAM行为模型里真的有一个可加载的寄存器数组名。不同厂商的模型命名差异大需要先打开模型文件确认。如果实在不行就用我上面提到的wrapper方案把RAM包一层在wrapper里做初始化后再映射到输出端口。这样网表和RTL在仿真实例层次上保持一致初始化逻辑也有地方可放。6.4 案例三Verdi打开后看不到源码这个坑看起来小但新人几乎都会碰到fsdb加载正常波形窗口能看到信号跳变但source code窗口是空的点击信号也没法追踪到RTL代码。原因我在4.3节提过——启动Verdi时没有携带源文件列表。Verdi需要知道fsdb文件里各个信号对应的是哪些源文件才能建立“层层次映射”。解决办法是启动Verdi时带上filelistverdi -f ../tb/filelist.f -ssf tb_top.fsdb 如果文件已经在Verdi里了也可以用菜单“Tools - Source Code”里的功能手动添加源文件但每次都手动加载太麻烦了。建议把Verdi启动命令也写进Makefile里的wave目标一行搞定。6.5 各窗口功能的快速速查表功能需求Verdi里的位置/操作具体对象查看波形主窗口“Signals”窗格中选中信号后拖到波形窗口或使用“Add to Waveform”Waveform窗口放大缩小波形波形窗口中按z / x键或使用鼠标滚轮Waveform窗口追踪信号驱动源波形窗口选中信号后右键选择“Trace Input Load”或“Get Drivers”源码窗口/NTrace查看信号列表主窗口下方信号列表双击即可加入波形nWave窗口查看FSDB层次结构左上角“Hierarchy”树形结构点击模块可查看对应的信号和源码Hierarchy窗口比较两轮仿真的波形File - Compare加载另一份fsdb差异会被高亮nWave的Waveform Compare7. 把联合仿真跑顺的几条具体操作建议如果让我总结联合仿真真正顺手的感受“流程固定”和“脚本固化”比学会某一条命令更重要。下面这些建议正好对应真实项目里会遇到的几个环节。第一编译选项不要每次手敲。把所有常用选项固化到Makefile里生成simv前先make clean一下旧产物免得旧文件缓存干扰。VCS的增量编译特性在多次迭代时能提升速度但有时候旧的时间戳缓存会引入奇怪的告警。如果编译时间突然和上次不一致可以先把work/目录彻底清一遍再编译。第二波形和日志分开保存文件名带上用例名和时间戳。比如sim_run_$(CASE)_$(DATE).fsdb。这样多个用例并行跑回归时波形不会互相覆盖。第三后仿里memory初始化文件路径用plusarg传入而不是在testbench里写死。这条我在5.4节演示过代码。真正跑了多次回归后就会体会到这种灵活性的价值——某个用例要换另一份初始化镜像只要在回归脚本里改参数不需要改任何RTL和验证代码。第四Verdi打开时把fsdb和filelist一次带上。别再人工加载源文件了容易漏掉某个文件导致整体层次映射异常直接走Makefile一条命令。第五排查问题的时候先看日志中是否有PLI相关的warning。很多fsdb和memory初始化的问题都跟PLI版本、路径有关而不是你的代码逻辑错了。编译日志里出现Unrecognized system task或Cannot find PLI等警告基本可以确定问题出在工具链衔接上。8. 回归一下从编译到波形调试最简单的完整流程最后给一个最简可跑的流程方便你验证环境是否正常。假设有最小文件../rtl/top.sv一个简单的计数器../tb/tb_top.svtestbench例化top驱动时钟和复位并在initial中dump fsdb。编译命令cd work vcs -sverilog -debug_accessall \ ../rtl/top.sv ../tb/tb_top.sv -o simv -l compile.log运行./simv -l sim.log fsdbauto如果testbench里有initial begin $fsdbDumpfile(tb_top.fsdb); $fsdbDumpvars; end运行结束后work目录会生成tb_top.fsdb。然后verdi -f ../tb/filelist.f -ssf tb_top.fsdb 如果filelist还没有准备好也可以这样启动verdi ../rtl/top.sv ../tb/tb_top.sv -ssf tb_top.fsdb 看到波形窗口能展开信号、源码窗口能高亮对应行这个最小的联合仿真流程就通了。再往后无论是引入更复杂的UVM环境还是进入门级后仿框架都不变VCS负责跑Verdi负责看你负责在两者之间找到那个信号跳变的瞬间。我这里开场时提到“搭环境折腾了很久”现在回头看真正值得花时间的地方不是工具安装本身而是理解编译、仿真、波形这条链路上每个环节的输入输出。把这条链路打通后面切到任何新项目都只是换文件列表和编译选项的事。希望这些经验能给你省下一些我当年浪费掉的时间。 VCS与Verdi联合仿真全流程解析：从编译到波形调试
1. 为什么要自己折腾VCS与Verdi仿真工具链的现实选择先说说我入坑时的背景。在学校做数字IC相关课题用的还是ModelSim跑RTL仿真波形一多就卡得没法看。后来去了公司实习发现真实项目里几乎没人用那一套清一色是Synopsys的工具链。带我的老工程师直接甩给我一句话“以后你写验证环境编译、仿真、看波形全在VCS和Verdi里搞定赶紧把环境搭起来。”老实说我当时连VCS和Verdi到底是什么关系都没搞清以为是一个工具的两个名字。后来自己踩了一堆坑才慢慢明白VCS是仿真器负责任务是把Verilog/SystemVerilog代码编译成可执行文件并跑仿真Verdi是调试工具负责把仿真过程中产生的波形、信号变化以可视化的方式呈现出来。两者配合使用才是工业界数字IC验证的标准姿势。需要说明的是VCS负责的是逻辑仿真层次它和Verdi通过一套PLI编程语言接口机制做通信Verdi并不是VCS的插件它们更像是“前端跑数据的”和“后端看数据的”两个独立环节。这篇文章我打算从零开始把VCS和Verdi联合仿真的完整流程梳理一遍包括环境准备、编译选项怎么给、波形文件怎么产生、后仿里memory初始化怎么处理以及那些网络上搜半天也搜不到答案的坑。内容偏向实际动手适合刚接触数字IC验证方向的学生或者从其他仿真器转过来的工程师参考。我会用我实际调试过的场景来讲尽量少说空话。2. 环境准备工作许可证、路径和工具链版本搭配2.1 先搞清楚VCS和Verdi真正做什么很多人在第一步就被绕晕是因为没分清VCS和Verdi的分工边界以为搭环境就是装两个软件然后一起点开。实际上是两条相对独立的流程线VCS编译仿真写好的RTL代码经过vcs命令预处理、编译、链接生成一个可执行的simv文件。simv运行起来仿真器内部按照事件驱动机制推进仿真时间信号变化会被记录下来前提是使能了波形记录机制。Verdi波形分析仿真过程中通过调用Verdi的PLI接口把信号变化写进fsdb格式的数据库文件里。仿真结束后也可以实时打开Verdi加载这个fsdb文件就能像看示波器一样查看每一个信号在每个仿真时刻的跳变关系。FSDB是Verdi专用的波形格式它比通用的VCD文件小很多加载速度也快。Verdi之所以在调试阶段占据绝对优势除了波形查看流畅更关键的是它支持source code的层次化追踪点一个信号可以直接追溯到它被驱动的位置这个后面细说。2.2 环境变量和工具链搭配的一些经验我这里用的是Synopsys的VCS和Verdi具体版本就不写了不同版本编译选项上会有些许差异——但核心逻辑大同小异。环境配置上主要注意这几个点确保VCS和Verdi的bin目录都加入PATH否则命令找不到。许可证环境变量要同时覆盖两个工具。很多License问题都是因为只设置了VCS的许可证Verdi的feature没放进去。Verdi需要设置VERDI_HOME同时把$VERDI_HOME/bin加入PATH。环境变量LM_LICENSE_FILE或SNPSLMD_LICENSE_FILE根据所用License管理方式二选一或都设置。具体来说我的bashrc里大概长这样export VERDI_HOME/opt/Synopsys/verdi export VCS_HOME/opt/Synopsys/vcs export PATH$VCS_HOME/bin:$VERDI_HOME/bin:$PATH export LM_LICENSE_FILE27020license-server export SNPSLMD_LICENSE_FILE27020license-server注意License服务器的地址只是举例不要照抄。如果实在不清楚许可配置方式可以确认一个简单的检查命令——在终端分别输入vcs -ID和verdi -help能正常输出版本信息和帮助就说明工具路径没问题再跑一个小例子验证License。这里提醒一个问题终端解析PATH的顺序很影响使用体验。如果你机器上同时装了别的仿真器的命令比如某些开源EDA工具链里的iverilog而PATH里VCS的bin目录放在后面敲vcs时可能调到别的同名命令。检查时用which vcs确认到底调的是哪个路径下的可执行文件这是排查“命令找不到”和“版本不对”的第一步。2.3 目录组织与文件规划正规项目的代码量很大目录组织从一开始就要规划好。我的习惯是分几个目录sim/ ├── rtl/ # RTL源码 ├── tb/ # testbench和验证环境 ├── work/ # 放编译中间文件和simv └── log/ # 日志和波形输出把中间文件和源文件分开的好处是清掉work目录重编译时不会误删代码波形和日志目录独立方便回归时归档。尤其是跑大批量回归时每次都把波形输出到固定目录脚本只要按用例名拼接路径即可不会互相覆盖。这也是我吃亏之后学乖的——最开始把所有文件放在一个目录里后仿跑几组用例后simv、中间产物、波形混在一起根本分不清哪次跑到哪步了。3. 编译流程拆解从源文件到simv的完整过程3.1 VCS编译的三步曲VCS的编译过程官方叫法是三步分析Analysis、细化Elaboration、仿真Simulation。对应到命令执行上前两步被一条vcs命令封装了但仍然可以通过选项控制细节。第一步VCS会把verilog/VHDL/SystemVerilog源文件解析成中间表示。这一步只负责语法检查和初步语义检查。第二步是elaboration把各个module连接起来确定实例化的层次、信号的驱动关系并完成参数重定义和宏展开最终生成可执行文件simv。第三步才是真正跑仿真。所以你在命令里看到的各种编译选项有的管第一步有的管第二步要分清楚容易混淆的地方。比如-sverilog启用SystemVerilog语法支持必须加。v2k启用Verilog 2001特性老项目可能要加新代码一般被-sverilog覆盖。-debug_accessall允许生成波形和UCLI调试信息。这一步在编译时定了后面才能在仿真时用$fsdbDumpfile写波形。如果编译时没开调试权限运行时dump波形会失败或者干脆不产生文件。-timescale1ns/1ps指定时间单位和精度。后仿时这个尤其关键如果SDF文件里标注的时间精度比仿真精度小会告警甚至导致时序标注失败。我实际遇到过的情况是有一个模块的timescale写的是1ps/1ps另一个是1ns/1ps顶层没有统一设置结果VCS编译后产生的simv在某些场景下时序行为看起来怪怪的。后来统一在编译命令里指定-timescale1ns/1ps内部不一致的告警消停了后仿时序也更符合预期。3.2 文件列表和依赖顺序VCS对文件列表的处理相对灵活。你可以直接命令行把所有文件写出来但项目大了以后没人这么干一般是写一个filelist.f文件每行一个源文件然后命令行用-f filelist.f读入。这里有个细节值得注意文件顺序会影响部分宏定义和include的解析。如果你在A文件里用include defines.vh而defines.vh和A在同一个目录下VCS通常能通过incdir指定include目录才能正确找到。不指定的话VCS默认搜索当前目录和编译命令中列出的路径并不自动搜索文件所在目录。这个坑非常常见尤其是从Windows上的开发环境迁到Linux时一堆include找不到头文件的错就是这么来的。我的标准写法是这样vcs -sverilog -timescale1ns/1ps -debug_accessall \ -f filelist.f -o simv \ -l compile.log \ incdir../rtl-f filelist.f把源码文件列表读进去incdir指定include搜索目录-o simv指定输出可执行文件名默认就是simv但指定一下方便区分多组编译-l compile.log保存编译日志。filelist.f里也可以直接写编译选项VCS会读进去当成命令行参数处理。常见做法是在filelist最开头写// filelist.f incdir../rtl -sverilog ../rtl/defines.vh ../rtl/cpu_top.v ../tb/tb_top.sv注意源文件的\续行符在filelist里完全不需要每行一个就行。写文件列表时还要尽量避免写绝对路径否则整个目录转移到别的机器时要重写。相对路径是基于执行vcs命令的目录来解析的所以最好固定在一个work目录下执行编译命令filelist里用相对路径指向源码。3.3 Makefile设计把复杂命令固化下来联合仿真的命令比较复杂每次手敲容易出错而且文件一多编译选项很难记住。我的建议是写一个Makefile把编译、仿真、清理、打开波形分别封装成target。这样一条命令做一件事回归测试时也方便。一个简化的Makefile长这样WORK_DIR : work TOP : tb_top VCS_OPTS : -sverilog -timescale1ns/1ps -debug_accessall incdir../rtl .PHONY: comp sim wave clean comp: mkdir -p $(WORK_DIR) cd $(WORK_DIR) vcs $(VCS_OPTS) -f ../tb/filelist.f -o simv -l compile.log sim: cd $(WORK_DIR) ./simv -l sim.log wave: cd $(WORK_DIR) verdi -f ../tb/filelist.f -ssf $(TOP).fsdb clean: rm -rf $(WORK_DIR)注意Verdi打开时也传filelist原因是Verdi需要加载源代码来对应波形层次。如果你不给filelist打开波形后信号列表能看到但source code窗口是空的追踪信号也没法跳到源码调试体验大打折扣。记住打开Verdi时一定要带源码的filelist和同一个fsdb文件这样才能做到波形与RTL联动追踪。4. 波形生成机制与Verdi侧调试技巧4.1 fsdb波形是怎么来的很多刚接触的人会有个误解以为只要装了Verdi仿真结束就自动有fsdb文件。其实fsdb的产生依赖仿真器在仿真过程中调用Verdi提供的PLI函数库。VCS编译时通过指定PLI库路径把Verdi的$fsdbDumpfile等系统函数注册进去仿真运行中这些函数才会生效。从命令上看VCS编译时通常要加这些-P $VERDI_HOME/share/PLI/VCS/LINUX64/novas.tab \ incdir$VERDI_HOME/share/PLI/VCS/LINUX64/pli.a或者用新版Verdi提供的更简洁写法-v $VERDI_HOME/share/PLI/VCS/LINUX64/verilog/novas_verilog.v不过现在很多版本的VCS已经内置了对fsdb的支持。你只要编译时给了-debug_accessalltestbench里直接调用$fsdbDumpfile和$fsdbDumpvars运行完一般就能在目录下看到fsdb文件。如果怎么都出不来波形再去检查上述两个PLI相关选项多半能找到原因。4.2 波形dump的控制函数写法testbench里通常这么写initial begin $fsdbDumpfile(tb_top.fsdb); $fsdbDumpvars(0, tb_top, all); end这里的0表示dump整个设计层次所有信号不限层级。如果只dump某个子模块可以写$fsdbDumpvars(0, tb_top.u_cpu)。all选项用于额外记录一些Verdi能识别的信息比如状态机的状态寄存器原始编码等这个对调试状态机特别有用。再扩展一下仿真时间长、信号特别多时全量dump会让fsdb文件膨胀到几十GBVerdi打开都费劲。这时候可以控制dump时机initial begin $fsdbDumpfile(tb_top.fsdb); $fsdbDumpvars; #10000 $fsdbDumpoff; // 前10us关闭dump因为这段是复位过程 #500000 $fsdbDumpon; // 到500us再打开dump end$fsdbDumpoff和$fsdbDumpon配合使用可以精确控制只dump关心的时间段大幅压缩波形文件体积。这个技巧在跑长仿真时尤其好用谁都希望波形文件小一点、Verdi加载快一点。4.3 Verdi里真正有效的调试路径波形dump出来后在Verdi里的操作流程我是这么走的第一步打开波形文件。verdi -f ../tb/filelist.f -ssf tb_top.fsdb -ssf参数指定fsdb波形文件。如果不指定也可以进入Verdi后在GUI里菜单选择打开新波形。第二步从波形窗口找到感兴趣的信号右键选择“Get Signals”选“Add to Waveform”就能把信号拖到波形窗口。光标选中一段区域后按z键可以放大按x键可以缩小。第三步Verdi最有价值的功能之一层次追踪Trace。当你看到一个信号发生了异常跳变选中它按快捷键或者右键选择“Trace Input Load”Verdi会回到源码中高亮那些驱动该信号的逻辑。再选中驱动逻辑的输入继续tracer可以一级一级找到根本原因。这套机制比我以前用ModelSim“在波形里瞪着信号猜”效率高太多了尤其是跨模块的bug用trace链路很快就能锁到某个状态机跳转到非法状态。如果你要在Verdi里查看信号在某个时刻的前一个事件即信号是什么事件导致这拍的选中信号后右键“Get Drivers”可以弹出一个信号驱动关系图把组合逻辑和时序逻辑的关系画出来。这种能力在定位“为什么这个信号同时被多个源驱动”或者“为什么信号在仿真开始阶段是X态”时非常有用。4.4 处理仿真中的X态问题在数字IC验证里最令人头疼的问题是仿真里信号出现X态未知态。RTL仿真里X态一般有两类来源一类是寄存器没有初始化上电就是X另一类是组合逻辑里出现了未定义的赋值比如case没有default、级联信号同时在两个always块里驱动等。后一类问题在Verdi里可以用一个非常实用的功能来排查波形窗口中默认会用红色高亮X态信号。你可以在波形窗口的“Bus/Array”显示设置里把X态的颜色调得更明显然后快速扫描哪个信号在哪个时间段变成了红色。选中该红色区域点击TraceVerdi会引导你到驱动源。如果是两个always块同时驱动同一个寄存器Verdi会在源码里标记Multiple Driver警告这个问题在仿真阶段一般不报错但综合时会有严重风险。关于X态还有一种常见于后仿场景的情况就是memory没有初始化导致大面积的X态蔓延。这个我会在下一节专门展开说因为它是VCS后仿里非常典型的坑。5. 后仿与memory初始化VCS中容易踩的硬骨头5.1 前仿和后仿在VCS使用上的差别先简单区分一下前仿和后仿。前仿又叫RTL仿真直接拿RTL代码跑功能验证不看门级延迟速度快。后仿则是把综合后的门级网表和SDF时序文件一起放进仿真器验证电路在真实门延迟和布线延迟下能不能正常工作。从VCS使用角度后仿和前仿的差异集中在以下几处需要读入网表文件通常是v或者vg格式一般也用一个filelist描述。需要把SDF文件通过$sdf_annotate读进来。标准单元库的仿真模型里通常有specify块用来标注时间参数VCS编译时要用选项保证specify信息不被跳过。门级仿真对复位和初始化更敏感因为综合后的网表没有initial语句或者说综合工具不会把initial语句综合成电路如果源设计里没有可靠的复位逻辑门级仿真一开始很多寄存器就是X态。后仿时我的VCS编译命令一般长这样vcs -sverilog -timescale1ns/1ps -debug_accessall \ -f ../../rtl/filelist.f \ -f ./netlist.f \ -v $STDCELL/verilog/slow_vdd1v8_basic_cells.v \ definePOST_SIM \ neg_tck \ -o simv_post其中definePOST_SIM用于让RTL testbench在编译时加入后仿相关分支比如加载sdf的initial块。-v选项是让仿真器在该库文件中查找在源代码中未例化定义的模块网表里引用的标准单元正好需要这种方式被解析到。这里注意区分-v和-y-y是指定库目录搜索-v是指定单个库文件两个都常用但别搞混了。5.2 memory初始化为什么后仿里寄存器全是X后仿里memory初始化的坑网上搜vcs后仿memory初始化能找到一堆问题就知道它有多普遍。综合工具会把代码里抽象的memory转换成一个或多个标准单元RAM模型。在门级仿真中RAM模型的初始输出往往是X因为它没有上电和复位逻辑。如果设计里没有对memory做专门的初始化比如load boot代码到instruction memory那么CPU取指时读到X态数据指令解码全部乱掉后仿从第一条指令就开始挂。很多人在RTL前仿里写了一套testbench用$readmemh把调试用的二进制文件加载到指令memory里跑得很开心。把同一套benchmark拿到后仿里跑发现加载的路径找不到了或者直接用force的方式在simv里对memory赋值发现根本写不进去。原因很简单$readmemh在RTL仿真里可以直接作用到你设计的memory数组上但后仿中用到的memory已经变成网表里的实例。RTL里的memory层次和后仿中RAM实例的层次不同$readmemh里写死的层次路径自然找不到。另外标准单元的仿真模型里可能并没有开放写入接口直接对实例内部节点force也容易导致仿真器行为异常。5.3 实际采用的几种初始化方案及对比我在实践过程中试过好几种办法各自适用场景不同方案一通过层次路径force/deposit在仿真前初始化在testbench里某个initial块中通过层次化引用来强制设置memory内容。initial begin force tb_top.u_soc.u_ram.mem[0] 32h00000000; force tb_top.u_soc.u_ram.mem[1] 32h00000001; release tb_top.u_soc.u_ram.mem[0]; // 如果元素很多一般要循环force再release end这种办法在小容量memory、几十个字以内可行。但如果指令memory有64KB甚至更大靠逐字force完全不现实。另外force和release的方式在半途操作时如果UVM验证环境或设计本身存在多个驱动源force操作容易和仿真器事件队列产生冲突我遇到过force之后release没生效导致仿真结果和RTL仿真不符的情况。方案二修改netlist层次的initial块比较工程化的做法是在门级网表中找到RAM实例在RAM实例内部增加一段initial块或用Verilog行为描述方式直接给内部寄存器数组加载数据。// 在网表或封装wrapper里补充一段初始化逻辑 reg [31:0] mem_core [0:4095]; initial begin $readmemh(boot.hex, mem_core); end显然直接改网表会污染原文件而且每换一次工艺库或重新综合就白改了。更合理的做法是把RAM模型封装在一个wrapper模块里wrapper内部例化标准单元RAM同时把initial块放在wrapper层级上仿真时只编译wrapper而不修改工艺库文件。当然用initial块这种方式本来就不是综合可综合的但注意它只用于仿真目的。在后仿中仿真时可以通过definePOST_SIM来控制是否编译这段代码。需要说明的是这是基于常见实践的补充方案不同工艺库的RAM仿真模型写法差异很大如果RAM模型本身没有开放memory阵列的层次路径wrapper方案也会受到局限。方案三在UVM环境的config_db里传memory初值如果你的验证环境用SystemVerilog/UVM搭的还有一种做法是在环境层直接维护一个shadow memory模型仿真进入后通过总线功能模型逐个写入RAM。这在功能上最接近真实加载流程因为它是通过实际写端口写入的时序行为和后仿目标一致。缺点也很明显写一个完整的加载序列慢尤其memory有几KB、几十KB时逐周期打激励会让仿真时间边长。不过这类问题可以通过在测试用例中直接对总线序列做burst优化来解决。综合来说我个人的建议是需要精确验证加载流程时用方案三需要快速跑通后仿时用方案二。方案一只适合极小容量临时瞄一眼可以千万别当主力方案。5.4 用$readmemh和$readmemb时的路径细节这里再说一个具体的坑。教材上给的$readmemh例子很简单$readmemh(file.hex, mem);。但到了复杂层次或者UVM环境里路径解析经常出问题。最直接的问题是文件路径是相对于哪个目录解析的VCS仿真时相对路径是相对于模拟运行simv时所在的工作目录也就是你敲./simv那个目录。如果你把simv放在work目录下而hex文件在另一个data目录里那么你写的boot.hex可能在work目录下找不到文件。VCS会报一个类似“Cannot open file”的warning然后$readmemh什么都不加载memory保持X或全0调试半天才发现是文件没读到。正确做法是给完整相对路径或者绝对路径。如果项目目录要从一台机器搬到另一台机器用获取环境变量的方式更可靠initial begin string mem_file; if ($value$plusargs(MEM_FILE%s, mem_file)) begin $readmemh(mem_file, tb_top.u_soc.u_ram.mem); end else begin $readmemh(../data/boot.hex, tb_top.u_soc.u_ram.mem); end end加一个$value$plusargs之后运行仿真时就能用./simv MEM_FILE./data/boot.hex来指定文件位置。调试异常时不用重新编译就能换文件非常方便。这种在仿真阶段通过plusarg传递参数的方式在后仿脚本里也是常见做法。6. 排错思路与实际案例编译、波形和仿真阶段的典型坑6.1 排查思想的顺序先环境再代码后脚本作为一个把VCSVerdi流程用了很久的人我总结出一个排错顺序遇到问题先按这个流程走能省很多时间。第一层查环境。which vcs、which verdi路径对不对License检查是否通过编译时报的错是command not found还是license相关的feature不够第二层查编译选项。缺了-sverilog报SystemVerilog语法错incdir没加报include文件找不到-v库没加导致标准单元模块未定义。第三层查文件列表。filelist里的顺序、相对路径基准目录、是否存在重复定义模块。第四层查仿真运行阶段。simv运行时可能在UVM的phase里就卡住了也可能跑起来但波形没dump出来这里要区分是编译问题还是运行问题。第五层查脚本和路径。尤其要注意$readmemh这类文件读取操作以及临时目录空间是否够大大fsdb文件写满/tmp会导致仿真中途挂掉。6.2 案例一编译成功但fsdb文件没生成这是我第一次跑联合仿真时遇到的问题卡了快一整天。场景vcs编译通过simv运行正常UVM打印也没有报错但工作目录下就是找不到fsdb文件。排查链路先确认testbench里面确实调用了$fsdbDumpfile。一看有。再确认编译时加了-debug_accessall。一看也加了。那为什么没生成fsdb然后我想起来检查运行日志发现日志中间有一行Warning类似“*W,PLIUNKG: Unrecognized system task $fsdbDumpfile”。这个warning非常重要它说明仿真器在编译testbench时根本没有识别出$fsdbDumpfile这个系统函数把它当成未知任务跳过了。为什么没识别因为VCS在编译的时候没有链接Verdi的PLI库。新版VCS在一些默认安装里能自动找到但我的环境里VCS和Verdi是两个独立安装的目录VCS不会主动知道Verdi的PLI库在哪里。解决方法是编译时显式加PLI相关参数vcs -sverilog -debug_accessall \ -P $VERDI_HOME/share/PLI/VCS/LINUX64/novas.tab \ $VERDI_HOME/share/PLI/VCS/LINUX64/pli.a \ -f filelist.f -o simv注意-P参数后面必须跟着.tab文件这是PLI函数的注册表然后跟着实际的静态库或动态库路径。不同版本的Verdi目录结构可能不同建议在安装完Verdi后用find $VERDI_HOME -name novas.tab确认路径。配好以后重新编译运行fsdb顺利生成。6.3 案例二VCS后仿中memory始终为X另一个印象深刻的坑后仿时所有信号都有波形唯独指令memory的数据一直是XCPU从第一拍开始就跳不到正常流程。当时我的编译命令和testbench里都写了$readmemh路径通过plusarg传进去了文件也确实存在。为什么还是X后来我把目光放到网表里标准单元RAM模型的内部层次和RTL数组的层次完全不同。在RTL里signal name叫u_ram.mem但在netlist里RAM被综合成了类似u_ram/inst/mem_reg_0_这样的单元结构不再存在一个名为mem的二维数组。这时候你对着RTL里的层次路径去$readmemh当然什么也加载不到。解决方式我看网上有人直接在编译时把RTL文件里用于后仿的memory模型排在netlist之前让仿真器优先解析RTL view的memory行为模型通常在工艺库的verilog模型文件夹里有behavioral或functional view里面保留了类似mem [0:4095]的寄存器数组定义然后在这个行为模型上加载$readmemh。具体做法编译顺序先编译库中RAM的行为级模型functional view再编译门级网表。在fsdb dump之前的initial块里通过层次路径引用到行为级模型的mem数组执行$readmemh。这个方案的前提是工艺库的RAM行为模型里真的有一个可加载的寄存器数组名。不同厂商的模型命名差异大需要先打开模型文件确认。如果实在不行就用我上面提到的wrapper方案把RAM包一层在wrapper里做初始化后再映射到输出端口。这样网表和RTL在仿真实例层次上保持一致初始化逻辑也有地方可放。6.4 案例三Verdi打开后看不到源码这个坑看起来小但新人几乎都会碰到fsdb加载正常波形窗口能看到信号跳变但source code窗口是空的点击信号也没法追踪到RTL代码。原因我在4.3节提过——启动Verdi时没有携带源文件列表。Verdi需要知道fsdb文件里各个信号对应的是哪些源文件才能建立“层层次映射”。解决办法是启动Verdi时带上filelistverdi -f ../tb/filelist.f -ssf tb_top.fsdb 如果文件已经在Verdi里了也可以用菜单“Tools - Source Code”里的功能手动添加源文件但每次都手动加载太麻烦了。建议把Verdi启动命令也写进Makefile里的wave目标一行搞定。6.5 各窗口功能的快速速查表功能需求Verdi里的位置/操作具体对象查看波形主窗口“Signals”窗格中选中信号后拖到波形窗口或使用“Add to Waveform”Waveform窗口放大缩小波形波形窗口中按z / x键或使用鼠标滚轮Waveform窗口追踪信号驱动源波形窗口选中信号后右键选择“Trace Input Load”或“Get Drivers”源码窗口/NTrace查看信号列表主窗口下方信号列表双击即可加入波形nWave窗口查看FSDB层次结构左上角“Hierarchy”树形结构点击模块可查看对应的信号和源码Hierarchy窗口比较两轮仿真的波形File - Compare加载另一份fsdb差异会被高亮nWave的Waveform Compare7. 把联合仿真跑顺的几条具体操作建议如果让我总结联合仿真真正顺手的感受“流程固定”和“脚本固化”比学会某一条命令更重要。下面这些建议正好对应真实项目里会遇到的几个环节。第一编译选项不要每次手敲。把所有常用选项固化到Makefile里生成simv前先make clean一下旧产物免得旧文件缓存干扰。VCS的增量编译特性在多次迭代时能提升速度但有时候旧的时间戳缓存会引入奇怪的告警。如果编译时间突然和上次不一致可以先把work/目录彻底清一遍再编译。第二波形和日志分开保存文件名带上用例名和时间戳。比如sim_run_$(CASE)_$(DATE).fsdb。这样多个用例并行跑回归时波形不会互相覆盖。第三后仿里memory初始化文件路径用plusarg传入而不是在testbench里写死。这条我在5.4节演示过代码。真正跑了多次回归后就会体会到这种灵活性的价值——某个用例要换另一份初始化镜像只要在回归脚本里改参数不需要改任何RTL和验证代码。第四Verdi打开时把fsdb和filelist一次带上。别再人工加载源文件了容易漏掉某个文件导致整体层次映射异常直接走Makefile一条命令。第五排查问题的时候先看日志中是否有PLI相关的warning。很多fsdb和memory初始化的问题都跟PLI版本、路径有关而不是你的代码逻辑错了。编译日志里出现Unrecognized system task或Cannot find PLI等警告基本可以确定问题出在工具链衔接上。8. 回归一下从编译到波形调试最简单的完整流程最后给一个最简可跑的流程方便你验证环境是否正常。假设有最小文件../rtl/top.sv一个简单的计数器../tb/tb_top.svtestbench例化top驱动时钟和复位并在initial中dump fsdb。编译命令cd work vcs -sverilog -debug_accessall \ ../rtl/top.sv ../tb/tb_top.sv -o simv -l compile.log运行./simv -l sim.log fsdbauto如果testbench里有initial begin $fsdbDumpfile(tb_top.fsdb); $fsdbDumpvars; end运行结束后work目录会生成tb_top.fsdb。然后verdi -f ../tb/filelist.f -ssf tb_top.fsdb 如果filelist还没有准备好也可以这样启动verdi ../rtl/top.sv ../tb/tb_top.sv -ssf tb_top.fsdb 看到波形窗口能展开信号、源码窗口能高亮对应行这个最小的联合仿真流程就通了。再往后无论是引入更复杂的UVM环境还是进入门级后仿框架都不变VCS负责跑Verdi负责看你负责在两者之间找到那个信号跳变的瞬间。我这里开场时提到“搭环境折腾了很久”现在回头看真正值得花时间的地方不是工具安装本身而是理解编译、仿真、波形这条链路上每个环节的输入输出。把这条链路打通后面切到任何新项目都只是换文件列表和编译选项的事。希望这些经验能给你省下一些我当年浪费掉的时间。