SoC基本仿真環(huán)境介紹

我在論壇上寫過一個(gè)。《如何搭建SoC項(xiàng)目的基本Testbench（我的流程）》，這里挑重要的和有改變的地方說一下。

假設(shè)這個(gè)SoC有CPU系統(tǒng)、內(nèi)存控制器、總線拓?fù)洹AD、Clockreset和一些邏輯功能模塊。

1. 仿真環(huán)境中有嵌入式軟件（firmware）

這里包括兩部分，一是初始化的bootloader（一般是固化在rom或者存放在外部的flash里），一是boot起來以后放在外部易失性存儲(chǔ)介質(zhì)上的應(yīng)用層面的程序。

2. 使用指令集模擬器（ISS）來代替CPU-IP.

有開源的也有不開源免費(fèi)的ARM多款處理器IP的ISS.考慮到ISS本身并不真實(shí)，如果不是為了驗(yàn)證bootrom代碼的話，個(gè)人建議找一個(gè)開源的就可以了。ISS可以編譯成.so的庫文件，這樣在仿真的時(shí)候就不用編譯整套ISS的C代碼了(需要設(shè)置LD_LIBRARY_PATH，告訴仿真器仿真的時(shí)候去哪里找；編譯過程中需要告訴鏈接庫地址和庫名稱)。

ISS需要一個(gè)配置文件來告訴它CPU的地址訪問空間，像程序區(qū)、堆棧區(qū)是ISS管理的空間（假設(shè)叫memory空間），像DUT的內(nèi)存地址以及DUT的寄存器空間就是DUT管理的空間（假設(shè)叫IO空間），ISS要能看到所有的地址空間，并且根據(jù)地址來判斷是memory空間還是IO空間來做不同的操作。

3. 共享空間CPU（ISS）和Testbench交互的時(shí)候可以指定一塊地址空間（比如0x3000_0000 ~ 0x3100_0000），這塊空間就是testbench中的一個(gè)數(shù)組。比如要實(shí)現(xiàn)對(duì)寄存器的隨機(jī)配置，由于ISS的C程序不方便做約束隨機(jī)，可以在Testbench組件中把約束隨機(jī)產(chǎn)生好的數(shù)值寫入到這塊共享空間中，然后讓ISS的C讀出共享空間的數(shù)值再配到寄存器中。

4. Define文件的維護(hù)

SoC項(xiàng)目中Testbench的一個(gè)define可能同時(shí)在匯編程序、嵌入式C程序、Cmodel的C程序、Testbench的SV代碼都要使用。同時(shí)維護(hù)多個(gè)類似的define文件肯定容易出錯(cuò)，所以只維護(hù)一個(gè)，其他的由腳本程序自動(dòng)產(chǎn)生。

5. 內(nèi)存控制器模塊（DDRC）的替換

DDRC是系統(tǒng)中最主要BUS-Slaver，通常需要初始化過程（也有的ddrc不需要），還通常需要DDR-PHY的模型，這些都比較影響仿真速度。而且在驗(yàn)證功能模塊的時(shí)候，使用DDRC也不容易模擬帶寬不同變化的場(chǎng)景。因此驗(yàn)證的時(shí)候可以考慮用一個(gè)BUS-Slaver的BFM來代替DDRC.

6. 打印的實(shí)現(xiàn)在SoC環(huán)境的Testcase的嵌入式C語言程序中沒有標(biāo)準(zhǔn)的stdio，所以要實(shí)現(xiàn)printf. printf是“不定參數(shù)個(gè)數(shù)的函數(shù)”，利用“參數(shù)從右向左壓棧，最開始的參數(shù)在最接近棧頂?shù)奈恢茫址詈笠粋€(gè)字符是\0”來實(shí)現(xiàn)printf.在C端只需要把第一個(gè)參數(shù)的地址（肯定不是0）傳到共享空間指定位置，在SVTB中獲取到地址以后按照%和參數(shù)地址來實(shí)現(xiàn)（SV端的實(shí)現(xiàn)和C語言里printf的實(shí)現(xiàn)很類似），需要注意的是1）C端程序要保證參數(shù)地址及時(shí)寫入到共享空間中，不要停在cache或者傳輸太長；2）使用ISS要打印的信息存在memory空間里，要能讓SV端看到memory空間。當(dāng)使用多核CPU-RTL的時(shí)候，注意不同core的打印控制（可以為每個(gè)core分配一個(gè)共享的空間，在print函數(shù)中根據(jù)不同的core-id來執(zhí)行不同的操作）。

malloc等函數(shù)的實(shí)現(xiàn)也可以利用共享空間來實(shí)現(xiàn)。

7. 多個(gè)模塊的協(xié)同驗(yàn)證在系統(tǒng)級(jí)下經(jīng)常要跑系統(tǒng)級(jí)case來模擬整個(gè)系統(tǒng)一起工作起來的場(chǎng)景（一般該case也適用于power分析）。這種case可能要花比較大的精力在Testcase的構(gòu)造上，如果有硬件仿真加速器還好，如果只能在純粹的仿真環(huán)境下做的話，盡量做簡化處理。

8. 單一case流程編譯dut和testbenchà編譯firmwareà開始仿真（在合適的時(shí)機(jī)loadfirmware和產(chǎn)生隨機(jī)控制數(shù)據(jù)寫入到共享空間。如果要把firmware load到ddr model中，并且DDRC初始化流程會(huì)做data-training這種寫數(shù)據(jù)的操作，那要保證初始化的數(shù)據(jù)不要被沖掉）

模塊級(jí)驗(yàn)證相對(duì)于系統(tǒng)（子系統(tǒng)）級(jí)仿真環(huán)境的優(yōu)勢(shì)：

1）仿真速度快

2）隨機(jī)可控性好

3）更容易做Error-Injection

4）更容易做開關(guān)切換和模式切換

仿真工具（2010年以后的版本）都支持模塊級(jí)和系統(tǒng)級(jí)的覆蓋率合并，可以加速收斂。

需要注意的是：雖然模塊級(jí)環(huán)境理論上可以覆蓋所有的系統(tǒng)級(jí)環(huán)境里的情況，但是在有限的人力和時(shí)間資源的情況下，很可能達(dá)不到100%的覆蓋。舉個(gè)例子：視頻外同步的dataenable信號(hào)變化情況過多，以至于random不到實(shí)際系統(tǒng)中可能出現(xiàn)的情況。總之：關(guān)鍵是模塊級(jí)環(huán)境有可能沒有覆蓋到實(shí)際中可能出現(xiàn)的情況。

模塊級(jí)環(huán)境基礎(chǔ)結(jié)構(gòu)

模塊級(jí)基礎(chǔ)環(huán)境中除了有驗(yàn)證組件（monitor driver scoreboard等），還有一條總線連接Master和Slave、CPU-Model控制DUT.注意：這里所說的模塊級(jí)環(huán)境里的DUT是一個(gè)完整的模塊，不考慮一個(gè)模塊內(nèi)部的子模塊.

假定DUT是一個(gè)總線的Master設(shè)備，會(huì)發(fā)起訪存操作。CPU-Model負(fù)責(zé)配置寄存器和一些訪存，模塊級(jí)環(huán)境為了簡化，讓CPU-Model不用通過總線而是直接訪問Bus-Slaver的空間。

模塊級(jí)環(huán)境Testcase在系統(tǒng)級(jí)上的重用

在人員和時(shí)間資源有限的情況，要保證模塊級(jí)代碼在系統(tǒng)級(jí)上的重用。一般來說Testbench組件（Driver Monitor Model Scoreboard等）重用比較簡單，比較麻煩的是testcase在SoC系統(tǒng)級(jí)（CPU上的C程序）環(huán)境下的重用比較麻煩。Testcase構(gòu)建是由TB架構(gòu)中CPU-Model的實(shí)現(xiàn)方法決定的。下面兩種我主要用的方案Testcase都是C的.

方案一：

使用ISS實(shí)現(xiàn)。與SoC基本仿真環(huán)境比較一致。

方案二：

使用DPI實(shí)現(xiàn)。CPU-Model是一個(gè)SV的model，實(shí)現(xiàn)寄存器訪問和內(nèi)存地址空間訪問的task，比較復(fù)雜的是對(duì)中斷的模擬。可以使用sv的fine-grain-process(process::self())來實(shí)現(xiàn)main-task和irq-task，模擬“CPU進(jìn)入中斷以后掛起主程序，執(zhí)行完中斷以后返回主程序”(main_task.suspend(); ….; main_task.resume();)的行為。使用DPI來把底層硬件接口的SV-Task傳遞給C程序。

DPI實(shí)現(xiàn)的方案中要注意底層硬件接口的代碼，以及C代碼中直接訪問的代碼（例如指向DUT內(nèi)存的指針的操作），尤其是IP-Vendor提供的參考代碼里很可能有類似代碼。比如，usb ethernet的軟硬件交互的協(xié)議棧放在內(nèi)存中，軟件代碼中一般會(huì)維護(hù)一個(gè)數(shù)據(jù)結(jié)構(gòu)，然后指針指向數(shù)據(jù)結(jié)構(gòu)地址操作。dpi環(huán)境下這樣的代碼就沒法直接用了（指針的操作就不行了，得換成硬件底層代碼實(shí)現(xiàn)）。這樣模塊的firmware代碼可能是現(xiàn)成的，仿真應(yīng)該盡量復(fù)用。簡單的方案就直接放棄模塊級(jí)環(huán)境，上系統(tǒng)級(jí)環(huán)境里驗(yàn)證，或者用iss。iss環(huán)境下，firmware代碼可能也要修改，比如上述的數(shù)據(jù)結(jié)構(gòu)地址就要注意分配到dut內(nèi)存地址上去（比如一個(gè)大的struct的賦值操作，先malloc出一塊空間，然后向這個(gè)空間填數(shù)。只要malloc到dut內(nèi)存地址上就可以了）。

其他方案：

Testcase不用C直接使用SV實(shí)現(xiàn)；或者把CPU-Model換成真實(shí)的CPU-IP，帶上boot-rom和boot-ram。

架構(gòu)評(píng)估

個(gè)人首推還是硬件加速器，需要注意的是架構(gòu)評(píng)估最好保證頻率的比例關(guān)系（訪存模塊的總線訪問頻率、總線拓?fù)渲懈鹘M件頻率、內(nèi)存控制器和內(nèi)存工作頻率），個(gè)人感覺可能Palladium和Veloce這種方案的硬件加速器更加適合。

如果采用仿真的方法做評(píng)估的話，需要注意：

1）pattern的真實(shí)性。現(xiàn)成的模塊RTL雖然可以反映真實(shí)的訪存行為和latency的容忍度，但是構(gòu)建環(huán)境偏復(fù)雜，仿真速度偏慢，通常還需要有初始化流程才能工作。個(gè)人建議構(gòu)造BFM模擬訪存行為：BFM可以吃配置文件，從而模擬比較真實(shí)的場(chǎng)景。

2）基礎(chǔ)架構(gòu)的自動(dòng)集成。稍微復(fù)雜一點(diǎn)的SoC架構(gòu)中，總線拓?fù)涞募煽赡芫秃軓?fù)雜了（統(tǒng)一的組件不太方便用emacs自動(dòng)集成的功能來做，而且一些特殊信號(hào)位寬的匹配手動(dòng)做起來很容易出錯(cuò)）。多年前就有自動(dòng)化的工具來實(shí)現(xiàn)這個(gè)集成。但是商業(yè)化的工具雖然提供了很多的功能，但是未必能直接滿足個(gè)體項(xiàng)目的需求，建議考慮開發(fā)自動(dòng)集成的工具。目前的low-powerflow里已經(jīng)不用在架構(gòu)集成的RTL中寫入多少額外的代碼了，簡化了自動(dòng)集成的難度。

架構(gòu)評(píng)估環(huán)境里還需要有內(nèi)存控制器和總線架構(gòu)模塊的performance-monitor，來統(tǒng)計(jì)吞吐量、內(nèi)存控制器效率、功能模塊訪存行為的latency等，根據(jù)吞吐量來看架構(gòu)評(píng)估環(huán)境是否和期望的訪存數(shù)據(jù)量比較一致，在這個(gè)前提下看內(nèi)存控制器的效率達(dá)到了多少，以及系統(tǒng)中哪個(gè)模塊會(huì)出現(xiàn)不合理的比較大的latency（導(dǎo)致該模塊可能設(shè)計(jì)的時(shí)候需要加大fifo深度）。通過調(diào)整內(nèi)存控制器和總線拓?fù)淠K的優(yōu)先級(jí)策略、時(shí)鐘頻率或者增減總線拓?fù)浣M件以及Master/Slave口的數(shù)量來做不同的仿真。

VIP的使用

通常我們對(duì)復(fù)雜的標(biāo)準(zhǔn)接口協(xié)議的數(shù)通模塊采用vip做bfm來驗(yàn)證。

vip的好處是不用特別開發(fā)bfm，有完整的tb組件，有的文檔中有比較完善的測(cè)試計(jì)劃和實(shí)例，隨機(jī)性和error-injection完備。壞處是代碼不可見，遇到問題容易抓瞎；vip作為工具安裝使用可能挑OS和仿真器；EDA vendor本地support人員不足等問題，通常VIP跑的速度比較慢。

能力和資源允許的情況下可以自己開發(fā)bfm.一種比較快的方案是reuse靠譜的rtl ip。比如我們要驗(yàn)證usbhost，那就找一個(gè)usb device或者uotg的rtl ip做bfm.這種方法的優(yōu)勢(shì)：BFM代碼質(zhì)量比較高，debug可見性高，將來在硬件加速器上可以更好的移植(有的可以不用phy,數(shù)字接口直接連)。劣勢(shì)：開發(fā)代碼量也不小，有的phy模型可能是個(gè)問題（比如一些單向數(shù)據(jù)傳輸?shù)模琈aster端是并行數(shù)據(jù)轉(zhuǎn)LVDS，Slave端是LVDS轉(zhuǎn)并行數(shù)據(jù)，這樣的PHY model可能需要另外開發(fā)），rtl通常需要初始化過程，隨機(jī)性和error-injection不夠友好。

我覺得如果DUT是內(nèi)部開發(fā)的話，因?yàn)榇a質(zhì)量可能不夠，用商用的vip更合適。如果DUT是買的已經(jīng)silicon-verification的IP的話，我覺得自己開發(fā)的BFM就夠了。

Coverage-Driven和Assertion-Based

個(gè)人認(rèn)為代碼覆蓋率是最重要的，是一定要統(tǒng)計(jì)和仔細(xì)的檢查的。

功能覆蓋率（包括assertion的覆蓋率）應(yīng)該是Testplan的反映，我覺得只是提供對(duì)Testplan覆蓋的數(shù)據(jù)統(tǒng)計(jì)，Testplan本身可能是不完備的，所以功能覆蓋率的100%并不能代表驗(yàn)證充分了。

Assertion對(duì)于一些不太復(fù)雜的協(xié)議時(shí)序驗(yàn)證還是比較適合的，但是感覺最近幾年EDA公司都不太在assertion上投入資源了。我覺得對(duì)于一個(gè)大模塊內(nèi)部的子模塊，assertion是非常適合的，可以針對(duì)子模塊的接口具體的做assertion的描述和驗(yàn)證。

仿真層面的加速

最快的加速技術(shù)肯定是硬件仿真加速器。

在“SoC基本仿真環(huán)境介紹”中的CPU和DDRC的替換都有加速仿真的功能。除此之外還有一些我在用的加速方法：

1）系統(tǒng)級(jí)仿真環(huán)境中把不需要的模塊dummy掉。-----需要兩個(gè)腳本程序，一個(gè)是自動(dòng)產(chǎn)生dummy文件，一個(gè)是自動(dòng)把dummy文件替換掉原有的RTL.

2）縮短SoC上電啟動(dòng)仿真時(shí)間。----通常是一個(gè)狀態(tài)機(jī)根據(jù)若干個(gè)counter的技術(shù)來實(shí)現(xiàn)狀態(tài)跳轉(zhuǎn)。方法是更改counter的初始值或者跳轉(zhuǎn)需要的數(shù)值，RTL級(jí)比較容易實(shí)現(xiàn)，門級(jí)仿真找信號(hào)比較麻煩，最好提前和flow的同事溝通好，把信號(hào)名保持住。

3）有些DUT里的IP比較耗仿真資源，可以考慮用簡化的model代替。比如PLL、DCM以及某些PHY-Model.

4）某些RTL代碼的寫法可能很耗仿真資源。比如在clock的每個(gè)上升沿當(dāng)reset有效的時(shí)候把一個(gè)比較大的二維數(shù)組附初始值。這種代碼最好加ifdefelse endif來改寫成Initial-block.

5）減少DPI過于頻繁的交互

6）謹(jǐn)慎使用separate-compilepartition-compile等技術(shù)，也許帶來負(fù)面效果。

門級(jí)仿真

功能仿真中一般有如下幾類門級(jí)仿真：

1）綜合后網(wǎng)表仿真

2）DFT后網(wǎng)表仿真

3）PR后反標(biāo)SDF的網(wǎng)表仿真

4）FPGA綜合后網(wǎng)表仿真

5）Gtech網(wǎng)表的仿真

綜合后和DFT后的網(wǎng)表比較類似，一般跑DFT以后的就可以了。除PR后的網(wǎng)表要反標(biāo)SDF以外，其他的都是跑0delay的門級(jí)仿真。一般額外做幾個(gè)處理：

1）給std-lib cell庫文件中給時(shí)序邏輯（dff等）加上clk2q的delay

2）保證SRAM model的輸出端在不工作的時(shí)候不要輸出X.

3）門級(jí)網(wǎng)表中如果有不帶reset端的dff，一般要找出來做$deposit處理（找的方法可以請(qǐng)flow的同事拿對(duì)應(yīng)的網(wǎng)表出一版sdf，然后parser sdf文件就可以得到對(duì)應(yīng)instance里的dff）。

4）反標(biāo)SDF的門級(jí)仿真如果checktiming的話，要注意把2dff等跨時(shí)鐘域的邏輯的timingcheck去掉。

FPGA綜合后的網(wǎng)表仿真一般不用做，但是當(dāng)FPGA timing報(bào)告、FPGA功能仿真、CDC和Lint-check都沒有問題，懷疑FPGA綜合有問題的時(shí)候值得做一下。我在做FPGA綜合后網(wǎng)表仿真中發(fā)現(xiàn)過幾個(gè)問題：1）Xilinx-V7默認(rèn)把RTL中復(fù)雜的case語句用blockram實(shí)現(xiàn)，結(jié)果實(shí)現(xiàn)的時(shí)候時(shí)序差了一拍2）FPGA把RTL里的一些運(yùn)算直接用內(nèi)部的DSP來實(shí)現(xiàn)，結(jié)果DSP的功能綜合錯(cuò)誤。FPGA綜合網(wǎng)表的信號(hào)名太亂，Testbench如果拉了一些內(nèi)部信號(hào)進(jìn)行觀測(cè)或者force的話，很難編譯通過。

Gtech網(wǎng)表的仿真很少需要做，如果FPGA上跑Gtech網(wǎng)表來代替RTL的話，需要注意FPGA版本Gtech單元的行為描述要保證和Asic的一致，否則容易有“坑”.

PR后門級(jí)仿真重點(diǎn)是出比較準(zhǔn)確的IR-Drop和Power數(shù)據(jù)，以及保證時(shí)序約束的完整和正確性，建議只跑典型的case就可以了。

仿真驗(yàn)證自動(dòng)化

舉例一些Testbench的自動(dòng)檢查機(jī)制以外的自動(dòng)化技術(shù)（很多是用crontab自動(dòng)執(zhí)行）。

1）每天自動(dòng)checkout出一份代碼做mini-regression，并且把結(jié)果自動(dòng)發(fā)email通知給項(xiàng)目組。

2）每隔幾個(gè)小時(shí)一旦檢查到有新tag就自動(dòng)update到新tag上做mini-regression并自動(dòng)發(fā)email

3）每天自動(dòng)把所有checkin的代碼列出來并自動(dòng)發(fā)email

4）每天自動(dòng)把未解決的問題總結(jié)并發(fā)郵件（bug-zilla、issue-tracker、Jira等bug-tracking系統(tǒng)有的自帶這個(gè)功能，有的可能沒有需要自己實(shí)現(xiàn)）

5）自動(dòng)代碼備份（有的代碼可能還在開發(fā)過程中，所以不想checkin到代碼庫里去，如果MIS沒有針對(duì)這類代碼做自動(dòng)備份，可能需要一個(gè)自動(dòng)備份的程序，）

6）除了自動(dòng)比對(duì)環(huán)境以外，還要有一個(gè)parse編譯和仿真log的程序在regression的時(shí)候調(diào)用。

如果某個(gè)功能上沒有自動(dòng)檢查機(jī)制，也要盡量想辦法減少人工比對(duì)的工作量。例如，有一個(gè)圖像算法模塊的c-code找不到了，但是RTL是golden的，跑實(shí)際圖形pattern一幅圖一幅圖看會(huì)比較耗時(shí)間，可以把regression中產(chǎn)生的圖像打包到一個(gè)網(wǎng)頁中，然后用瀏覽器去看。

腳本語言是仿真工作中非常重要的一環(huán)。我們一般會(huì)用到shell\perl\tcl\python等腳本語言，建議在學(xué)習(xí)腳本語言期間，強(qiáng)迫自己遇到問題使用正在學(xué)的語言來實(shí)現(xiàn)。

驗(yàn)證項(xiàng)目管理

http://bbs.eetop.cn/thread-581216-1-1.html《多媒體類SoC項(xiàng)目Verification Project Leader工作內(nèi)容介紹（討論）》我在這個(gè)帖子里列的比較詳細(xì)了，VerificationEngineer的工作基本上是Verification Project Leader的子集。

帖子里是按照項(xiàng)目開始前的準(zhǔn)備à項(xiàng)目啟動(dòng)但未提供第一版integration代碼à0.5版本à0.75版本à0.9版本à1.0版本àTO前到TO后的項(xiàng)目開發(fā)時(shí)間來寫的。我在這里列一下帖子里幾個(gè)沒有提到的內(nèi)容。

Leader要注意把握驗(yàn)證流程，上FPGA驗(yàn)證前除了仿真和檢查FPGA時(shí)序以外，還要做CDC和Lint等靜態(tài)驗(yàn)證檢查。

Leader及時(shí)給項(xiàng)目組內(nèi)新同事培訓(xùn)工作環(huán)境基本技能，避免組內(nèi)同事出現(xiàn)因?yàn)楣ぷ鳝h(huán)境影響工作效率（比如不同的工具對(duì)機(jī)器的要求側(cè)重點(diǎn)不同，有的要求cache大，有的要求memory大，可能要綜合考慮cache\memory\cpu-core-num\cpu-frequency等因素。如果MIS沒有按照機(jī)器性能來進(jìn)行LSF計(jì)算資源劃分的話，使用LSF預(yù)先配置的分配策略可能會(huì)把任務(wù)提交到不合適的機(jī)器上.）

注意避免驗(yàn)證工程師過度依賴模塊級(jí)環(huán)境。比如FPGA上報(bào)了問題，模塊級(jí)上復(fù)現(xiàn)不出來就認(rèn)為沒有功能問題了。

Leader一定要及時(shí)總結(jié)所有仿真遺漏的bug，開發(fā)階段通常是設(shè)計(jì)工程師項(xiàng)目后期模塊級(jí)環(huán)境跑仿真暴露以及FPGA上發(fā)現(xiàn)的bug.有的bug可能是由于FPGA在仿真驗(yàn)證過之前就開始導(dǎo)致遺漏的，對(duì)于的確是驗(yàn)證工程師遺漏的bug要特別關(guān)注。

一般Power數(shù)據(jù)是來源于門級(jí)仿真的VCD或者Saif文件，隨著設(shè)計(jì)越來越大，有可能導(dǎo)致VCD文件過大，這種情況下及時(shí)與跑power分析的同事溝通，看有沒有合適的手段解決。有的硬件加速器可以內(nèi)部分析哪段時(shí)間翻轉(zhuǎn)劇烈，可以根據(jù)這個(gè)信息來dump vcd.注意一點(diǎn)：當(dāng)要dump的信號(hào)特別多的時(shí)候，其實(shí)dump vcd和dump fsdb這種壓縮格式的文件大小是差不多的（大量的存儲(chǔ)用來構(gòu)建信號(hào)名的表了），這種情況下直接dump vcd就可以了，還可以避免引入dump波形的PLI和后面的格式轉(zhuǎn)換工作。

理論上說驗(yàn)證是做不完的，有所為有所不為。leader不能把事情大包大攬，有些事情在資源有限的情況下要推出去。

及時(shí)總結(jié)記錄和分析

重用程度高的項(xiàng)目很容易犯經(jīng)驗(yàn)錯(cuò)誤，千萬謹(jǐn)慎。改動(dòng)的地方加強(qiáng)review.