隨著系統級芯片（SoC）的復雜度不斷提高，軟、硬件開發融合所帶來的挑戰已經不可小覷。這些功能強大的系統現在由復雜的軟件、固件、嵌入式處理器、GPU、存儲控制器和其它高速外設混合而成。更高的功能集成度與更快的內部時鐘速度以及復雜的高速I/O相結合，意味著提供正常運行、并經過全面驗證的系統比以前變得更難。

　　傳統上，軟件驗證和調試及硬件驗證和調試一直是兩個不同的世界。通常情況下，軟件團隊和硬件團隊各自為政，前者專注于編程模型內部的軟件執行，后者則在硬件開發框架內進行調試，其中時鐘周期精度、并行運行及調試數據回溯原始設計的關系是關鍵。理論上，經過全面調試后，軟件和硬件應無差錯地協同運行。但在實際環境中，無差錯協同運行的情況不多，正因如此，經常會導致關鍵成本上升及產品開發周期延誤。

　　為在合理的成本和時間范圍內實現更高的集成度，業界必須轉向新的方法：設計的洞察。換句話說，如果我們想能夠高效地持續驗證和調試這些系統，工程師們必須提前設計成能夠提供全面的系統視圖。其中的關鍵是能夠了解涵蓋硬件領域和軟件領域的各種行為之間的臨時關系。本文介紹了使用嵌入式儀器調試SoC的一種方法，說明了通過整合硬件調試視圖和軟件調試視圖，可以更快、更高效地調試整個系統。

　　構建測試臺

　　圖1所示的SoC 由一塊32位RISC指令集處理器及一條AMBA APB外設總線組成，處理器連接到AMBA AHB系統總線上。SoC還包含一個DDR2存儲控制器、一個千兆位以太網網絡適配器、一個Compact Flash控制器、VGA控制器及多個低速外設接口。SoC運行Debian GNU Linux操作系統第4版，這一操作系統運行v2.6.21內核。處理器核心工作頻率為60MHz，DDR存儲控制器工作頻率為100MHz，其它I/O 外設在33MHz~12MHz之間的基本頻率上運行。整個SoC在Virtex-5開發板卡上實現。

　　圖1. SoC基線測試臺

　　總體上看，這一系統是一臺全功能計算機，能夠提供基于終端的用戶接入，能夠連接互聯網，運行應用程序，安裝文件系統等等。SoC的這些特點產生了復雜的調試場景，給硬件調試設施和軟件調試設施的功能帶來了壓力。在大多數情況下，關鍵操作都同時涵蓋硬件和軟件。

　　調試基礎設施

　　處理器核心開發人員一般會提供調試基礎設施，要么是某個核心的一套固定特性，要么是一群核心的可配置插件。不管是哪種形式，調試基礎設施都變成了被制造的核心的一部分。然后調試軟件使用這個基礎設施，為軟件開發人員提供調試特性。

　　與大多數現代處理器類似，如英特爾處理器、AMD處理器、IBM處理器、Oracle處理器和ARM處理器，這里突出顯示的處理器核心支持一套基本調試功能。在本例中，可以通過JTAG訪問的“后門”，允許軟件調試程序（如GDB）讀取和寫入系統中的存儲器，檢測處理器的運行狀態。通過這些機制及訪問原始軟件源代碼，GDB和其它軟件調試程序可以提供軟件斷點、單步操作、變量值檢查、堆棧跟蹤、初始條件配置、交替存儲器值及恢復功能。

　　在大多數情況下，硬件調試設施并不是與構成SoC的硬件IP核心一起提供的。相反，硬件調試設施通常疊加到現有的SoC設計上。造成這種差異的原因有很多。首先，與軟件調試不同，硬件要求的底層功能具有多樣化特點，通常只有在SoC組裝時才能得到全面了解。此外，每種新的SoC通常要求不同的調試基礎設施。最后，作為新興領域，硬件調試的標準化程度不高，生態系統建設不夠。因此，硬件調試設施通常被留給各個設計人員，這些設計人員會創建針對不同功能領域的特定調試特性。在大型機構中，通常會開發擁有內部支持的工具和結構。但是，隨著SoC的復雜程度不斷提高，創建高效硬件調試設施的復雜程度也在不斷提高，內部開發工作難以為繼。

　　作為替代方案，測試和測量廠商可以提供完整的設計工具、IP庫和工作流程，創建硬件調試設施。圖2所示的設置稱為Tektronix Clarus Post-Silicon Validation Suite，這一驗證套件由多種可以重復配置的嵌入式儀器組成，這些儀器可以連接起來，分布在整個SoC中，創建滿足特定功能要求的調試基礎設施。 Implementer工具可以在RTL級（Vreilog、System Verilog和VHDL）把硬件設計中任何層級的任何信號儀器化。Analyzer通過JTAG或以太網連接，配置和控制嵌入式儀器。最后，Investigator把嵌入式儀器收集的數據向回映射到原始RTL（在仿真環境中），實現更復雜的調試。

　　圖2： Clarus Post-Silicon Vlidtion Suite套件的結構。

　　嵌入式儀器被應用到SOC中，提供調試基礎設施，如圖3所示。其中一個重要方面是能夠在調試過程中重新配置儀器，針對SoC不同領域中的各種信號和場景?；緝x器稱為捕獲站，其獨立管理觀測數據的選擇、壓縮、處理和存儲。多臺捕獲站通常一起使用，為某個SoC創建特定設計基礎設施。在插入過程中，捕獲站配置一系列關心的潛在信號、最高同時觀測數量以及最大RAM容量。捕獲站一般被分配給特定時鐘域，同時捕獲觀測數據。Analyzer從每個捕獲站中收集數據，顛倒壓縮算法，把每個站中捕獲的數據對準，在所有捕獲站中生成時間相關的視圖。

　　圖3： 硬件調試基礎設施。

　　本例中使用的SoC有四個捕獲站：一個位于處理器時鐘域，標為1號捕獲站（60MHz），針對362個信號；一個位于RX以太網域，標為2號捕獲站 （25MHz），針對17個信號；一個位于TX以太網域，標為3號捕獲站（25MHz），針對17個信號；最后一個位于閃存時鐘域，標為4號捕獲站 （33MHz），針對178個信號。每個捕獲站都并行運行，能夠選擇性地觀測任意信號組合。Analyzer工具的最終輸出是一個表示實際硅片器件中時鐘周期準確信號事務的波形，如圖4所示。

　　圖4： SoC波形實例。

　　盡管軟件調試設施和硬件調試設施在目標平臺上觀測只限于軟件問題或硬件問題時效果很好，但在了解涉及軟件和硬件交互的行為時，則面臨著明顯挑戰。表1列出了我們的測試臺開發過程中遇到的部分問題，以及我們在業界看到的代表性問題。

　　主要挑戰在于，盡管使用軟件調試設施或硬件調試設施能夠“看到”非預期行為的影響，但通常很難確定觀測到的不正確行為到底是因還是果。這個問題經常變成軟件中非預計的行為是硬件行為不正確的結果，還是其它方式。關鍵在于確定多個事件之間的臨時關系，這要求軟件調試視圖和硬件調試視圖之間有一個公共參照物。

　　事件管理

　　重建軟件調試視圖和硬件調試視圖之間臨時關系的能力，涉及兩種調試設施中調試狀態和事件處理的整合，或綜合硬件管理，如圖5所示。

　　圖5： 綜合事件管理。

　　在本例中，Clarus Suite提供的分布式異步儀器使得每個捕獲站可以視作自治設備。為支持儀器之間的“交叉觸發”，有一條共享事件總線及一個集中式事件處理器。集中式事件處理器在圖5中標為接入控制（Access Control），把調試事件和狀態傳送給Analyzer軟件，Analyzer軟件管理著整個調試基礎設施。這可以對多個功能單元和時鐘域同時進行高效硬件調試。為創建綜合事件管理，這些信息傳播到軟件調試設施中，并從軟件基礎設施中收集數據。通過采用綜合事件管理，基礎設施可以檢測軟件斷點事件，調試處理器的狀態。同樣，軟件調試設施能夠檢測硬件觸發，調試硬件調試設施的狀態。

　　綜合事件管理的兩大優勢是軟件調試發起的事件能夠控制硬件觸發，硬件調試發起的事件能夠控制軟件調試。更具體地說，軟件斷點可以映射到特定硬件行為，硬件觸發可以在某個點中斷軟件。圖6和圖7分別說明了這兩種場景的實例。

　　圖6：由軟件發起的事件。

　　圖7：由硬件發起的事件。

　　為演示綜合調試系統中軟件發起的斷點功能，我們修改了Linux內核，在磁盤扇區0x00041d90上發生讀取時打印消息“BLOCK”。然后，把目標對準調試設施中來自“sysace”Compact Flash控制器的軌跡。我們使用GDB，在xsysace.c文件第714行上設置了一個硬件斷點（printk發生的行）。然后配置測試設施，使用綜合事件管理監測軟件調試設施。最后，“find/”命令強制內核讀取整個磁盤。如圖6所示，軟件斷點在希望的行上暫停了內核執行，另外還觸發了硬件調試設施。結果，可以在軟件斷點時間上看到詳細的硬件行為。

　　我們使用硬件適配器，演示綜合調試系統中硬件發起的觸發功能。我們設置成在Linux內核清除以太網適配器中的“RX Packet Ready Interrupt Bit”時發生硬件觸發。我們把綜合事件管理界面配置成把硬件事件映射到軟件調試設施。到系統中路由器IP地址的ping從SoC到路由器應答位置發起一個發送包。在應答發生時，這個包到達以太網物理層，由以太網適配器處理。然后處理器被中斷，Linux內核服務中斷。在中斷服務結束時，中斷被清除。這導致硬件觸發和軟件被暫停，如圖7所示。得到的視圖顯示了從物理層直到操作系統的整個復雜系統中硬件和軟件的同步行為或時間相關行為。

　　小結：通過在軟件調試設施和硬件調試設施之間創建綜合事件管理界面，可以圍繞軟件調試事件和硬件調試事件實現單事件同步。這種同步可以有意義地表示同時來自這兩種基礎設施的調試數據。這樣一個完整的系統視圖為觀察涵蓋軟件和硬件的各種SoC功能之間的臨時關系打開了一扇窗戶，可以更快、更高效地調試日益復雜的 SoC設計。