简介这份Cadence Xceliumxrun数字仿真工具操作指南面向硬件验证工程师、芯片设计师以及希望深入掌握数字仿真流程的从业人员。内容从检查环境安装、xrun -version、单步仿真到分阶段compile/elaborate/sim命令系统梳理了基础选项与帮助查找方法并深入说明xcelium.d目录作用、shm/db/fsdb三类波形文件生成、覆盖率收集策略及GLS门级仿真中的sdf反标、时序检查关闭等高级应用。针对工程中常见的elaborate报错、license欠费或超限等实际问题也提供了利用xmhelp与Cadence官网定位解决的思路。资源为1个PDF文档压缩包大小505KB内容精炼、组织清晰适合初学者按图索骥也适合有经验者作为速查手册。已有2050人学习可作为日常仿真与排错的重要参考。1. 数字仿真绕不开的 xrun从一条命令到一套流程在数字仿真里Cadence Xcelium 的入口命令 xrun 是验证工程师绕不开的一道关。很多项目初期从xrun test.v单步跑通开始代码一多就会发现选项和阶段拆分的门道远不止一条命令。这份资源从实际使用笔记整理而来把 xrun 的环境确认、单步与三步仿真、常用选项、波形转储、覆盖率收集、GLS 参数和典型报错串成一条能照着操作的主线。适合正在用或准备用 Xcelium 的验证工程师和芯片设计人员也适合刚开始接触数字仿真、想系统梳理 xrun 用法的人——新手能按步骤跑通熟手能直接查参数边界。2. 基础操作与选项速查从单步仿真到三步分离xrun 的用法可以拆成两个层次理解一是怎么跑通二是跑通之后怎么控制它。最基础的是知道 xrun 默认是单步仿真也就是一个命令把 compile、elaborate、sim 三个阶段全走完。对小的 testbench 来说xrun test.v这一句就够了。但工程一大全量重编的时间成本就上来了这时候就需要把三个阶段拆开按需增量执行。2.1 先确认环境which xrun 与 xrun -version在 Linux 环境下动手之前先确认 xrun 是否已经可以直接调用。这一步经常被跳过等报错才发现调用的是别的版本或者环境脚本根本没 source。$ which xrun /opt/cadence/tools/bin/xrun $ xrun -version xrun: 20.09-p001: (c) Copyright ...which输出的是 xrun 可执行文件的绝对路径能看到这个路径才能确定当前 shell 用的是哪个安装版本。如果输出为空多半是 Cadence 的安装环境脚本没有 source或者 PATH 里没加 tools/bin。xrun -version除了能确认版本还能在后续沟通报错时把版本信息一起贴出来——很多 Cadence 的疑难问题是版本相关的版本号对齐了才好查支持库。2.2 单步仿真与三步分离-compile / -elaborate / -R 的协作关系# 单步仿真compile elaborate sim 一次完成 xrun test.v # 分步仿真只做 compile xrun -compile test.v # 分步仿真做 elaborate若之前没 compile 会自动补一次 xrun -elaborate test.v # 分步仿真加载已有 snapshot 并运行 xrun -R第一次跑单步仿真时xrun 会在工作目录生成 xcelium.d 目录compile 产生的 library 和 elaborate 产生的 snapshot 都在里面。-R会去当前目录检测这个 snapshot存在就直接加载跑。分步的意义在大型工程里很明显几百个文件的验证环境只改了一个 rtl 文件如果每次全量重来光是 compile 就要等很久。拆开之后改代码只重编对应的文件再重新 elaborate 和 sim。需要注意的细节是-elaborate之前没有 compile 时它会自动补一次 compile这个行为手册里写得很明确实际用也不用担心顺序搞反。真正容易翻车的是-R如果当前目录下没有 snapshot它直接报错找不到而不是自动去编一次。所以分步跑的流程里第一次还是得先xrun -compile和xrun -elaborate各走一遍。2.3 基础 option 速查表与一个完整组合option作用使用场景-6464bit 模式大设计、大数组、深层次 testbench 内存不足时-sv按 SystemVerilog 解析输入文件里有 interface、class、package 时必须加-access rwc设置读、写、可执行访问权限波形 dump、force/release、PLI 访问内部信号-timescale 1ns/1ps设置仿真时间单位和精度与 testbench 和 IP 的 timescale 对齐-f file扫描文件列表工程 filelist 标准化管理-top module指定仿真顶层输入文件里有多个 module 时防止选错顶层-l file指定 log 路径与名字默认 xrun.log多 job 并行时避免互相覆盖-errormax nerror 数到达 n 时退出仿真回归测试里的快速失败策略-parseinfo include打印 compile 阶段 include 的信息排查 include 路径错误实际工程里这些选项很少单独用通常会组合成一个启动命令xrun -64 -sv -access rwc -timescale 1ns/1ps \ -f filelist.f -top tb_top -l sim.log-access rwc在这个组合里比较关键后面如果要做波形 dump 或者用force内部信号没有这个选项仿真器访问内部信号的权限是不够的波形跑完一片空白或者 force 不生效都是从这里来的。-timescale 1ns/1ps是常见的 1ns 单位、1ps 精度搭配如果文件里没有timescale 指令或者和某些 IP 的精度不匹配仿真行为会变得很难预期。-f 把 filelist 收进来之后命令行就不用再堆一长串文件路径。2.4 帮助系统-helpargs、-helpall 与 xmhelpxrun 的选项数量非常多靠记是不现实的关键是会用它的帮助系统。# 查看某个 option 的用法 xrun -helpargs -64 # 一次性导出全部 option 说明方便本地检索 xrun -helpall xrun_all_option.txt # 查看仿真错误的具体原因 xmhelp xmvlog 12345-helpargs后面跟具体的选项名会打印出该选项的作用和用法说明适合临时确认。-helpall会把所有 option 的说明导出到一个文件里全套大约有 1500 多个选项平时用 grep 在这个文件里搜关键词比翻网页快得多。xmhelp是专门查错误的工具tool name 填 xmvlog、xmelab、xmsim 三个阶段中的一个后面跟错误码比如 log 里出现*E开头的错误把错误码喂给 xmhelp能查到比 log 里更完整的描述。3. 进阶功能实操波形转储、覆盖率收集与门级仿真参数基础流程跑通之后真正花时间的环节通常是三个波形要能dump出来并且能在对应工具里看、覆盖率要能收到指定类型的覆盖率、门级仿真要能在反标延时之后还不被时序检查淹没。这三个场景分别对应不同的 option 组合下面按场景拆开说。3.1 波形文件三种格式shm、db、fsdb 的适用场景格式查看工具适用场景shmSimVisionCadence 原生环境基本无额外配置dbIndago调试深度大、需要分析功耗或信号活动时fsdbVerdi前端验证最常用文件体积小Verdi 加载快三种格式的生成方式都是通过 tcl 脚本来控制的xrun 用-input把 tcl 文件喂进去。选择哪种格式主要看团队用的调试工具SimVision 是 Cadence 自带的shm 格式最稳基本不用额外配置如果环境里主要是 Verdi 看波形那就用 fsdbIndago 的 db 格式在深度调试场景里更占优势但日常回归用得少。3.2 fsdb 波形生成的 tcl 脚本与 -loadpli1 参数Verdi 是很多验证团队的主力波形工具fsdb 也因此最常见的波形格式。生成 fsdb 波形需要两个配合一个 tcl 脚本来控制打开数据库和打 probe一个-loadpli1参数把 fsdb 的 PLI 库加载进来。# wave.tcl database -open wave.fsdb -fsdb probe -create -database wave.fsdb -all -depth all runxrun -64 -sv -access rwc \ -input wave.tcl \ -loadpli1 ${FSDB_INST_DIR}/.../boot/debpli.so:novas_pli_bootdatabase -open是打开一个 fsdb 数据库文件名叫 wave.fsdbprobe -create ... -all -depth all表示对所有信号打 probe深度到所有层次。这里要注意-depth all会让波形文件膨胀得很快大型设计跑长回归时一般只对感兴趣的子模块用-depth指定层数而不是全设计打满。-loadpli1的作用是把 Verdi 提供 的 fsdb PLI 库加载进仿真器仿真器才能识别 tcl 里的database -open ... -fsdb这类 task。debpli.so 的完整路径以${FSDB_INST_DIR}实际安装目录为准不同版本路径会有差异。如果 tcl 执行了但没生成 fsdb先确认两件事第一-loadpli1的路径是否真实存在加载失败时 log 里会有提示第二-access rwc有没有加probe 内部信号没有读权限是探不到的。3.3 覆盖率收集-coverage 的 B/E/F/T/U 与 -covoverwrite覆盖率收集在回归里属于「必须但容易被忽视」的环节。xrun 用-coverage指定收集类型可选 B、E、F、T、U 或 All含义分别是块覆盖率、表达式覆盖率、状态机覆盖率、翻转覆盖率和用户自定义覆盖率。All 就是全部收集但运行时间和内存开销都更大。xrun -64 -sv -coverage all -covoverwrite -l cov.log-covoverwrite打开覆盖率重载功能。这个选项在多次回归时很重要默认情况下每次仿真的覆盖率数据会叠加到已有的覆盖数据库里如果不想让旧数据干扰本轮结果或者想让它每次都从零开始重新累积就把-covoverwrite加上。实际项目里通常配合回归脚本统一管理只在前几轮冒烟测试时用 all大规模回归时按需要选 B、E、T 几类能省不少时间。3.4 门级仿真 GLS$sdf_annotate 与反标参数门级仿真比 RTL 仿真麻烦的地方在于网表里带specify块和大量的时序检查SDF 延时反标之后任何一条 check 违反都会刷屏。所以 GLS 的参数搭配核心是「反标要完整但检查要可控」。xrun -64 -access rwc \ -sdf_annotate top.sdf \ -notimingcheck \ -nospecify \ -sdf_verbose \ -f gls.f$sdf_annotate是网表里调用的系统任务把 top.sdf 里的延时值反标到门级网表的指定路径上-sdf_verbose会把反标的具体信息打印到 log 里方便核对哪些路径反标成功、哪些被跳过。-notimingcheck表示不做时序检查-nospecify让 specify 块不起作用相当于没有延时也没有时序检查。这两个选项在功能仿真阶段的 GLS 里常用因为目的只是验证门级网表的功能等价性而不是做时序收敛。真正跑带时序的 GLS 时不建议轻易加这两个会把 setup/hold 问题全盖住。如果只想关闭某几个模块的时序检查而不是全局关闭用-tfile指定一个文本文件按路径精确控制PATH test.dut.ff_i0 -tcheck PATH test.dut_i $setup -tcheck PATH test... -tchecktcheck.file 的每行是一个路径规则路径后跟要关闭的检查类型再跟-tcheck。第一行关闭 ff_i0 这个实例的全部时序检查第二行只关闭 dut_i 上的$setup检查其它检查保持生效第三行test...用了三点通配表示关闭 test 下所有下属层次的时序检查。这种写法比全局-notimingcheck精细得多适合门级仿真里已知某个孤立模块有时序问题、但不影响功能验证的场景。4. 仿真常见问题与排查license、挂死与隐式声明三类典型报错仿真跑不动的时候大多数人第一反应是翻 log 最后几行。但有些问题光看 log 末尾是定位不了的比如 license 报错、挂死、隐式名字错误它们的共同点是报错信息短真正的原因藏在环境或代码的细节里。这一章把三类高频问题按「现象 → 原因 → 解决」写清楚。4.1 license 报错lic_error -18并发不够还是 feature 缺失现象xmsim 阶段报*F,NOLICN: Unable to checkout license for the simulation. lic_error -18.仿真直接退出。原因xrun 只有在 simulation 阶段也就是 xmsim才检测 licensecompile 和 elaborate 阶段不会报这个错。lic_error -18通常有两种情况一是当前服务器上同时跑的 xrun job 数量超过了 license 并发限制比如只有 4 个 license 但提交了 5 个 job二是当前环境变量指向的 license 里没有你需要的 feature。解决如果只是并发不够加-licqueue让 xrun 排队等待 license 释放而不是立刻失败。如果是 feature 缺失用lmstat -a -c $LM_LICENSE_FILE或者lmstat -a -c $CDS_LIC_FILE查看当前 license 的安装信息具体用哪个环境变量取决于你的 license 指向。lmstat 输出里能看到当前哪些 feature 被 checkout、总数和已用数。对比一下你所需的 feature 是否在列表里不在就说明 license 文件本身没买这个 feature加-licqueue也没用。4.2 仿真器像挂死时间不动先分清是死循环还是等待现象xrun 跑了好久终端没有任何输出log 停在某一行看起来像挂死了。原因仿真「假死」的原因不止一种代码死循环、等待 license、门级零延迟震荡表现都是仿真时间不走。如果不加参数直接猜效率很低。解决先看波形文件是否还在增大。如果波形的大小还在涨说明仿真时间实际在前进只是 log 刷得不频繁不算挂死。如果波形一点动静都没有加-gui -linedebug重新跑仿真器会在卡住的位置把当前执行的源码行标出来。另一个手段是用-profile跑完看生成的 profout 文件里 license check 的时间。正常情况这个时间是 0.1 秒级别如果特别长说明仿真一直卡在等待 license 上跟代码逻辑没关系。如果是门级仿真还要考虑零延迟震荡的可能见下一条。4.3 门级零延迟震荡与仿真不收敛现象GLS 跑起来后仿真时间一直卡在同一个点波形上信号疯狂翻转毛刺一条接一条。原因门级网表里存在零延迟反馈环典型的组合环路信号变化在一个仿真步内无限循环。从模拟仿真转过来的人一看时间不走第一反应是换求解器但在数字门级仿真里更常见的是这种零延迟震荡。解决加-gateloopwarn仿真器会在检测到门级环路时打印具体信息把报错指向的路径拉出来去网表里查那条反馈路径。有一个临时缓解手段是把-notimingcheck加上再看情况但这不是根治环路的根本原因通常在网表结构或例化连接上需要回到综合或网表生成环节去修。4.4 elaborate 报隐式名字错误CUVIMG 与 -genhier 的取舍现象elaborate 阶段报隐式名字的 hierarchy 错误报错码是 CUVIMG 相关看起来像是在某个层次引用了一个不存在的名字。原因常见原因是使用 generate 时没有按 Verilog 标准给 generate 块显式命名。工具在展开层次时找不到它期望的名字就抛出一个隐式声明的错误。这种*E报错和常见的「器件未定义」是同一类问题——工具找不到它期望的定义。解决最稳妥的修复是回到代码里按 Verilog 标准给 generate 块加上名称像generate gen_xxx : if (...) ... endgenerate这样的写法。如果代码量很大、暂时没法改源码可以在 Cadence 支持库搜关键词 CUVIMG能找到对应的 option加-genhier可以放宽对 generate 层次命名的语法检查。但这属于「后悔药」本质是用更宽松的解析规则绕过检查不是修复代码。能用-genhier把仿真先跑通但代码在别的工具上仍可能报错后续还是得改。5. 大型工程提效重载机制、profile 分析与特殊扩展名处理工程一大时间就成了最贵的资源。这一章讲的是几个能直接省时间的机制xrun 的默认重载特性怎么利用、xcelium.d 目录里到底放了什么、profile 怎么定位时间消耗、以及非常规文件后缀名怎么处理。每一条都是在多文件工程里踩过之后才理解的。5.1 默认重载特性与 -clean 的适用场景xrun 有一个默认行为如果之前执行过 compile 或 elaborate它会检测代码是否有修改。没修改的话默认直接重新载入之前的编译结果不会全量重来。这个机制在多轮仿真时能省掉大量重复编译时间。但要注意它的边界。改了 RTL 文件、换了启动脚本、改了 include 路径这些情况下增量机制不一定能正确感知。如果发现仿真结果没有反映最新的代码改动或者出现了诡异的「旧文件被编译进去」的现象直接用-clean强制重新 compile、elaborate 一遍。我一般会把它加进回归脚本里作为可选参数默认不带遇到可疑问题或者版本大版本升级时加上。无脑全量-clean会让每次回归都从零开始时间成本很高。5.2 xcelium.d 目录与 xmls 查看 snapshotxcelium.d 是 xrun 在工作目录下生成的文件夹compile 阶段生成的 library 和 elaborate 阶段生成的 snapshot 都在里面。平时不用关心它的内部结构但有两个场景需要用到一是排查 snapshot 有没有正确生成二是确认当前目录里跑的是不是预期的顶层。# 查看 snapshot 信息注意默认查 32bit64bit 仿真要加 -64 xmls -64xmls是 xrun 自带的 snapshot 查看工具。它默认查找 32bit 的 snapshot如果你的仿真工具是 64bit必须加-64才能查到。输出里能看到 snapshot 的层次列表、所依赖的 library 信息。这个工具用得不多但当你怀疑跑的是旧 snapshot、或者顶层选错的时候它是定位最快的途径。5.3 -profile 与 -profoutput定位仿真时间花在哪仿真跑得慢不能只靠猜。-profile会生成一个 profile.out 文件里面包含检查 license 的时间、各组件消耗的仿真时间能清楚地看到时间到底花在编译、elaborate、还是 sim 阶段的哪个环节。# 生成 profile 信息并指定输出文件 xrun -64 -sv -profile -profoutput prof.txt -f filelist.f默认情况下 profile 信息写入 profile.out加-profoutput可以指定别的文件名。多 job 并行跑的时候每个 job 都生成同名 profile.out 会互相覆盖我用-profoutput加 job 名后缀区分。profile 输出里重点看两项一是 license check 时间这个数值异常大说明卡在 license 上跟代码无关二是各组件消耗时间占比如果 elaborate 占比异常高通常是顶层例化层次太深或接口不匹配导致的大量解析工作。5.4 特殊扩展名处理-sysv_ext 与 -vlog_ext有些 IP 或旧工程的 verilog 文件后缀不是标准的 .v、.sv比如 .v11、.sv11或者自定义的后缀。直接丢给 xrun它可能不识别导致文件被忽略或者解析方式错误。# 把 .sv11 识别为 SystemVerilog.v11 识别为 Verilog xrun -64 -sv -sysv_ext .sv11 -vlog_ext .v11 -f filelist.f-sysv_ext指定哪些扩展名按 SystemVerilog 解析-vlog_ext指定哪些扩展名按 Verilog 解析。这个选项的好处是不用改文件名也不用改 filelist对于有历史包袱的老工程特别有用。改文件名会牵连 makefile、版本管理里的引用关系代价很大用扩展名映射是在 xrun 层面解决问题副作用最小。6. 一个值得养成的验证习惯每次仿真前强制检查这五件事这套内容看下来真正影响效率的不是某个高深 option而是每次跑仿真前有没有把基本项检查完。我吃过一次亏连续跑了三轮回归结果发现其中两轮用的还是旧 snapshot因为代码改了但没注意到增量机制没触发。从那以后我每次换代码、换启动脚本、换工艺库都强制走一遍下面这五个检查形成肌肉记忆。第一which xrun和xrun -version当前 shell 用的是哪个版本。多版本共存的环境里PATH 顺序一变跑的可能就是完全不同的工具这个问题排在最前面查十几秒就能确认返工代价最小。第二xrun -helpargs确认本次要用的几个 option 存在尤其是-access rwc和-timescale这两个直接影响波形和时序表现。第三跑之前先看一眼 xcelium.d 目录的生成时间确认上一次编译的产物是不是最新的拿不准就直接-clean重编避免在旧 snapshot 上浪费几小时的仿真时间。第四log 里 grep*E和*Werror 一定要清零warning 至少要知道原因特别是CUVIMG这类隐式名字错误等 elaborate 到后面才炸会更难查。第五GLS 场景下强制确认-notimingcheck、-nospecify、-tfile的组合是不是当前阶段想要的该查时序的时候别为了跑通把它们全关了。这五件事看起来基础但能挡住大部分翻车现场。尤其是「拿不准就-clean」这条看似多花几分钟编译时间实际上是在给后面几小时仿真买保险。希望帮到你。本文还有配套的精品资源点击获取