基于SystemC的GPU軟硬件協同虛擬平臺構建方法

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

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

0 引 言

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

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

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

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

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

2 SystemC語言簡介

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

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

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

3 虛擬仿真平臺構建方法

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

圖2 GPU芯片驗證平臺

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

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

驗證平臺硬件部分的代碼如果需要例化在此仿真平臺上，首先需要添加硬件描述語言-SystemC語言標準接口[9]，將硬件描述語言代碼轉換為SystemC語言代碼。首先必須統計硬件部分代碼的外接口，之后按照SystemC語言中規定的帶接口的頂層代碼的寫法構造轉接口。以此驗證平臺硬件部分頂層代碼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 底層驅動模型的構造

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

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

3.2.1 統計上層軟件需要的task

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

3.2.2 在底層驅動模型實現task功能

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

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

完成時鐘配置后，使用SystemC語法實現軟件調用的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輸入輸出的參數包括rdwr(讀寫指示，高讀低寫)、addr(讀寫地址)、data_in(寫操作輸入數據)、data_out(讀操作輸出數據)，底層驅動模型的輸出信號包括c_addr_out，c_wren，c_rden，c_data_out，輸入信號包括c_wrack，c_rdack，c_data_in。為實現上層軟件需要的時序，在task開始時，首先判斷task輸入的參數rdwr的值，若rdwr為1則為讀操作，使用SystemC語言語法.write給底層驅動模型的輸出信號c_addr_out賦值為task的輸入addr，給底層驅動模型的輸出信號c_rden賦值為1，之后使用SystemC語言語法do while循環檢測c_rdack直到此信號為1，將c_data_in的值賦給上層軟件task輸出data_out，給底層驅動模型的輸出信號c_rden賦值為0；若rdwr為0則為寫操作，使用SystemC語言語法.write給底層驅動模型的輸出信號c_addr_out賦值為task的輸入addr，給底層驅動模型的輸出信號c_data_out賦值為task的輸入data_in，給底層驅動模型的輸出信號c_wren賦值為1，之后使用SystemC語言語法do while循環檢測c_wrack直到此信號為1，給底層驅動模型的輸出信號c_wren賦值為0，其示例邏輯如圖5所示。

圖4 Pcie存儲器讀寫時序

圖5 底層驅動模型數據轉換示例

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

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

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

圖6 底層驅動模型數據轉換示例

4 仿真驗證結果

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

表1 軟硬件協同仿真平臺和傳統仿真平臺速度比較

5 結束語

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