簡介這是一份面向硬件驗證工程師、芯片設計師及半導體設計自動化學習者的 Cadence Xcelium(xrun) 數字仿真操作指南。文檔從 Linux 環(huán)境下的安裝配置檢查切入系統(tǒng)講解單步仿真、compile/elaborate/sim 多階段分離流程、常用 option 及 xcelium.d 目錄機制并深入覆蓋 shm/db/fsdb 三類波形生成、覆蓋率收集、Gate Level Simulation 延時反標與 timing check 關閉等高級功能針對復雜工程中的典型報錯如 generate 命名不規(guī)范、license 不足等也給出了具體排查思路與解決選項。資源為單份 PDF 文檔大小約 505KB內容濃縮而完整適合項目規(guī)劃、日常仿真實施和故障排查時快速查閱。目前已有 2049 人學習下載是入門到進階 Xcelium 工具鏈的實用參考資料。1. xrun 到底是什么一個命令解決不了的仿真問題這篇文章全講透Cadence Xcelium 這個名字很多做數字驗證的工程師張口就來但真要上手跑通一個工程靠的還是它底下那個叫xrun的命令。這篇筆記從 xrun 基礎操作講起一路到覆蓋率收集、門級仿真和疑難 debug幫你把日常用得到的特性按命令行粒度串一遍。我拆這份資料時最直接的感受是xrun 看著是一堆 option 的堆砌其實背后有一條非常清晰的邏輯線——從單步仿真到分階段仿真從波形生成到覆蓋率、到 GLS 時序反標。你只要理解了這條線以后遇到陌生報錯排查思路是有章可循的不是靠瞎試。記得我第一次用 xrun 的時候對著一份亂糟糟的工程腳本被*E,UNKNOWNSYM這類報錯折騰到夜里。后來把-helpargs、xmhelp這些工具用起來才發(fā)現(xiàn)大部分問題在命令行階段就能定位。這篇就把這些方法寫透新手可以照著敲熟手可以直接跳到 debug 和進階部分看參數邊界。2. 跑通第一個仿真單步模式與三步分離的完整操作2.1 環(huán)境檢查裝沒裝、能不能用兩句話定位先解決一個最基礎的問題——xrun 到底在不在你的 Linux 環(huán)境里。$ which xrun // 打印 xrun 的路徑確認可以直接被調用 $ xrun -version // 查看 xrun 的版本信息確認版本符合工程要求這兩個命令是每次開工前我必跑的。which的作用不是告訴你裝沒裝是告訴你shell 能不能找到它。很多時候環(huán)境變量PATH沒配好xrun 裝了你照樣調不到。xrun -version更關鍵因為 Xcelium 不同版本對 SystemVerilog 特性和語法檢查的嚴格程度不一樣同一個工程換版本可能有完全不同的報錯行為。從資源文檔里可以看到 xrun 核心有三段xmvlog對應 compilexmelab對應 elaboratexmsim對應 sim。這三個名字后面 debug 時要記住因為xmhelp查錯誤就是按這三個工具名查的。2.2 單步仿真一條命令的省心與局限xrun 默認是單步仿真意思是它自己把 compile編譯、elaborate細化、sim仿真三個階段一次性跑完。$ xrun test.v // 一個命令仿真完成不用手動區(qū)分三個階段單步仿真的優(yōu)點是省事。寫一個小模塊、跑一個簡單 testbench一條命令下去該出的波形、log 都有了。但它的局限也很明顯你沒法在 compile 之后、simulate 之前插入額外操作也沒法只重跑仿真而跳過編譯。工程一旦變大比如幾千個文件、有 IP 有 memory model單步仿真的效率就很尷尬了改一行代碼要全量重來。所以實際工程里我更推薦把階段拆開這也是這份文檔里最有價值的部分三個階段對應三個命令但它們之間有聯(lián)動關系不是完全獨立的。2.3 三步分離compile、elaborate、sim 的聯(lián)動機制$ xrun -compile test.v // 階段一編譯源碼生成 library 寫入 xcelium.d 目錄 $ xrun -elaborate test.v // 階段二細化設計生成 snapshot $ xrun -R // 階段三加載 snapshot 并執(zhí)行仿真注意文檔里強調了一個細節(jié)如果 elaborate 之前沒做 compile當前 elaborate 會自動執(zhí)行 compile。也就是說-elaborate自帶對 compile 的依賴檢查。-R則會在當前目錄自動檢測 elaborate 生成的 snapshot找到就 load找不到會報錯。這個聯(lián)動機制在日常使用中很有用。比如你只改了 testbench 里的約束沒動 RTL那重新 elaborate 就夠不必重新 compile 所有設計文件。但 xrun 的默認重載機制會更激進——它檢測到代碼有任何修改會重新走完整的 compileelaborate。想強制跳過這個檢測用-clean$ xrun -clean test.v // 忽略之前的編譯結果強制全量重來-clean在兩種場景下是救命的一是之前 compile 是在不同 option 組合下跑的snapshot 狀態(tài)不可信二是改了-timescale、-access這類影響全局的 option舊結果不能復用。但反過來如果只是改了局部源碼我一般不給-clean讓 xrun 自己去做增量省時間。2.4 基礎 option 速記每個參數的含義和適用邊界文檔列了一批最常用的 option我按實際使用頻率整理成下面這張表Option作用備注-6464bit 模式大設計、內存吃緊時必開-sv支持 SystemVerilog 語言工程里有.sv文件就加上-access rwc設置訪問權限讀、寫、執(zhí)行需要 dump 波形、force 信號時必須有-timescale 1ns/1ps設置仿真時間精度單位/精度能細化不能粗化-f filename掃描文件列表大型工程用 f 文件管理源碼列表-top module指定仿真頂層多頂層或自動檢測失敗時用-l filename指定 log 路徑和名字不指定默認是xrun.log-errormax nerror 數達到 n 時仿真退出防止無效跑仿真浪費時間-parseinfo include打印 compile 階段 include 信息排查 include 路徑問題時用這里重點說兩個容易踩坑的。-access rwc的rwc分別對應 read、write、execute如果你要在仿真中通過force改信號值或者用 UCLI 做交互操作r是遠不夠的得rwc全給。-timescale的單位可以比精度大但精度不能比單位大比如1ns/1ps合法1us/1ns也合法反過來寫1ps/1ns就會報錯。這是很經典的翻車點我看過不少人栽在這上面。2.5 查 option 的正確姿勢1521 個選項別硬背xrun 文檔里明確寫了全部 option 有 1521 個但你常用的可能就二三十個。所以查幫助的本事比記背參數更值錢。$ xrun -helpargs option // 打印出指定 option 的作用和用法 $ xrun -helpall xrun_all_option.txt // 把全部 option 內容導出成文件 $ xmhelp tool error // 查錯誤類型與原因tool 填 xmvlog/xmelab/xmsim我發(fā)現(xiàn)-helpall導出的文件配合 grep 是效率最高的查找方式。比如你想找所有和 coverage 相關的選項直接grep -i coverage xrun_all_option.txt就出來了比自己翻 PDF 文檔快得多。xmhelp這個命令很多老手都不用但它其實是被忽視的 debug 利器?？吹?log 里*E開頭的報錯第一反應應該是xmhelp xmelab error code它會給出一段規(guī)范化的錯誤原因描述比在代碼里瞎找效率高。比如*E,CUVIMG這類詭異錯誤不查說明你根本不知道問題出在 generate 塊的命名規(guī)范上這個在第 5 章避坑部分我會重點展開。3. xcelium.d 目錄與文件機制黑匣子里到底裝了什么3.1 compile 產物與 snapshot文件的來龍去脈xrun 在compile階段生成的是 library編譯庫在elaborate階段生成的是 snapshot仿真快照這兩個東西都放在xcelium.d目錄下。很多人跑完仿真看到這個目錄問能不能刪答案是能刪但不建議隨便刪因為它就是 xrun 的增量緩存刪了下次全量重來。我一般的工作習慣是工程收尾歸檔時不帶xcelium.d但日常迭代中留著它。文檔里提到一個排查技巧就是當你懷疑 snapshot 狀態(tài)不對時不要直接-clean先用工具檢查 snapshot 的生成情況$ xmls -64 // 查看 64bit snapshot 的生成情況這里有個細節(jié)值得注意xmls默認查找的是 32bit snapshot如果你的仿真工具跑在 64bit 模式下必須加-64否則會出現(xiàn)明明生成過 snapshot 卻查不到的詭異現(xiàn)象。我剛開始就被這事坑過一次后來記住多少位的仿真器就用多少位的 xmls 查這個口訣才沒再犯。3.2 默認重載機制xrun 到底在檢測什么文檔里說得很清楚如果之前做過 compile 或 elaboratexrun 默認會檢測代碼是否有修改若無修改則直接重新載入舊結果。這個機制省時間但也有它的不透明之處——它檢測的是文件時間戳和內容不是文件數量。有時候你往工程里加了一個新文件以為會被自動識別結果 xrun 根本不理會為什么因為它檢測的對象是上一次命令中顯式列出的文件集合新文件沒進命令行它就沒理由知道。所以我的習慣是文件列表變了直接用-clean或顯式重新-compile不要賭 xrun 的自動檢測。另外-clean這個選項的語義是忽略之前的全部結果它會清掉舊 snapshot 和 library在時序仿真、覆蓋率合并等對編譯選項敏感的步驟里我用-clean的頻率明顯更高。3.3 xrun 的增量編譯邊界什么能增量什么不能結合文檔內容我總結出自己能接受的增量邊界給新人做個參考可以增量只改 RTL 內部邏輯不改端口、不改參數化配置、不改模塊例化關系。盡量別增量改 testbench 頂層結構、改define、改include 文件路徑、換 timescale。必須全量換語言標準比如從 Verilog 換成 SystemVerilog、開/關覆蓋率收集、切換 32/64bit、改 access 權限。這個邊界不是官方規(guī)定而是我實際踩出來的經驗。覆蓋率收集這個點很微妙因為-coverage是在 elaborate 階段植入 instrumentation 的如果你第一次沒加-coverage跑了 elaborate第二次只是在命令里加了-coverage想重新跑xrun 可能因為代碼沒變而直接復用舊的編譯結果導致覆蓋率選項根本沒生效。正確的做法是任何會影響仿真器內部行為的 option 變更都強制-clean不要依賴 xrun 的自動檢測。4. 高級功能實操波形生成、覆蓋率收集與門級仿真的完整參數鏈4.1 三種波形格式的取舍shm、db、fsdb 分別給誰用仿真不 dump 波形等于白跑但波形格式選錯是很多新手的隱藏痛點。文檔里明確列了三種格式shm 給 Cadence 自家 SimVision 用db 給 Indago 用fsdb 給 Verdi 用。$ xrun test.v -input wave.tcl // tcl 腳本定義波形 dump 行為和時長這里-input指定的是 tcl 腳本而腳本里會根據你需要調對應波形庫的 task。我實際項目里最常用的是 fsdb因為驗證環(huán)境里看波形的主力工具是 Verdi。但注意 fsdb 不是 xrun 內置支持的格式需要顯式加載 debpli 插件$ xrun test.v -loadpli1 ${FSDB_INST_DIR}/.../boot/debpli.so:novas_pli_boot-loadpli1的作用是加載 PLI 庫novas_pli_boot是 Verdi 提供的初始化函數名。省略這個選項的直接后果是仿真 log 里不會報錯但 fsdb 文件就是生成不出來非常隱蔽。我第一次遇到這問題花了半小時排查最后發(fā)現(xiàn)是環(huán)境變量FSDB_INST_DIR沒定義加載路徑本身就是空的。4.2 覆蓋率收集B/E/F/T/U/All 六個字母背后的含義收集覆蓋率是驗證收斂的依據xrun 支持按類型選擇性收集$ xrun test.v -coverage B // 收集 branch coverage $ xrun test.v -coverage E // 收集 expression coverage $ xrun test.v -coverage F // 收集 FSM coverage $ xrun test.v -coverage T // 收集 toggle coverage $ xrun test.v -coverage U // 收集 conditional(expression) coverage $ xrun test.v -coverage All // 全部都要實際項目里我一般用-coverage All單次跑全量收集最后用imcIncisive Metrics Center做 merge 和分析。真正容易翻車的是-covoverwrite。這個 option 的作用是允許覆蓋率數據被覆蓋寫入不加它時第二次跑仿真不會覆蓋第一次的覆蓋率數據而是累積合并。這在跑回歸時是好事因為你要的是多輪累加不是單輪結果。但如果你刻意要對比兩輪不同參數下的覆蓋率差異就必須加-covoverwrite把上一輪清掉$ xrun test.v -coverage All -covoverwrite覆蓋率收集的另一個邊界是它也不能脫離 compile/elaborate 單獨開啟。我的血淚經驗是開覆蓋率時老老實實-clean全量重來省那幾分鐘編譯時間換來的是覆蓋率數據無效的排查成本不劃算。4.3 門級仿真SDF 反標與時序檢查的完整鏈路GLSGate Level Simulation是后端 netlist 驗證的核心環(huán)節(jié)。文檔從$sdf_annotate反標切入我把完整參數鏈整理如下$ xrun netlist.v testbench.v -notimingcheck -nospecify -sdf_verbose這里的參數語義要拆開講-notimingcheck不做時序檢查。它關掉的是$setup、$hold、$width這些時序檢查原語讓仿真在時序違例時不報 violation。-nospecify讓 specify 塊完全不起作用。這比-notimingcheck更粗暴連 specify 里的延時都不算。-sdf_verbose把 SDF 反標的具體信息打到 log 上。這個在排查為什么某個 cell 的延時沒有反標進去時是必開項。我實際做 GLS 時還常配一個參數-sdf_verbose跑第一遍確認所有 instance 都反標到了確認無誤再關掉跑正式回歸因為 verbose 輸出會拖慢仿真速度。如果一個 SDF 文件只反標了部分模塊可以用-sdf_verbose看反標統(tǒng)計但更精細的控制要結合代碼里的$sdf_annotate寫區(qū)域限定。另外文檔里給了-tfile來精細關閉特定模塊的時序檢查$ xrun netlist.v testbench.v -tfile tcheck.filetcheck.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第一行是關閉ff_i0這個 instance 的全部時序檢查第二行只看setup這類第三行的...是通配指test下所有層次的 timing check 全部關閉。實際使用時我建議盡量精確到 instance不要濫用...通配因為它會把關鍵路徑的時序檢查也關掉門級仿真就失去了一半意義。4.4 特殊擴展名與性能剖析參數幾條少有人提但關鍵的選項文檔里還埋了幾個平時不太被人注意、但在特定場景非常頂用的選項$ xrun test.v11 -sysv_ext .v11 // 把 .v11 結尾的文件識別為 SystemVerilog $ xrun test.v -vlog_ext .v11 // 把 .v11 結尾的文件識別為 Verilog $ xrun test.v -profile // 生成 profile.out含各組件時間與內存消耗 $ xrun test.v -profoutput prof.txt // 指定 profile 輸出文件不覆蓋默認的 profile.out我在多版本混合項目里用過-sysv_ext這類擴展名選項。公司自研 IP 庫里有舊的.v文件其實內容是 SV 語法不想為了適配去改文件后綴就用-sysv_ext .v暴力把.v全識別為 SV——這招好用但慎用因為它影響所有.v的解析方式如果有老工程混合了純 Verilog會把語法檢查標準提高一個檔次導致舊代碼報一堆無辜錯誤。-profile是我排查性能問題時的第一選擇。當仿真跑得異常慢先開-profile看 profile.out 里的時間分布如果大部分時間花在 license check 上那是 license 服務器的問題如果花在 PLI 回調上那是你 testbench 的$monitor或者 force/release 太頻繁。這個診斷思路遠比盲目優(yōu)化 RTL 代碼效率高。5. 避坑與調試實戰(zhàn)五條踩坑記錄從 *E 報錯到仿真死循環(huán)全解析5.1 隱式命名報錯*E,CUVIMG的根因與 check 方法現(xiàn)象elaborate 階段報*E,CUVIMG提示 implicit name 在 hierarchy 中出錯代碼里怎么看怎么覺得邏輯沒問題。原因這個報錯十有八九出在 generate 塊上。Verilog-2001 規(guī)定 generate 塊必須顯式命名你沒寫名字或者名字寫得不規(guī)范xrun 無法在 hierarchical path 中引用它就報隱式名字錯誤。實際工程里if generate嵌套在for generate內部、又沒有給中間層命名的情況我也見到過。解決按標準寫法給 generate 塊補名字比如genvar i; generate for (i0; i8; ii1) begin : gen_blk ... end endgenerate。如果想放寬 xrun 對這類問題的語法檢查可以在 compile 階段加-genhier。但這個選項是放寬不是修復建議只是臨時繞過最終還是要改代碼補名字。5.2 license 報錯NOLICN 的三種可能性排查現(xiàn)象仿真在 elaberate 通過后、開始 simulation 的瞬間log 里出現(xiàn)xmsim: *F,NOLICN: Unable to checkout license for the simulation. lic_error -18仿真直接退出。原因xrun 只在 simulation 階段才檢測 licensecompile 和 elaborate 階段不檢測。所以你這個報錯不是編譯出問題而是模擬階段拿不到 license 授權。解決如果確認服務器上 license 剩余數量充足問題可能出在你沒有某些 feature 的授權。用 Linux 命令看 license 安裝信息$ lmstat -a -c $LM_LICENSE_FILE // 如果 LM_LICENSE_FILE 指向 license 文件 $ lmstat -a -c $CDS_LIC_FILE // 如果 CDS_LIC_FILE 指向 license 文件如果 license 不夠用xrun 提供了排隊等待機制$ xrun test.v -licqueue // 提交后進入 license 等待隊列等到了再跑實際使用中-licqueue適合大量并行回歸。注意排隊時間不設上限regression 跑到凌晨job 就排隊掛到凌晨。所以不是無腦加這個選項要評估隊列深度。5.3 仿真掛死先看波形還是先看 profile順序不能錯現(xiàn)象仿真器進程還在但 log 長時間不增長看起來像是死循環(huán)。原因不一定是死循環(huán)。文檔把這三種情況都列出來了我在實際項目中都遇到前兩種解決第一步先打開波形窗口看波形時間軸是否在前進。時間軸在走仿真就沒掛只是慢時間軸完全不動那才是真的堵住了。第二步如果時間軸不動加-gui -linedebug定位卡住的代碼行這個組合會把當前執(zhí)行位置實時反映在源碼窗口上。第三步加-profile看 profile.out重點看 license check 時間如果它異常巨大說明仿真卡在等待 license 上不是死循環(huán)而是許可瓶頸。要是做的是 gate level 仿真還有一個非常容易被忽略的點零延遲門級震蕩。門級網表的組合環(huán)如果沒有延時就可能高頻振蕩仿真器陷進去出不來。加-gateloopwarn會打印具體震蕩路徑信息用這個定位到底是哪個 loop 在振再去查后端 netlist 是否插了必要的 delay cell。5.4 -loadpli1 大小寫和路徑順序fsdb 生成的一個隱性隱患現(xiàn)象-input wave.tcl指定了 fsdb dump 腳本仿真正常跑完但目標目錄下根本沒有 fsdb 文件也不報錯。原因-loadpli1的路徑不對或者環(huán)境變量FSDB_INST_DIR沒有定義xrun 靜默忽略了加載后面 tcl 里調fsdbDumpfile時找不到對應 task但因為 tcl 腳本沒做錯誤檢查仿真照跑。解決嚴格按照文檔樣例寫完整路徑-loadpli1 ${FSDB_INST_DIR}/.../boot/debpli.so:novas_pli_boot并且用bash -c echo $FSDB_INST_DIR先確認變量存在。另外檢查-loadpli1是否在 compile 階段之前被參數解析器處理這個 option 必須出現(xiàn)在 xrun 命令行中不能直接寫進 f 文件f 文件里加載有時序問題。5.5-timescale寫反工具不報錯但結果全歪的情況現(xiàn)象仿真不報任何錯誤但波形上的延遲時間完全對不上。比如預期的時鐘是 10ns 周期波形量出來是 10ms。原因-timescale 1ps/1ns這種精度比單位大的寫法不正確。單位規(guī)定了時間值的度量單位精度規(guī)定了時間值可以精確到的程度。精度不能比單位更粗實際使用時很多人寫反了也不報錯但所有延時都按錯誤換算輸出結果整個仿真時間軸都失真。解決確認時間語義是單位比精度大或相等。1ns/1ps是標準推薦1us/1ns也穩(wěn)妥。如果你要測亞穩(wěn)態(tài)需要皮秒級精度就寫1ns/1ps而不是反過來。另外多個文件混合時xrun 默認按最精細的精度做全局時間精度這可能拖慢整體仿真速度可以考慮在關鍵模塊上縮小精度范圍。6. 代碼與參數技巧速查一個工程從編譯到調試的完整命令行參考6.1 日常迭代的完整 xrun 命令模板實際項目里我常寫的 xrun 命令比文檔里的單命令要長不少通常是一個 f 文件加一堆全局 optionxrun -f rtl.f -f tb.f -sv -64 -access rwc \ -timescale 1ns/1ps -top tb_top \ -coverage All -covoverwrite \ -input wave.tcl -l run.log這份命令在一天內會反復用。注意-sv的使用場景是 f 文件列表里既有.v也有.sv加這個是讓 .sv 文件按 SystemVerilog 標準解析如果沒有.sv文件加了無害但也沒必要。-top tb_top指定頂層避免多頂層模塊的存在讓 xrun 無法自動識別。-input wave.tcl走的是 tcl 腳本里面由fsdbDumpfile這類 task 控制波形文件生成不在命令行里直接指定格式便于仿真前改波形配置而不動 xrun 主體命令。6.2 性能排查兩步走profile 優(yōu)先linedebug 兜底遇到仿真速度慢到可疑的情況我有固定的排查路徑$ xrun test.v -profile -profoutput prof_i0.txt打開 prof_i0.txt 看時間分布。重點看兩類時間license check 時間如果占到總時長 10% 以上說明 license 在拖后腿和各個編譯組件耗時。xrun 的 profile 輸出里包含了檢查 license 時間、各組件消耗仿真時間這些數據能幫你精確區(qū)分是 license 瓶頸、PLI 回調瓶頸還是 RTL 本身仿真慢。如果 profile 顯示 license check 正常、組件消耗均衡但還是慢再用-gui -linedebug掛在仿真上看它停在哪一行判斷是測試代碼里的循環(huán)等待問題還是 RTL 本身的死循環(huán)邏輯。6.3 門級震蕩與 SDF 反標的最后兜底門級仿真時如果出現(xiàn)時序異常反復、仿真停在某些門級路徑上我最后會開這三個參數組合$ xrun netlist.v tb.v -sdf_verbose -gateloopwarn -notimingcheck-sdf_verbose打印所有 SDF 反標條目方便確認反標量-gateloopwarn把組合環(huán)位置提示出來避免仿真真死在里面-notimingcheck在初步驗證功能階段關掉時序約束讓功能先對上。等前兩步通過后再把-notimingcheck去掉跑正式時序驗證。這套流程做完工程 speed 和正確性才都收住?，F(xiàn)在我每次起新工程第一件事就是把 xrun 這份命令模板、tcl 腳本結構和 f 文件組織方式一起拷過來寧可在開頭多花十分鐘搭框架也絕不在跑完一輪回歸后才回頭補 option。也希望我的這份拆解對你上手機器有幫助。本文還有配套的精品資源點擊獲取 xrun 完全指南：仿真、覆蓋率與門級調試全掌握
簡介這是一份面向硬件驗證工程師、芯片設計師及半導體設計自動化學習者的 Cadence Xcelium(xrun) 數字仿真操作指南。文檔從 Linux 環(huán)境下的安裝配置檢查切入系統(tǒng)講解單步仿真、compile/elaborate/sim 多階段分離流程、常用 option 及 xcelium.d 目錄機制并深入覆蓋 shm/db/fsdb 三類波形生成、覆蓋率收集、Gate Level Simulation 延時反標與 timing check 關閉等高級功能針對復雜工程中的典型報錯如 generate 命名不規(guī)范、license 不足等也給出了具體排查思路與解決選項。資源為單份 PDF 文檔大小約 505KB內容濃縮而完整適合項目規(guī)劃、日常仿真實施和故障排查時快速查閱。目前已有 2049 人學習下載是入門到進階 Xcelium 工具鏈的實用參考資料。1. xrun 到底是什么一個命令解決不了的仿真問題這篇文章全講透Cadence Xcelium 這個名字很多做數字驗證的工程師張口就來但真要上手跑通一個工程靠的還是它底下那個叫xrun的命令。這篇筆記從 xrun 基礎操作講起一路到覆蓋率收集、門級仿真和疑難 debug幫你把日常用得到的特性按命令行粒度串一遍。我拆這份資料時最直接的感受是xrun 看著是一堆 option 的堆砌其實背后有一條非常清晰的邏輯線——從單步仿真到分階段仿真從波形生成到覆蓋率、到 GLS 時序反標。你只要理解了這條線以后遇到陌生報錯排查思路是有章可循的不是靠瞎試。記得我第一次用 xrun 的時候對著一份亂糟糟的工程腳本被*E,UNKNOWNSYM這類報錯折騰到夜里。后來把-helpargs、xmhelp這些工具用起來才發(fā)現(xiàn)大部分問題在命令行階段就能定位。這篇就把這些方法寫透新手可以照著敲熟手可以直接跳到 debug 和進階部分看參數邊界。2. 跑通第一個仿真單步模式與三步分離的完整操作2.1 環(huán)境檢查裝沒裝、能不能用兩句話定位先解決一個最基礎的問題——xrun 到底在不在你的 Linux 環(huán)境里。$ which xrun // 打印 xrun 的路徑確認可以直接被調用 $ xrun -version // 查看 xrun 的版本信息確認版本符合工程要求這兩個命令是每次開工前我必跑的。which的作用不是告訴你裝沒裝是告訴你shell 能不能找到它。很多時候環(huán)境變量PATH沒配好xrun 裝了你照樣調不到。xrun -version更關鍵因為 Xcelium 不同版本對 SystemVerilog 特性和語法檢查的嚴格程度不一樣同一個工程換版本可能有完全不同的報錯行為。從資源文檔里可以看到 xrun 核心有三段xmvlog對應 compilexmelab對應 elaboratexmsim對應 sim。這三個名字后面 debug 時要記住因為xmhelp查錯誤就是按這三個工具名查的。2.2 單步仿真一條命令的省心與局限xrun 默認是單步仿真意思是它自己把 compile編譯、elaborate細化、sim仿真三個階段一次性跑完。$ xrun test.v // 一個命令仿真完成不用手動區(qū)分三個階段單步仿真的優(yōu)點是省事。寫一個小模塊、跑一個簡單 testbench一條命令下去該出的波形、log 都有了。但它的局限也很明顯你沒法在 compile 之后、simulate 之前插入額外操作也沒法只重跑仿真而跳過編譯。工程一旦變大比如幾千個文件、有 IP 有 memory model單步仿真的效率就很尷尬了改一行代碼要全量重來。所以實際工程里我更推薦把階段拆開這也是這份文檔里最有價值的部分三個階段對應三個命令但它們之間有聯(lián)動關系不是完全獨立的。2.3 三步分離compile、elaborate、sim 的聯(lián)動機制$ xrun -compile test.v // 階段一編譯源碼生成 library 寫入 xcelium.d 目錄 $ xrun -elaborate test.v // 階段二細化設計生成 snapshot $ xrun -R // 階段三加載 snapshot 并執(zhí)行仿真注意文檔里強調了一個細節(jié)如果 elaborate 之前沒做 compile當前 elaborate 會自動執(zhí)行 compile。也就是說-elaborate自帶對 compile 的依賴檢查。-R則會在當前目錄自動檢測 elaborate 生成的 snapshot找到就 load找不到會報錯。這個聯(lián)動機制在日常使用中很有用。比如你只改了 testbench 里的約束沒動 RTL那重新 elaborate 就夠不必重新 compile 所有設計文件。但 xrun 的默認重載機制會更激進——它檢測到代碼有任何修改會重新走完整的 compileelaborate。想強制跳過這個檢測用-clean$ xrun -clean test.v // 忽略之前的編譯結果強制全量重來-clean在兩種場景下是救命的一是之前 compile 是在不同 option 組合下跑的snapshot 狀態(tài)不可信二是改了-timescale、-access這類影響全局的 option舊結果不能復用。但反過來如果只是改了局部源碼我一般不給-clean讓 xrun 自己去做增量省時間。2.4 基礎 option 速記每個參數的含義和適用邊界文檔列了一批最常用的 option我按實際使用頻率整理成下面這張表Option作用備注-6464bit 模式大設計、內存吃緊時必開-sv支持 SystemVerilog 語言工程里有.sv文件就加上-access rwc設置訪問權限讀、寫、執(zhí)行需要 dump 波形、force 信號時必須有-timescale 1ns/1ps設置仿真時間精度單位/精度能細化不能粗化-f filename掃描文件列表大型工程用 f 文件管理源碼列表-top module指定仿真頂層多頂層或自動檢測失敗時用-l filename指定 log 路徑和名字不指定默認是xrun.log-errormax nerror 數達到 n 時仿真退出防止無效跑仿真浪費時間-parseinfo include打印 compile 階段 include 信息排查 include 路徑問題時用這里重點說兩個容易踩坑的。-access rwc的rwc分別對應 read、write、execute如果你要在仿真中通過force改信號值或者用 UCLI 做交互操作r是遠不夠的得rwc全給。-timescale的單位可以比精度大但精度不能比單位大比如1ns/1ps合法1us/1ns也合法反過來寫1ps/1ns就會報錯。這是很經典的翻車點我看過不少人栽在這上面。2.5 查 option 的正確姿勢1521 個選項別硬背xrun 文檔里明確寫了全部 option 有 1521 個但你常用的可能就二三十個。所以查幫助的本事比記背參數更值錢。$ xrun -helpargs option // 打印出指定 option 的作用和用法 $ xrun -helpall xrun_all_option.txt // 把全部 option 內容導出成文件 $ xmhelp tool error // 查錯誤類型與原因tool 填 xmvlog/xmelab/xmsim我發(fā)現(xiàn)-helpall導出的文件配合 grep 是效率最高的查找方式。比如你想找所有和 coverage 相關的選項直接grep -i coverage xrun_all_option.txt就出來了比自己翻 PDF 文檔快得多。xmhelp這個命令很多老手都不用但它其實是被忽視的 debug 利器?？吹?log 里*E開頭的報錯第一反應應該是xmhelp xmelab error code它會給出一段規(guī)范化的錯誤原因描述比在代碼里瞎找效率高。比如*E,CUVIMG這類詭異錯誤不查說明你根本不知道問題出在 generate 塊的命名規(guī)范上這個在第 5 章避坑部分我會重點展開。3. xcelium.d 目錄與文件機制黑匣子里到底裝了什么3.1 compile 產物與 snapshot文件的來龍去脈xrun 在compile階段生成的是 library編譯庫在elaborate階段生成的是 snapshot仿真快照這兩個東西都放在xcelium.d目錄下。很多人跑完仿真看到這個目錄問能不能刪答案是能刪但不建議隨便刪因為它就是 xrun 的增量緩存刪了下次全量重來。我一般的工作習慣是工程收尾歸檔時不帶xcelium.d但日常迭代中留著它。文檔里提到一個排查技巧就是當你懷疑 snapshot 狀態(tài)不對時不要直接-clean先用工具檢查 snapshot 的生成情況$ xmls -64 // 查看 64bit snapshot 的生成情況這里有個細節(jié)值得注意xmls默認查找的是 32bit snapshot如果你的仿真工具跑在 64bit 模式下必須加-64否則會出現(xiàn)明明生成過 snapshot 卻查不到的詭異現(xiàn)象。我剛開始就被這事坑過一次后來記住多少位的仿真器就用多少位的 xmls 查這個口訣才沒再犯。3.2 默認重載機制xrun 到底在檢測什么文檔里說得很清楚如果之前做過 compile 或 elaboratexrun 默認會檢測代碼是否有修改若無修改則直接重新載入舊結果。這個機制省時間但也有它的不透明之處——它檢測的是文件時間戳和內容不是文件數量。有時候你往工程里加了一個新文件以為會被自動識別結果 xrun 根本不理會為什么因為它檢測的對象是上一次命令中顯式列出的文件集合新文件沒進命令行它就沒理由知道。所以我的習慣是文件列表變了直接用-clean或顯式重新-compile不要賭 xrun 的自動檢測。另外-clean這個選項的語義是忽略之前的全部結果它會清掉舊 snapshot 和 library在時序仿真、覆蓋率合并等對編譯選項敏感的步驟里我用-clean的頻率明顯更高。3.3 xrun 的增量編譯邊界什么能增量什么不能結合文檔內容我總結出自己能接受的增量邊界給新人做個參考可以增量只改 RTL 內部邏輯不改端口、不改參數化配置、不改模塊例化關系。盡量別增量改 testbench 頂層結構、改define、改include 文件路徑、換 timescale。必須全量換語言標準比如從 Verilog 換成 SystemVerilog、開/關覆蓋率收集、切換 32/64bit、改 access 權限。這個邊界不是官方規(guī)定而是我實際踩出來的經驗。覆蓋率收集這個點很微妙因為-coverage是在 elaborate 階段植入 instrumentation 的如果你第一次沒加-coverage跑了 elaborate第二次只是在命令里加了-coverage想重新跑xrun 可能因為代碼沒變而直接復用舊的編譯結果導致覆蓋率選項根本沒生效。正確的做法是任何會影響仿真器內部行為的 option 變更都強制-clean不要依賴 xrun 的自動檢測。4. 高級功能實操波形生成、覆蓋率收集與門級仿真的完整參數鏈4.1 三種波形格式的取舍shm、db、fsdb 分別給誰用仿真不 dump 波形等于白跑但波形格式選錯是很多新手的隱藏痛點。文檔里明確列了三種格式shm 給 Cadence 自家 SimVision 用db 給 Indago 用fsdb 給 Verdi 用。$ xrun test.v -input wave.tcl // tcl 腳本定義波形 dump 行為和時長這里-input指定的是 tcl 腳本而腳本里會根據你需要調對應波形庫的 task。我實際項目里最常用的是 fsdb因為驗證環(huán)境里看波形的主力工具是 Verdi。但注意 fsdb 不是 xrun 內置支持的格式需要顯式加載 debpli 插件$ xrun test.v -loadpli1 ${FSDB_INST_DIR}/.../boot/debpli.so:novas_pli_boot-loadpli1的作用是加載 PLI 庫novas_pli_boot是 Verdi 提供的初始化函數名。省略這個選項的直接后果是仿真 log 里不會報錯但 fsdb 文件就是生成不出來非常隱蔽。我第一次遇到這問題花了半小時排查最后發(fā)現(xiàn)是環(huán)境變量FSDB_INST_DIR沒定義加載路徑本身就是空的。4.2 覆蓋率收集B/E/F/T/U/All 六個字母背后的含義收集覆蓋率是驗證收斂的依據xrun 支持按類型選擇性收集$ xrun test.v -coverage B // 收集 branch coverage $ xrun test.v -coverage E // 收集 expression coverage $ xrun test.v -coverage F // 收集 FSM coverage $ xrun test.v -coverage T // 收集 toggle coverage $ xrun test.v -coverage U // 收集 conditional(expression) coverage $ xrun test.v -coverage All // 全部都要實際項目里我一般用-coverage All單次跑全量收集最后用imcIncisive Metrics Center做 merge 和分析。真正容易翻車的是-covoverwrite。這個 option 的作用是允許覆蓋率數據被覆蓋寫入不加它時第二次跑仿真不會覆蓋第一次的覆蓋率數據而是累積合并。這在跑回歸時是好事因為你要的是多輪累加不是單輪結果。但如果你刻意要對比兩輪不同參數下的覆蓋率差異就必須加-covoverwrite把上一輪清掉$ xrun test.v -coverage All -covoverwrite覆蓋率收集的另一個邊界是它也不能脫離 compile/elaborate 單獨開啟。我的血淚經驗是開覆蓋率時老老實實-clean全量重來省那幾分鐘編譯時間換來的是覆蓋率數據無效的排查成本不劃算。4.3 門級仿真SDF 反標與時序檢查的完整鏈路GLSGate Level Simulation是后端 netlist 驗證的核心環(huán)節(jié)。文檔從$sdf_annotate反標切入我把完整參數鏈整理如下$ xrun netlist.v testbench.v -notimingcheck -nospecify -sdf_verbose這里的參數語義要拆開講-notimingcheck不做時序檢查。它關掉的是$setup、$hold、$width這些時序檢查原語讓仿真在時序違例時不報 violation。-nospecify讓 specify 塊完全不起作用。這比-notimingcheck更粗暴連 specify 里的延時都不算。-sdf_verbose把 SDF 反標的具體信息打到 log 上。這個在排查為什么某個 cell 的延時沒有反標進去時是必開項。我實際做 GLS 時還常配一個參數-sdf_verbose跑第一遍確認所有 instance 都反標到了確認無誤再關掉跑正式回歸因為 verbose 輸出會拖慢仿真速度。如果一個 SDF 文件只反標了部分模塊可以用-sdf_verbose看反標統(tǒng)計但更精細的控制要結合代碼里的$sdf_annotate寫區(qū)域限定。另外文檔里給了-tfile來精細關閉特定模塊的時序檢查$ xrun netlist.v testbench.v -tfile tcheck.filetcheck.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第一行是關閉ff_i0這個 instance 的全部時序檢查第二行只看setup這類第三行的...是通配指test下所有層次的 timing check 全部關閉。實際使用時我建議盡量精確到 instance不要濫用...通配因為它會把關鍵路徑的時序檢查也關掉門級仿真就失去了一半意義。4.4 特殊擴展名與性能剖析參數幾條少有人提但關鍵的選項文檔里還埋了幾個平時不太被人注意、但在特定場景非常頂用的選項$ xrun test.v11 -sysv_ext .v11 // 把 .v11 結尾的文件識別為 SystemVerilog $ xrun test.v -vlog_ext .v11 // 把 .v11 結尾的文件識別為 Verilog $ xrun test.v -profile // 生成 profile.out含各組件時間與內存消耗 $ xrun test.v -profoutput prof.txt // 指定 profile 輸出文件不覆蓋默認的 profile.out我在多版本混合項目里用過-sysv_ext這類擴展名選項。公司自研 IP 庫里有舊的.v文件其實內容是 SV 語法不想為了適配去改文件后綴就用-sysv_ext .v暴力把.v全識別為 SV——這招好用但慎用因為它影響所有.v的解析方式如果有老工程混合了純 Verilog會把語法檢查標準提高一個檔次導致舊代碼報一堆無辜錯誤。-profile是我排查性能問題時的第一選擇。當仿真跑得異常慢先開-profile看 profile.out 里的時間分布如果大部分時間花在 license check 上那是 license 服務器的問題如果花在 PLI 回調上那是你 testbench 的$monitor或者 force/release 太頻繁。這個診斷思路遠比盲目優(yōu)化 RTL 代碼效率高。5. 避坑與調試實戰(zhàn)五條踩坑記錄從 *E 報錯到仿真死循環(huán)全解析5.1 隱式命名報錯*E,CUVIMG的根因與 check 方法現(xiàn)象elaborate 階段報*E,CUVIMG提示 implicit name 在 hierarchy 中出錯代碼里怎么看怎么覺得邏輯沒問題。原因這個報錯十有八九出在 generate 塊上。Verilog-2001 規(guī)定 generate 塊必須顯式命名你沒寫名字或者名字寫得不規(guī)范xrun 無法在 hierarchical path 中引用它就報隱式名字錯誤。實際工程里if generate嵌套在for generate內部、又沒有給中間層命名的情況我也見到過。解決按標準寫法給 generate 塊補名字比如genvar i; generate for (i0; i8; ii1) begin : gen_blk ... end endgenerate。如果想放寬 xrun 對這類問題的語法檢查可以在 compile 階段加-genhier。但這個選項是放寬不是修復建議只是臨時繞過最終還是要改代碼補名字。5.2 license 報錯NOLICN 的三種可能性排查現(xiàn)象仿真在 elaberate 通過后、開始 simulation 的瞬間log 里出現(xiàn)xmsim: *F,NOLICN: Unable to checkout license for the simulation. lic_error -18仿真直接退出。原因xrun 只在 simulation 階段才檢測 licensecompile 和 elaborate 階段不檢測。所以你這個報錯不是編譯出問題而是模擬階段拿不到 license 授權。解決如果確認服務器上 license 剩余數量充足問題可能出在你沒有某些 feature 的授權。用 Linux 命令看 license 安裝信息$ lmstat -a -c $LM_LICENSE_FILE // 如果 LM_LICENSE_FILE 指向 license 文件 $ lmstat -a -c $CDS_LIC_FILE // 如果 CDS_LIC_FILE 指向 license 文件如果 license 不夠用xrun 提供了排隊等待機制$ xrun test.v -licqueue // 提交后進入 license 等待隊列等到了再跑實際使用中-licqueue適合大量并行回歸。注意排隊時間不設上限regression 跑到凌晨job 就排隊掛到凌晨。所以不是無腦加這個選項要評估隊列深度。5.3 仿真掛死先看波形還是先看 profile順序不能錯現(xiàn)象仿真器進程還在但 log 長時間不增長看起來像是死循環(huán)。原因不一定是死循環(huán)。文檔把這三種情況都列出來了我在實際項目中都遇到前兩種解決第一步先打開波形窗口看波形時間軸是否在前進。時間軸在走仿真就沒掛只是慢時間軸完全不動那才是真的堵住了。第二步如果時間軸不動加-gui -linedebug定位卡住的代碼行這個組合會把當前執(zhí)行位置實時反映在源碼窗口上。第三步加-profile看 profile.out重點看 license check 時間如果它異常巨大說明仿真卡在等待 license 上不是死循環(huán)而是許可瓶頸。要是做的是 gate level 仿真還有一個非常容易被忽略的點零延遲門級震蕩。門級網表的組合環(huán)如果沒有延時就可能高頻振蕩仿真器陷進去出不來。加-gateloopwarn會打印具體震蕩路徑信息用這個定位到底是哪個 loop 在振再去查后端 netlist 是否插了必要的 delay cell。5.4 -loadpli1 大小寫和路徑順序fsdb 生成的一個隱性隱患現(xiàn)象-input wave.tcl指定了 fsdb dump 腳本仿真正常跑完但目標目錄下根本沒有 fsdb 文件也不報錯。原因-loadpli1的路徑不對或者環(huán)境變量FSDB_INST_DIR沒有定義xrun 靜默忽略了加載后面 tcl 里調fsdbDumpfile時找不到對應 task但因為 tcl 腳本沒做錯誤檢查仿真照跑。解決嚴格按照文檔樣例寫完整路徑-loadpli1 ${FSDB_INST_DIR}/.../boot/debpli.so:novas_pli_boot并且用bash -c echo $FSDB_INST_DIR先確認變量存在。另外檢查-loadpli1是否在 compile 階段之前被參數解析器處理這個 option 必須出現(xiàn)在 xrun 命令行中不能直接寫進 f 文件f 文件里加載有時序問題。5.5-timescale寫反工具不報錯但結果全歪的情況現(xiàn)象仿真不報任何錯誤但波形上的延遲時間完全對不上。比如預期的時鐘是 10ns 周期波形量出來是 10ms。原因-timescale 1ps/1ns這種精度比單位大的寫法不正確。單位規(guī)定了時間值的度量單位精度規(guī)定了時間值可以精確到的程度。精度不能比單位更粗實際使用時很多人寫反了也不報錯但所有延時都按錯誤換算輸出結果整個仿真時間軸都失真。解決確認時間語義是單位比精度大或相等。1ns/1ps是標準推薦1us/1ns也穩(wěn)妥。如果你要測亞穩(wěn)態(tài)需要皮秒級精度就寫1ns/1ps而不是反過來。另外多個文件混合時xrun 默認按最精細的精度做全局時間精度這可能拖慢整體仿真速度可以考慮在關鍵模塊上縮小精度范圍。6. 代碼與參數技巧速查一個工程從編譯到調試的完整命令行參考6.1 日常迭代的完整 xrun 命令模板實際項目里我常寫的 xrun 命令比文檔里的單命令要長不少通常是一個 f 文件加一堆全局 optionxrun -f rtl.f -f tb.f -sv -64 -access rwc \ -timescale 1ns/1ps -top tb_top \ -coverage All -covoverwrite \ -input wave.tcl -l run.log這份命令在一天內會反復用。注意-sv的使用場景是 f 文件列表里既有.v也有.sv加這個是讓 .sv 文件按 SystemVerilog 標準解析如果沒有.sv文件加了無害但也沒必要。-top tb_top指定頂層避免多頂層模塊的存在讓 xrun 無法自動識別。-input wave.tcl走的是 tcl 腳本里面由fsdbDumpfile這類 task 控制波形文件生成不在命令行里直接指定格式便于仿真前改波形配置而不動 xrun 主體命令。6.2 性能排查兩步走profile 優(yōu)先linedebug 兜底遇到仿真速度慢到可疑的情況我有固定的排查路徑$ xrun test.v -profile -profoutput prof_i0.txt打開 prof_i0.txt 看時間分布。重點看兩類時間license check 時間如果占到總時長 10% 以上說明 license 在拖后腿和各個編譯組件耗時。xrun 的 profile 輸出里包含了檢查 license 時間、各組件消耗仿真時間這些數據能幫你精確區(qū)分是 license 瓶頸、PLI 回調瓶頸還是 RTL 本身仿真慢。如果 profile 顯示 license check 正常、組件消耗均衡但還是慢再用-gui -linedebug掛在仿真上看它停在哪一行判斷是測試代碼里的循環(huán)等待問題還是 RTL 本身的死循環(huán)邏輯。6.3 門級震蕩與 SDF 反標的最后兜底門級仿真時如果出現(xiàn)時序異常反復、仿真停在某些門級路徑上我最后會開這三個參數組合$ xrun netlist.v tb.v -sdf_verbose -gateloopwarn -notimingcheck-sdf_verbose打印所有 SDF 反標條目方便確認反標量-gateloopwarn把組合環(huán)位置提示出來避免仿真真死在里面-notimingcheck在初步驗證功能階段關掉時序約束讓功能先對上。等前兩步通過后再把-notimingcheck去掉跑正式時序驗證。這套流程做完工程 speed 和正確性才都收住?，F(xiàn)在我每次起新工程第一件事就是把 xrun 這份命令模板、tcl 腳本結構和 f 文件組織方式一起拷過來寧可在開頭多花十分鐘搭框架也絕不在跑完一輪回歸后才回頭補 option。也希望我的這份拆解對你上手機器有幫助。本文還有配套的精品資源點擊獲取