劉 鵬，劉 杰，賈 訊

（江南計(jì)算技術(shù)研究所，江蘇 無(wú)錫 214215）

0 概述

在高端服務(wù)器或低功耗嵌入式產(chǎn)品中，調(diào)試機(jī)制雖然不受關(guān)注但不可或缺。已經(jīng)通過(guò)驗(yàn)證測(cè)試的成熟芯片產(chǎn)品一般提供非入侵式、入侵式這兩種或其中一種調(diào)試機(jī)制［1］。入侵式調(diào)試機(jī)制主要通過(guò)軟件或硬件中斷陷入調(diào)試模式［2］，主要以斷點(diǎn)和單步調(diào)試為代表。用戶(hù)在斷點(diǎn)和步進(jìn)調(diào)試過(guò)程中，可以控制應(yīng)用程序代碼運(yùn)行到代碼中的指定點(diǎn)，然后Halt 標(biāo)識(shí)的處理器，此時(shí)，用戶(hù)可以選擇檢查或更改內(nèi)存以及寄存器內(nèi)容，步進(jìn)或重新啟動(dòng)應(yīng)用程序。非侵入式調(diào)試機(jī)制以跟蹤（Trace）模式為主，主要實(shí)現(xiàn)方式是將CPU 狀態(tài)及指令流信息壓縮導(dǎo)入存儲(chǔ)器，協(xié)同軟件解壓縮開(kāi)展現(xiàn)場(chǎng)或性能分析，能夠幫助用戶(hù)查證CPU 在全速運(yùn)轉(zhuǎn)下才出現(xiàn)的或偶然發(fā)生而不可預(yù)測(cè)的錯(cuò)誤［3］。

本文針對(duì)某自主國(guó)產(chǎn)SoC 芯片（下文簡(jiǎn)稱(chēng)為GCXP），設(shè)計(jì)一個(gè)保證用戶(hù)可調(diào)試觀測(cè)和安全性的用戶(hù)調(diào)試解決方案。調(diào)試行為通過(guò)中斷及其處理程序來(lái)實(shí)現(xiàn)，保證在調(diào)試中斷監(jiān)控下開(kāi)展調(diào)試行為。兼容開(kāi)源上位機(jī)OpenOCD 調(diào)試軟件生態(tài)，從而支持Eclipse等IDE。不同于ARM、Sivife 等需要進(jìn)行CPU 設(shè)計(jì)，本文方案向CPU IP 核已經(jīng)設(shè)計(jì)完備的SoC 中增加硬件輔助調(diào)試功能，不需要修改CPU 設(shè)計(jì)。

1 相關(guān)工作

目前，大多數(shù)處理器都獨(dú)立設(shè)計(jì)了一套調(diào)試體系結(jié)構(gòu)，以便于用戶(hù)進(jìn)行片上調(diào)試。例如，x86 體系結(jié)構(gòu)提供了6 個(gè)調(diào)試寄存器來(lái)支持硬件斷點(diǎn)和調(diào)試異常［1］，同時(shí)Intel Processor Trace［2］也是一個(gè)備受關(guān)注的硬件輔助調(diào)試特性［3-4］。Arm 架構(gòu)的處理器具有調(diào)試和非調(diào)試兩種狀態(tài)，并設(shè)計(jì)了一組調(diào)試寄存器來(lái)支持自主機(jī)調(diào)試和外部調(diào)試［5-6］。同時(shí)，ARM［7-9］還引入了硬件組件，如Embedded Trace Macrocell［10］和Embedded Cross Trigger［11］，以完成各種硬件輔助調(diào)試目的。相應(yīng)地，硬件供應(yīng)商通過(guò)片上調(diào)試端口將上述調(diào)試特性暴露給外部調(diào)試器，比較常用的調(diào)試端口是IEEE 1149.1［12］定義的聯(lián)合測(cè)試工作組（Joint Test Action Group，JTAG）端口，主要用來(lái)支持調(diào)試目標(biāo)和外部調(diào)試工具之間的通信。使用JTAG端口和外部調(diào)試工具（如Intel System Debugger［13］、ARM DS-5［14］、OpenOCD［15］），開(kāi)發(fā)人員能夠有效、方便地訪問(wèn)目標(biāo)的內(nèi)存和寄存器。

ARM 的調(diào)試基礎(chǔ)架構(gòu)稱(chēng)為CoreSight，主要實(shí)現(xiàn)調(diào)試和跟蹤這2 個(gè)功能：

1）調(diào)試功能，運(yùn)行處理器的控制，允許啟動(dòng)和停止程序單步調(diào)試源碼和匯編代碼，在處理器運(yùn)行時(shí)設(shè)置斷點(diǎn)，即時(shí)讀取/寫(xiě)入存儲(chǔ)器內(nèi)容和外設(shè)寄存器，讀寫(xiě)內(nèi)部和外部FLASH 存儲(chǔ)器。

2）跟蹤功能，提供程序計(jì)數(shù)器采樣、數(shù)據(jù)跟蹤、事件跟蹤等，實(shí)現(xiàn)CPU 歷史序列調(diào)試、軟件性能分析和代碼覆蓋率分析。

開(kāi)源SoC 硬件輔助調(diào)試解決方案主要有RISCV Debug Spec 0.11/0.13［16］、Open SoC Debug（OSD）［17］，兩者都描述了基于Run-Stop、Trigger、System Bus Access調(diào)試的具體規(guī)范細(xì)節(jié)，后者著重描述Trace 模式并給出了基于Rocket-Core 的參考設(shè)計(jì)實(shí)現(xiàn)，需要在Core 內(nèi)實(shí)現(xiàn)Core Debug Unit 邏輯，前者有獨(dú)立的Trace-Spec［18］，依賴(lài)CPU 預(yù)留Core Trace IO。

在GCXP 系列中，用戶(hù)通過(guò)片外維護(hù)控制模塊訪問(wèn)I/O 和存儲(chǔ)空間，CPU 片內(nèi)狀態(tài)通過(guò)掃描鏈硬件邏輯來(lái)觀測(cè)調(diào)試［19-20］。同時(shí)，特有的HMCODE 機(jī)制也可以在核心驅(qū)動(dòng)調(diào)試以承擔(dān)調(diào)試功能，但一般不對(duì)用戶(hù)開(kāi)放。與商業(yè)SoC 調(diào)試功能相比，現(xiàn)階段GCXP 系列產(chǎn)品的調(diào)試機(jī)制缺少安全性［21］以及交互、斷點(diǎn)、靈活讀寫(xiě)功能，同時(shí)缺乏上位機(jī)調(diào)試軟件IDE 工具生態(tài)［22］，尤其在安全性和嵌入式用戶(hù)調(diào)試工具生態(tài)上，存在較大缺陷，如基于掃描鏈重用的調(diào)試機(jī)制，因掃描鏈在芯片上留下一個(gè)獨(dú)立的邏輯接口，不受任何權(quán)限檢查，可以在任何時(shí)刻獲取芯片內(nèi)部的狀態(tài)信息，相當(dāng)于為芯片增加了一個(gè)“后門(mén)”。同時(shí)，文獻(xiàn)［21］中也提到了一種JTAG 掃描鏈攻擊的逆向技術(shù)，黑客可以獲取掃描鏈上芯片架構(gòu)設(shè)計(jì)相關(guān)細(xì)節(jié)信息。在嵌入式用戶(hù)調(diào)試工具方面，ARM、Sifive 都配備對(duì)應(yīng)的上位機(jī)IDE 或兼容主流開(kāi)源IDE，如Eclipse、Keil 等，與硬件調(diào)試輔助機(jī)制相結(jié)合，可以提供便捷豐富的寄存器以及內(nèi)存觀測(cè)讀寫(xiě)、斷點(diǎn)、程序下載、性能分析功能。

GCXP 硬件輔助調(diào)試配套軟件部署要求較高（可參見(jiàn)文獻(xiàn)［20］），且只提供觀測(cè)功能，目前沒(méi)有與商業(yè)SoC 產(chǎn)品類(lèi)似的用戶(hù)環(huán)境。此外，交互式調(diào)試設(shè)計(jì)需要CPU 設(shè)計(jì)配合，是流水線設(shè)計(jì)的重要一環(huán)，且目前沒(méi)有向已有成熟CPU 設(shè)計(jì)的SoC 環(huán)境中增加交互調(diào)試的方法。

2 GCXP-1A 調(diào)試模塊設(shè)計(jì)

GCXP-1A 是一款面向低功耗嵌入式領(lǐng)域、采用精簡(jiǎn)GCXP 指令集的國(guó)產(chǎn)通用處理器核心，實(shí)現(xiàn)了全獨(dú)立自主指令集嵌入式子集，是GCXP 架構(gòu)下面向嵌入式領(lǐng)域的處理器核心，該核心采用IP 化設(shè)計(jì)，指令、數(shù)據(jù)存儲(chǔ)器工作模式、TLB 條目數(shù)等關(guān)鍵微結(jié)構(gòu)參數(shù)化設(shè)計(jì)，并實(shí)現(xiàn)標(biāo)準(zhǔn)AXI 接口，便于通用SoC 集成。

GCXP-1A 設(shè)計(jì)主要參考RISCV Debug Spec 0.13.2 規(guī)范及Sifive U500K 開(kāi)源SoC源碼，兼容RISCV OpenOCD 軟件調(diào)試工具及OpenOCD 的IDE生態(tài)，結(jié)合GCXP 軟硬件架構(gòu)開(kāi)展調(diào)試模塊設(shè)計(jì)，結(jié)合GCXP 特權(quán)架構(gòu)開(kāi)展用戶(hù)調(diào)試工具的硬件設(shè)計(jì)，同時(shí)在OpenOCD 軟件端開(kāi)辟GCXP 分支，兼容RISCV Debug Spec 0.13.2 流程，實(shí)現(xiàn)完整的Run-Stop 侵入式調(diào)試機(jī)制以及OpenOCD 接口下的基本調(diào)式、程序下載功能，相較于無(wú)感知的掃描鏈重用調(diào)試信息獲取，該方法處于調(diào)試中斷語(yǔ)義監(jiān)控環(huán)境中，安全性更高，并且對(duì)CPU 核內(nèi)無(wú)設(shè)計(jì)要求，借助OpenOCD，可直接與GDB、開(kāi)源IDE 產(chǎn)品對(duì)接，可以向前擴(kuò)展CPU 產(chǎn)品的通用調(diào)試生態(tài)，同時(shí)開(kāi)展模擬驗(yàn)證及FPGA 驗(yàn)證，從而證明功能的正確性。

RISCV Debug Spec 0.13.2 Spec 中 對(duì)CPU 設(shè) 計(jì)提出了諸多要求，例如，需要2 條調(diào)試專(zhuān)用指令EBREAK、DRET，Trigger 硬件斷點(diǎn)寄存器，以及調(diào)試模式與配套的DPC、DCSR 寄存器等，同時(shí)，在流水線控制上也需要對(duì)應(yīng)的設(shè)計(jì)。在GCXP 特權(quán)架構(gòu)下，為了不對(duì)原有CPU 設(shè)計(jì)、操作系統(tǒng)核軟件接口及編譯工具鏈設(shè)計(jì)進(jìn)行改動(dòng)，取消調(diào)試模式（調(diào)試模式在RISCV 開(kāi)源CPU 中實(shí)現(xiàn)，特權(quán)層級(jí)還是處于M 模式，嚴(yán)格上來(lái)說(shuō)并不算是一種獨(dú)立的特權(quán)層級(jí)），同時(shí)，EBREAK 與DRET 分別設(shè)計(jì)成GCXP 指令集中的SYSCALL，并分別約定特定的調(diào)用號(hào)，將DPC、DCSR 放入Debug Module（IO 地址空間）中。同時(shí)，因?yàn)镚CXP HM 特權(quán)架構(gòu)不響應(yīng)中斷，所以將RISCV Trigger 調(diào)試中斷、單步調(diào)試、硬件調(diào)試中斷都進(jìn)行重新設(shè)計(jì)，并設(shè)置對(duì)應(yīng)的HMCODE 處理軟件程序，以實(shí)現(xiàn)Spec 中調(diào)試中斷處理的硬件邏輯部分。

2.1 硬件邏輯設(shè)計(jì)

由于GCXP-1A 面向低功耗MCU 場(chǎng)景，因此調(diào)試機(jī)制設(shè)計(jì)主要考慮用戶(hù)調(diào)試應(yīng)用程序的Run-Stop調(diào)試以及外設(shè)I/O、Memory 內(nèi)容讀寫(xiě)功能這些需求，從而實(shí)現(xiàn)中斷調(diào)試模式、總線訪問(wèn)調(diào)試。GCXP-1A的具體硬件邏輯架構(gòu)如圖1 所示。

圖1 GCXP-1A 用戶(hù)調(diào)試模塊的邏輯架構(gòu)Fig.1 Logical architecture of GCXP-1A user debugging module

RISCV Debug Spec 0.13.2 中主要規(guī)范了一套抽象調(diào)試命令，便于不同架構(gòu)具體實(shí)現(xiàn)與調(diào)試工具及生態(tài)解耦，其Run-Stop 調(diào)試機(jī)制基于DM 模塊接管PC 來(lái)實(shí)現(xiàn)，分為T(mén)rigger 中斷（由硬件斷點(diǎn)觸發(fā)）、上位機(jī)調(diào)試中斷、軟件斷點(diǎn)陷入調(diào)試中斷這3 類(lèi)，最終通過(guò)Debug ROM 程序與調(diào)試模塊（Debug Module，DM）狀態(tài)機(jī)協(xié)同路由，決定CPU PC 取指地址，從而執(zhí)行從抽象命令解析、翻譯、預(yù)裝填到抽象命令相關(guān)字段所指定的不同存儲(chǔ)空間的調(diào)試命令。

GCXP-1A 用戶(hù)調(diào)試模塊的邏輯架構(gòu)主要實(shí)現(xiàn)用戶(hù)程序異常中斷調(diào)試、提供斷點(diǎn)環(huán)境通用寄存器及CSR 寄存器的訪問(wèn)、提供SoC 總線上外設(shè)I/O 寄存器或存儲(chǔ)器的訪問(wèn)。具體如下：

1）DM_TRANSPORT 模塊負(fù)責(zé)JTAG TAP 狀態(tài)機(jī)的實(shí)現(xiàn)，以及上位機(jī)指令操作向DM_ROUTER模塊內(nèi)部總線的轉(zhuǎn)寫(xiě)，主要分為DM_TRASNPORT寄存器訪問(wèn)和DM 內(nèi)部總線訪問(wèn)，前者主要是標(biāo)識(shí)調(diào)試協(xié)議實(shí)現(xiàn)版本，后者用于交互具體的調(diào)試任務(wù)。

當(dāng)TAP 狀態(tài)機(jī)進(jìn)入U(xiǎn)pdate-DR 狀態(tài)，IR 寄存器的值為DMI_ACCESS（5’h11），且當(dāng)前調(diào)試系統(tǒng)總線（Debug Message Interface，DMI）接口沒(méi)有錯(cuò)誤信息時(shí)，開(kāi)始執(zhí)行dmi.op 指定的操作。

如圖2 所示，當(dāng)dmi.op=0x1，dmi 狀態(tài)機(jī)進(jìn)入Read 狀態(tài)。在Read 狀態(tài)中，先將dmi_req_valid 信號(hào)拉高，再等待dmi_req_ready 信號(hào)為高時(shí)進(jìn)入WaitReadValid 狀態(tài)。在WaitReadValid 狀態(tài)中等待dmi_resp_valid 信號(hào)為高，當(dāng)該信號(hào)為高時(shí)，dmi 讀取DM 模塊回應(yīng)的數(shù)據(jù)（dmi_resp.data），并返回Idle 狀態(tài)。當(dāng)dmi.op=0x2，dmi 狀態(tài)機(jī)進(jìn)入Write 狀態(tài)。在Write 狀態(tài)中，先將dmi_req_valid 信號(hào)拉高，再等待dmi_req_valid 信號(hào)為高時(shí)返回Idle 狀態(tài)。

圖2 JTAG 轉(zhuǎn)DMI 內(nèi)部總線狀態(tài)機(jī)Fig.2 JTAG to DMI internal bus state machine

2）DM_ROUTER 模塊負(fù)責(zé)上位機(jī)通過(guò)JTAG DMI_ACCESS 訪問(wèn)填充的抽象調(diào)試寄存器內(nèi)容，圖3 為其功能邏輯圖，將調(diào)試任務(wù)依據(jù)抽象命令對(duì)應(yīng)標(biāo)志位，通過(guò)內(nèi)部總線發(fā)送到具體部件執(zhí)行。

圖3 DM_ROUTER 功能流程Fig.3 Procedure of DM_ROUTER function

3）DM_EXE 模塊接收并處理處理器內(nèi)部信息的調(diào)試指令，圖4 為其功能邏輯圖，根據(jù)用戶(hù)Halt 指令、軟件配置的硬件斷點(diǎn)是否等于CPU Trace 信號(hào)中PC 值、單步調(diào)試指令標(biāo)志情況，向外發(fā)出調(diào)試中斷信號(hào)，同時(shí)完成調(diào)試目的寄存器訪問(wèn)路由，分別組織指令架構(gòu)下通用寄存器訪問(wèn)、CSR 寄存器訪問(wèn)的指令編碼，并依據(jù)調(diào)試任務(wù)中標(biāo)識(shí)的執(zhí)行空間進(jìn)行指令填充（結(jié)果目的地址為內(nèi)部DATA 寄存器），等待PC 正確跳入取指執(zhí)行，執(zhí)行完畢標(biāo)記完成位，上位機(jī)將DATA 寄存器中的結(jié)果掃回。DM_EXE 模塊中的關(guān)鍵點(diǎn)是CPU、上位機(jī)、DM 模塊的三方協(xié)同狀態(tài)機(jī)，從而保證作業(yè)正常流轉(zhuǎn)。

圖4 DM_EXE 解析ABSTRACT_CMD 以及填充指令槽位邏輯Fig.4 DM_EXE parsing ABSTRACT_CMD and filling instruction slot logic

三方協(xié)同狀態(tài)機(jī)設(shè)計(jì)如圖5 所示，其中，左圖主要描述DM_EXE 硬件狀態(tài)機(jī)，右圖主要描述Debug Rom 軟件中斷處理程序。中斷可以由軟件陷入或上位機(jī)調(diào)制命令通過(guò)DM 發(fā)出，任何一種調(diào)試中斷發(fā)起，即觸發(fā)調(diào)試中斷，PC 跳入調(diào)試中斷入口程序（Debug Rom），首先挪用一個(gè)通用寄存器，再將標(biāo)定調(diào)試的Core_Id 寫(xiě)入DM Halted 寄存器，硬件狀態(tài)機(jī)確認(rèn)選中的CPU 已經(jīng)被停住，此時(shí)，若上位機(jī)發(fā)送了調(diào)試命令，則DM 將CMD_BUSY 拉高，進(jìn)入下一狀態(tài)，否則停留在IDLE，在Debug Rom 程序go 與resume 都等于0 的情況下會(huì)在Debug Rom 程序空間死循環(huán)，等待調(diào)試指令到來(lái)。

圖5 DM_EXE 軟硬協(xié)同狀態(tài)機(jī)Fig.5 DM_EXE software and hardware collaborative state machine

當(dāng)上位機(jī)調(diào)試指令到來(lái)，CMD_BUSY 信號(hào)隨即拉高，DM_EXE狀態(tài)機(jī)進(jìn)入GO狀態(tài)，此時(shí)等待Debug Rom程序填寫(xiě)DM 寄存器going 為1，此處設(shè)計(jì)是因?yàn)檎{(diào)試指令一般由1～2 條組成，并且為硬件寄存器裝填，1 個(gè)CLK 周期就能完成，在GCXP-1A 5 級(jí)流水線設(shè)計(jì)下，一條指令執(zhí)行周期即可保證指令硬件裝填完畢，Debug Rom執(zhí)行DM go寄存器判斷這條指令周期就足以滿(mǎn)足，因此，這里不再做DM 指令槽位填充完畢握手機(jī)制。狀態(tài)機(jī)檢測(cè)到Going 地址有寫(xiě)操作后，隨即PC 獲取一條跳轉(zhuǎn)指令，跳入DM_EXE 取指入口（where to go），根據(jù)上位機(jī)指令標(biāo)記獲取跳入不同DM 內(nèi)部指令槽入口的跳轉(zhuǎn)指令，從而執(zhí)行調(diào)試任務(wù)，指令槽位最后一條指令必然為跳回Debug Rom 首地址，通過(guò)再次寫(xiě)Halted地址進(jìn)入Idle 狀態(tài)。復(fù)位三方握手流程類(lèi)似，不再詳細(xì)描述。

4）DM_SBA 模塊實(shí)現(xiàn)一個(gè)總線的Master 端，從而使得DM 模塊能夠訪問(wèn)SoC 總線下編址地址信息讀寫(xiě)。DM_SBA 的總體功能邏輯結(jié)構(gòu)如圖6所示。

圖6 DM_SBA 模塊功能邏輯Fig.6 DM_SBA module function logic

DM_SBA 模塊的讀寫(xiě)過(guò)程用一個(gè)狀態(tài)機(jī)實(shí)現(xiàn)，有idle、write、read、waite_write、waite_read 這5 種狀態(tài)。狀態(tài)機(jī)的轉(zhuǎn)換示意圖如圖7 所示，Idle 為master接口處于空閑狀態(tài)，write 為master 接口往內(nèi)存寫(xiě)數(shù)據(jù)，read 為master 接口向內(nèi)存讀取數(shù)據(jù)，waite_write和waite_read 分別為master 接口的讀、寫(xiě)等待狀態(tài)。

圖7 DM_SBA 工作狀態(tài)機(jī)Fig.7 DM_SBA working state machine

2.2 軟件設(shè)計(jì)

GCXP 軟件特權(quán)架構(gòu)有3 種特權(quán)級(jí)：1）硬件模式（Hadware Mode，HM），是最高權(quán)限模式，為特權(quán)程序運(yùn)行環(huán)境；2）內(nèi)核模式（Kernel Mode，KM），是次低級(jí)模式，為操作系統(tǒng)運(yùn)行環(huán)境；3）用戶(hù)模式（User Mode，UM），是最低級(jí)模式，為用戶(hù)程序運(yùn)行環(huán)境。

特權(quán)程序運(yùn)行程序（SW-HMCODE）為代替硬件邏輯的軟件代碼，定義了平臺(tái)SYS_CALL，注冊(cè)了操作系統(tǒng)核心對(duì)應(yīng)的特權(quán)異常、中斷處理入口地址，在擴(kuò)展處理器功能實(shí)驗(yàn)、規(guī)避硬件錯(cuò)誤以及OS 調(diào)試上都有重要的地位，是一種GCXP 獨(dú)有的軟硬件協(xié)同機(jī)制，默認(rèn)為絕對(duì)正確，保證程序不會(huì)掛死在HM 模式下，且對(duì)用戶(hù)透明。

RISCV Debug Spec 中所涉及的CPU 硬件中斷處理、調(diào)試模式及其配套的DPC、DCSR，在GCXP GCXP-1A 軟硬件環(huán)境下都進(jìn)行了重新設(shè)計(jì)，與GCXP-1A HMCODE 相結(jié)合，調(diào)試中斷改為普通中斷，通過(guò)HMCODE 中斷處理流程，實(shí)現(xiàn)現(xiàn)場(chǎng)保護(hù)和復(fù)原，并在HMCODE 中設(shè)置專(zhuān)用SYS_CALL 入口，結(jié)合中斷控制器，與普通中斷跳入操作系統(tǒng)核心注冊(cè)處理程序不同，調(diào)試中斷處理程序（DM_ROM）在HMCODE 內(nèi)部進(jìn)行調(diào)試中斷識(shí)別并完成跳轉(zhuǎn)，從而實(shí)現(xiàn)軟硬件調(diào)試陷入。

在上位機(jī)OpenOCD 中，由于兼容RISCV Debug Spec 0.13.2，因此按照RISCV Debug Spec 0.13.2 的軟件流程，添加th1a-013 target 分支，注冊(cè)寄存器讀寫(xiě)、內(nèi)存地址讀寫(xiě)以及programbuf、abstract commad函數(shù)讀寫(xiě)等，從而完善用戶(hù)調(diào)試流程。

3 驗(yàn)證分析

3.1 GCXP-1A 調(diào)試模塊模擬驗(yàn)證

如圖8 所示，GCXP-1A 調(diào)試模塊模擬驗(yàn)證環(huán)境由3 個(gè)部分組成，分別為：1）SimJTAG.sv 包含Jtag_tick DPI-C 接口，負(fù)責(zé)路由來(lái)自DPI-C 的JTAG引腳信號(hào)，并與GCXP-1A SOC DM JTAG 橋接；2）DPI-C 接口具體實(shí)現(xiàn)本機(jī)socket 注冊(cè)、監(jiān)聽(tīng)和鏈接接受服務(wù)，使用bitbang 協(xié)議將socket 調(diào)試請(qǐng)求轉(zhuǎn)換成JTAG 信號(hào)；3）上位機(jī)調(diào)試軟件通過(guò)DPI-C 暴露的本地端口鏈接，開(kāi)展調(diào)試流程。

圖8 調(diào)試模塊模擬驗(yàn)證環(huán)境邏輯結(jié)構(gòu)Fig.8 Debugging module simulation verification environment logical structure

如圖9 所示，在模擬驗(yàn)證環(huán)境下，激勵(lì)時(shí)鐘起震、復(fù)位撤銷(xiāo)前使用HMCODE+TEST_CODE HEX進(jìn)行約定地址空間布數(shù)。軟件流程具體如下：1）CPU 從HMCODE 開(kāi)始取指運(yùn)行，跳轉(zhuǎn)到TEST_CODE 地址；2）TEST_CODE 配置CSR 寄存器打開(kāi)調(diào)試中斷使能；3）跳出HM 模式，運(yùn)行死循環(huán)；4）HMCODE 根據(jù)CPU 捕獲的中斷（CPU 保證流水線硬件沖刷），將PC 跳轉(zhuǎn)到Debug ROM HALT 地址執(zhí)行；5）上位機(jī)執(zhí)行調(diào)試作業(yè)；6）Debug 退出，執(zhí)行Debug ROM resume 程序段，恢復(fù)現(xiàn)場(chǎng)，跳轉(zhuǎn)PC 到保留PC。

圖9 模擬驗(yàn)證環(huán)境軟件邏輯結(jié)構(gòu)Fig.9 Simulation verification environment software logical structure

基于Synopsys VCS 2018.09-SP2 開(kāi)展GCXP-1A SoC 模擬驗(yàn)證，針對(duì)dm 開(kāi)展OpenOCD test_compliance測(cè)試集驗(yàn)證，針對(duì)所設(shè)計(jì)的功能，波形日志如下：

1）調(diào)試中斷流程。

如圖10 所示，當(dāng)上位機(jī)中斷請(qǐng)求發(fā)起，dm 模塊io_debug_req_o 信號(hào)拉高，由HMCODE 中斷現(xiàn)場(chǎng)保護(hù)，并跳轉(zhuǎn)PC 到0x100 調(diào)試處理程序首地址，執(zhí)行118 地址的寫(xiě)hart id（0）到dm 0x400（Halted_aligned）地址，dm狀態(tài)機(jī)檢測(cè)到該寫(xiě)操作后隨即拉高h(yuǎn)alted_q 信號(hào)，標(biāo)識(shí)CPU 已經(jīng)成功響應(yīng)調(diào)試中斷。

圖10 模擬環(huán)境調(diào)試中斷響應(yīng)波形圖Fig.10 Simulated environment debugging interrupt response waveform

2）CPU 內(nèi)部寄存器讀寫(xiě)。

如圖11所示，state_q為上文描述的三方交互狀態(tài)機(jī)狀態(tài)寄存器，分別標(biāo)識(shí)idle（0）、go（1）、resume（2）、excuting（3），調(diào)試指令下達(dá)后，由idle-＞go 狀態(tài)，并等待debug rom 程序?qū)慻oing 地址，期間硬件完成abstract_cmd 任務(wù)指令轉(zhuǎn)譯和填充，在going 拉高后跳入excuting 階段，執(zhí)行完畢后（指令槽位最后一條固定位回到debug rom 首地址），等待debug rom 再次寫(xiě)halted_align 地址，從而回到Idle 狀態(tài)。

圖11 模擬環(huán)境abstract cmd CPU 內(nèi)部寄存器讀寫(xiě)Fig.11 Simulated environment abstract cmd CPU internal register read and write

3）SBA 總線地址訪問(wèn)。

如圖12 所示，上位機(jī)通過(guò)OpenOCD 對(duì)總線上的地址進(jìn)行讀寫(xiě)訪問(wèn)，dm_sba 模塊從dm_csr 路由信號(hào)操作axi4 master 讀寫(xiě)時(shí)序，從而完成讀寫(xiě)任務(wù)。

圖12 模擬環(huán)境SBA 時(shí)序Fig.12 Simulation environment SBA time limit

3.2 GCXP-1A 調(diào)試模塊FPGA 驗(yàn) 證

FPGA 驗(yàn)證環(huán)境為KCU105，將設(shè)計(jì)中的JTAG引腳約束到FMC XM105 擴(kuò)展卡引腳，鏈接JLink v9，DM 模塊掛在系統(tǒng)總線下。在Vivado 2019.2 環(huán)境下開(kāi)展SoC 綜合仿真實(shí)驗(yàn)，運(yùn)行頻率為100 MHz。

在仿真過(guò)程中，需要HMCODE 邏輯配合，在不依賴(lài)linux kernel 的情況下識(shí)別響應(yīng)調(diào)試中斷。實(shí)驗(yàn)環(huán)境如圖13 所示。

圖13 GCXP SoC DM+JLINKV9+OpenOCD 驗(yàn)證平臺(tái)Fig.13 GCXP SoC DM+JLINKV9+OpenOCD verification platform

在圖14 中，使用OpenOCD 客戶(hù)端鏈接JLNK 開(kāi)展DM 功能測(cè)試實(shí)驗(yàn)，圖14（a）測(cè)試內(nèi)容為通用寄存器或CSR 寄存器讀寫(xiě)功能，圖中示例使用OpenOCD寄存器讀寫(xiě)命令讀寫(xiě)寄存器，圖14（b）測(cè)試內(nèi)容為SoC 總線地址空間存儲(chǔ)器讀寫(xiě)功能，使用OpenOCD SBA 模式測(cè)試字讀寫(xiě)。

圖14 OpenOCD 命令行操作示例Fig.14 OpenOCD command line operation example

覆蓋率是判斷DUT 驗(yàn)證是否完備的重要指標(biāo)，在數(shù)字集成電路設(shè)計(jì)中，覆蓋率分為代碼覆蓋率和功能覆蓋率，代碼覆蓋率表征每行代碼的執(zhí)行情況，功能覆蓋率表征具備一定功能的代碼組合的執(zhí)行情況。從圖15 可以看出，本文DM 模塊的代碼及功能覆蓋率都能達(dá)到100%，能夠滿(mǎn)足流片要求。

圖15 代碼及功能覆蓋率Fig.15 Code and function coverage rate

4 結(jié)束語(yǔ)

本文在RISCV 調(diào)試協(xié)議規(guī)范的基礎(chǔ)上，結(jié)合GC，使用GCXP的HMCODE機(jī)制實(shí)現(xiàn)一套輕量級(jí)且對(duì)CPU無(wú)設(shè)計(jì)需求的調(diào)試方案，該方案可以兼容GCXP 全系列CPU IP 產(chǎn)品以及RISCV 的調(diào)試軟件和轉(zhuǎn)接器，從而豐富自主芯片的調(diào)試生態(tài)。下一步將協(xié)同CPU 設(shè)計(jì)Trace 模式，實(shí)現(xiàn)CPU 非入侵式調(diào)試機(jī)制，完成可控可過(guò)濾的指令流、數(shù)據(jù)流跟蹤，此外，配套上位機(jī)程序開(kāi)發(fā)，實(shí)現(xiàn)性能可分析觀測(cè)、功能完備且安全的用戶(hù)調(diào)試機(jī)制，也是今后的研究方向。