嵌入式系統芯片的軟硬件協同仿真環境設計

官楓林,習友寶,劉斌

(1.電子科技大學電子工程學院,成都610000;2.海思半導體成都研究所)

官楓林(碩士研究生),研究方向為ASIC芯片設計與驗證。

1 概 述

隨著微電子產業日新月異的發展,IC設計的規模越來越大,集成度越來越高,已經足以將一套完整的系統集成到一塊小小的芯片中。在這種形勢下,SoC技術應運而生[1]。隨著IP核復用技術的出現,SoC芯片的設計已經不再是很大的難題,SoC芯片的驗證已逐漸取代芯片設計成為芯片開發階段的瓶頸。現階段SoC芯片設計的正確性要經過前仿真、后仿真以及FPGA驗證來保證。前仿真包括單元驗證、集成驗證和系統驗證,后仿真包括帶反標時序SDF的網表仿真。其中系統驗證和后仿真都需要關注SoC芯片的全局功能,這就涉及SoC的軟件仿真和硬件仿真的協同問題。本文以DSM模型替代ARM核,以VMM驗證方法學和VCS仿真器為基礎,搭建一個可重用性高、調試和定位問題方便、仿真真實性高、軟件和硬件能夠很好配合的協同驗證平臺。

軟硬件協同仿真架構如圖1所示,協同驗證分軟件驗證環境和硬件驗證環境兩部分。軟件代碼通常由C/C++和匯編語言混合編寫而成,然后由軟件編譯器轉換成二進制格式,最后將該二進制文件加載到SoC芯片的存儲器中去,芯片boot啟動時由ARM核調用軟件代碼并執行;硬件環境基于VMM驗證方法學進行搭建,下文中會有詳細介紹。協同仿真就是通過事件和命令,使用一些機制,在這兩個環境間進行控制。

2 DSM模型的使用

1 軟硬件協同仿真架構

SoC芯片的CPU一般選用ARM,協同驗證平臺中ARM可以用seamless CVE模型替代,或者直接選用ARM網表。采用seamless CVE模型進行仿真,雖然速度比較快,但需要替換設計中的Memory模型,且必須使用CVE自己的模型,這樣與芯片真實情況有出入;采用ARM網表進行仿真,速度比較慢,調試也不方便,但是更接近實際情況。相比于這兩者,本文采用的DSM(DesignSimulation Model)模型由ARM公司提供,能完全模擬ARM的接口和時序行為,具有更高的真實性,而且 DSM無需更換存儲器模型和外掛仿真工具,使驗證DUT與實際芯片完全一致,即不必為了滿足仿真需求修改部分RTL代碼。此外,DSM環境仿真過程中輸出的LOG文件log.eis真實記錄每個周期執行的CPU代碼和操作。根據該文件能快速定位軟件問題。CVE環境通過調用XRAY軟件調試工具,雖然可以進行單步調試、設置斷點等操作,但出現軟件問題時定位沒有DSM環境那么直觀、方便。

DSM是ARM公司提供的設計仿真模型,該模型直接從ARM公司的RTL代碼經過加密處理轉化而來,具有同真實RTL代碼完全一致的功能和特性。在時序仿真過程中,還能直接對該模型反標時序。在仿真過程中,將模型WRAPPER——也就是模型的最頂層——例化到RTL代碼中,仿真器在仿真過程中觸發WRAPPER,請求Model Manager動態調用模型庫進行仿真。Model Manager響應請求動態調用模型庫文件,達到功能仿真的目的。由此可以看出,Model Manager在仿真過程中充當中介角色,將模型和仿真器動態連接在一起。DSM模型的工作原理如圖2所示。

圖2 DSM模型工作原理

3.軟件仿真

ARM匯編器工具ARMASM、ARM的C/C++編譯工具 ARMCC和 ARMCPP,以及 ARM的鏈接工具ARMLINK,利用ARM工具對軟件代碼進行編譯鏈接生成的文件格式為ELF格式(Executable Link File),原始代碼在文件中的位置通過SCATTER文件指定。ARM提供了fromelf工具,該工具將ELF格式的文件根據運行時域轉化為二進制文件,以便在仿真起始階段將代碼放到指定的Memory中。在makefile中將ELF格式轉化為BIN文件的具體實例如下:

上述語句表示將software.elf文件轉化為二進制文件放到當前目錄。

在軟硬件協同仿真的初始階段,需要將生成的二進制文件導入相應的存儲器中,這通過Verilog提供的系統函數fread實現。下面是一個將二進制文件導入存儲器的實例,先通過＄fopen函數讀出文件地址,然后通過＄fread函數將指定地址的文件數據傳給變量inst_file_word,最后將變量inst_file_word中的值傳給存儲器中的相應地址單元。在DSM仿真中都需要一個這樣的“橋梁”文件,將軟件和邏輯鏈接起來。

軟硬件協同仿真的軟件結構如圖3所示,系統BOOT起來后直接跳轉到main()函數進行單進程任務,如果出現中斷異常,則boot代碼中根據中斷向量表地址跳轉到中斷處理函數。中斷處理函數中包含對各中斷的處理,main()函數中調用各個模塊的TC(Test Case)函數,TC調用底層的驅動代碼。驅動代碼的編寫則基于各個模塊的寄存器定義文件和全局變量。該軟件結構清晰可控,便于各測試用例TC的并行提交和管理。

圖3 軟件結構圖

4 構建基于VMM的軟硬件協同仿真平臺

在軟硬件協同仿真環境中,完全可以采用基于VMM的驗證架構,但軟硬件協同仿真環境較一般的純邏輯集成驗證環境難度大,主要體現在軟硬件協同仿真環境因為仿真過程中有軟件代碼在執行,同時驗證環境也在執行,因此如何將軟件代碼和硬件環境協調起來是關鍵。在仿真過程中,軟件和驗證環境之間需要建立一種通信機制,如可以通過中斷通信,也可以通過某一特殊信號線通信。軟硬件協同仿真環境中,某一項功能點的測試常常需要軟硬件兩條測試用例TC,軟件TC需要驅動代碼,而一般的集成測試用例不需要軟件TC和驅動。典型的VMM的驗證架構如圖4所示。

驗證的總體架構是分層次的,層次化的驗證環境具有很好的擴展性和重用性,各個層次完成自己特定的功能。Test層又叫TC層,主要完成數據激勵的定義、環境的控制工作。Generator層定義的數據“模板”,產生各種數據激勵。Function Layer層完成輸入和輸出數據激勵的收集,進行自動比對。Command Layer層主要按接口時序收發數據,同時將一些底層方法(如數據讀寫等)進行封裝。Signal Layer層主要是完成接口信號連接工作。不同的人關注不同層次,一般的驗證人員只需要在Test層工作,編寫測試向量。只有搭建環境的驗證人員才需了解各個層次。驗證架構的層次化降低了驗證環境復雜度和環境維護成本,提升了驗證效率。

圖4 傳統VMM驗證環境架構

本文基本采用圖4的驗證環境架構的思路,并在其基礎上進行修改,添加相應組件。VMM驗證環境架構如圖5所示,環境數據流從測試用例Test Case開始,經過數據包產生器Generator和數據處理器Transactor送給BFM處理,BFM把驗證環境的抽象層次從信號級抽象到Transaction級,在實現上只做時序轉換功能,利于重用。從發送方向看,BFM只負責將接收到的數據發送給DUT;從接收方向看,BFM只負責將接收到的數據發給Transactor,實現任何數據的解析。Monitor抓取接口上的信號,并分析各組控制信號之間的邏輯時序關系,檢查其是否滿足協議所規定的邏輯時序關系,同時把監測到的數據信號轉化為數組送到RM解析。與BFM一樣,Monitor只實現時序轉換功能,不做數據解析。從Monitor上采樣數據再送入RM,是基于重用的角度考慮。參考模型(RM)用于預測數據響應[2],Check組件將RM的輸出數據與被觀測響應進行比較。

圖5 VMM驗證環境架構

該驗證環境架構還添加斷言(Assertion)來提高觀察和定位設計問題的能力。斷言是檢查DUT中信號行為是否正確的觀察器,用來描述被預期的特定性質。本文采用的斷言為SVA斷言語言,可以應用到設計過程的各個階段,還可以統計功能覆蓋率。

5 基于DSM的軟硬件協同仿真調試

由于DSM模型在仿真過程中,會將ARM執行的每一步動作打印出來,生成一個log.eis文件,由該文件給出的信息定位問題非常方便,如圖6所示。

圖中第1列表示程序執行到ARM的第幾個時鐘周期。第2列是ARM執行的指令類型。第3列的CCFAIL表示條件執行時是否執行,如果條件執行了,則不打印CCFAIL,反之則打印出CCFAIL。第4列是 ARM執行的機器碼。最后幾列是詳細的ARM執行的動作,從圖中可以看出ARM執行哪一步指令,將哪些數據讀寫到哪些地址。對應的仿真波形圖如圖7所示。可以看出,log.eis完整無誤地將ARM執行的動作打印了出來。

圖6 log.eis文件

圖7 仿真波形

結 語

設計驗證是SoC設計的關鍵技術之一,貫穿整個SoC設計過程[3]。隨著 SoC技術的發展,軟硬件協同驗證的效率和正確性對整個SoC設計的影響也越來越大。相比傳統的軟硬件協同環境,本文介紹的環境速度快,更真實,調試也更加容易。該環境可繼承性好,能夠為各種SoC項目開發驗證所用。

[1]鮑華,洪一,郭二輝.面向SoC的軟硬件協同驗證平臺設計[J].計算機工程,2009(8).

[2]Bergeron Janick.Verification Methodology ManuaL For SystemVerilog[M].北京航空航天大學出版社,2007.

[3]幸強.一種基于ISS的軟硬件協同驗證環境[J].現代電子技術,2007(8).

[4]李建成,莊釗文,張亮.SoC設計的軟硬件協同驗證研究[J].半導體技術,2007(10).

[5]馮博凌,李平,王憶文.基于混合建模的SoC軟硬件協同驗證平臺研究[J].單片機與嵌入式系統應用,2009(5).

[6]申敏,曹聰玲.基于SoC設計的軟硬件協同驗證技術研究[J].廣東通信技術,2009(2).