雖然硬件/軟件接口的設計問題已經討論了 10 年的大部分時間，但當今應用程序驅動設計中軟件內容的增加已經給這些問題帶來了新的緊迫性——特別是軟件對硬件和高效分區的依賴。過去，軟件開發人員使用連接到原型板的嵌入式軟件調試器以獨立于硬件的“外圍盲區”方式執行調試任務。這提供了對處理器的深入了解，但幾乎沒有關于周圍外圍設備和片上互連結構的信息。相比之下，硬件開發人員專注于寄存器和片上系統 （SoC） 互連中的低級效應，這些效應每年都變得越來越復雜。

在考慮調試挑戰時，必須評估片上和系統內效應。在開發階段需要進行片上調試，以確保芯片本身正常工作。系統內效應與芯片在其環境中的行為方式有關。如果要在芯片開發期間考慮影響，則調試系統內影響需要對環境進行復雜建模，或者在芯片可用后控制實際環境。

圖 1 顯示了一個典型的基于 ARM 內核的 SoC，其處理器子系統包含各種處理器，這些處理器通過連貫的結構連接到芯片的其余部分。SoC 還包含用于 3D 圖形、數字信號處理、專用專用硬件加速器、低速外設和高速接口的定制應用特定組件。調試挑戰包括同步調試多個內核、確保 IP 塊集成正常工作、調試 AMBA 4 AXI 一致性擴展 （ACE） 協議等協議，以及調試整個芯片互連。

圖 1：典型的基于 ARM 內核的 SoC 存在調試挑戰，例如同步調試多個內核。

相比之下，圖 2 在其系統環境中顯示了相同的 SoC。SoC 和實際系統外圍設備之間的連接建立在 PCB 上，并且通常基于 DigRF、MIPI 和 USB 等標準。現在，調試挑戰從片上區域轉移到芯片在其環境中的行為方式。例如，圖形引擎生成的幀是否被外部顯示器正確顯示？各種片外和系統內效應需要與片上效應一起考慮，因為它們通常會驅動圖形內容和控制。

圖 2：系統環境中的 SoC 對芯片在其環境中的行為方式提出了調試挑戰。

硬件/軟件集成和調試方法

在開發流程中，設計團隊使用多種技術來實現軟件調試和硬件/軟件集成。

一旦所有芯片都可用并集成后，硬件團隊通常會構建有限數量的原型板，以便軟件開發人員可以開始在設備上構建他們的代碼。在產品發布并激增后，這些原型板通常被稱為開發套件。它們以實時速度運行并且完全準確。調試器通過 JTAG（邊界掃描）接口連接到這些板。這種類型的軟件調試非常普遍且易于理解，但也有其挑戰，因為對硬件深度的訪問受限于實現的片上儀器的級別。

將集成到板上的基于 FPGA 的芯片原型可以在硅片之前幾個月提供。這些原型在數十 MHz 范圍內運行，硬件精確，并且通常只有在穩定的寄存器傳輸語言 （RTL） 代碼可用后才能使用。它們允許有限的調試功能。與軟件調試器的連接通常通過 JTAG 建立，但設計人員可以使用調試信息增強 RTL，以啟用硬件/軟件調試和分析。根據原型，可以將芯片連接到環境；經常需要使用速度適配器，或者需要降低環境速度以匹配原型速度。

硬件仿真器甚至可以在設計流程的早期使用，它們在 MHz 速度范圍內執行正在開發的芯片或其子集。它們提供快速啟動（與基于 FPGA 的原型設計相比，后者需要對實現硬件的代碼進行更多修改）和更好的硬件/軟件調試，因為硬件仿真器的很大一部分專用于調試和控制設計。然而，當今仿真器的大小和價格限制了它們被大量軟件開發人員復制的能力。

RTL 仿真是第一個可以滿足精確硬件和軟件的執行環境。它提供了出色的硬件調試能力，但由于它運行在 KHz 范圍內，它在軟件開發和軟硬件集成方面的適用性非常有限。RTL 專注于硬件驗證，傳統上僅用于非常低級的裸機軟件開發。鑒于現代片上和片外接口的復雜性，商業驗證 IP（提供預定義的測試模式以檢查接口正確性）可以在片上和系統內使用。

使用不太準確的抽象硬件模型，正在開發的虛擬芯片平臺可以高速運行，有時在硅片之前 9-12 個月就可以使用。它們使用 GNU 調試器 （GDB） 和周期精確調試接口 （CADI） 等標準接口提供出色的軟件調試功能，以將軟件調試器連接到虛擬化硬件。以后可以在板級使用相同的軟件調試器。根據建模工作，整個芯片及其環境可用于片上和系統內的高級硬件/軟件調試。

最后，軟件開發工具包 （SDK） 通常是最早可用的開發平臺。像 Apple iPhone SDK 或 Android SDK 這樣的 SDK 使許多軟件開發人員能夠為非常抽象的硬件編寫代碼，因此無法調試。在 SDK 上開發的代碼通常需要重新編譯才能在實際設備上運行，這與前面提到的虛擬原型和其他引擎不同，后者加載 .elf 文件并運行相同的二進制代碼，然后在硬件目標上執行。

跨執行引擎進行調試

電子制造商越來越多地跨多個內核分發軟件，以保持在復雜設計的功率范圍內。因此，多核調試已成為更大的挑戰。多核設計的完全同步的異構軟件調試非常適合在所有軟件組件和硬件本身中設置斷點，然后允許檢查狀態、堆棧、軟件中的變量和硬件中的寄存器。

使用原型板，即使不是不可能，也很困難。如果斷點觸發了一個處理器的軟件并導致其停止，則所有其他處理器繼續執行，從而改變斷點發生的環境狀態。相比之下，使用虛擬原型，所有參與元素（即所有處理器和硬件模塊）都可以在斷點發生時準確停止，從而實現高效的硬件/軟件調試。

此外，當開發人員在實際硬件或老一代虛擬原型上工作時，他們會看到各種不同步的調試器窗口。現代虛擬原型允許用戶通過抽象層有效地集成來自不同供應商的處理器模型，從而在單一、統一的環境中實現完全同步的調試和分析。

另一個在實際開發板上難以分析的影響是根據硬件所處的狀態而必須停止軟件。在仿真器、RTL 模擬器和虛擬原型的世界中，硬件調試是先進的，兩者硬件和軟件可以根據表示硬件內狀態或狀態轉換的斷點有效地停止 - 例如達到特定的計數器值或通過總線發送的特定事務。

每當涉及基于軟件的硬件執行時，軟件調試也可以與不同硬件抽象級別的混合有效地同步。這在衍生項目開始時很有價值，因為新的硬件組件在事務級別作為高度抽象的模型可用，而不是在 RTL 上實現的硬件。

全面了解硬件/軟件

現代軟件的復雜性及其對執行它的硬件的依賴性使得延遲調試和硬件/軟件集成，直到所有芯片都可用并集成到 PCB 上是不可行的。芯片和系統開發團隊可以使用多個執行引擎，但這些引擎的開發和調試軟件能力差異很大。圖 3 顯示了之前介紹的芯片和電路板與引擎相結合以執行正在開發的芯片以及與硬件/軟件調試的連接。

圖 3：結合 SoC 和電路板的硬件/軟件執行引擎在芯片開發過程中執行芯片。

Debug 有幾個層次，通常構建在 Eclipse 等集成開發環境 （IDE） 上。用戶需要調試實際硬件、操作系統之外的裸機軟件執行、硬件和軟件的結合以及整個系統的性能。

隨著不同引擎和新一代軟件調試器的混合組合，該行業正在接近一個時代，在這個時代，軟件開發人員可以比以往任何時候都更早地在設計周期中獲得軟件和硬件的完整程序員視圖。

作者：Frank Schirrmeister，Michael （Mac） McNamara，Larry Melling，Neeti Bhatnagar

審核編輯：郭婷