1

前言

在芯片設計中，通常都會增加一些debug(調試)電路邏輯，方便定位軟硬件問題。增加這些debug電路的基本要求對系統原有的正常操作無影響，否則可能會出現heisenbug。因此，debug邏輯電路通常用額外的專用資源去實現，debug面積占用超過總芯片面積5%的芯片也不在少數。

由于debug電路邏輯所花費的面積不大，而且可以通過power gating技術，在不用debug功能時，把debug電路關掉，這樣耗電量小，對功耗的影響不大。故debug在復雜設計中還是廣泛使用的。

2

DAP口

Debug電路包含以下三個主要方面，都是通過Debug Access Port (DAP)來進行的。

• Tracing(追蹤)：tracing是將芯片中的關鍵信息存入到trace buffer(追蹤緩沖)；

• Triggering(觸發)：triggering決定何時開始或結束tracing；

• Single stepping(單步操作)：single stepping允許芯片暫停運行、按時鐘或指令來單步調試；

Trace的信息通常以壓縮形式存放。而且有了trace的內容，我們就可以通過debugger(調試器)控制處理器執行的前進或回退。

在SoC上，芯片版本、寄存器和寄存器域段信息一般會存放在片上ROM，因此也可以通過DAP口去訪問SoC芯片的一些基本信息。

3

Debugger

Debugger可以采用標準的技術去控制芯片包含：

• Pause和Step：控制一個核(Core)的停止、按指令單步執行、重新開始執行等。單步執行通常通過執行一個指令后觸發中斷或暫停，這使得debugger可以控制正在被調試的對象。

• 訪問處理器的寄存器：在Core內，程序員模型可見的任何寄存器都可以被debugger讀寫。

• 遠程控制讀寫：debugger可以觸發load或store操作。一種方式是直接通過系統主總線；另一種是通過受控Core發起的。

• 觀察點(Watchpoints)和斷點(Breakpoints)：在每個Core中可能會存在多個硬件寄存器，debugger可以使用這些寄存器去存儲感興趣的地址。如果load或store地址匹配到存儲在watchpoints寄存器中的地址，那么就產生一個事件。同樣地，當程序計數器(PC)匹配到breakpoints寄存器中的值時，也會產生一個事件。

• Cross-trigger狀態機：每個IP模塊產生的重要event可以作為輸入匯集到中央程序中，形成一個通用的cross-trigger狀態機。額外提供了可以被matrix輸出設置和復位的狀態觸發器，它們的輸出直接反饋到matrix的輸入。因此，可以根據用戶指定的事件序列來編程狀態機。

4

Debug系統舉例

4.1 單核SoC系統

通常情況下，SoC會有一個邏輯DAP口，如下圖1所示為一個微控制器或單核的SoC。TCP通過USB與SoC連接起來。JTAG使用1-bit的數據通路，因此速度會慢一些。連接到Core的DAP也可以自己在主總線上觸發操作。

在這個簡單的單核系統中，breakpoint和watchpoint寄存器會放在CPU核或PMU(Performance management unit)協處理器內部。DAP可以停止或單步調試Core，也可以查看和修改Core中的寄存器。當有來自watchpoint或breakpoint的事件發生時，可以通過PMU寄存器計數或者上報中斷給Core或者暫停Core這幾種可編程選擇的方式去處理，這樣debugger就可以接管了。

圖1 單核SoC的debug硬件。DAP通過JTAG和USB連接到debug工作站

許多非Core類型的IP模塊也會產生事件，對這些事件進行統計也是很有用的，在圖1中粉色所示的IP組件的事件可以被連接到某一個Core和PMU，或者可選實現的EMU(Event-Monitoring Unit)組件上。例如，EMU可以對L2緩存缺失率，DRAM的總線事物事件等進行計數。

4.2 多核SoC系統

在多核SoC系統(MPSoC)中，每個core的debug集成不需要很大的變化。不過會新增其它帶有debug接口的IP組件。下圖2為多核SoC系統的兩個主要新增組件，分別是Event Trace Logging和Cross-Triggering。為了支持trace logging，Core還另外給出一個接口，用于傳遞trace events信息給專用事件總線(綠色的線)。這個接口支持很多層面的信息，包括關掉、只報中斷、分支和追蹤足夠的數據去復現。不同Cores的信息通過Trace Event Funnel和Event Filters進行組合或稀疏。Funnels提供多路選擇和其它一些靈活的功能，比如共享一個timestamp給不同擁有同樣timestamp輸入的數據。Lossless Compressor會執行連續系統時間的運行長度編碼，或者無損算法，就像Lempel–Ziv。總得來說，事件帶寬必須不能超過事件終點，事件終點要么是片上SRAM事件緩沖或專用高性能總線bond-out。Bond-out在這里的意思是一組Pads。片外追蹤緩存經常用于工業或自動駕駛控制器。對于這些，一個更寬并行DAP將其大部分管腳用于數據。或者，一個多gigabit串行器用于快速將數據導出。

圖2 現代MPSoC的典型事件追蹤流資源。運行的數據總線是黑色的。事件流總線是綠色的。Debug訪問總線是藍色的。粉色箭頭代表來自其他IP組件的事件監控線，它們要么沒有自己的計數器，要么需要提供cross-triggering

從CPU Cores處收集數據的話，很容易收集到太多的事件追蹤數據，因為每個Core執行每條指令平均會有10-bits數據。因此，數據可以從系統總線上收集。如果CPU Core擁有常規緩存的命中率，那么圖2中連接到DRAM控制器輸入的總線追蹤監控器就可以產生少于兩個數量級的數據。此外，如果內存可以正常運行的話，那么讀數據可能都不需要記錄，因為讀數據和更早的寫數據是一致的。

Event filter可被編程去記錄地址窗口內對應的事件，這樣可以拓展有效地時間窗口。

由于追蹤內存大小是有限的，片上追蹤緩沖使用了基于地址卷繞的圓形排列，這樣在內存不夠時可以先覆蓋最老的數據。因此，感興趣點的數據可以在停止該點追蹤時被捕獲，而且近期歷史記錄也會保存在緩沖。另外，在操作系統的控制下，也有可能周期性的將存儲在SoC DRAM的追蹤數據放到主存中。

圖2右下角的ROM會存儲Part/ECO信息。另外，每個IP模塊通常將自己的標識號寫死在它內部debug空間的第一個寄存器。

文章來源于 專芯致志er ，作者 滬閔菜菜子

EETOP 芯片課程推薦