1. 数字芯片验证环境搭建的核心思路数字IC验证这行干久了你会发现一个很有意思的现象前端设计工程师写RTL的时候觉得自己逻辑天衣无缝后端工程师跑综合的时候觉得时序约束已经卡到极限而验证工程师夹在中间手里攥着仿真器和波形查看器像个侦探一样在信号跳变里找线索。VCS加Verdi这套组合就是绝大多数验证工程师手里最顺手的“放大镜”和“显微镜”。这套流程解决的核心问题其实很朴素你写了一段Verilog或者SystemVerilog代码怎么知道它功能对不对靠仿真。仿真跑出来的结果是一堆信号随时间变化的数值怎么直观地看靠波形。VCS负责把代码编译成可执行的仿真模型并跑出结果Verdi负责把结果以图形化波形的方式呈现出来让你能像看心电图一样观察每一个信号的跳动。听起来简单但实际用起来从环境变量配置到FSDB文件生成从编译选项到波形加载每一步都有坑。这篇文章适合谁看如果你是刚入行的验证新人正在被Makefile里一堆编译选项搞得头晕或者你是设计工程师偶尔需要自己跑个仿真验证一下小模块又或者你是学生正在做课程项目需要用到VCS和Verdi——那这篇内容就是给你写的。我会把整个流程拆开揉碎从最基础的环境准备讲到实际调试中的问题排查尽量让每一步都有据可循。需要提前说明的是VCS和Verdi都是Synopsys公司的商业工具本文假设你所在的环境已经合法获取了相关授权。整个流程的核心关键词包括VCS编译、Verdi加载、FSDB波形、联合仿真调试这些概念会贯穿全文。2. 环境准备与工具链配置2.1 工具版本匹配与路径设置VCS和Verdi的版本匹配是个容易被忽视但极其重要的问题。我见过太多次因为版本不匹配导致FSDB文件生成失败或者Verdi加载波形时直接崩溃的情况。一般来说VCS和Verdi最好使用同一大版本号比如VCS 2020.03配Verdi 2020.03这样底层的FSDB库接口才能对得上。如果你用的是公司服务器通常这些工具已经预装好了你需要做的就是确认版本并设置好环境变量。环境变量的设置方式取决于你用的shell类型。如果是bash在.bashrc或者.bash_profile里添加如果是csh或者tcsh在.cshrc里设置。核心需要设置的变量包括VCS_HOME指向VCS安装目录VERDI_HOME指向Verdi安装目录然后把它们的bin目录加到PATH里。另外LD_LIBRARY_PATH也要包含Verdi的库路径否则Verdi启动时可能找不到动态链接库。export VCS_HOME/tools/synopsys/vcs/2020.03 export VERDI_HOME/tools/synopsys/verdi/2020.03 export PATH$VCS_HOME/bin:$VERDI_HOME/bin:$PATH export LD_LIBRARY_PATH$VERDI_HOME/share/PLI/VCS/LINUX64:$LD_LIBRARY_PATH设置完之后用which vcs和which verdi确认一下路径是否正确。有时候服务器上装了多个版本PATH的顺序决定了你调用的是哪个版本这个细节在多人共用的服务器上尤其要注意。2.2 编译流程与关键选项解析VCS的编译流程本质上分两步分析和精化。分析阶段把Verilog/SystemVerilog源代码解析成中间表示精化阶段把中间表示转换成可执行的仿真二进制文件。你可以用一条命令完成也可以分步执行。对于日常调试我习惯用一条命令搞定把常用选项都写进Makefile里。最基础的编译命令长这样vcs -full64 -sverilog -debug_accessall \ -timescale1ns/1ps \ -f filelist.f \ -o simv这里每个选项都有讲究。-full64表示编译64位版本现在基本是标配了。-sverilog开启SystemVerilog支持如果你的代码里用了SV特性就必须加。-debug_accessall是生成调试信息的关键没有这个选项Verdi就没法加载波形和源码做联合调试。-timescale设置时间单位和精度这个要和你的testbench保持一致否则时序会对不上。-f filelist.f指定源文件列表把所有需要编译的.v和.sv文件路径写进去。-o simv指定输出的可执行文件名默认就是simv。注意-debug_accessall会显著增加编译时间和生成的仿真文件大小但在调试阶段这是必须的。等验证环境稳定后可以换成-debug_accesspp只保留部分调试能力来加速编译。2.3 FSDB波形生成的配置方法FSDB是Verdi专用的波形格式相比VCD格式它的压缩率高得多同样规模的仿真FSDB文件可能只有VCD的十分之一大小而且Verdi加载FSDB的速度也快很多。要生成FSDB波形需要在testbench里调用Verdi提供的PLI接口函数。最常用的方式是在initial块里调用$fsdbDumpfile和$fsdbDumpvarsinitial begin $fsdbDumpfile(wave.fsdb); $fsdbDumpvars(0, tb_top); end$fsdbDumpfile指定波形文件名$fsdbDumpvars的第一个参数是dump层级0表示dump所有层级第二个参数指定从哪个模块开始dump。如果你只想看特定模块的信号可以把层级设小一点比如$fsdbDumpvars(1, tb_top.u_dut)只dump DUT内部一层。编译的时候需要链接Verdi的PLI库在VCS命令里加上vcs -full64 -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这两个文件novas.tab和pli.a就是Verdi提供的PLI接口没有它们仿真器就不认识$fsdbDumpfile这些系统函数编译时会报undefined system task的错误。3. 联合仿真实操全流程3.1 从编译到仿真的完整操作步骤假设你有一个简单的设计一个8位计数器加一个testbench。目录结构大概是这样的rtl/放设计文件tb/放testbenchfilelist.f列出所有源文件Makefile定义编译和仿真规则。第一步确认filelist.f内容正确./rtl/counter.v ./tb/tb_counter.v第二步执行编译。在终端里运行make compile或者直接敲vcs命令。编译过程中VCS会输出分析进度如果代码有语法错误会在这里报出来。编译成功后会在当前目录生成simv可执行文件和csrc目录。第三步运行仿真。执行./simv或者make run。仿真开始后testbench里的$fsdbDumpfile会被调用在当前目录生成wave.fsdb文件。仿真结束时终端会打印仿真时间和结束状态。第四步启动Verdi查看波形。执行verdi -ssf wave.fsdb Verdi启动后会自动加载波形文件。在Verdi的nWave窗口里你可以把信号拖进来观察也可以用Get Signals按钮浏览设计层级。整个流程跑通一次之后你会发现其实就三步编译、仿真、看波形。但每一步的细节决定了你调试的效率。3.2 Verdi波形调试的核心操作技巧Verdi的nWave窗口是你看波形的主战场但很多人只用了它十分之一的功能。我分享几个日常调试中高频使用的操作。信号分组管理。当你dump了上百个信号全堆在波形窗口里根本没法看。Verdi支持创建Group你可以按功能模块把信号分组比如时钟复位一组、数据通路一组、控制信号一组。创建Group的快捷键是CtrlG把选中的信号加进去。这样你可以在不同Group之间快速切换不用在信号列表里翻来翻去。光标测量。按ShiftC创建光标可以创建多个光标Verdi会自动计算两个光标之间的时间差。这个功能在检查时序关系时特别有用比如你想知道从请求信号拉高到应答信号拉高之间隔了多少个时钟周期放两个光标一量就出来了。信号搜索。设计大了之后在层级树里找信号很费劲。Verdi支持通配符搜索在信号列表上方的搜索框里输入*data*就能过滤出所有名字里带data的信号。还支持按值搜索比如你想找某个时刻值为8hFF的信号可以用Search - Signal by Value。实操心得在Verdi里按CtrlW可以把当前波形窗口的配置保存成.rc文件下次打开同样类型的调试可以加载这个配置省去重新拖信号和分组的时间。这个技巧在反复调试同一个模块时特别省事。3.3 基于波形的调试案例分析光说操作可能还是抽象我拿一个实际调试中遇到的案例来说。有一次验证一个SPI Master模块仿真跑完了波形也dump出来了但读数据始终不对。打开Verdi先把SPI的四个信号SCLK、MOSI、MISO、CS_N拖出来再配上时钟和复位。观察波形发现CS_N拉低之后SCLK开始翻转MOSI上的数据看起来也正常但MISO上采回来的数据总是比预期晚一个周期。用光标量了一下SCLK上升沿和MISO数据变化的时间关系发现MISO的数据变化发生在SCLK上升沿之后大约2ns而testbench里的采样逻辑是在SCLK上升沿采的这时候数据还没稳定。问题定位到了testbench的采样时机不对。解决方案是在testbench里把采样点改成SCLK下降沿或者在上升沿之后加一个小延迟再采样。改完重新编译仿真波形上MISO的数据在SCLK上升沿时已经稳定了读数据正确。这个案例说明的是Verdi不只是用来看信号高低电平的更重要的是看信号之间的时间关系。很多时候bug不是逻辑错了而是时序对不上而时序问题在代码里很难看出来在波形上一目了然。4. 常见问题排查与避坑指南4.1 编译阶段典型报错与解决编译阶段最常见的问题就是找不到文件或者语法错误。如果VCS报Error-[SFC] Source file not found说明filelist.f里的路径不对。注意filelist.f里的路径是相对于你执行vcs命令的目录不是相对于filelist.f文件本身。如果你在sim/目录下执行vcsfilelist.f里写../rtl/counter.v才是对的。另一个高频错误是Error-[URMI] Unresolved module意思是某个模块被例化了但找不到定义。检查一下filelist.f里是不是漏了某个文件或者模块名拼写是不是一致。Verilog是大小写敏感的Counter和counter是两个不同的模块。如果报Error-[ICPD] Invalid compiler directive通常是timescale或者define这类编译指令写错了位置或者格式。timescale必须写在模块外面而且格式必须是1ns/1ps这种不能写成1ns/1ps以外的形式。还有一种情况是PLI相关的错误比如undefined system task $fsdbDumpfile。这说明编译时没有正确链接Verdi的PLI库检查-P选项后面的novas.tab路径和pli.a路径是否正确以及LD_LIBRARY_PATH里是否包含了Verdi的库目录。4.2 仿真阶段异常与波形加载问题仿真跑起来了但波形文件没生成这是很常见的问题。先检查testbench里有没有调用$fsdbDumpfile再看调用时机对不对。如果$fsdbDumpfile放在了一个永远不会执行的initial块里那自然不会有波形。另外确认仿真正常结束了如果仿真中途崩溃FSDB文件可能不完整。Verdi加载FSDB时报FSDB file is corrupted多半是仿真异常终止导致的。可以尝试在仿真结束前调用$fsdbDumpoff把波形文件正常关闭。如果仿真时间很长FSDB文件可能非常大Verdi加载时会很慢甚至卡死。这时候可以用$fsdbDumpvars的层级参数限制dump范围只dump你关心的模块。还有一种情况是Verdi打开了但波形窗口是空的。检查一下-ssf选项后面的文件名对不对以及FSDB文件是不是在当前目录。如果FSDB文件在别的路径要写全路径。4.3 常见问题速查表问题现象可能原因排查方向编译报找不到源文件filelist路径错误确认路径相对于执行目录编译报未定义模块文件遗漏或模块名拼写错误检查filelist和模块名大小写编译报未定义系统任务PLI库未链接检查-P选项和LD_LIBRARY_PATH仿真无FSDB生成testbench未调用dump函数检查$fsdbDumpfile调用Verdi加载波形报错FSDB文件损坏检查仿真是否正常结束Verdi波形窗口空白文件路径错误确认-ssf后的文件名和路径波形信号不全dump层级不够调整$fsdbDumpvars层级参数仿真速度过慢dump信号过多缩小dump范围或使用fsdbautoflush4.4 提升调试效率的独家经验第一个经验是关于Makefile的。把编译、仿真、看波形三个步骤写成Makefile的三个target用make all一键跑完。Makefile里还可以加一个cleantarget清理生成的临时文件。这样你每次改完代码只需要敲一个命令不用重复输入一长串vcs选项。第二个经验是关于波形文件管理的。仿真跑多次之后目录里会堆满各种fsdb文件建议按时间戳或者版本号命名比如wave_20240101_120000.fsdb。在testbench里可以用$sformatf动态生成文件名把仿真时间或者随机种子编进去。第三个经验是关于Verdi的启动速度。Verdi首次启动会比较慢因为它要加载各种库和字体。如果你只是快速看一下波形可以用verdi -ssf wave.fsdb -nologo跳过启动画面。另外把常用的信号分组保存成.rc文件下次直接加载能省不少时间。第四个经验是关于调试思路的。不要一上来就把所有信号都dump出来那样波形文件巨大Verdi加载慢你找信号也费劲。正确的做法是先dump顶层和关键模块的信号定位到问题模块后再针对性地dump该模块内部信号。这种“由粗到细”的调试策略比一次性dump所有信号效率高得多。5. 进阶技巧与效率提升5.1 自动化脚本与批处理模式当你需要反复跑大量测试用例时手动敲命令就不现实了。VCS支持批处理模式可以把编译和仿真写成shell脚本或者Python脚本自动执行。一个典型的批处理脚本会遍历所有测试用例对每个用例执行编译、仿真、检查结果、保存波形最后生成一份汇总报告。Verdi也支持命令行模式可以用verdi -ssf wave.fsdb -play script.rc的方式自动加载波形并执行预设的调试脚本。这个功能在回归测试后快速筛查失败用例时特别有用。你可以写一个脚本自动打开每个失败用例的波形把关键信号拖出来截图保存然后关闭。这样你只需要看截图就能快速判断问题类型。5.2 与其他工具的协同使用VCS和Verdi这套流程并不是孤立的。在实际项目中你可能会用到其他工具配合。比如用Python脚本解析FSDB文件提取特定信号的数据做统计分析或者用MATLAB对仿真结果做算法层面的验证。FSDB文件本身是二进制格式但Verdi提供了fsdb2vcd工具可以把FSDB转成VCD格式VCD是文本格式用Python或者MATLAB都很容易解析。另外如果你做的是数模混合仿真VCS可以和模拟仿真器协同工作。数字部分用VCS跑模拟部分用SPICE类仿真器跑通过接口交换数据。这种场景下波形的联合调试会更复杂但基本思路是一样的先确保每个部分单独跑通再联合调试。5.3 性能优化与资源管理仿真速度是验证工程师永远的痛。一个大型SoC的仿真可能跑几个小时甚至几天优化仿真速度能直接缩短项目周期。除了前面提到的缩小dump范围还有几个手段可以用。使用fsdbautoflush选项可以让FSDB文件在仿真过程中定期刷新避免仿真崩溃时丢失全部波形数据。但autoflush会稍微降低仿真速度需要权衡。另一个选项是fsdbparallel利用多核并行写波形文件对大容量dump场景有加速效果。编译阶段可以用-j选项开启多线程编译比如-j8用8个线程并行分析源文件。对于大型设计这能显著缩短编译时间。另外增量编译也是个好习惯只重新编译修改过的文件VCS会自动检测哪些文件变了。注意增量编译虽然快但偶尔会出现编译结果不一致的问题。如果遇到莫名其妙的仿真行为异常先试试全量编译排除增量编译的干扰。6. 从波形到代码的闭环调试思维6.1 建立信号与代码的映射关系Verdi最强大的功能之一是可以把波形和源代码关联起来。在nWave窗口里选中一个信号按CtrlShiftL或者右键选择Trace to SourceVerdi会自动打开源代码窗口并定位到该信号被赋值的那一行。反过来在源代码窗口里选中一个信号也可以直接把它加到波形窗口里。这个功能在调试时极其高效。你看到波形上某个信号值不对直接跳转到源代码看赋值逻辑马上就能定位到问题。不用在代码里搜索信号名也不用在波形里翻层级树。我个人的习惯是调试时始终开着源代码窗口和波形窗口两个窗口并排看到异常波形就跳代码改完代码重新编译仿真再看波形形成闭环。6.2 基于断点和单步的精细调试除了看波形VCS还支持在仿真过程中设置断点和单步执行。在编译时加上-debug_accessall之后可以用verdi -ssf wave.fsdb -dbg启动调试模式或者在仿真时用UCLIUnified Command Line Interface交互式地控制仿真。UCLI里常用的命令包括stop设置断点、run继续执行、step单步执行、examine查看信号值。这种方式适合调试那些波形上看不出明显异常的复杂逻辑问题比如状态机跑飞了你可以单步跟踪状态转移看每一步的跳转条件是否满足。不过UCLI的学习曲线比较陡日常调试中大部分问题用波形就能解决。我建议先把波形调试练熟遇到波形搞不定的问题再上UCLI。6.3 调试记录与知识沉淀最后说一个容易被忽视但长期收益很高的事情记录调试过程。每次解决一个bug把问题现象、排查过程、根本原因、解决方案记下来。可以用简单的文本文件也可以用公司内部的wiki。积累多了之后你会发现很多问题是重复出现的下次再遇到类似现象翻一下记录就能快速定位。我自己的习惯是在项目目录下建一个debug_log.md每次调试都往里加一条记录。格式很简单日期、问题描述、排查步骤、根因、修复方法。这个习惯坚持了几年之后我发现自己排查问题的速度明显比新人快因为很多坑我已经踩过了知道往哪个方向查。VCS加Verdi这套流程本身并不复杂核心就是编译、仿真、看波形三步。但每一步的细节和技巧决定了你是花十分钟解决问题还是花一天。工具是死的人是活的多动手多总结自然就熟练了。
VCS与Verdi联合仿真调试：从环境搭建到波形分析的完整指南
1. 数字芯片验证环境搭建的核心思路数字IC验证这行干久了你会发现一个很有意思的现象前端设计工程师写RTL的时候觉得自己逻辑天衣无缝后端工程师跑综合的时候觉得时序约束已经卡到极限而验证工程师夹在中间手里攥着仿真器和波形查看器像个侦探一样在信号跳变里找线索。VCS加Verdi这套组合就是绝大多数验证工程师手里最顺手的“放大镜”和“显微镜”。这套流程解决的核心问题其实很朴素你写了一段Verilog或者SystemVerilog代码怎么知道它功能对不对靠仿真。仿真跑出来的结果是一堆信号随时间变化的数值怎么直观地看靠波形。VCS负责把代码编译成可执行的仿真模型并跑出结果Verdi负责把结果以图形化波形的方式呈现出来让你能像看心电图一样观察每一个信号的跳动。听起来简单但实际用起来从环境变量配置到FSDB文件生成从编译选项到波形加载每一步都有坑。这篇文章适合谁看如果你是刚入行的验证新人正在被Makefile里一堆编译选项搞得头晕或者你是设计工程师偶尔需要自己跑个仿真验证一下小模块又或者你是学生正在做课程项目需要用到VCS和Verdi——那这篇内容就是给你写的。我会把整个流程拆开揉碎从最基础的环境准备讲到实际调试中的问题排查尽量让每一步都有据可循。需要提前说明的是VCS和Verdi都是Synopsys公司的商业工具本文假设你所在的环境已经合法获取了相关授权。整个流程的核心关键词包括VCS编译、Verdi加载、FSDB波形、联合仿真调试这些概念会贯穿全文。2. 环境准备与工具链配置2.1 工具版本匹配与路径设置VCS和Verdi的版本匹配是个容易被忽视但极其重要的问题。我见过太多次因为版本不匹配导致FSDB文件生成失败或者Verdi加载波形时直接崩溃的情况。一般来说VCS和Verdi最好使用同一大版本号比如VCS 2020.03配Verdi 2020.03这样底层的FSDB库接口才能对得上。如果你用的是公司服务器通常这些工具已经预装好了你需要做的就是确认版本并设置好环境变量。环境变量的设置方式取决于你用的shell类型。如果是bash在.bashrc或者.bash_profile里添加如果是csh或者tcsh在.cshrc里设置。核心需要设置的变量包括VCS_HOME指向VCS安装目录VERDI_HOME指向Verdi安装目录然后把它们的bin目录加到PATH里。另外LD_LIBRARY_PATH也要包含Verdi的库路径否则Verdi启动时可能找不到动态链接库。export VCS_HOME/tools/synopsys/vcs/2020.03 export VERDI_HOME/tools/synopsys/verdi/2020.03 export PATH$VCS_HOME/bin:$VERDI_HOME/bin:$PATH export LD_LIBRARY_PATH$VERDI_HOME/share/PLI/VCS/LINUX64:$LD_LIBRARY_PATH设置完之后用which vcs和which verdi确认一下路径是否正确。有时候服务器上装了多个版本PATH的顺序决定了你调用的是哪个版本这个细节在多人共用的服务器上尤其要注意。2.2 编译流程与关键选项解析VCS的编译流程本质上分两步分析和精化。分析阶段把Verilog/SystemVerilog源代码解析成中间表示精化阶段把中间表示转换成可执行的仿真二进制文件。你可以用一条命令完成也可以分步执行。对于日常调试我习惯用一条命令搞定把常用选项都写进Makefile里。最基础的编译命令长这样vcs -full64 -sverilog -debug_accessall \ -timescale1ns/1ps \ -f filelist.f \ -o simv这里每个选项都有讲究。-full64表示编译64位版本现在基本是标配了。-sverilog开启SystemVerilog支持如果你的代码里用了SV特性就必须加。-debug_accessall是生成调试信息的关键没有这个选项Verdi就没法加载波形和源码做联合调试。-timescale设置时间单位和精度这个要和你的testbench保持一致否则时序会对不上。-f filelist.f指定源文件列表把所有需要编译的.v和.sv文件路径写进去。-o simv指定输出的可执行文件名默认就是simv。注意-debug_accessall会显著增加编译时间和生成的仿真文件大小但在调试阶段这是必须的。等验证环境稳定后可以换成-debug_accesspp只保留部分调试能力来加速编译。2.3 FSDB波形生成的配置方法FSDB是Verdi专用的波形格式相比VCD格式它的压缩率高得多同样规模的仿真FSDB文件可能只有VCD的十分之一大小而且Verdi加载FSDB的速度也快很多。要生成FSDB波形需要在testbench里调用Verdi提供的PLI接口函数。最常用的方式是在initial块里调用$fsdbDumpfile和$fsdbDumpvarsinitial begin $fsdbDumpfile(wave.fsdb); $fsdbDumpvars(0, tb_top); end$fsdbDumpfile指定波形文件名$fsdbDumpvars的第一个参数是dump层级0表示dump所有层级第二个参数指定从哪个模块开始dump。如果你只想看特定模块的信号可以把层级设小一点比如$fsdbDumpvars(1, tb_top.u_dut)只dump DUT内部一层。编译的时候需要链接Verdi的PLI库在VCS命令里加上vcs -full64 -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这两个文件novas.tab和pli.a就是Verdi提供的PLI接口没有它们仿真器就不认识$fsdbDumpfile这些系统函数编译时会报undefined system task的错误。3. 联合仿真实操全流程3.1 从编译到仿真的完整操作步骤假设你有一个简单的设计一个8位计数器加一个testbench。目录结构大概是这样的rtl/放设计文件tb/放testbenchfilelist.f列出所有源文件Makefile定义编译和仿真规则。第一步确认filelist.f内容正确./rtl/counter.v ./tb/tb_counter.v第二步执行编译。在终端里运行make compile或者直接敲vcs命令。编译过程中VCS会输出分析进度如果代码有语法错误会在这里报出来。编译成功后会在当前目录生成simv可执行文件和csrc目录。第三步运行仿真。执行./simv或者make run。仿真开始后testbench里的$fsdbDumpfile会被调用在当前目录生成wave.fsdb文件。仿真结束时终端会打印仿真时间和结束状态。第四步启动Verdi查看波形。执行verdi -ssf wave.fsdb Verdi启动后会自动加载波形文件。在Verdi的nWave窗口里你可以把信号拖进来观察也可以用Get Signals按钮浏览设计层级。整个流程跑通一次之后你会发现其实就三步编译、仿真、看波形。但每一步的细节决定了你调试的效率。3.2 Verdi波形调试的核心操作技巧Verdi的nWave窗口是你看波形的主战场但很多人只用了它十分之一的功能。我分享几个日常调试中高频使用的操作。信号分组管理。当你dump了上百个信号全堆在波形窗口里根本没法看。Verdi支持创建Group你可以按功能模块把信号分组比如时钟复位一组、数据通路一组、控制信号一组。创建Group的快捷键是CtrlG把选中的信号加进去。这样你可以在不同Group之间快速切换不用在信号列表里翻来翻去。光标测量。按ShiftC创建光标可以创建多个光标Verdi会自动计算两个光标之间的时间差。这个功能在检查时序关系时特别有用比如你想知道从请求信号拉高到应答信号拉高之间隔了多少个时钟周期放两个光标一量就出来了。信号搜索。设计大了之后在层级树里找信号很费劲。Verdi支持通配符搜索在信号列表上方的搜索框里输入*data*就能过滤出所有名字里带data的信号。还支持按值搜索比如你想找某个时刻值为8hFF的信号可以用Search - Signal by Value。实操心得在Verdi里按CtrlW可以把当前波形窗口的配置保存成.rc文件下次打开同样类型的调试可以加载这个配置省去重新拖信号和分组的时间。这个技巧在反复调试同一个模块时特别省事。3.3 基于波形的调试案例分析光说操作可能还是抽象我拿一个实际调试中遇到的案例来说。有一次验证一个SPI Master模块仿真跑完了波形也dump出来了但读数据始终不对。打开Verdi先把SPI的四个信号SCLK、MOSI、MISO、CS_N拖出来再配上时钟和复位。观察波形发现CS_N拉低之后SCLK开始翻转MOSI上的数据看起来也正常但MISO上采回来的数据总是比预期晚一个周期。用光标量了一下SCLK上升沿和MISO数据变化的时间关系发现MISO的数据变化发生在SCLK上升沿之后大约2ns而testbench里的采样逻辑是在SCLK上升沿采的这时候数据还没稳定。问题定位到了testbench的采样时机不对。解决方案是在testbench里把采样点改成SCLK下降沿或者在上升沿之后加一个小延迟再采样。改完重新编译仿真波形上MISO的数据在SCLK上升沿时已经稳定了读数据正确。这个案例说明的是Verdi不只是用来看信号高低电平的更重要的是看信号之间的时间关系。很多时候bug不是逻辑错了而是时序对不上而时序问题在代码里很难看出来在波形上一目了然。4. 常见问题排查与避坑指南4.1 编译阶段典型报错与解决编译阶段最常见的问题就是找不到文件或者语法错误。如果VCS报Error-[SFC] Source file not found说明filelist.f里的路径不对。注意filelist.f里的路径是相对于你执行vcs命令的目录不是相对于filelist.f文件本身。如果你在sim/目录下执行vcsfilelist.f里写../rtl/counter.v才是对的。另一个高频错误是Error-[URMI] Unresolved module意思是某个模块被例化了但找不到定义。检查一下filelist.f里是不是漏了某个文件或者模块名拼写是不是一致。Verilog是大小写敏感的Counter和counter是两个不同的模块。如果报Error-[ICPD] Invalid compiler directive通常是timescale或者define这类编译指令写错了位置或者格式。timescale必须写在模块外面而且格式必须是1ns/1ps这种不能写成1ns/1ps以外的形式。还有一种情况是PLI相关的错误比如undefined system task $fsdbDumpfile。这说明编译时没有正确链接Verdi的PLI库检查-P选项后面的novas.tab路径和pli.a路径是否正确以及LD_LIBRARY_PATH里是否包含了Verdi的库目录。4.2 仿真阶段异常与波形加载问题仿真跑起来了但波形文件没生成这是很常见的问题。先检查testbench里有没有调用$fsdbDumpfile再看调用时机对不对。如果$fsdbDumpfile放在了一个永远不会执行的initial块里那自然不会有波形。另外确认仿真正常结束了如果仿真中途崩溃FSDB文件可能不完整。Verdi加载FSDB时报FSDB file is corrupted多半是仿真异常终止导致的。可以尝试在仿真结束前调用$fsdbDumpoff把波形文件正常关闭。如果仿真时间很长FSDB文件可能非常大Verdi加载时会很慢甚至卡死。这时候可以用$fsdbDumpvars的层级参数限制dump范围只dump你关心的模块。还有一种情况是Verdi打开了但波形窗口是空的。检查一下-ssf选项后面的文件名对不对以及FSDB文件是不是在当前目录。如果FSDB文件在别的路径要写全路径。4.3 常见问题速查表问题现象可能原因排查方向编译报找不到源文件filelist路径错误确认路径相对于执行目录编译报未定义模块文件遗漏或模块名拼写错误检查filelist和模块名大小写编译报未定义系统任务PLI库未链接检查-P选项和LD_LIBRARY_PATH仿真无FSDB生成testbench未调用dump函数检查$fsdbDumpfile调用Verdi加载波形报错FSDB文件损坏检查仿真是否正常结束Verdi波形窗口空白文件路径错误确认-ssf后的文件名和路径波形信号不全dump层级不够调整$fsdbDumpvars层级参数仿真速度过慢dump信号过多缩小dump范围或使用fsdbautoflush4.4 提升调试效率的独家经验第一个经验是关于Makefile的。把编译、仿真、看波形三个步骤写成Makefile的三个target用make all一键跑完。Makefile里还可以加一个cleantarget清理生成的临时文件。这样你每次改完代码只需要敲一个命令不用重复输入一长串vcs选项。第二个经验是关于波形文件管理的。仿真跑多次之后目录里会堆满各种fsdb文件建议按时间戳或者版本号命名比如wave_20240101_120000.fsdb。在testbench里可以用$sformatf动态生成文件名把仿真时间或者随机种子编进去。第三个经验是关于Verdi的启动速度。Verdi首次启动会比较慢因为它要加载各种库和字体。如果你只是快速看一下波形可以用verdi -ssf wave.fsdb -nologo跳过启动画面。另外把常用的信号分组保存成.rc文件下次直接加载能省不少时间。第四个经验是关于调试思路的。不要一上来就把所有信号都dump出来那样波形文件巨大Verdi加载慢你找信号也费劲。正确的做法是先dump顶层和关键模块的信号定位到问题模块后再针对性地dump该模块内部信号。这种“由粗到细”的调试策略比一次性dump所有信号效率高得多。5. 进阶技巧与效率提升5.1 自动化脚本与批处理模式当你需要反复跑大量测试用例时手动敲命令就不现实了。VCS支持批处理模式可以把编译和仿真写成shell脚本或者Python脚本自动执行。一个典型的批处理脚本会遍历所有测试用例对每个用例执行编译、仿真、检查结果、保存波形最后生成一份汇总报告。Verdi也支持命令行模式可以用verdi -ssf wave.fsdb -play script.rc的方式自动加载波形并执行预设的调试脚本。这个功能在回归测试后快速筛查失败用例时特别有用。你可以写一个脚本自动打开每个失败用例的波形把关键信号拖出来截图保存然后关闭。这样你只需要看截图就能快速判断问题类型。5.2 与其他工具的协同使用VCS和Verdi这套流程并不是孤立的。在实际项目中你可能会用到其他工具配合。比如用Python脚本解析FSDB文件提取特定信号的数据做统计分析或者用MATLAB对仿真结果做算法层面的验证。FSDB文件本身是二进制格式但Verdi提供了fsdb2vcd工具可以把FSDB转成VCD格式VCD是文本格式用Python或者MATLAB都很容易解析。另外如果你做的是数模混合仿真VCS可以和模拟仿真器协同工作。数字部分用VCS跑模拟部分用SPICE类仿真器跑通过接口交换数据。这种场景下波形的联合调试会更复杂但基本思路是一样的先确保每个部分单独跑通再联合调试。5.3 性能优化与资源管理仿真速度是验证工程师永远的痛。一个大型SoC的仿真可能跑几个小时甚至几天优化仿真速度能直接缩短项目周期。除了前面提到的缩小dump范围还有几个手段可以用。使用fsdbautoflush选项可以让FSDB文件在仿真过程中定期刷新避免仿真崩溃时丢失全部波形数据。但autoflush会稍微降低仿真速度需要权衡。另一个选项是fsdbparallel利用多核并行写波形文件对大容量dump场景有加速效果。编译阶段可以用-j选项开启多线程编译比如-j8用8个线程并行分析源文件。对于大型设计这能显著缩短编译时间。另外增量编译也是个好习惯只重新编译修改过的文件VCS会自动检测哪些文件变了。注意增量编译虽然快但偶尔会出现编译结果不一致的问题。如果遇到莫名其妙的仿真行为异常先试试全量编译排除增量编译的干扰。6. 从波形到代码的闭环调试思维6.1 建立信号与代码的映射关系Verdi最强大的功能之一是可以把波形和源代码关联起来。在nWave窗口里选中一个信号按CtrlShiftL或者右键选择Trace to SourceVerdi会自动打开源代码窗口并定位到该信号被赋值的那一行。反过来在源代码窗口里选中一个信号也可以直接把它加到波形窗口里。这个功能在调试时极其高效。你看到波形上某个信号值不对直接跳转到源代码看赋值逻辑马上就能定位到问题。不用在代码里搜索信号名也不用在波形里翻层级树。我个人的习惯是调试时始终开着源代码窗口和波形窗口两个窗口并排看到异常波形就跳代码改完代码重新编译仿真再看波形形成闭环。6.2 基于断点和单步的精细调试除了看波形VCS还支持在仿真过程中设置断点和单步执行。在编译时加上-debug_accessall之后可以用verdi -ssf wave.fsdb -dbg启动调试模式或者在仿真时用UCLIUnified Command Line Interface交互式地控制仿真。UCLI里常用的命令包括stop设置断点、run继续执行、step单步执行、examine查看信号值。这种方式适合调试那些波形上看不出明显异常的复杂逻辑问题比如状态机跑飞了你可以单步跟踪状态转移看每一步的跳转条件是否满足。不过UCLI的学习曲线比较陡日常调试中大部分问题用波形就能解决。我建议先把波形调试练熟遇到波形搞不定的问题再上UCLI。6.3 调试记录与知识沉淀最后说一个容易被忽视但长期收益很高的事情记录调试过程。每次解决一个bug把问题现象、排查过程、根本原因、解决方案记下来。可以用简单的文本文件也可以用公司内部的wiki。积累多了之后你会发现很多问题是重复出现的下次再遇到类似现象翻一下记录就能快速定位。我自己的习惯是在项目目录下建一个debug_log.md每次调试都往里加一条记录。格式很简单日期、问题描述、排查步骤、根因、修复方法。这个习惯坚持了几年之后我发现自己排查问题的速度明显比新人快因为很多坑我已经踩过了知道往哪个方向查。VCS加Verdi这套流程本身并不复杂核心就是编译、仿真、看波形三步。但每一步的细节和技巧决定了你是花十分钟解决问题还是花一天。工具是死的人是活的多动手多总结自然就熟练了。
