萬(wàn)瑞罡, 朱煥杰

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

1 引言

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

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

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

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

2 研究背景

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

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

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

(1) 抽象命令(abstract command)

(2) 程序緩存(program buffer)

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

規(guī)范強(qiáng)制要求待測(cè)系統(tǒng)中的DM至少支持上述3種方式中的一種. 但無(wú)論選擇實(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是待測(cè)設(shè)備. RISC-V調(diào)試規(guī)范所定義的JTAG-DTM模塊對(duì)DM的交互依靠于JTAG DR寄存器DMI (debug module interface)[3]接口. 在通常的實(shí)現(xiàn)中, DTM與DM之間使用不同的時(shí)鐘域[4], 而DMI寄存器承擔(dān)了在兩個(gè)時(shí)鐘域中時(shí)鐘跨越的功能. 這種設(shè)計(jì)引入的跨時(shí)鐘域握手機(jī)制將導(dǎo)致DTM阻塞, 即使在DM完全不阻塞的情況下. 任何對(duì)DM的訪問(wèn)請(qǐng)求,一般分為如下幾步.

圖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錯(cuò)誤, 則進(jìn)入錯(cuò)誤處理流程.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 設(shè)計(jì)理念

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

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

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

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

為了降低模塊間耦合, 提高傳輸效率, 使得整個(gè)調(diào)試系統(tǒng)靈活、可持續(xù)擴(kuò)展, 同時(shí)又不引入模塊間調(diào)用的巨大開(kāi)銷, 依據(jù)第3.1節(jié)中的設(shè)計(jì)理念, 借鑒各個(gè)現(xiàn)存調(diào)試系統(tǒng)的優(yōu)勢(shì)和成功經(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ū)動(dòng)程序、地址映射表(memory-map)等必要信息.

(2) GDB server: 直接提供對(duì)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ù)待測(cè)系統(tǒng)的調(diào)試協(xié)議版本, 將RVDAL命令轉(zhuǎn)換成相應(yīng)的DM控制命令序列.

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

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

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

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

Morpheus各組件之間使用Morpheus interface所提供的接口進(jìn)行調(diào)用. 其中RPC協(xié)議基于簡(jiǎn)單的TLV(type-length-value)[13]幀格式, 運(yùn)行在RPC管道上.RPC管道是一個(gè)保證按序交付的幀式管道的虛擬實(shí)體. 目前有一個(gè)基于USB虛擬串口(CDC-ACM協(xié)議)[14]與一個(gè)共享內(nèi)存的RPC管道參考實(shí)現(xiàn), 未來(lái)可擴(kuò)展基于以太網(wǎng)或其他協(xié)議的傳輸管道, 達(dá)到靈活部署的目的. 其中, 基于共享內(nèi)存的管道用于在單實(shí)例中函數(shù)間的調(diào)用場(chǎng)景. 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)一的編程模型, 對(duì)主機(jī)程序的開(kāi)發(fā)與調(diào)試適配器固件的開(kāi)發(fā)成為可能.

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

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

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

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

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

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

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

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

4.1 總線訪問(wèn)流程

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

圖5 總線訪問(wèn)流程圖

4.2 Flash存儲(chǔ)器編程流程

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

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

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

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

圖6 Flash編程流程圖

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

4.3 性能測(cè)試結(jié)果

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

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

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

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

5 總結(jié)與展望

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

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