基于SoC-FPGA 的RISC-V 處理器軟硬件系統級平臺

齊 樂 常軼松,2 陳欲曉,2 張 旭,2 陳明宇,2 包云崗,2 張 科,2

1 （處理器芯片全國重點實驗室（中國科學院計算技術研究所）北京 100190）

2 （中國科學院大學計算機科學與技術學院 北京 100049）

敏捷開發最初是指以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發.而近年來隨著當今處理器核心設計需求的多樣性與復雜性不斷增加，一些前沿領域的芯片設計團隊也開始嘗試借鑒敏捷開發的思想[1-3].處理器芯片設計在投片前,需要基于近似真實的硬件環境，敏捷地進行軟硬件系統定義、集成和試錯，開展軟硬件系統級評估.

在早期的處理器開發流程中，由于對硬件的依賴，處理器相關軟件的開發和驗證需要穩定的硬件原型，這種硬件開發和軟件開發之間的串行性在一定程度上降低了整體的開發與迭代效率.為了縮短開發周期，軟硬件協同開發[4]的思路被提出.軟硬件協同開發在設計初期將系統功能進行軟件和硬件的劃分，隨后軟件和硬件的開發并行進行，驗證階段采用軟硬件協同驗證的方式.軟硬件協同驗證是一種對軟硬件設計同時進行驗證的方法，要求在驗證框架下搭建待驗證硬件環境并運行待驗證軟件，運行過程中軟硬件的行為可以彼此提供測試向量，從而將驗證工作并行化，縮短驗證時間.同時，軟件應根據硬件配置進行設計，綜合啟動引導固件、操作系統、應用程序等各層次的代碼，組織成完整的軟件棧.隨著硬件設計的規模逐漸擴大，軟件棧需要跟蹤各種硬件接口（時鐘與復位邏輯、訪存接口、各類對外通信設備等）的準確版本以及從固件到用戶級應用程序的特性和功能，因此軟件棧的開發和測試變得更加復雜.設計復雜性的不斷增加對實驗和研究軟件工作負載的管理提出了挑戰.

處理器設計的系統性改進升級可能涉及修改任何層次代碼，包括從低級電路的硬件描述代碼到操作系統和應用程序的軟件代碼.綜上所述，處理器設計團隊需要一個硬件和軟件完全集成的原型驗證系統.全系統級驗證是對軟件或硬件合作的嘗試.系統級驗證指對系統層面的硬件設計進行驗證，驗證對象通常是軟硬件整體.系統級驗證的方法主要采用對軟硬件整體仿真或模擬的方法，如搭建現場可編程門陣列（field programmable gate array，FPGA）原型系統進行驗證，就是一種目前業界廣泛采用的基于可編程硬件模擬的方法.近年來，由于FPGA 器件成本的下降和邏輯資源規模的提升，加上FPGA 本身與真實電路的近似性，FPGA 原型驗證作為系統級驗證的一種方式，其優勢愈加明顯.

現有的系統級原型驗證平臺主要基于通用型FPGA 器件.通用型FPGA 器件以提供可編程邏輯資源為目標，幾乎不包含硬核，設計流程上主要通過FPGA制造商提供的電子設計自動化（electronics design automation，EDA）支持工具來構建設計并配置器件，從而構建FPGA 原型系統.各制造商的FPGA 開發過程基本相同，但開發過程往往涉及工程方面的繁雜細節.在基于傳統通用型FPGA 的原型驗證中，除了需要測試的處理器核部署在FPGA 上之外，還需要實現一些基本的內存訪問接口和I/O 外設（包括但不限于網絡接口、串行端口、USB、SD/MMC 等）.沒有FPGA 開發經驗的人需要相當長的時間來學習掌握，技術門檻較高.這些接口的實現本身也需要占用FPGA 的大量片上邏輯資源，從而擠壓待測試的處理器核心的布局和布線自由度空間，帶來時序違例等問題.此外由于芯片底層實現工藝的原因，相較于專用集成電路（application specific integrated circuit，ASIC），通用型FPGA 的原型驗證場景中處理器核的運行頻率低，執行一些計算密集型任務往往需要消耗相當長的時間，而這些等待時間也會間接影響到處理器的驗證流程.

1 研究背景

基于面向開放RISC-V 指令集[5]的開源處理器在近年來受到廣泛關注.隨著開源芯片社區的不斷發展和成熟，處理器內部的一些典型基礎邏輯功能模塊也在歷經多次流片驗證后趨于穩定，這些基礎模塊在未來爆發大規模邏輯錯誤和設計缺陷的可能性已大幅度降低。然而，隨著系統整體復雜度的不斷提升，目前的處理器集成了越來越多的基礎模塊部件，因此，未來不僅需要開展面向傳統RTL（register transfer logic）邏輯設計描述和門級電路的仿真測試，更需要一種快速構建軟硬件原型的平臺和方法，以盡快開展系統級測試評估.設計團隊亟需一種利用開源IP 快速構建硅前系統級平臺的方法，盡快開展硅前硬件糾錯和軟件調試工作.

隨著片上系統（system-on-a-chip，SoC[6]）技術的演進，出現了在同一芯片上集成FPGA 可編程邏輯（programmable logic，PL）和硬核處理系統（processing system，PS）的新型SoC-FPGA[7]器件.以Xilinx 的Zynq-7000/MPSoC 為例，其硬核處理系統部分是一個以ARM 處理器硬核為核心的SoC，它包含硬核ARM 處理器、平臺管理單元（platform management unit，PMU）協處理器及各類豐富的外設接口資源.SoC-FPGA 可以認為是ASIC 器件與傳統FPGA 器件的互補，將一些廣泛使用的標準化處理器核與外設接口以硬核的形式直接提供給開發者復用.

如何充分利用SoC-FPGA 提供的各類外設接口及算力資源，為開源RISC-V 處理器核提供一套敏捷易用的原型驗證環境，以更好地開展軟硬件全系統評估工作，是本文著力解決的問題.

2 國內外研究現狀

FireMarshal[8]是一個用在全棧SoC 上創建和共享可復制和可重復實驗的軟件工件的工具.用戶可以將配置項寫入JSON 文件，以快速生成所需的所有級別的軟件棧.然而，FireMarshal 側重于RISC-V 軟件系統的自動化生成，在硬件上依賴FireSim[9]仿真加速平臺，尚未充分考慮如何為RISC-V 處理器的完整軟硬件系統級驗證提供豐富的I/O 外設接口.

Freedom[10]是SiFive 設計的一個平臺，用于將特定的RISC-V 核——Rocketchip[11]部署到傳統通用型FPGA 設備，為設計者提供一套典型的RISC-V SoC參考系統.雖然Freedom 開源代碼倉庫中提供了一些簡單I/O 接口的使用方法，但接口類型和功能極為有限，不能滿足目標處理器軟硬件系統的完整驗證需求.此外，Freedom 提供的I/O 接口可選擇使用Xilinx FPGA 開發工具中提供的IP，但這些IP 核仍需要以邏輯電路的形式被部署在FPGA 上，占用待驗證處理器需要的邏輯資源.

ESP[12]是用于異構SoC 設計的開源研究平臺.ESP體系結構具有高度可擴展性，并在規則性和專業性之間取得平衡.伴隨的方法提高了系統級設計的抽象級別，并支持從軟件和硬件開發到FPGA 上的全系統原型的自動化過程.對于應用程序開發人員，ESP提供面向特定領域的自動化解決方案，為其軟件合成新的加速器，并將復雜的工作負載映射到SoC 架構上.對于硬件工程師來說，ESP 提供了將加速器設計集成到完整SoC 中的自動化解決方案.

國內也有團隊開始探索基于SoC-FPGA 構建RISCV 處理器的測試系統[13].其基本思路是通過對RISCV 發起的外設地址訪問請求進行捕獲，將RISC-V 處理器通過AXI 外設控制總線對外設控制器訪問產生的相應數據轉存，最終通過串口打印.然而該方法僅能對RISC-V 處理器的外設訪問通路進行相關訪問數據記錄的收集，轉存機制本身也難以保證數據交互的實時性，同時也未考慮對復雜高速DMA 外設的訪問支持還無法滿足完整的系統級驗證需求.

綜上，盡管國內外已開始重視RISC-V 有關的軟硬件協同驗證系統，但主要沿用傳統的通用型FPGA模式，測試待驗證處理器所需的接口通常需要直接在FPGA 上實現.特別是對于一些高速接口，即使能夠應用Xilinx 或第三方公司提供的IP 核保證功能可靠，但這些IP 核需要占用大量的邏輯資源，基于Xilinx ZynqMP ZU2EG 系列器件測得的各IP 以默認配置設置時所需的邏輯資源數量與所占總邏輯資源的比例，如表1 所示.而目前基于SoC-FPGA 構建RISC-V 處理器測試系統的技術嘗試，尚存在一定的局限性.

Table 1 Logical Resources Required by the IP of Several Peripheral Interfaces表1 若干外設接口IP 所需的邏輯資源

針對傳統通用型FPGA 在構建復雜系統方面的這些缺點，本文面向RISC-V 處理器提出了一種基于SoC-FPGA 的RISC-V 處理器軟硬件系統級平臺.該平臺充分發掘可編程SoC-FPGA 軟硬件協同可編程的潛力，通過構建各級硬件和軟件的設計，使部署在硬件可編程邏輯部分的待驗證目標RISC-V 處理器核能夠充分利用硬核SoC 側的I/O 外設資源，并與ARM 硬核處理器進行協同，以獲得較好的仿真驗證效果.最后，通過與一系列定制化軟硬件自動化設計框架，用戶只需提供幾個關鍵參數即可自動生成可在SoC-FPGA 上部署的目標RISC-V 開源處理器軟硬件鏡像文件，降低原型驗證環境的構建開銷.

3 驗證平臺的設計

如圖1 所示，待測RISC-V 軟核處理器位于可編程邏輯側，可通過不同類型的總線接口（訪存接口和外設接口）訪問ARM 硬核SoC 側的內存與I/O 外設資源；同時I/O 外設可通過一致性接口向RISC-V 可見內存發起DMA 訪問.此外，為了提高驗證平臺在軟硬件各個層次上的兼容性，本文提出一種基于Mailbox 模塊的軟硬件協同的驗證平臺設計框架，通過RISC-V 軟核與ARM 硬核對Mailbox 模塊的共享訪問，實現硬核處理器對RISC-V 處理器軟硬件驗證的高效協同.

Fig.1 Overall schematic diagram of prototype verification platform based on SoC-FPGA圖1 基于SoC-FPGA 的原型驗證平臺總體示意圖

3.1 目標RISC-V 處理器訪問內存與I/O 外設

完整的軟硬件協同驗證需要待測試RISC-V 處理器核與各種總線接口之間進行頻繁交互.一些特定的測試數據、測試結果也需要通過相關的總線接口與待驗證處理器進行傳輸.

在驗證平臺框架中如圖1 所示，待驗證的RISCV 處理器核主要包含3 類總線接口，分別為訪存接口、一致性接口和外設接口，其中外設接口一般使用內存映射輸入輸出（memory-mapped I/O，MMIO）的方式工作.為了充分利用硬核處理系統側的各項資源，本文將可編程邏輯側待驗證處理器的MMIO 接口連接到硬核處理系統端，并允許待驗證處理器訪問硬核處理系統端的各種I/O 外設；將待驗證處理器通過訪存接口訪問硬核處理系統側的內存控制器.一些具有大量通信數據的外設設備，如用于訪問SD/MMC便攜存儲設備的安全數字輸入輸出（secure digital input and output，SDIO）接口和以太網，其DMA 交互接口也與待驗證處理器的緩存一致性接口連接.此外，Mailbox 模塊可以像普通外設一樣由MMIO 接口直接尋址訪問，為可編程邏輯側的待驗證處理器提供了一種間接訪問PMU 的方式在ARM 處理器的算力協助工作中發揮重要作用.

硬核處理系統[14]中的UART、SDIO、網絡等外設既可以被可編程邏輯中的待驗證處理器通過接口訪問，也可以被硬核處理系統中的ARM 處理器訪問，但不應該被二者同時占用.在驗證平臺啟動過程中，首先由ARM 處理器完成平臺初始化和引導文件加載工作，之后各外設的控制權被移交給待驗證處理器，以實現外設資源的復用.各外設資源在平臺啟動過程中的使用情況為：

1）UART 接口.在驗證平臺啟動期間，ARM 處理器和待驗證處理器的各個啟動階段的日志信息，以及掛載文件系統后的交互都可以通過UART 接口完成輸入輸出.

2）SDIO 接口.在基于SD 卡的引導模式下，ARM和待驗證處理器引導文件都需要從SD 卡移動到內存.啟動Linux 內核后，待驗證處理器還可能需要在SD 卡分區上掛載發行版文件系統，也需要訪問SDIO接口.

3）網絡.在基于網絡的啟動模式下，ARM 和待驗證處理器都需要從網絡的遠端服務器讀取啟動鏡像文件到內存.啟動Linux 內核后，待驗證處理器還可能需要在網絡文件系統（network file system，NFS）服務器上掛載發行版文件系統，這也需要訪問網絡接口.

值得注意的是，由于ARM 處理器在通電和啟動的初始階段僅暫時使用SDIO 或網絡接口，一旦開始執行服務程序，ARM 將不再訪問硬核處理系統端的各類外設資源.因此，待驗證處理器從開始加載啟動到掛載發行版文件系統的整個過程，對硬核處理系統端的所有接口資源都具有完全權限.

3.2 基于硬核處理器協同的待測RISC-V 處理器運行時環境

硬核處理系統側的處理器核心主要包括ARM主處理器和PMU 協處理器2 部分.ARM 主處理器作為硬核處理系統的高性能處理器，主頻較高，而且上電后立即開始工作，可直接進行訪存以及各類外設接口的交互操作，能夠向待測RISC-V 處理器軟核提供算力方面的協助.PMU 是一個在SoC-FPGA 上執行管理功能的硬核處理器.PMU 可以執行其他處理器不被允許的操作，如電源管理、時鐘管理和可編程邏輯配置，能夠向待測RISC-V 處理器軟核提供功能上的輔助.待測RISC-V 核對2 種硬核處理器資源的利用在結構上均需要基于Mailbox 進行關鍵信息的交互，如圖1 所示.3.2.1 節將對硬核處理器資源的利用方法，以及不同處理器之間的具體交互流程進行闡述說明.

3.2.1 平臺管理單元協同

基于3.1 節的方法雖然能夠訪問到I/O 外設的控制與狀態寄存器空間，但無法直接訪問一些對系統行為較為敏感的特殊寄存器（如I/O 外設的時鐘寄存器）.這些特殊寄存器只能由PMU 管理，其他處理器核沒有直接訪問權限.當待驗證RISC-V 處理器需要讀寫特殊寄存器時，需要向PMU 發出核間中斷請求，委托PMU 進行特殊寄存器的讀寫操作.因此需要建立待驗證RISC-V 處理器與PMU 的核間中斷通信機制.然而，現有SoC-FPGA 器件往往并不允許位于可編程邏輯的待測處理器直接向PMU 單元發出核間中斷操作.

為解決這些問題，本文提出一種虛擬核間中斷機制，通過ARM 硬核處理器作為第三方，對核間中斷（inter-processor interrupt，IPI）請求進行轉發.具體地，本文提出一種基于Mailbox 的核間中斷請求轉發流程.同時，為了對特殊寄存器的操作與普通寄存器操作進行隔離，本文在RISC-V 的機器態運行模式（machine mode，M-MODE）下實現了程序調用接口，允許在其他運行模式下通過環境調用（environment call，ECALL）模式訪問.

如圖2 所示，Mailbox 主要包括請求標記段和參數段，參數段包括請求類型段、輸入參數段與輸出參數段3 部分，可基于FPGA 片上小容量BRAM 實現.請求標記段由RISC-V 在需要時進行置位和回讀，ARM 則在默認情況下循環檢測該請求標記.為了當RISC-V 開始執行PMU 訪問時首先通過ECALL 陷入M-MODE，將核間中斷的相關信息通過MMIO 總線接口寫入Mailbox 的相應位置.在Mailbox 模塊的配合下，RISC-V 核對PMU 等單元的操作請求將由ARM進行中轉，代替RISC-V 向PMU 發出操作請求從而實現虛擬核間中斷機制，最終RISC-V 通過Mailbox回讀核間中斷操作的返回結果，圖2 中，從平臺的角度上，各操作按數字序號的次序依次執行；從RISCV 與ARM 處理器的角度上，各自按照其執行步驟箭頭依次執行.

Fig.2 Interaction process between RISC-V processor and PMU圖2 RISC-V 處理器與PMU 的交互流程

基于Mailbox 構建的虛擬核間中斷機制將在平臺的操作系統引導過程中起到重要作用.在待測RISC-V 軟核啟動時，Linux 內核的初始化階段需要陷入M-MODE 的管理器二進制接口（supervisor binary interface，SBI）固件代碼中執行核間中斷請求.RISCV 處理器上的Linux 內核運行于S-MODE, 更高級別的M-MODE 運行OpenSBI（OpenSBI 是SBI 的一種開源實現，除了作為引導程序以外, 同時也作為平臺管理固件運行于處理器的最高級別）.本文兼容了現有的SoC-FPGA 時鐘驅動程序，通過添加相應的接口函數來支持RISC-V 從內核態陷入M-MODE 固件，發起對PMU 的虛擬核間中斷，如圖3 所示.

Fig.3 Linux drivers running on RISC-V processor initiate a virtual IPI towards PMU圖3 RISC-V 處理器上運行的Linux 驅動程序發起對PMU 的虛擬核間中斷請求

3.2.2 ARM 處理器協同

在驗證平臺中，ARM 處理器負責為RISC-V 處理器核的啟動準備內存環境，并將RISC-V 的啟動鏡像文件從SD 卡提前移動到內存，完成可編程邏輯端的位流配置等.并在啟動和運行期間最終執行服務程序以協助ECALL 和RISC-V 的其他操作.除了RISC-V 操作所需的輔助外，ARM 處理器還可以承擔一些計算任務.

例如，在涉及RISC-V 安全框架的研究中，ARM處理器不僅負責協助RISC-V 啟動和轉發IPI 消息，它本身還具有更高的工作時鐘頻率和更大的計算潛力.對于一些計算密集型的任務，RISC-V 可以通過Mailbox 向ARM 提交計算輔助請求以及所需要計算的任務類型、原始數據信息等，如圖4 所示.ARM 接收到計算輔助請求后，將通過一致性接口讀取所需計算的原始數據，之后將計算結果數據由一致性接口寫入共享內存區域，并通過清除請求標記告知RISC-V 去回讀共享內存中的計算結果，從平臺的角度上，各操作按數字序號的次序依次執行；從RISCV 與ARM 處理器的角度上，各自按照其執行步驟箭頭依次執行.

Fig.4 ARM processor cooperates to run complex computing tasks of RISC-V圖4 ARM 處理器協同運行RISC-V 的復雜運算任務

3.3 敏捷驗證平臺開發框架

為了提升軟硬件協同驗證平臺的敏捷性，本文構建了RISC-V 處理器軟硬件驗證的可配置、自動化開發框架.

3.3.1 可配置框架

驗證平臺通過多層Git 存儲庫組織，將有關的軟件和硬件倉庫以高內聚、低耦合的原則組織成一個集成的設計環境.用戶僅需要向平臺的接口文件提供關鍵配置參數，如硬件處理器核的相關配置、軟件代碼的入口地址等.如圖5 所示，平臺通過一系列逐層調用并相互協作的Makefile 和工具命令語言（tool command language，Tcl）腳本，將這些關鍵參數配至各個代碼倉庫的編譯傳參接口，自動進行各個軟硬件模塊的參數修改以及FPGA 工程的適配工作，而不需要用戶深入平臺內部進行繁瑣的手動修改.當出現某些模塊的更替時僅需要關注關鍵參數即可，從而使得平臺能夠快速兼容各個軟硬件層次的設計變化.

Fig.5 Organization structure of platform on software and hardware codes圖5 平臺軟硬件代碼組織結構

軟硬件協同驗證平臺的敏捷性應該體現在其可以快速高效地集成任何符合標準接口的軟件與硬件模塊.軟件模塊包括軟件協議棧的各層次代碼，例如啟動引導軟件、Linux 操作系統、應用層可執行程序的不同階段的軟件代碼；而硬件模塊則主要包括處理器層次的邏輯設計與配置代碼與板卡層次的硬件腳本代碼.對于不同的軟硬件層次，需要分別配置特定的參數，如表2 所示.

Table 2 Configuration Parameters Required for Integration of Different Software and Hardware Modules表2 不同軟硬件層次整合時所需要提供的配置參數

3.3.2 自動化框架

考慮到系統級原型驗證涉及到很多軟硬件各層次代碼，本文探索在云端將全棧的代碼倉庫組織起來，使用戶在本地或服務器端，自動化執行編譯和測試流程.由于編譯需要許多特定版本的工具鏈，基于持續集成（continuous integration，CI）的編譯方法可以將不同的編譯階段分成特定順序的job，各個job 使用包含所需編譯工具鏈的獨立容器鏡像，相比本地編譯更簡單、更可靠.除了編譯階段，本文也探索了將編譯產出的目標文件通過持續部署（continuous deployment，CD）更新到設備.

4 驗證平臺的評估

4.1 驗證平臺評估實驗環境

4.1.1 硬件環境

平臺的硬件環境包括2 種自研板卡平臺，實物如圖6 所示，分別是基礎實驗平臺（Plat-B）板卡，以及擴展實驗平臺（Plat-E）板卡, 2 種板卡的各項板載基礎配置參數分別如表3 所示.Plat-E 配備了邏輯資源更大的SoC-FPGA 器件，可以提供更多的片上存儲資源以支持相對復雜的應用場景（如基于RISC-V 的可信執行環境）.

Fig.6 Physical photos of platform hardware圖6 平臺硬件實物照片

Table 3 Basic Configurations of Two Experimental Platforms表3 2 個實驗平臺的基本配置

4.1.2 目標軟核處理器

在評估實驗中，Plat-E 板卡與Plat-B 板卡上RISC-V軟核處理器的基本配置相同，但Plat-E 板卡為RISCV 提供的訪存空間更大、可編程邏輯側提供的時鐘頻率更高，如表4 所示.

4.1.3 軟件負載

基于表3、表4 硬件環境，通過部署并運行一系列軟件負載，如表5 所示，評估本文提出的驗證平臺性能.

1）驗證平臺的I/O 外設性能

硬核處理系統側的各類外設接口在交予可編程邏輯側的待測試處理器使用時，由于片內通路較長，需要更多的總線中轉，可能會產生一定的性能下降.對于大多數待驗證處理器的功能和性能測試，特別是需要運行Linux 的場景，考慮到文件系統通常需要放置在SD/MMC 卡或NFS 服務器上，并且數據輸入和輸出也取決于SD/MMC 存儲介質或網絡接口.為了測試本文所述的原型驗證平臺是否可以提供足夠的網絡與SD 卡訪問能力以滿足系統級測試的基本需求，本文基于Plat-B 板卡的硬件環境設計了一些典型的比較試驗，對驗證平臺的網絡與SDIO 這2 個典型外設接口進行了性能測試和評估.

2）驗證平臺的算力輔助

在原型驗證中，待測處理器軟核往往不能以高時鐘頻率運行.當待測處理器必須執行一些耗時的計算任務時，長時間的等待往往會給其他后續驗證過程帶來麻煩.硬核處理系統側的ARM 處理器可以輔助進行一些較為復雜的計算密集型任務.

如何提供一個安全可信執行環境是未來處理器設計中的重要發展方向.在現有可信執行框架下，基于第三代安全散列算法[15-16]（secure Hash algorithm 3，SHA-3）的度量操作屬于一種計算密集型任務，它占整體運行時間的80.4%.本文在RISC-V 開源處理器核上部署UC Berkley 發布的開源可信執行環境Keystone[17-18]，探索將SHA-3 核心計算任務委托到ARM 硬核處理器進行處理的方法，并進行性能評估.

4.2 驗證平臺I/O 外設性能評估

在Xilinx Zynq UltraScale+ MPSoC 設備上，本文分別在硬核處理系統側使用ARM 處理器，在可編程邏輯側使用待驗證處理器核來測試兩側處理器訪問通信的各項性能.網絡帶寬Inbound（驗證平臺接收來自外界發送的數據）和Outbound（驗證平臺向外界發送數據）的情況如表6 所示.實驗評估了分別由ARM硬核和RISC-V 軟核訪問SDIO 接口時的性能參數，如圖7 所示，從左到右依次為SDIO 接口的帶寬、每秒讀寫操作次數、延遲測試結果.

Fig.7 SDIO performance evaluation of prototype platform圖7 原型平臺的SDIO 性能評估

Table 6 Network Performance Evaluation of Prototype Verification Platform表6 原型驗證平臺的網絡性能評估

從芯片架構來看，硬核處理系統側的ARM 處理器具有更高的運行主頻（1.5GHz），其到網絡外設設備的數據和控制路徑更短.Inbound 和Outbound 的測試性能均優于被測的RISC-V.盡管如此，被測的RISC-V 仍然可以保證一定的網絡傳輸帶寬，在大多數原型驗證工作中不會出現明顯的瓶頸，可以滿足系統級測試的基本需求.

4.3 驗證平臺算力輔助效果評估

基于硬核處理系統側的ARM 處理器來進行SHA-3計算的基本思路如圖4 所示.ARM 可以按RISC-V 地址空間，以常規訪存方式，通過RISC-V 緩存一致性接口讀取數據.執行完成后，通過ARM 側顯式地執行緩存寫回操作，將ARM 側的運算結果主動通過RISC-V 一致性接口直接寫回RISC-V 內存，無需顯式地進行結果數據在ARM 與RISC-V 內存中的搬移.

逐一運行Keystone 的功能測試集進行算力輔助效果測試.在實驗中RISC-V 軟核處理器通過Mailbox將用于SHA-3 計算的數據塊的起始地址信息傳遞給ARM 處理器.ARM 運行特定的加速程序對該地址的數據塊執行SHA-3 計算.ARM 輔助計算的方法顯著加快了SHA-3 計算速度，平均將加解密計算運行時間減少了81.13%.由于SHA-3 的計算得以輔助進行，Keystone 框架中各功能測試集的執行時間均顯著縮短，如圖8 所示.

Fig.8 Evaluation of the computing power’s auxiliary effect of the ARM processor on the prototype platform圖8 原型平臺的ARM 處理器算力輔助效果評估

4.4 驗證平臺敏捷性效果評估

為進一步驗證本文所提出的平臺在敏捷性方面的改進程度，本文在4.1 節所述的在基準平臺基礎上，分別對3 個處理器實例進行移植，如表7 所示.

Table 7 Amount of Work Required to Integrate Different Software and Hardware Modules表7 整合不同軟硬件模塊所需要的工作量

如表7 所示，當需要實現實例I 的目標處理器時，平臺在基準Rocketchip 環境的基礎上，僅需將代碼倉庫中的處理器核子倉庫替換為“果殼”處理器子倉庫，根據相應的設計要求修改DRAM 起始地址與內存范圍，此外考慮到“果殼”處理器核不包含硬件浮點計算單元，需要啟動引導軟件提供浮點模擬輔助，因此增加BBL（Berkeley boot loader ）代碼倉庫到啟動引導軟件棧路徑下，最后修改頂層軟件棧相應編譯腳本即可.

當需要實現實例II 的目標處理器時，則以實例I為基礎，替換支持脈沖神經網絡加速的“果殼”處理器子倉庫，繼續沿用實例I 處理器的其他改動即可直接重新編譯并部署新的處理器核到平臺上.

當需要實現實例III 的目標處理器時，平臺首先將虛擬化擴展的四核Rocketchip 子倉庫替換基準Rocketchip 子倉庫，再修改U-Boot 與Linux 的配置項以支持RISC-V 的虛擬化功能即可.

最后，根據3 個實例所需的包括對平臺腳本的配置項、Makefile 與Tcl 腳本代碼修改等工作量進行了評估，如表7 所示.

綜上，對于以上軟硬件層次的需求變更，僅需較少的手動修改工作即可快速整合進平臺，開啟新一輪的部署與驗證迭代.

5 結 論

處理器芯片設計在投片前需要基于近似真實的軟硬件環境，敏捷地進行軟硬件系統定義、集成和試錯.為更好地支持敏捷的軟硬件協同驗證技術，本文提出了一套基于SoC-FPGA 的系統級全棧平臺，支持主流開源RISC-V 處理器軟硬件棧，支撐軟硬件協同的評測工作.

未來的工作包括進一步提升平臺兼容性，以便為設計規模更大、邏輯結構更為復雜的國產香山RISCV 開源處理器項目[23-24]提供系統級原型環境.對于香山處理器核所需的可編程邏輯資源規模，現有的SoCFPGA 器件尚不足以提供支持，本文正在探索相關解決方案，以構建邏輯資源規模更大的系統級平臺.

本文所述的敏捷軟硬件系統級評估平臺已經開放①https://gitlab.agileserve.org.cn:8001.，并發布了平臺的使用說明②https://gitlab.agileserve.org.cn:8001/ICT-SERVE-FARM/serve-docs/user-manual.git.，歡迎申請試用并提出寶貴建議.

作者貢獻聲明：齊樂實施實驗并撰寫論文；常軼松負責提供實驗方案與詳細工作思路；陳欲曉和張旭提出相關意見并修改論文；陳明宇、包云崗和張科提供總體指導.