基于輕量化遠程過程調用的RISC-V調試協議棧方案①

萬瑞罡, 朱煥杰

(芯來科技(武漢)有限公司 基礎軟件部, 武漢 430073)

1 引言

現代處理器和微控制器中一般擁有一組稱為調試模塊(debug module, DM)的硬件電路, 該電路集成在處理器內部, 為開發者提供編程、調試、(部分)異常處理、性能記錄、追蹤等功能. 這些功能既可以幫助軟件工程師對代碼進行除錯、性能分析與調優; 又在事實上成為了在硬件量產工序時, 自動測試設備(auto test equipment)對系統進行各項測試、對芯片內的存儲器進行編程的首選接口[1]. 因此, 調試模塊已經成為現代片上系統的一個不可或缺的組成部分. RISC-V的模塊化的特性推動了芯片行業自動化設計流程的變革,同時也對調試模塊的設計思路帶來了全新的挑戰.

在RISC-V調試規范中, 完整可調試的硬件系統包含待測系統(device under-test)和調試系統, 調試系統由調試適配器(debug transport hardware)和調試翻譯器(debug translator)等組件組成[2], 通過運行調試協議棧完成調試功能. 目前被廣泛使用的基于OpenOCD的調試協議棧在主機端實現了幾乎全部調試邏輯, 而將調試適配器實現為一個簡單協議轉換器. 這種緊耦合、無內聚的設計理念不僅難以維護, 不利于二次開發, 并且導致調試系統和待測系統間信息的傳輸速度受制于主機與調試適配器之間較高的I/O延遲, 進而導致數據傳輸效率的低下.

本文提出了一種全新的開源調試協議棧設計. 我們將調試翻譯器中的調試前端、RISC-V調試前端、待測系統驅動、傳輸后端等組件分離, 在組件間使用標準API接口和輕量級的遠程過程調用(remote procedure call, RPC)框架建立異步的數據通路. 這樣的設計允許部分對I/O延遲有要求的功能由主機端卸載(offload)至調試適配器上, 提高數據傳輸效率. 組件的模塊化設計和合理的層次結構使得整個系統代碼簡潔,維護方便, 易于二次開發.

本文組織結構如下: 第2節介紹相關的背景知識及目前常用的調試協議棧與調試系統存在的問題; 第3節介紹Morpheus調試協議棧的基本架構設計思路與解決現有問題的方法; 第4節介紹Morpheus調試協議棧部分操作的具體實現流程; 第5節對本文做出總結.

2 研究背景

2.1 調試協議概述

交互式調試(interactive debugging)過程中對大批量高效率傳輸數據的需求, 幾乎全部是對目標系統總線的訪問. 總線讀寫請求的對象包括目標系統的隨機訪問存儲器(random access memory, RAM)、內存映射輸入輸出(memory mapped input/output, MMIO)寄存器與非易失性存儲器(non-volatile memory, NVM). 由于調試或量產時的編程操作需要對存儲器進行順序、大塊數據的讀取或寫入, 會導致大量對RAM和NVM的讀寫請求.

根據目前的RISC-V調試規范, 對待測系統的總線訪問請求可以使用3種方式實現[2]:

(1) 抽象命令(abstract command)

(2) 程序緩存(program buffer)

(3) 系統總線訪問(system bus access)

規范強制要求待測系統中的DM至少支持上述3種方式中的一種. 但無論選擇實現其中哪一種, 數據傳輸均基于調試傳輸模塊(debug transport module,DTM)所建立的數據通路.

圖1展示了RISC-V調試系統的整體結構, 其中RISC-V platform是待測設備. RISC-V調試規范所定義的JTAG-DTM模塊對DM的交互依靠于JTAG DR寄存器DMI (debug module interface)[3]接口. 在通常的實現中, DTM與DM之間使用不同的時鐘域[4], 而DMI寄存器承擔了在兩個時鐘域中時鐘跨越的功能. 這種設計引入的跨時鐘域握手機制將導致DTM阻塞, 即使在DM完全不阻塞的情況下. 任何對DM的訪問請求,一般分為如下幾步.

圖1 RISC-V 調試系統整體結構框圖

(1) 填充DMI寄存器的DM地址、數據與操作碼;

(2) 等待DTM模塊中DTMCS (DTM control and status)寄存器中要求的run-test-idle周期;

(3) 回讀DMI寄存器, 檢查狀態位. 若DMI忙, 則重復第2步, 等待操作結束為止. 若DMI錯誤, 則進入錯誤處理流程.

同樣, 由于DM中不存在類似ARM調試系統的總線訪問緩存機制[5], 無論使用3種總線訪問方式中的哪一種, 不僅需要等待DMI就緒, 也需要查詢DM中的對應寄存器的狀態位, 確保DM對請求的正確執行,并確保在總線通路空閑的時候, 再進行下一筆數據的傳輸.

2.2 現存社區維護的工具存在的問題

目前, 開源社區存在一定數量的調試協議棧實現,例如OpenOCD、RV-Link等. OpenOCD由RISC-V基金會維護, 且對RISC-V架構處理器的調試功能支持最全面, 是現今應用最廣泛的開源調試協議棧.

OpenOCD將調試協議棧需要實現的所有功能, 包括對DMI的訪問, 以及對DM各寄存器的操作, 均在主機側完成[6]. 根據RISC-V調試規范, 每一筆對總線的訪問, 長度最多與RISC-V處理器字長(XLEN)相等. 而每一筆對總線的操作, 均需要執行發出請求-查忙-完成的3步流程[2]. 其中查忙流程導致主機無法簡單的向無處理能力的調試適配器, 如常與OpenOCD搭配的FTDI公司的多協議同步串行引擎(multi protocol synchronous serial engine, MPSSE)發送一塊含有多筆請求的命令塊實現, 而必須逐步的將命令分解為不同的、細碎的讀寫請求再發送給調試適配器, 并依賴每一步調試適配器返回的結果執行下一步請求[7]. 因此,調試器大批量對存儲器的讀寫請求, 很大程度上被主機到調試適配器間的往返延遲所限制.

例如, 使用USB 2.0全速協議連接主機與調試適配器, 假設操作系統和主機互聯系統不引入任何延遲.每個USB IN令牌包為59-bit, 每個握手包為44-bit[8].倘若USB主機接口(host controller interface)不間斷的發送IN令牌包, 則最高輪詢速率為:

實際上, 由于HCI和操作系統實際引入的損耗, 實測基于USB 2.0 全速主機-適配器通訊接口, 由Open-OCD配合基于FTDI公司的MPSSE的調試適配器, 每秒鐘可被目標執行的命令速率約為14 kHz, 實際傳輸速率約為57 KB/s. 由于系統性能瓶頸存在于主機-調試適配器間較高的通訊往返延遲與較大的查詢開銷.即使在調試適配器對目標系統的DTM接口上使用較高的JTAG傳輸頻率, 也無法對傳輸性能和傳輸效率做進一步的提升, 體現在邏輯分析儀捕獲的DTM接口波形上即為較長的請求間隔, 如圖2所示.

圖2 基于OpenOCD調試器總線訪問操作時序圖

RV-Link項目與上述項目不同, 它將整個調試協議棧卸載到調試適配器上, 對主機通過GDB server協議通訊, 其大幅度降低了延遲, 提高了系統的傳輸效率,達到了近似下文所述商業工具J-Link的性能[9]. 但它存在以下的問題:

(1) 調試適配器本身資源有限, 難于存儲不同的設備支持表、外設支持驅動等必要的信息, 使得支持設備的數量較少且二次開發門檻較高.

(2) 使用GDB server協議與主機通訊, 難以承載其他的調試需求, 如裸JTAG通訊等.

(3) 無完善的固件升級方案, 難于解決使用固件升級的方式對系統增加功能, 或是修復問題.

2.3 現存商業化工具存在的問題

SEGGER公司推出的J-Link V11調試器提供了對RISC-V架構的支持. 與OpenOCD所不同的是, J-Link將調試協議棧中絕大多數功能卸載到調試適配器上運行[10], 有效緩解了主機-調試適配器間通訊延遲高造成的開銷, 從而大幅提升了調試器的編程速率.

但是, J-Link如傳統的商業化工具一樣, 存在以下幾個較為明顯的問題, 使其應用難于鋪開:

(1) 大量功能需要在調試適配器上直接運行, 對調試適配器本身的處理性能有一定要求.

(2) J-Link并非開源系統, ASIC設計廠商和開發者難以改進J-Link內置的設備支持或增加其他芯片的支持.

(3) J-Link對第三方的開放接口十分有限, 且經常變化. 第三方開發者如果基于J-Link開發了專有的目標系統驅動程序, 如Flash存儲器編程驅動等, 后續升級J-Link軟件版本的成本非常高.

(4) 截至2022年3月, J-Link對多核RISC-V系統的支持仍然不佳, 對部分處理器IP核與專有DTM協議的兼容性較差.

(5) J-Link的組件耦合緊密, 單獨剝離使用(如在產線上用作離線編程器)較為困難.

(6) J-Link購置成本高, 難以大規模推廣.

3 Morpheus調試協議棧

針對以上現有工具的不足, 本文提出一種基于異步I/O、模塊化、輕量級RPC的調試協議棧的設計方案. 該方案充分結合了各現有調試方案的優勢, 并為未來的擴展留下了足夠的空間.

3.1 設計理念

在緩存設置合理的情況下, 異步傳輸的吞吐率并不會因為延遲增加而產生明顯下降. 同步傳輸由于需要在每一步狀態改變之后等待對面設備響應, 實際吞吐率和全鏈路的延遲呈現負相關. 因此, 在設計新調試器方案時, 為了解決系統的傳輸瓶頸, 應當將同步傳輸局限于調試適配器與待測系統之間, 而在主機-調試適配器間使用異步傳輸, 以求最大化的降低延遲.

RV-Link式的將所有功能均卸載到調試適配器上,僅對主機暴露最終調試接口的設計范式, 也能夠滿足上述要求. 但調試適配器本身處理性能較主機弱、存儲容量較主機小. 這些缺點無疑限制了它的擴展性與它能夠達到的性能上限. 因此, 對調試協議棧整體架構的設計, 既不能將所有模塊均放置于主機端, 這意味著較高的延遲導致的較低傳輸效率; 也不應當將所有模塊均放置于調試適配器端, 這意味著較低的處理能力導致的受限的擴展性和有限的功能.

綜合考慮, 意味著Morpheus必須對軟件模塊進行拆分, 摒棄OpenOCD等軟件傳統的緊耦合式大狀態機結構, 并且讓拆分出的小狀態機能夠在不同架構的硬件上表現一致, 同時, 盡量將必須同步通信的模塊設計在同一硬件實體上運行, 并依靠RPC機制實現其他模塊間的高效跨設備異步傳輸. 上述模塊拆分能力同時讓接口的標準化成為現實. 對Morpheus系統中任何功能的廠商定制都可以通過實現一組標準的軟件接口來完成, 無需廠商自行維護整個調試器的一個單獨分支.這一設計有效避免了現有開源調試器軟件碎片化、各公司提供的版本和功能不一致的問題, 也為低成本的離線編程器提供了實現的基礎.

3.2 系統結構

為了降低模塊間耦合, 提高傳輸效率, 使得整個調試系統靈活、可持續擴展, 同時又不引入模塊間調用的巨大開銷, 依據第3.1節中的設計理念, 借鑒各個現存調試系統的優勢和成功經驗, 調試協議棧整體被分拆為如下組件, 如圖3所示. 其中, 圖中標示為PC的組件可運行于主機系統上, 標示為HW的組件可運行于調試適配器上.

圖3 Morpheus調試協議棧結構框圖

(1) SoC library: 提供目標系統的配置信息、驅動程序、地址映射表(memory-map)等必要信息.

(2) GDB server: 直接提供對GDB或其他GDB 協議客戶端(如Eclipse)的調試服務功能, 并結合SoC library提供的目標系統信息, 產生合適的調試抽象命令RVDAL (RISC-V debug abstract language)提供給RISC-V frontend.

(3) RISC-V frontend: 根據待測系統的調試協議版本, 將RVDAL命令轉換成相應的DM控制命令序列.

(4) Transport backend: 將對應的DM控制命令序列轉換成DTM所需要的時序, 并連接DTM, 提供調試的物理通路. 如JTAG/cJTAG[11]/Nuclei-Wire/USB[8]等接口.

(5) Morpheus interface: 提供各個組件之間的互操作與異步I/O接口的定義和參考實現. 實現輕量化的RPC協議[12]與可選的調試適配器維護(如固件升級)等功能. 未來將支持可選的對外裸接口功能. 使得其他的調試工具, 如FPGA配置工具也能復用transport backend提供的數據通路, 達到僅需單調試器與調試線路, 可同時調試不同種類型的待測系統的目的, 如Xilinx Zynq異構集成系統.

此外, Morpheus使用C語言(符合C89標準)開發, 各基礎組件均能跨平臺工作, 耦合度低且不依賴特定操作系統. 因此, 其中部分組件可以獨立運作來實現某些定制功能. 例如SoC library、RISC-V frontend、transport backend、Morpheus interface單獨提取出來即可作為一個基本的離線編程器使用.

3.3 輕量級RPC的實現

Morpheus各組件之間使用Morpheus interface所提供的接口進行調用. 其中RPC協議基于簡單的TLV(type-length-value)[13]幀格式, 運行在RPC管道上.RPC管道是一個保證按序交付的幀式管道的虛擬實體. 目前有一個基于USB虛擬串口(CDC-ACM協議)[14]與一個共享內存的RPC管道參考實現, 未來可擴展基于以太網或其他協議的傳輸管道, 達到靈活部署的目的. 其中, 基于共享內存的管道用于在單實例中函數間的調用場景. RPC協議的幀格式如表1所示.

表1 RPC協議幀格式

表1中, 調用方的載荷, 作為被調用方的輸入參數使用. 若被調用方存在返回值, 則在應答幀中填入函數返回值的載荷, 使得載荷返回調用方. 載荷格式如表2.

表2 載荷格式

該輕量化的RPC協議實現了主機與調試適配器之間靈活的調用關系, 并具有多樣化的載荷類型擴展能力, 使得使用統一的編程模型, 對主機程序的開發與調試適配器固件的開發成為可能.

3.4 驗證方法與啞傳輸后端

為了在無實際硬件的情況下(如回歸仿真環境)對調試協議棧的正確性進行快速測試, 并向EDA環境提供調試接口. Morpheus調試協議棧提供了兩種特殊的傳輸后端, 分別為啞傳輸后端與Verilog過程接口(Verilog procedural interface, VPI)傳輸后端.

其中啞傳輸后端實現了一個簡單的基于RISC-V調試規范0.13版本的DM后端, 能夠簡單的對RISC-V frontend進行覆蓋測試. 同時, 為了能兼容存量MPSSE調試適配器, Morpheus提供了基于MPSSE的傳輸后端, 但此時所有Morpheus組件均運行于主機, 沒有降低I/O延遲所帶來的傳輸效率提升.

VPI傳輸后端提供了類似OpenOCD的JTAGVPI接口[15], 能與EDA仿真環境互通, 操作EDA環境中的RISC-V核心的DM或DTM, 提供在EDA仿真環境中對處理器調試模塊的訪問與控制能力.

3.5 系統初始化流程

由于Morpheus調試系統使用同一套代碼庫編譯出可跨平臺運行的各組件, 組件間使用RPC方式互操作并建立數據通路. 因此啟動時必須保證主機端與適配器端的固件版本完全一致, 否則RPC無法正常工作.因此, 在進行初始化流程時必須加入版本確認過程, 確保適配器與主機端程序版本完全一致, 如圖4所示.

圖4 Morpheus 調試協議棧非啞傳輸模式下啟動流程圖

4 性能優化的具體實現

4.1 總線訪問流程

在處理總線訪問請求時, 由位于主機的GDB server負責接收或提供數據, 以RPC的方式對位于調試適配器固件中的RISC-V frontend組件進行調用, RISC-V frontend根據命令和總線訪問方式, 進行可選的虛擬地址-物理地址轉換[16], 產生對應的DM訪問序列, 由之前已選擇好的DTM傳輸接口所對應的后端發出. 由于RISC-V frontend組件與transport backend組件均可運行在調試適配器上, 且調試適配器使用微控制器實現, 故相比于主機直接控制的方式能提供較低的輸入輸出延遲, 由此達到提高傳輸效率, 降低數據傳輸時間的目的, 其流程如圖5所示.

圖5 總線訪問流程圖

4.2 Flash存儲器編程流程

Flash存儲器具有電可擦除, 無需后備電源保持數據、可重復編程、存儲密度高、低功耗、低成本等特點, 是一類應用廣泛的NVM存儲器[17]. 但相比RAM而言, Flash存儲器需要特殊的寫入時序進行編程, 編程前必須擦除原有內容[18]; 不同Flash亦具有不同的編程模型, 互不兼容, 故無法用簡單的總線訪問流程解決對Flash存儲器的編程問題. 因此我們引入一個中間層, 即Flash驅動機制[19], 解決對不同系統、不同型號Flash的編程問題.

由于主機側對待測系統通信延遲高, Morpheus調試協議棧為提高效率和簡化設計, 不支持類似OpenOCD將Flash驅動直接實現在主機側的Flash驅動方案, 強制使用基于Flashloader的Flash驅動方案.

Flashloader是一組簡單的、平臺相關的、可被重定位的運行于待測系統上的程序[20], 存儲于SoC library中. 若用戶請求對某塊地址空間的寫入, GDB server將對比SoC library中的系統配置, 確定用戶是否請求對Flash區間進行編程. 若用戶訪問的地址空間不屬于Flash區間, 則系統轉入總線訪問流程.

若用戶訪問的地址空間屬于Flash區間, 則GDB將對GDB server請求目標系統地址的映射表[21], 然后,GDB server將根據系統配置, 在待測系統上尋找一塊合適的可被執行的內存塊, 申請足夠大小的內存, 該內存塊被稱為工作區. 申請到工作區后, 將工作區分為程序區與數據緩沖區, 將Flashloader寫入程序區. 再使用Flashloader與GDB server已約定好的ABI, 運行Flashloader的初始化過程與擦除過程, 在確認初始化和擦除過程成功完成后, 進入編程循環: GDB server將對申請到的數據緩沖區寫入部分數據, 隨后運行Flashloader的寫入流程, 不斷重復編程循環, 直到所有數據均被正確編程到Flash中. 在Flash編程完畢后,GDB server將運行Flashloader的反初始化流程, 確保系統被復原. 然后銷毀工作區, 完成整個編程流程, 流程如圖6所示.

圖6 Flash編程流程圖

使用Flashloader的Flash編程方式, 相較于原本直接由主機或調試適配器上運行的固件對Flash控制器的寄存器直接操作的方式有效降低了往返延遲, 提高了編程速率, 并充分利用了待測系統的運行性能, 且降低了Morpheus本身的復雜度: Morpheus本身不需要內置任何Flash控制器的驅動程序, 僅需要按照標準接口增加Flashloader, 就能快速便捷的支持新的Flash控制器. 在用戶軟件開發能力不足時, 無需重新編譯整個項目, 僅需簡單增加SoC library配置即可支持, 可大大縮短開發周期; Morpheus維護團隊則僅需維護一份平臺無關的代碼, 即可實現對不同結構、不同外設驅動的SoC的支持, 有效減輕了軟件測試壓力.

4.3 性能測試結果

在基于芯來科技Bumblebee內核的兆易創新GD32VF103芯片平臺, JTAG TCK頻率設定為4 MHz.OpenOCD作為調試協議棧, FTDI作為調試適配器的工況下, 對RAM的編程速率約為57 KB/s, 對Flash的編程速率約為10 KB/s.

在完全相同的GD32VF103硬件平臺上, JTAGTCK頻率設定仍為4 MHz. Morpheus作為調試協議棧, GD32VF103+Morpheus固件作為調試適配器的工況下, 對RAM的編程速率約為141 KB/s, 對Flash的編程速率約為16 KB/s.

由于使用了異步I/O機制, 并應用了RPC架構, 將大量耗時的I/O操作由主機卸載到調試適配器上,Morpheus相對OpenOCD的RAM編程、Flash編程性能提升分別為+140%、+60%, 體現在DTM接口波形上, 即為較短的請求間隔. 邏輯分析儀抓取的DTM接口波形如圖7所示, 可見相比圖2, 延遲由118 μs縮短為2.3 μs.

圖7 Morpheus 調試協議棧總線訪問時序圖

5 總結與展望

RISC-V架構以它獨特的開放、開源且模塊化的優勢得到了產業及學術界的青睞. 為了推進RISC-V生態的鋪開, 開發工具與軟件生態的建設十分重要. 本文在分析各現有方案不足的基礎上, 提出并實現了一套開源、模塊化并基于輕量化RPC實現互操作的全新的RISC-V調試協議棧——Morpheus. 該方案解決了目前現有調試方案性能低下、擁有成本高昂的問題,成功的降低了調試器的開發、維護、測試成本.

目前, Morpheus尚未實現同類商業調試系統提供的全部的功能. 在未來, Morpheus需要走的路還很長.但基于靈活的RPC和異步I/O機制, Morpheus的開發和維護, 相對傳統緊耦合的調試器設計, 存在巨大的優勢. 基于這一先進架構, Morpheus開發團隊將逐步實現更多的功能, 如對Semihosting、Flash軟斷點的支持以及對虛擬內存/對稱多處理機系統的支持等, 助力RISC-V架構在行業內進一步的普及, 為RISC-V開發工具與基礎軟件生態建設作出貢獻.