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