何嘉文，杜 斐，聶 瞾，田 澤

(航空工業(yè)西安航空計算技術研究所，陜西 西安 710068)

0 引 言

當前進行的芯片設計中，一般需要搭建虛擬仿真平臺以驗證待測設計的正確性。虛擬仿真平臺包括三個部分，即待測設計、主設備模型、測試激勵。傳統(tǒng)的驗證平臺，一般使用硬件語言開發(fā)主設備模型和測試激勵，模擬主設備行為以檢測待測設計正確性。但隨著芯片復雜度的增加，使用硬件語言開發(fā)主設備模型和測試激勵的難度也越來越大，尤其對于GPU芯片而言，由于其功能復雜，為兼顧設計效率和開發(fā)難度，其功能被拆分到軟件驅(qū)動和硬件邏輯中。因此，如果按照傳統(tǒng)方法搭建GPU的虛擬驗證平臺，則面臨著兩個難題，一是使用硬件語言構造的主設備模型和激勵開發(fā)難度大，且難以保證其功能與軟件驅(qū)動的一致性，二是未能驗證軟件驅(qū)動的正確性[1-2]。

針對上述問題，該文提供了一種GPU芯片的軟硬件協(xié)同仿真平臺構建方法。以SystemC語言作為橋梁，在虛擬仿真平臺中兼容C語言開發(fā)的軟件驅(qū)動、測試激勵，以及硬件語言開發(fā)的待測設計，不僅能夠加快虛擬仿真平臺的開發(fā)進度，還能保證虛擬仿真和真實芯片測試的一致性，對當前的GPU芯片虛擬驗證工作很有幫助。

1 GPU芯片虛擬仿真面臨的仿真問題

GPU芯片待測設計包括兩個部分，即軟件驅(qū)動和硬件邏輯，芯片的激勵輸入為標準OPENGL函數(shù)，軟件驅(qū)動部分將OPENGL函數(shù)處理后，通過PCIe總線接口與GPU芯片進行數(shù)據(jù)交互，而硬件邏輯部分，則負責接收軟件驅(qū)動部分發(fā)送的數(shù)據(jù)，將此數(shù)據(jù)處理后轉換為視頻格式(如DVI、LVDS等)輸出。

如果按照傳統(tǒng)的芯片虛擬仿真平臺搭建方法，使用硬件語言構建主機模型和測試激勵，模擬主機行為，則會出現(xiàn)以下三個問題：第一，GPU芯片的軟件驅(qū)動功能復雜，難以迅速開發(fā)出主機模型，且不能保證軟件驅(qū)動和主機模型功能一致；第二，未能驗證軟件驅(qū)動功能；第三，測試激勵需要存儲大量數(shù)據(jù)，至少256 MB的存儲空間，如果使用硬件語言構建主機模型和驗證平臺，勢必在驗證平臺中增加容量為256 MB的存儲器模型，導致仿真速度大大減慢。因此，有必要引入一種新的仿真平臺構建方法，能夠在仿真平臺中同時容納軟件驅(qū)動和硬件邏輯。該文以SystemC語言作為橋梁，構建了一種基于SystemC語言的GPU芯片軟硬件協(xié)同虛擬仿真平臺，實現(xiàn)了軟件驅(qū)動和硬件邏輯的聯(lián)合仿真。

2 SystemC語言簡介

SystemC語言是一種系統(tǒng)級建模語言，是在C++語言的基礎上擴展了一系列的硬件類，并且提供了一個基于事件驅(qū)動的模擬核。SystemC語言既能按照硬件設計的要求進行時鐘精確的并行設計，輸入輸出接口可以按照硬件的要求設計為input和output管腳模式，也可以按照軟件設計人員的要求進行抽象層級較高的串行設計，還能兼容C語言、C++語言，且有專門的標準接口處理SystemC語言與硬件語言的連接問題，因此很適合作為橋梁連接軟件設計和硬件設計[3-5]。

圖1為一個使用SystemC語言作為橋梁的兼容軟件語言設計和硬件語言設計的驗證平臺示例。圖中，硬件語言設計通過硬件語言-SystemC語言標準接口嵌入SystemC語言設計中，軟件語言設計則可以直接嵌入SystemC語言設計中，再將兩個SystemC語言設計直接連接，即可完成兼容軟件語言設計和硬件語言設計的驗證平臺。

圖1 兼容軟件語言設計和硬件語言設計的驗證平臺

3 虛擬仿真平臺構建方法

GPU芯片的待測設計分為兩部分，即軟件驅(qū)動部分和硬件設計部分。軟件驅(qū)動分為兩部分，第一部分功能為對激勵輸入的OPENGL語言進行解碼(下文均簡稱為上層驅(qū)動)，此部分的輸出為經(jīng)解碼后的命令和數(shù)據(jù)，第二部分功能為控制PCIe主設備(在虛擬仿真中為PCIe主設備模型)經(jīng)PCIe總線發(fā)送經(jīng)解碼后的命令和數(shù)據(jù)到GPU(下文均簡稱為底層驅(qū)動)[6-8]。GPU芯片的硬件設計部分則在收到解碼后的命令和驅(qū)動后進行處理，轉換為視頻格式(DVI格式、LVDS格式等)輸出。因此，在構建仿真平臺時，對于硬件方面，需要引入PCIe主設備模型，并將硬件設計和PCIe主設備模型共同構建在一個頂層下；對于軟件方面，上層驅(qū)動部分不需要修改，需要構建能夠替代底層驅(qū)動功能的測試部件，用于驅(qū)動PCIe主設備模型向硬件設計部分發(fā)送數(shù)據(jù)，并將軟件驅(qū)動和硬件設計通過使用SystemC語言開發(fā)的轉接口相連接，其功能框圖如圖2所示。

圖2 GPU芯片驗證平臺

如圖2所示，此仿真平臺包括硬件部分、軟件部分、硬件語言-SystemC語言標準接口和底層驅(qū)動模型，其中硬件部分包括硬件設計、PCIe主設備模型，例化在硬件描述語言-SystemC語言標準接口的內(nèi)部；軟件部分包括測試激勵、上層驅(qū)動、調(diào)用服務器內(nèi)存；底層驅(qū)動模型，一側連接軟件部分，一側連接硬件描述語言-SystemC語言轉接口。

3.1 硬件描述語言-SystemC語言標準接口的構造

驗證平臺硬件部分的代碼如果需要例化在此仿真平臺上，首先需要添加硬件描述語言-SystemC語言標準接口[9]，將硬件描述語言代碼轉換為SystemC語言代碼。首先必須統(tǒng)計硬件部分代碼的外接口，之后按照SystemC語言中規(guī)定的帶接口的頂層代碼的寫法構造轉接口。以此驗證平臺硬件部分頂層代碼GPU_PCIe_Top.v為例，首先構造同名SystemC語言代碼GPU_PCIe_Top.cpp和GPU_PCIe_Top.h，其中GPU_PCIe_Top.cpp中僅引用GPU_PCIe_Top.h。在GPU_PCIe_Top.h中，首先引用SystemC語言庫文件systemc.h，之后按照GPU_PCIe_Top.v的輸入輸出在GPU_PCIe_Top.h構建同名的輸入輸出，之后使用SystemC語言專用類ncsc_foreign_module將GPU_PCIe_Top.v例化在GPU_PCIe_Top.h中，如圖3所示。GPU_PCIe_Top.h即可例化在此仿真平臺上。

圖3 硬件描述語言-SystemC語言標準接口的構造

3.2 底層驅(qū)動模型的構造

底層驅(qū)動模型用于替代原軟件底層驅(qū)動的功能，即控制PCIe主設備模型，將上層軟件需要發(fā)送的數(shù)據(jù)和命令通過PCIe總線發(fā)送至GPU芯片，因此，底層驅(qū)動模型存在兩類接口，即由上層軟件調(diào)用的函數(shù)接口和連接硬件描述語言-SystemC語言標準接口的信號接口，此底層驅(qū)動模型的主要功能，即將上層軟件的函數(shù)接口功能轉換為PCIe主設備模型需要的信號時序，之后再將此信號按照SystemC語言的接口形式輸出。

因此，構造底層驅(qū)動模型時，需要按照以下步驟進行工作：第一，統(tǒng)計上層軟件需要的task，并在底層驅(qū)動模型定義此task，并通過C語言語法extern將此task調(diào)用到軟件部分供上層軟件調(diào)用；第二，在C語言-SystemC語言轉接口實現(xiàn)task功能，即將C語言輸入的數(shù)據(jù)轉換為硬件描述語言需要的信號時序，并將涉及的信號例化為輸入輸出接口。

3.2.1 統(tǒng)計上層軟件需要的task

按照GPU上層軟件部分的要求，需要底層驅(qū)動模型實現(xiàn)的task包括兩類，第一類是由上層軟件調(diào)用的，通過此類task控制PCIe主設備向GPU發(fā)送數(shù)據(jù)；第二類是由PCIe主設備模型控制的，通過此類task向驗證平臺軟件部分的服務器內(nèi)存進行讀寫操作。對于第一類task，上層軟件需要Pcie內(nèi)部寄存器配置讀寫task Pcie_Config()和Pcie存儲器讀寫task Pcie_Mem_write()；對于第二類task，需要在軟件內(nèi)部通過C語言語法malloc向服務器申請256 MB空間，之后在C語言實現(xiàn)對服務器空間的配置函數(shù)Config_Mem()，之后通過語法extern到底層驅(qū)動模型中。

3.2.2 在底層驅(qū)動模型實現(xiàn)task功能

當在底層驅(qū)動模型中定義task后，下一步為實現(xiàn)task功能，首先需要在底層驅(qū)動模型中內(nèi)部實現(xiàn)時鐘，之后使用此時鐘來作為時序電路的時鐘端，對上文涉及的兩類task，即選擇第一類task介紹其實現(xiàn)方法，第二類task實現(xiàn)方法類似，限于篇幅不做專門介紹。

為在底層驅(qū)動模型內(nèi)部實現(xiàn)時鐘，在確認了時鐘頻率后，首先使用SystemC語法sc_clock定義時鐘clock，之后使用SystemC時鐘配置專用函數(shù)clock[10-13](“信號名”，路徑，周期，延遲，初始值)設置時鐘頻率，保證其頻率與PCIe主設備模型的時鐘一致。

完成時鐘配置后，使用SystemC語法實現(xiàn)軟件調(diào)用的task到硬件需要的時序的轉換[14-16]，下文將以軟件需要的Pcie存儲器讀寫task Pcie_Mem_Access()轉換為驗證平臺硬件部分PCIe主設備模型的Pcie存儲器讀寫時序為例，詳細介紹轉換方法。圖4為驗證平臺硬件部分PCIe主設備模型的Pcie存儲器讀寫時序，若軟件需要啟動對GPU的讀操作，應將信號rden和addr設置為有效，信號rden應一直有效直到PCIe主設備模型返回rdack為1一周期，此時軟件可從信號data_from_pcie_to_host取值；若軟件需要啟動對GPU的寫操作，應將信號wren、addr和data_from_host_to_pcie設置為有效，信號wren應一直有效直到PCIe主設備模型返回wrack為1一周期；上層軟件task輸入輸出的參數(shù)包括rdwr(讀寫指示，高讀低寫)、addr(讀寫地址)、data_in(寫操作輸入數(shù)據(jù))、data_out(讀操作輸出數(shù)據(jù))，底層驅(qū)動模型的輸出信號包括c_addr_out，c_wren，c_rden，c_data_out，輸入信號包括c_wrack，c_rdack，c_data_in。為實現(xiàn)上層軟件需要的時序，在task開始時，首先判斷task輸入的參數(shù)rdwr的值，若rdwr為1則為讀操作，使用SystemC語言語法.write給底層驅(qū)動模型的輸出信號c_addr_out賦值為task的輸入addr，給底層驅(qū)動模型的輸出信號c_rden賦值為1，之后使用SystemC語言語法do while循環(huán)檢測c_rdack直到此信號為1，將c_data_in的值賦給上層軟件task輸出data_out，給底層驅(qū)動模型的輸出信號c_rden賦值為0；若rdwr為0則為寫操作，使用SystemC語言語法.write給底層驅(qū)動模型的輸出信號c_addr_out賦值為task的輸入addr，給底層驅(qū)動模型的輸出信號c_data_out賦值為task的輸入data_in，給底層驅(qū)動模型的輸出信號c_wren賦值為1，之后使用SystemC語言語法do while循環(huán)檢測c_wrack直到此信號為1，給底層驅(qū)動模型的輸出信號c_wren賦值為0，其示例邏輯如圖5所示。

圖4 Pcie存儲器讀寫時序

圖5 底層驅(qū)動模型數(shù)據(jù)轉換示例

3.3 信號連接和軟件激勵添加

在實現(xiàn)了硬件描述語言-SystemC語言標準接口和底層驅(qū)動模型后，首先需要連接硬件描述語言-SystemC語言轉接口和底層驅(qū)動模型，連接時，需要使用SystemC語言的信號連接標準類SC_CTOR[17-18]。首先定義硬件描述語言-SystemC語言轉接口和底層驅(qū)動模型及其相關信號名，之后在此類的定義中分別將兩接口的相應輸出相連接即可。

連接完成后，需要在仿真平臺中添加激勵。軟件提供的激勵為函數(shù)sim，需要在仿真開始時運行。為達到此效果，可以使用SystemC語言類SC_THREAD，此類的功能為在其敏感列表條件達成后開始運行此類中設置的函數(shù)。在實際使用中，如圖6所示，設置函數(shù)HOST_TEST_THREAD，在其中調(diào)用測試激勵函數(shù)sim和退出仿真函數(shù)exit(1)，之后在SystemC語言類SC_THREAD中調(diào)用函數(shù)HOST_TEST_THREAD，SC_THREAD類的敏感列表為時鐘上升沿。

圖6 底層驅(qū)動模型數(shù)據(jù)轉換示例

4 仿真驗證結果

驗證平臺搭建完成后，經(jīng)運行，能夠?qū)④浖罱?jīng)驗證平臺軟件部分送至硬件部分的PCIe主設備模型，能夠最大限度保證測試激勵和實際芯片仿真環(huán)境的一致性，且軟件部分調(diào)用存儲資源是向服務器申請的，可以根據(jù)仿真項使用的Mem大小靈活調(diào)用和釋放，不需在仿真平臺上添加Mem模型，其仿真速度大大加快[19-20]。經(jīng)比較，如表1所示，此仿真平臺的仿真速度比同類的純硬件仿真平臺高5倍以上。因此，無論從功能實現(xiàn)，還是仿真速度，此虛擬仿真平臺均能達到設計要求。

表1 軟硬件協(xié)同仿真平臺和傳統(tǒng)仿真平臺速度比較

5 結束語

該文介紹了一種基于SystemC語言的GPU芯片軟硬件協(xié)同虛擬仿真平臺構建方法，能夠同時在驗證平臺中兼容C語言開發(fā)的測試激勵和軟件驅(qū)動，以及硬件語言開發(fā)的待測設計和PCIe主設備模型。此仿真平臺不僅能同時測試軟件驅(qū)動和硬件設計，其仿真速度也優(yōu)于傳統(tǒng)仿真平臺，對GPU芯片的虛擬驗證工作很有幫助。但由于GPU芯片規(guī)模大，設計復雜，且需要的存儲器也較多，導致虛擬仿真速度仍較慢。下一步，將在此基礎上研究加快GPU虛擬仿真平臺仿真速度的辦法，以更好地推進GPU芯片的虛擬驗證工作。