首页 / 资讯中心 / 文章详情

Cadence Xcelium xrun 仿真全流程实战指南:从环境确认到覆盖率收集与避坑

Cadence Xcelium xrun 仿真全流程实战指南:从环境确认到覆盖率收集与避坑 ★ FEATURED ARTICLE
简介这份资源是面向硬件验证工程师、芯片设计师及半导体设计自动化从业者的 Cadence Xceliumxrun操作指南兼顾初学者与有经验的技术人员。内容从 Linux 环境下的安装检查、单步与多阶段分离仿真、基础 option 应用讲起深入剖析 xcelium.d 目录作用、shm/db/fsdb 波形文件生成、覆盖率收集策略以及 Gate Level Simulation 中的 SDF 反标与参数调整并针对复杂工程常见报错给出 debug 思路。资源包为 1 个 pdf 文件约 505KB篇幅紧凑、便于随查随用。目前已有 2050 人学习下载说明其在验证社区中具备一定认可度。读者可借此快速掌握 xrun 的常用命令与高级特性理解编译、精化、仿真三阶段的分工学会用 help 选项定位错误、处理 license 报错并在实际项目中提高仿真效率与排错准确性。1. 从一条which xrun开始这份指南能帮你省下多少试错时间刚接手一个数字仿真环境第一反应往往不是写 testbench而是先确认工具到底装没装、能不能跑。which xrun打印不出路径后面所有仿真流程都无从谈起。这份 Cadence Xceliumxrun操作指南核心价值就在于把从环境确认、单步仿真、三步分离编译到覆盖率收集、门级仿真、license 排查的完整链路拆成了可复现的命令和参数说明。它适合正在用 Verilog/SystemVerilog 做数字验证的工程师也适合刚接触 Xcelium、被xcelium.d目录和各类波形格式搞得一头雾水的从业者。我见过太多人卡在xrun的默认重载特性上以为代码没改就不用重新编译结果仿真结果对不上白白浪费一整天。2. 基础操作从单步仿真到三步分离的完整命令链2.1 环境确认与版本检查拿到一个新环境先别急着写脚本。第一步永远是确认xrun是否在 PATH 里以及版本是否匹配项目要求。常见做法是which xrun # 打印 xrun 的绝对路径确认可直接调用 xrun -version # 查看版本信息核对与项目文档是否一致如果which xrun没有输出说明环境变量没配好或者工具根本没装。这时候不要硬试先找环境管理员确认。xrun -version的输出里会包含版本号和 build 日期有些老项目对版本敏感版本不对可能导致 elaborate 阶段报奇怪的错误。2.2 单步仿真与三步分离xrun默认是单步仿真一个命令完成 compile、elaborate、sim 三个阶段xrun test.v # 单步完成编译、精化、仿真但实际项目中单步仿真往往不够用。比如你需要反复调试同一个 testbench每次只改仿真阶段的参数这时候三步分离更高效xrun -compile test.v # 只做编译生成中间库文件 xrun -elaborate test.v # 只做精化生成 snapshot xrun -R # 加载当前目录的 snapshot 并仿真注意如果在 elaborate 之前没有做 compilexrun -elaborate会自动执行 compile。xrun -R会在当前目录自动检测 elaborate 生成的 snapshotload 后进行仿真。这个特性在反复调试时非常实用但也要小心——如果你换了目录snapshot 不在当前路径下-R就会报错找不到。2.3 基础仿真 option 速查下面这些 option 是日常仿真里出现频率最高的建议先混个脸熟optionusage-6464bit 模式-sv支持 SystemVerilog 语言-access rwc设置访问权限读、写、可执行-timescale 1ns/1ps设置仿真时间精度-f filename扫描文件把多个源文件路径写进一个 .f 文件里-top指定仿真的顶层模块-l filename指定仿真 log 的路径和名字不指定默认为 xrun.log-errormax n指定 error 数到达 n 时仿真 exit-parseinfo include将 compile 阶段 include 的信息打印出来-f这个 option 特别值得展开说。当工程里有几十个 .v 文件时一条条写在命令行里不现实。常见做法是建一个filelist.f每行写一个文件路径然后xrun -f filelist.f。注意文件里的路径可以是相对路径但相对的是你执行 xrun 命令的目录不是 .f 文件所在的目录。这个坑我踩过后来统一在 .f 文件里写绝对路径或者用-f时先 cd 到工程根目录。-errormax在回归测试里很有用。默认情况下仿真器遇到 error 会继续跑log 里堆几百条 error 才停。设成-errormax 10前 10 条 error 就能让你快速定位问题不用在 log 里大海捞针。2.4 用 help 快速定位 option 用法xrun有 1521 个 option但常用的就那么几十个。遇到不认识的 option不用翻文档xrun -helpargs option # 打印指定 option 的作用及用法 xrun -helpall xrun_all_option.txt # 生成包含所有 option 的 txt 文件 xmhelp tool name tool error # 查看具体错误类型及原因xmhelp的 tool name 可以是xmvlog、xmelab、xmsim分别对应 compile、elaborate、sim 三个阶段。比如 log 里出现一个*E开头的错误直接xmhelp xmsim *E就能看到错误解释和可能的修复方向。这个习惯能帮你省下大量搜索时间。3. 进阶特性xcelium.d 目录、波形生成与覆盖率收集3.1 xcelium.d 目录与默认重载特性xrun跑完之后当前目录会多出一个xcelium.d文件夹。这是 compile 阶段生成的 library 和 elaborate 阶段生成的 snapshot 的存放位置。不要手动删它也不要把它提交到版本控制里。xrun有一个默认重载特性如果之前进行过 compile 或 elaboratexrun会检测代码是否有修改。如果没有修改默认直接重新载入跳过编译和精化。这个特性在反复调试时能省时间但也会带来一个经典翻车场景——你改了代码但文件时间戳没变比如从别处拷贝过来xrun认为没修改直接载入旧 snapshot仿真结果自然不对。想强制重新编译加上-cleanxrun -clean test.v # 强制重新 compile 和 elaborate查看 snapshot 生成情况可以用xmls但注意xmls默认查找 32bit 的 snapshot。如果仿真工具是 64bit查找时需要加上-64xmls -64 # 查看 64bit snapshot 列表3.2 波形文件生成shm、db、fsdb 三种格式波形文件一般通过 tcl 脚本输入来生成常见做法是xrun -input wave.tcl test.v三种波形格式对应不同的查看工具格式查看工具说明shmSimVisionXcelium 自带工具无需额外 licensedbIndago调试分析工具适合大规模信号追踪fsdbVerdi业界常用需要额外 license 和 PLI 加载生成 fsdb 时必须加上-loadpli1来保证仿真器识别 fsdb 相关 taskxrun -input wave.tcl \ -loadpli1 ${FSDB_INST_DIR}/.../boot/debpli.so:novas_pli_boot \ test.v这里的${FSDB_INST_DIR}需要替换成实际的 Verdi 安装路径。如果这个路径写错仿真会报 PLI 加载失败波形文件也不会生成。我一般会先确认debpli.so文件确实存在再写进脚本。3.3 覆盖率收集-coverage 与 -covoverwrite覆盖率收集需要添加-coverageoption后面跟要收集的覆盖率类型xrun -coverage B,E,F,T,U -covoverwrite test.v各字母含义如下字母覆盖率类型BBranch分支覆盖率EExpression表达式覆盖率FFSM状态机覆盖率TToggle翻转覆盖率UUser-defined用户自定义覆盖率All以上全部一般还会加上-covoverwrite打开对覆盖率的重载功能。不加这个 option第二次跑仿真时覆盖率数据可能不会覆盖旧数据导致你看到的是上一次的结果。这个坑在回归测试里特别隐蔽因为覆盖率数字看起来“正常”但实际上没更新。3.4 门级仿真SDF 反标与时序检查门级仿真Gate Level Simulation需要把延时文件反标到门级网标中通过$sdf_annotate系统任务实现。常用 option 包括xrun -notimingcheck -nospecify -sdf_verbose -tfile tcheck.file test.v-notimingcheck不做时序检查-nospecifyspecify 不起作用即没有延时和时序检查-sdf_verbose展示反标的具体信息-tfile tcheck.file关闭某个 module 的时序检查tcheck.file的写法规则如下PATH test.dut.ff_i0 -tcheck // 关闭 ff_i0 的 timing check PATH test.dut_i $setup -tcheck // 关闭 dut 的 setup timing check PATH test... -tcheck // 关闭 test 所有下属层次 timing check门级仿真里零延迟门级震荡是常见问题加上-gateloopwarn可以打印具体信息帮你定位是哪个门产生了震荡。4. 避坑排查仿真报错、license 与挂死问题的处理4.1 仿真报错从 *E 到 -genhierelaborate 阶段报了一个隐式名字在 hierarchy 出错的错误log 上只显示一个*E看起来一头雾水。这时候用xmhelp查看错误具体原因xmhelp xmelab *E常见原因是在使用 generate 时没有按照 Verilog 标准写法给定名称。解决方法有两种一是按照标准写法加上名称二是添加-genhieroption 放宽语法检查xrun -genhier test.v-genhier不是万能药它只是放宽检查不解决根本问题。如果代码里 generate 块确实需要命名还是应该补上名字否则后续调试时信号层级会很难看。4.2 license 报错-licqueue 与 lmstat仿真阶段报 license 错误xmsim: *F,NOLICN: Unable to checkout license for the simulation. lic_error -18.xrun只有在 simulation 阶段才会检测 license。可能的原因有两种一是当前服务器上有 4 个 xrun 的 license但你提交了 5 个 xrun job。这时候加上-licqueue让仿真排队等待 license 释放xrun -licqueue test.v二是你没有某些 feature 的 license。用lmstat打印 license 安装信息lmstat -a -c $LM_LICENSE_FILE # 或者 lmstat -a -c $CDS_LIC_FILE取决于哪个变量指向 license。lmstat的输出会列出所有 feature 的使用情况看看你需要的 feature 是不是已经满了或者根本没装。4.3 仿真挂死从波形到 linedebug仿真器看起来像是挂死了先别急着 kill。按以下顺序排查检查波形是否增加即仿真时间是否在前进。如果波形在动说明仿真没挂只是跑得慢。如果波形不动加上-gui -linedebug进行具体定位xrun -gui -linedebug test.v加上-profile查看生成的profile.out里 license check 时间。通常为 0.1s如果特别长代表仿真卡在等待 license 上xrun -profile -profoutput profile.out test.v如果是 gate level 仿真也可能是零延迟门级震荡加上-gateloopwarn打印具体信息。4.4 特殊场景的 option 语法扩展有些项目里文件扩展名不标准比如.sv11表示 SystemVerilog.v11表示 Verilog。可以用-sysv_ext和-vlog_ext指定xrun -sysv_ext .sv11 -vlog_ext .v11 test.v11-profile和-profoutput配合使用可以生成各组件 time 和内存消耗信息。profile.out包含检查 license 时间、各组件消耗仿真时间对性能调优很有帮助。5. 进阶技巧用 -helpall 和 xmhelp 建立自己的排错手册xrun -helpall生成的xrun_all_option.txt有 1521 个 option但真正高频使用的不到 50 个。我的习惯是第一次遇到某个场景时用xrun -helpargs option查清楚用法然后把命令和参数说明记到一个自己的xrun_notes.md里。下次遇到类似问题直接翻笔记不用重新查。xmhelp的用法也值得展开。除了xmhelp xmsim *E这种查错误码的方式还可以用xmhelp xmvlog查看 compile 阶段的所有错误类型。我一般会在项目初期把xmhelp xmvlog、xmhelp xmelab、xmhelp xmsim的输出各存一份遇到报错先在里面搜关键字比直接上网搜快得多。还有一个容易被忽略的技巧-parseinfo include可以把 compile 阶段 include 的信息打印出来。当工程里 include 路径混乱、宏定义冲突时这个 option 能帮你快速定位到底是哪个文件被 include 了、顺序对不对。xrun -parseinfo include -f filelist.f test.v最后说一个我自己的教训。有一次跑回归测试覆盖率数字一直不更新我以为是 testbench 没覆盖到新代码查了半天才发现是没加-covoverwrite。从那以后我每次跑覆盖率收集都强制走一遍-coverage All -covoverwrite再也没出现过覆盖率数据不刷新的问题。希望这些经验能帮到你少走一些我走过的弯路。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助?
咨询建站