萬瑞罡, 朱煥杰

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

1 引言

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

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

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

本文組織結(jié)構(gòu)如下: 第2節(jié)介紹相關(guān)的背景知識及目前常用的調(diào)試協(xié)議棧與調(diào)試系統(tǒng)存在的問題; 第3節(jié)介紹Morpheus調(diào)試協(xié)議棧的基本架構(gòu)設(shè)計思路與解決現(xiàn)有問題的方法; 第4節(jié)介紹Morpheus調(diào)試協(xié)議棧部分操作的具體實(shí)現(xiàn)流程; 第5節(jié)對本文做出總結(jié).

2 研究背景

2.1 調(diào)試協(xié)議概述

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

根據(jù)目前的RISC-V調(diào)試規(guī)范, 對待測系統(tǒng)的總線訪問請求可以使用3種方式實(shí)現(xiàn)[2]:

(1) 抽象命令(abstract command)

(2) 程序緩存(program buffer)

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

規(guī)范強(qiáng)制要求待測系統(tǒng)中的DM至少支持上述3種方式中的一種. 但無論選擇實(shí)現(xiàn)其中哪一種, 數(shù)據(jù)傳輸均基于調(diào)試傳輸模塊(debug transport module,DTM)所建立的數(shù)據(jù)通路.

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

圖1 RISC-V 調(diào)試系統(tǒng)整體結(jié)構(gòu)框圖

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

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

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

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

2.2 現(xiàn)存社區(qū)維護(hù)的工具存在的問題

目前, 開源社區(qū)存在一定數(shù)量的調(diào)試協(xié)議棧實(shí)現(xiàn),例如OpenOCD、RV-Link等. OpenOCD由RISC-V基金會維護(hù), 且對RISC-V架構(gòu)處理器的調(diào)試功能支持最全面, 是現(xiàn)今應(yīng)用最廣泛的開源調(diào)試協(xié)議棧.

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

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

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

圖2 基于OpenOCD調(diào)試器總線訪問操作時序圖

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

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

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

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

2.3 現(xiàn)存商業(yè)化工具存在的問題

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

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

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

(2) J-Link并非開源系統(tǒng), ASIC設(shè)計廠商和開發(fā)者難以改進(jìn)J-Link內(nèi)置的設(shè)備支持或增加其他芯片的支持.

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

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

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

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

3 Morpheus調(diào)試協(xié)議棧

針對以上現(xiàn)有工具的不足, 本文提出一種基于異步I/O、模塊化、輕量級RPC的調(diào)試協(xié)議棧的設(shè)計方案. 該方案充分結(jié)合了各現(xiàn)有調(diào)試方案的優(yōu)勢, 并為未來的擴(kuò)展留下了足夠的空間.

3.1 設(shè)計理念

在緩存設(shè)置合理的情況下, 異步傳輸?shù)耐掏侣什⒉粫驗(yàn)檠舆t增加而產(chǎn)生明顯下降. 同步傳輸由于需要在每一步狀態(tài)改變之后等待對面設(shè)備響應(yīng), 實(shí)際吞吐率和全鏈路的延遲呈現(xiàn)負(fù)相關(guān). 因此, 在設(shè)計新調(diào)試器方案時, 為了解決系統(tǒng)的傳輸瓶頸, 應(yīng)當(dāng)將同步傳輸局限于調(diào)試適配器與待測系統(tǒng)之間, 而在主機(jī)-調(diào)試適配器間使用異步傳輸, 以求最大化的降低延遲.

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

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

3.2 系統(tǒng)結(jié)構(gòu)

為了降低模塊間耦合, 提高傳輸效率, 使得整個調(diào)試系統(tǒng)靈活、可持續(xù)擴(kuò)展, 同時又不引入模塊間調(diào)用的巨大開銷, 依據(jù)第3.1節(jié)中的設(shè)計理念, 借鑒各個現(xiàn)存調(diào)試系統(tǒng)的優(yōu)勢和成功經(jīng)驗(yàn), 調(diào)試協(xié)議棧整體被分拆為如下組件, 如圖3所示. 其中, 圖中標(biāo)示為PC的組件可運(yùn)行于主機(jī)系統(tǒng)上, 標(biāo)示為HW的組件可運(yùn)行于調(diào)試適配器上.

圖3 Morpheus調(diào)試協(xié)議棧結(jié)構(gòu)框圖

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

(2) GDB server: 直接提供對GDB或其他GDB 協(xié)議客戶端(如Eclipse)的調(diào)試服務(wù)功能, 并結(jié)合SoC library提供的目標(biāo)系統(tǒng)信息, 產(chǎn)生合適的調(diào)試抽象命令RVDAL (RISC-V debug abstract language)提供給RISC-V frontend.

(3) RISC-V frontend: 根據(jù)待測系統(tǒng)的調(diào)試協(xié)議版本, 將RVDAL命令轉(zhuǎn)換成相應(yīng)的DM控制命令序列.

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

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

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

3.3 輕量級RPC的實(shí)現(xiàn)

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

表1 RPC協(xié)議幀格式

表1中, 調(diào)用方的載荷, 作為被調(diào)用方的輸入?yún)?shù)使用. 若被調(diào)用方存在返回值, 則在應(yīng)答幀中填入函數(shù)返回值的載荷, 使得載荷返回調(diào)用方. 載荷格式如表2.

表2 載荷格式

該輕量化的RPC協(xié)議實(shí)現(xiàn)了主機(jī)與調(diào)試適配器之間靈活的調(diào)用關(guān)系, 并具有多樣化的載荷類型擴(kuò)展能力, 使得使用統(tǒng)一的編程模型, 對主機(jī)程序的開發(fā)與調(diào)試適配器固件的開發(fā)成為可能.

3.4 驗(yàn)證方法與啞傳輸后端

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

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

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

3.5 系統(tǒng)初始化流程

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

圖4 Morpheus 調(diào)試協(xié)議棧非啞傳輸模式下啟動流程圖

4 性能優(yōu)化的具體實(shí)現(xiàn)

4.1 總線訪問流程

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

圖5 總線訪問流程圖

4.2 Flash存儲器編程流程

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

由于主機(jī)側(cè)對待測系統(tǒng)通信延遲高, Morpheus調(diào)試協(xié)議棧為提高效率和簡化設(shè)計, 不支持類似OpenOCD將Flash驅(qū)動直接實(shí)現(xiàn)在主機(jī)側(cè)的Flash驅(qū)動方案, 強(qiáng)制使用基于Flashloader的Flash驅(qū)動方案.

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

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

圖6 Flash編程流程圖

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

4.3 性能測試結(jié)果

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

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

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

圖7 Morpheus 調(diào)試協(xié)議?？偩€訪問時序圖

5 總結(jié)與展望

RISC-V架構(gòu)以它獨(dú)特的開放、開源且模塊化的優(yōu)勢得到了產(chǎn)業(yè)及學(xué)術(shù)界的青睞. 為了推進(jìn)RISC-V生態(tài)的鋪開, 開發(fā)工具與軟件生態(tài)的建設(shè)十分重要. 本文在分析各現(xiàn)有方案不足的基礎(chǔ)上, 提出并實(shí)現(xiàn)了一套開源、模塊化并基于輕量化RPC實(shí)現(xiàn)互操作的全新的RISC-V調(diào)試協(xié)議?！狹orpheus. 該方案解決了目前現(xiàn)有調(diào)試方案性能低下、擁有成本高昂的問題,成功的降低了調(diào)試器的開發(fā)、維護(hù)、測試成本.

目前, Morpheus尚未實(shí)現(xiàn)同類商業(yè)調(diào)試系統(tǒng)提供的全部的功能. 在未來, Morpheus需要走的路還很長.但基于靈活的RPC和異步I/O機(jī)制, Morpheus的開發(fā)和維護(hù), 相對傳統(tǒng)緊耦合的調(diào)試器設(shè)計, 存在巨大的優(yōu)勢. 基于這一先進(jìn)架構(gòu), Morpheus開發(fā)團(tuán)隊將逐步實(shí)現(xiàn)更多的功能, 如對Semihosting、Flash軟斷點(diǎn)的支持以及對虛擬內(nèi)存/對稱多處理機(jī)系統(tǒng)的支持等, 助力RISC-V架構(gòu)在行業(yè)內(nèi)進(jìn)一步的普及, 為RISC-V開發(fā)工具與基礎(chǔ)軟件生態(tài)建設(shè)作出貢獻(xiàn).