2 模擬環境中的嵌入式軟體調試

2.1 固件調試方法概述

目前的EDA環境提供了各種固件調試方法。通常可以使用以下方法之一：

• 使用硬體的SystemC模型進行模擬

這可以在不接觸硬體的情況下儘早開始固件開發，併在假設模型準確的情況下測試代碼的功能。主要局限是缺乏系統視圖和（取決於模型的準確性）缺乏硬體時序準確性（行為模型）。

• 在模擬器CPU上執行固件的硬體模擬。

這是結合實際RTL的最簡單方法，可實現代碼原型。它需要一些SystemC封裝器來訪問寄存器和中斷。它缺乏系統視圖，因此無法驗證固件在其他系統元素存在時的行為。

• 回放（可雙向播放）錄製的系統模擬會話。

• 帶有完整系統模型的硬體模擬。

這是一種同步混合模擬，RTL和軟體在同一模擬過程中運行。可分為使用CPU的快速模型--這允許非常快速地執行代碼（例如，在1分鐘內啟動Linux），但由於TLM到RTL的轉換缺乏周期精度。當開始進行完整的 RTL 模擬（啟用所有時鐘）時，速度也會明顯減慢。

使用全系統RTL模擬通常非常緩慢，只能在合理的時間內測試簡單的操作（低於10kCPU指令）。上圖TLM部分包括CPU快速模型，RTL部分包括介面IP核。

• 完整系統的硬體模擬

同樣可分為由CPU快速模型和模擬RTL組成的混合模式。在介面IP核的情況下，執行速度非常快，但需要對快速模型和模擬設備之間的記憶體進行良好管理，以確保有效模擬數據傳輸（通常是CPU寫入數據，然後發送到介面）。註意：在這種模式下，軟體與RTL非同步執行，兩者在跨域事務和設定的時間間隔內同步。實際上，軟體時序與硬體的周期並不精確，而且根據設置會移除高速緩存事務和高速緩存缺失記憶體事務。

全RTL模式下，所有系統的周期都是精確的。這種模式速度較慢（Linux啟動可能需要10分鐘），但在模擬過程中可以保持穩定的性能。該模式允許測試通用系統用例或複製FPGA 測試過程中發現的問題。

無CPU模擬--PCIeSpeedBridge®適配器可用於將任意介面IP核設備連接到PC，併在PCIe空間開發驅動程式。模擬環境允許訪問IP核的所有內部信號（在運行時捕獲，甚至使用非常複雜的基於條件的觸發器），以調試問題（無論是來自軟體、硬體還是連接在介面另一端的設備）。

• 使用FPGA進行硬體原型開發

處理器的運行速度可達10-100MHz（如果是與FPGA邏輯相連的硅內核，運行速度甚至可達GHz）。這些環境並不能很好地調用新的（未經驗證的）硬體，但它們非常適合以下用途：實時或接近實時的系統測試；性能測試；浸泡測試。

也可以在FPGA中製作簡單的SoC原型。

• 硅測試

這通常被視為系統級晶元（SoC）的調試，所有硬體問題都應在此得到解決，但這並不妨礙在固件中進行一些調整。系統以全速運行，通常無法訪問實際硬體（信號），但應該有一個處理器調試介面，可以逐步檢查代碼。、

2.2 固件可調試性

在許多情況下，管理固件的工程師可能不是代碼的創建者，因此提供儘可能多的有關代碼功能的信息非常重要。最佳做法包括

• 自解釋的寄存器名稱結構或巨集
• 自解釋的變數名（而不是 a、b、c、d）
• 自解釋函數名
• 特別有用的是有關指針用法的信息，因為固件通常使用指針來存儲常式地址，因此必須提供足夠的信息，以便調試工程師能夠理解代碼應該做什麼。

目前市場上出現了一些新系統，其中大部分IP核驅動程式代碼都可以通過高級（行為）語言自動生成。在這種情況下，重要的是能夠重新生成代碼，並將所有更改追溯到源代碼（元代碼），以便傳播所有調試信息。

生成的代碼：

如上所述，使用寄存器抽象可以將代碼從寄存器和歸檔地址中分離出來，即使結構中的任何寄存器發生移動，代碼也不會受到影響。

2.3 介面IP核的測試驅動固件開發

在創建初始固件時，新的IP核通常剛剛被開發出來，這就需要一種持續的閉環工作模式，在這種模式下，新版本的代碼可以根據新版本的RTL進行測試。介面IP固件支持團隊的典型開發流程如下：

• 硬體團隊設計IP核
• 固件工程師參與設計，為寄存器介面設計決策提供信息
• 一旦設計出寄存器模型，並完成具有功能匯流排連接的首個RTL實現，就可以立即將此類IP核集成到早期固件開發中。

在固件開發中，測試驅動開發是一種有趣的方法。這可以被視為硬體升級過程的正規化，在這一過程中，對功能的某些預期始終是明確定義的，而開發/升級的目的則是啟用/支持該功能。
測試驅動開發的步驟是

• 設計一個失敗的測試
• 實現通過的功能
• 完善以便於集成。

2.3.1 開始開發

第一個開發周期通常以硬體為重點。最初的測試一般是對IP核的地址空間進行寄存器讀/寫操作，以確認IP核已與系統正確集成。

一旦這些代碼就位（由於它們總是相同的，因此很容易重覆使用），就可以開始準備測試平臺了。在當前的硬體模擬環境中，可以使用虛擬平臺環境 (VPE Virtual Platform VPE) 類型的環境（如圖所示），其中CPU和所有系統外設都作為SystemC快速模型存在，而正在開發的IP核則通過TLM到RTL封裝器連接。在典型的使用案例中，這種連接需要以下步驟：

• 為新IP準備系統級封裝器
• 將封裝器與現有系統集成
  • 選擇基地址
  • 提供該IP核所需但現有從屬匯流排介面無法提供的任何控制信號
  • 在介面IP核的情況下，將IP的實際"外部世界"介面（圖）連接到合理的交易器至關重要。這些介面可以是
    • 驗證IP核實例
    • 與介面相容的IP核實例。

在理想情況下，這種集成應該是無縫的，因為IP核自帶標準匯流排介面，只需將這些介面連接到系統即可。實際上，測試環境的"事務處理"部分可能是測試環境準備工作中最費力的部分。在早期階段，這可以推遲到首次接觸IP核寄存器之後，但這一階段通常可以很快通過。

一旦所有設備連接完畢並將二進位文件載入到系統中，就需要進行幾個軟體/硬體聯合調試周期，包括

• 檢查從屬匯流排埠訪問
• 檢查中斷生成

最終形成可正常工作的固件調試環境。寄存器讀寫操作的C代碼示例：

裸機讀寫：

在這一階段，固件調試過程通常開始與硬體驗證團隊交叉進行。如果IP核附帶了機器可讀的寄存器描述（如 IP-XACT 或 SysRDL），則可以直接自動生成系統級測試序列，這些序列可以立即在新設計上執行，測試代碼完全由寄存器設計數據驅動。這構成了一套非常基本的系統正常性測試用例，例如

• 檢查寄存器複位值
• 確認寄存器可寫位是否可寫
• 確認寄存器只讀位為只讀

讀寫地址8的寄存器（在APB上）

這些一般由硬體驗證小組負責，但在實際系統中執行這些操作可以解決匯流排訪問問題和任何細小的寄存器庫問題。
在此階段，固件開發人員可以開始在IP核上運行任何功能測試用例。

2.3.2 首次功能測試

在為某個IP核開發底層驅動程式的典型情況下，需要支持一些 "關鍵功能"，以便進行初始系統級集成。這些功能通常包括：

• 初始化IP核
• 使用寄存器介面通過介面發送數據
• 使用寄存器介面通過介面接收數據
• 使用主匯流排介面/觸發DMA

2.3.2.1 初始化IP核

一旦驗證環境就緒，就可以設置簡單的常式來執行IP核初始化，並確認初始化是否正確。確認初始化的測試可以是

• 接收中斷，說明系統已準備就緒
• 輪詢寄存器，說明系統已就緒
• 在極端情況下，可能需要窺探實際的IP核信號，以確定其已初始化。

IP核初始化可能涉及設置與IP連接的元素，以建立工作數據通道，如物理層初始化。在這一階段，系統的所有組件都必須正確連接，在某些情況下，固件在系統環境中執行的初始化程式可能會發現硬體連接問題。使用自動IP核組裝工具可以輕鬆避免這些集成問題。在這種情況下，還需要在"外部介面 "的另一端有一個正常工作的"交易器"，以確保連接已經建立。如果轉換器是支持相同協議的另一個IP核實例，則最好有單元測試環境，在該環境中，每個IP核都可以根據已知模型（如驗證IP核實例）進行隔離測試。

2.3.2.2 發送和接收數據

IP核初始化和數據通道就位後，就可以開始傳輸數據以確認系統的連接性。在介面IP核的情況下，需要有一個能滿足通信協議要求的"交易者"實例，以確保IP核能完成數據傳輸。讓我們以快閃記憶體控制器為例。調試步驟的目的是確認我們可以創建一個工作代碼，通過寄存器介面逐字發送數據，從而在NAND存儲器中寫入一頁數據。要做到這一點，必須具備以下先決條件：

• 控制器已初始化
• 存儲器已初始化
  需要瞭解存儲器控制器使用的協議（對於 NAND 存儲器，它是一串與所需數據交錯的標準化命令（如 ONFI）。
  讓我們考慮一個操作示例：使用寄存器介面寫入記憶體頁，然後讀取以確認一致性。在模擬中調試該代碼可實現以下功能：
• 逐步瀏覽固件代碼
• 查看寄存器介面，確認向快閃記憶體控制器發送了正確的數據
• 查看存儲器介面，確認向快閃記憶體發送和從快閃記憶體接收的數據正確無誤（模型）
• 查看寄存器介面，確認從存儲器讀取的數據正確（模型）
• 訪問存儲器（或調試信息），以確認數據的完整性。

代碼經過模擬調試和驗證後，就可以在FPGA設置上進行測試。一旦在模擬中解決了所有基本問題，FPGA平臺就可以使用真實存儲器部件對運行進行性能分析和剖析。

2.3.2.3測試DMA

模擬環境是測試DMA傳輸和執行這些傳輸的固件原型的絕佳平臺。DMA傳輸會顯示系統問題（如記憶體緩存），因此最好能看到傳輸啟動時的系統記憶體以及主匯流排介面上的數據流，以確認傳輸數據的完整性。下圖顯示了與上一節相同的記憶體寫入和讀取過程，但這次建立了一個請求每次操作的描述符，在初始觸發後，IP核預計將

• 讀取描述符
• 開始讀取存儲器（使用主匯流排介面）
• 開始向設備寫入數據
• 完成讀取存儲器
• 完成數據寫入
• 中斷處理器，通知操作已完成
• 執行與上述類似的步驟，但方向相反。

在確認單個DMA可以正常工作後，可能需要測試鏈式DMA操作，即獲取多個描述符（按順序，可能使用部分硬體緩衝），以確保固件能夠創建和處理這些描述符。比如在APB匯流排上執行初始化序列：

另一種方法是測試多通道DMA，其中介面IP核在多個連接設備上創建並執行多條命令鏈。

2.3.2.4 在FPGA上發送和接收數據

FPGA的調試能力大大降低，可跟蹤的IP核信號數量有限，在模擬中檢查代碼可大大減少調試過程。將FPGA中的嵌入式處理器連接到調試器上，仍然可以逐步檢查代碼，但查看介面信號可能比較困難，可能需要使用示波器或邏輯分析儀。

可以在FPGA上重覆先前定義的步驟（已在模擬中得到驗證），以實現硬體的基本功能。
FPGA 測試的優勢在於速度，例如在NAND快閃記憶體測試中，可以運行比模擬（16 MB多2個數量級的數據（500 MB）。這也有助於發現驅動程式在處理大量數據塊時存在的問題。此外由於測試是在真實存儲器上進行的，因此可以發現所使用的存儲器模型是預設擦除的，而真實存儲器晶元並非如此，因此需要更新存儲器擦除程式。
下圖在QSPI IP核上啟用介面：

帶有圖像處理裝置和攝像頭/顯示器MIPI介面的示例系統

2.3.3 調試系統

一旦系統的所有組件都已調試完畢（至少在正向路徑上），就可以開始調試系統以及同時 使用多個組件的應用程式。此時的假設應該是

• 有一個可調試的中央處理器（允許逐步檢查代碼）
• 所有組件都能執行基本操作
• CPU都能訪問記憶體。

一旦確定了這些步驟，就可以進行系統調試。在大多數情況下，系統調試會從一些基本的裸機測試開始，其中會同時使用多個組件。例如，在調試攝像頭介面（MIPI CSI）IP核時，可能需要將UART用作調試輸出（甚至輸入）。此外，在使用 MIPI介面獲取圖像並將其存入系統存儲器的同時，可能還需要使用另一個簡單介面（如 I2C）對攝像頭進行初始化。在這種情況下，瞭解上圖所示的完整系統架構非常重要，因為多個組件會相互影響，CPU 也會與所有組件相互影響。
上例中的調試步驟如下：

• 為調試信息創建串列埠連接（運行UART）
• 創建與攝像頭的I2C連接並記錄連接結果
• 初始化攝像頭並記錄結果
• 初始化MIPI CSI介面
• 請求MIPI CSI介面開始從攝像機向系統記憶體傳輸數據。
• 使用調試器訪問記憶體，或使用 UART 轉儲記憶體內容。

在此示例中，最好有一個可控環境，在此環境中，攝像機將發送可驗證（如測試模式）的已知數據，以確定是否已將正確的內容寫入系統記憶體。一旦確認系統按照正確的順序執行了所有操作，正確的數據被覆制到記憶體中，還需要確認數據傳輸與系統的其他部分同步良好，即一旦攝像機開始以每秒多幀的速度發送數據，就會有足夠的緩衝，幀數據不會損壞。這是測試中斷的好機會，因為多個設備（UART、I2C、MIPI CSI）都可能觸發中斷，因此設置正確的中斷處理方式非常重要。優先執行中斷的示例如圖所示。

需要適當設置中斷優先順序，以確保在這種情況下不會中斷數據流和用戶交互，因為這隻是為了設置和調試目的。
系統記憶體傳輸（DMA）示意圖：

中斷處理不應影響系統功能，因此可能需要人為創造條件，同時觸發多個中斷。

2.3.4 系統性能

一旦所有組件都能協同工作，就可以考慮系統性能，並對代碼進行優化，以達到所需的基準。讓我們在上述系統的基礎上增加一個屏幕界面和一個圖像處理程式。在這種情況下，圖像

• 從攝像頭獲取圖像並存儲到記憶體中
• 由圖像/信號處理組件從記憶體中讀取、
• 由圖像/信號處理組件存儲回記憶體
• 由顯示組件（如 MIPI DSI）從記憶體中讀取。

在RGB模式下處理VGA測試圖像時，系統需要為每幅圖像讀取2MB和寫入2MB的數據。如果圖像以30幀/秒的速度傳輸，則讀取和寫入速度分別為60MB/秒和60MB/秒。我們必須考慮到，系統可能需要同時為其他目的訪問記憶體（例如，記錄/維護/讀取程式或與圖像處理相關的其他數據）。如果系統運行在FPGA上，則需要確保系統架構能夠提供所需的帶寬。FPGA平臺本身就是證明這一點的理想工具。

一旦系統的性能在FPGA中得到驗證，那麼擴展到ASIC速度就會簡單得多，可能只需要進行少量的軟體優化。這裡需要考慮的問題包括

• 匯流排訪問
• 記憶體訪問
• 記憶體帶寬（匯流排、控制器、模塊）
• 記憶體緩存。

"在我們的一個演示設計中，團隊使用了一塊現有的FPGA板，其中主（也是最大的FPGA晶元與DDR存儲器沒有直接連接。DDR控制器是在單獨的（較小的 FPGA）上合成的，它可以通過晶元間連接與主晶元相連。上述系統（包括攝像頭、圖像處理器和顯示器）就是在這塊電路板上實現的，結果發現記憶體帶寬成為圖像解析度和每秒幀數的限制因素。為了達到最佳性能，採用了Xilinx Chip2 AXI結構的特殊設計。這需要在硬體和軟體層面進行進一步優化。在硬體方面，重要的調整因素包括

• 晶元2的時鐘速度（以及相對於系統匯流排的同步/非同步實現）
• 圖像處理器緩存大小
• 圖像處理器緩存行大小（根據DDR行大小調整）。

在軟體方面，重要的是要限制記憶體訪問，並確保圖像塊（在四條數據路徑中的每一條路徑上）將使用'鏈式'DMA 操作序列發送，以充分利用結構帶寬"。

2.3.5 全功能操作系統案例中的介面IP核性能

另一個有趣的例子是，乙太網MAC實現可用作帶有PCIe端點的NIC（網路介面卡）。兩個內核連接在一起並插入PC。有兩種鏡像設置：

• 模擬（使用 PCIe SpeedBridge® 適配器和乙太網 SpeedBridge® 適配器）
• 帶有標準PCIe和乙太網連接器的FPGA。

其中任何一種實現方式都可以連接到運行Linux操作系統的實驗室PC上，併在Linux中作為PCIe設備為介面IP核實施驅動程式，以進行性能測試和調試（同樣的設置用於合規性測試）。

在一個特殊的案例中，乙太網控制器增加了一項功能，可以卸載軟體TCP/IP協議棧，使其不必將接收到的數據包"聚合"成一個大數據包。Linux 驅動程式中增加了對該功能的支持，網卡平臺的兩種實現方式都用於在系統環境中測試該功能。FPGA實現用於對卸載功能節省CPU的情況進行基準測試，在運行過程中發現了卸載的潛在問題。採用了以下步驟來跟蹤 FPGA 的問題：）

• Linux驅動程式中的附加日誌記錄
• 在Linux中啟用額外的內核日誌記錄
• 使用TCP嗅探器（wireshark）確認數據傳輸。

然而，所有這些方法都無法找到問題的原因，因此需要在模擬環境中複製該問題，以便全面瞭解問題。此外，事實證明，有些問題在不同的PC上是不一致的。在可以完全訪問所有硬體設計信號的模擬環境中複製問題後，結果發現

• PCIe 根埠（主機）可能會對數據包重新排序
• 某些PCIe匯流排參數會影響該問題的發生
  除此之外，通過進一步完善測試，還發現了一個與PCIe匯流排無關的實際硬體問題。
  在執行此類實驗室測試時，對測試環境進行嚴格控制是非常重要的，這樣才能確保隨機事件或設置變化不會導致系統以不同的方式運行。最佳做法是建立一個乾凈的沙盒，通過完全腳本化的路徑進行測試，並對外部事件進行完全控制（例如，避免連接到實時本地網路）。

2.3.6 最新嵌入式系統中的低級固件調試

硬體設計人員在實驗室調試用於合規性測試的新SoC系統時，創建了一個由64位CPU內核和當代中斷控制器組成的系統，兩者都用於測試嵌入式xHCI 控制器的消息信號中斷（MSI）能力，xHCI控制器作為IP和USB SuperSpeed設備VIP實例。MSI 功能是基於PCIe設備的典型功能，支持良好，但隨著新型中斷控制器的推出，嵌入式系統也可以接收這些中斷。

在嵌入式MSI中斷中，記憶體位置被中斷控制器劫持，為CPU生成中斷信號。這就需要設置正確的匯流排配置（包括受保護的訪問線路），以便與中斷控制器協同工作，並允許匯流排上的設備訪問給定的記憶體位置以產生中斷。支持這一功能的設備示例是xHCI介面內核。Linux驅動程式支持MSI模式，通過在模擬環境中運行完整系統，可以確認IP會產生MSI中斷。在對地址進行適當配置後，將xHCI內核切換到MSI模式，並配置GIC以接收這些信息。

2.4 作為硬體驗證工具的固件啟動

由於目前可以在全系統環境的模擬/模擬中快速調用IP核，因此可以使用現成的系統測試對新開發的IP核進行早期驗證。
最近，我們在實驗室環境中對兩個不同的內核進行了驗證。

2.4.1 NAND快閃記憶體

我們為一個新的NAND快閃記憶體控制器內核創建了MTD（記憶體技術設備 Memory Technology Device）驅動程式，以便在 Linux中使用MTD測試框架，對仍在開發中的IP和執行多個（現有）系統測試。
社區中可用的MTD測試列表：

• mtd_speedtest：測量並報告MTD設備的讀/寫/擦除速度。
• mtd_stresstest：執行隨機讀/寫/擦除操作，驗證MTD設備的 I/O 能力。
• mtd_readtest：該測試讀取整個MTD設備，每次讀取一個NAND頁，包括OOB（或在NOR等快閃記憶體情況下每次讀取512位元組），並檢查讀取是否正常。
• mtd_pagetest：僅適用於NAND快閃記憶體，測試不同大小和順序的NAND頁寫入和讀取；該測試最初是為測試 OneNAND 驅動程式而開發的，因此可能有點面向 OneNAND，但必須適用於任何NAND快閃記憶體。
• mtd_oobtest：僅適用於NAND快閃記憶體，通過向不同偏移量寫入數據並驗證，測試OOB區域I/O是否正常工作。
• mtd_subpagetest：僅適用於NAND快閃記憶體，測試I/O。
• mtd_torturetest：該測試旨在耗盡快閃記憶體擦除鎖。它會重覆寫入和擦除同一組擦除鎖，直到發生I/O錯誤，因此要小心！該測試支持許多選項（請參閱 modinfo mtd_torturetest），允許你設置要折磨的擦除塊數量以及折磨的方式。你可以使用 cycles_count 模塊參數來限制折磨周期的數量。如果有備用設備，最好能運行該測試一段時間，並對快閃記憶體驅動程式和硬體進行驗證。例如，我們在一塊使用OneNAND快閃記憶體的OMAP2板上發現了一個相當罕見且令人討厭的 DMA 問題，但只需運行該測試幾個小時即可解決。
• mtd_nandecctest：這是一個簡單的測試，用於檢查256和512位元組緩衝區內置軟體 ECC 的正確性；該測試並非針對特定驅動程式，而是測試一般的NAND支持代碼。

這有助於發現Linux驅動程式中的許多問題，因為它是一套現成的"測試過的測試"，因此是一個完美的驅動程式開發環境，具有明確的驗收標準（通過所有測試）。

MTD 框架允許在現有堆棧上運行文件系統（如 JFFS2），從而進一步提高系統和壓力測試能力。

2.4.2 xHCI

對於具有標準寄存器介面的IP核，只要能將IP核集成到模擬/模擬環境中，Linux本身就可用作系統測試的第一階段。此外，USB-test Linux框架還可用於執行多個系統測試，以確認IP核的系統級穩定性（該IP核同時經歷了設計更新和標準硬體驗證過程）。

其中：

• iterations-迭代次數
• length-數據包大小
• sglen-收集/彙集數據包條目
• vary-數據包大小的變化。
• i-當前迭代次數

通過這些測試，我們發現了驅動程式的一些問題，特別是

• 停滯支持
• 設備配置

測試套件還被用作IP核的壓力測試，使用了多種系統配置（32/64 位、傳統/MSI 中斷），以確保驅動程式的系統質量。

參考資料

• 軟體測試精品書籍文檔下載持續更新 https://github.com/china-testing/python-testing-examples 請點贊，謝謝！
• 本文涉及的python測試開發庫 謝謝點贊！ https://github.com/china-testing/python_cn_resouce
• python精品書籍下載 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
• Linux精品書籍下載 https://www.cnblogs.com/testing-/p/17438558.html

2.5 使用 Cadence® Indago™ 嵌入式軟體調試器進行回放調試

隨著時間的推移，數字系統變得越來越複雜。在保留向後相容性的同時，對新功能的要求使得每一次新系統的發佈都比上一次複雜。要對這樣的項目進行全面驗證，就需要一種能對固件和硬體進行共同驗證的工具。硬體測試（無論是UVM還是功能/定向測試）可能還不夠，為了創建更真實的用例，需要固件驅動的測試用例。這樣就可以在單個測試用例中建立完整的用例，例如，向SoundWire設備添加新的聲音通道需要重新配置IP核並同時運行所有傳輸。因此，將帶有微控制器的系統作為驗證平臺的一部分非常重要。

另一方面，市場競爭日趨激烈，迫使人們更多地考慮設計新版本設備的成本。其中，上市時間的考慮尤為重要。關鍵是要確保工作不被難以分析的意外錯誤所耽擱。這些問題的出現可能會導致項目延期和 "緊要關頭"的出現，對團隊造成重大影響，並可能引發更多問題。在很多情況下，錯誤發生後是可以觀察到的，而且很容易在隨後的執行時間設置斷點以查看其影響，但可能很難跟蹤根本原因（如意外輸入值或代碼中的錯誤）。在這種情況下，能夠觀察系統的過去（硬體和軟體，包括記憶體內容）以追蹤實際根源的發生是非常重要的。

Indago™ 嵌入式軟體調試器是一種可以調試整個系統（硬體和軟體）的解決方案。它是一個完整的解決方案，只需使用一個工具即可訪問項目的所有組件。它可以輕鬆分析硬體和軟體之間的合作。通過 Indago™ 嵌入式軟體調試器，可以跟蹤所有信號、CPU 狀態和記憶體內容，隨時觀察整個系統的狀態。

2.5.1 示例

為SoundWire主設備和從設備創建的驗證系統示例如圖。該系統基於 SoC，SystemC 和 RTL 均在 Incisive® Enterprise 模擬器中執行。

該系統由以下組件組成：

• SystemC：
  • CPU 快速模型
  • 虛擬結構模型
  • 記憶體模型
  • UART 模型
• RTL (Verilog)：
  • 聲導線主站
  • 聲導線從站
• VIP：
  • 聲導線從站

要使用 Indago™ 嵌入式軟體調試器進行回放調試，需要ELF文件和有關軟體執行流程的信息。可以是跟蹤文本文件，允許使用 Indago™ 嵌入式軟體調試器的所有功能、
波形上的PC計數器跟蹤，僅提供基本調試功能。
還可將包含硬體信號信息的相容波形資料庫載入到應用程式中，從而實現硬體/軟體協同調試。
下圖顯示了 Indago™ 嵌入式軟體調試器的主界面，它包含兩個主要部分：代碼調試器和可顯示軟硬體信息的波形視窗。

下圖展示了一個中斷處理程式調用的函數示例。調用堆棧和波形可用於快速確定調用原因。

下圖顯示了對硬體的寫操作。CPU將數據寫入FIFO，在硬體級顯示為AHB寫事務。

離線調試功能允許在代碼執行過程中向前或向後移動，並可設置無限斷點。當代碼在中斷處理程式中失敗時，這一點尤其有用。Indago™ 嵌入式軟體調試器允許跳回最後一次執行，查看出錯的地方，而無需步進成功的運行。

離線調試允許使用非侵入式調試方法。使用列印來調試代碼很常見，但它會影響代碼的執行時間，因此在代碼中添加一些列印後，有問題的代碼可能會開始工作。Indago™嵌入式軟體調試器支持SmartPrints。在執行的任何一行代碼中，都可以添加包含自定義信息和可用變數的列印信息。由於它使用的是軟體執行的離線資料庫，因此不會增加任何延遲，尤其是在中斷期間，延遲可能會影響執行。這也使調試變得更加容易。

2.5.2 覆蓋範圍測量

Indago™ 嵌入式軟體調試器與 Incisive® Enterprise Simulator Metrics Center 一起使用，可以測量代碼覆蓋率。
下圖顯示了應用程式的主視窗。通過該視窗可快速瞭解代碼測試質量，並有助於識別和修複代碼驗證中的問題。如圖 2.18 所示，還可以查看代碼源代碼，並顯示執行了哪一行。多個測試運行的結果可以合併在一起。

上圖為模擬器指標中心顯示代碼覆蓋率結果示例

上圖為函數源代碼覆蓋視圖

2.5.3 缺點

其局限性在於無法對修改進行現場測試。因此，必須使用多種調試工具，以便能夠重新評估新代碼，因為記錄新系統運行可能會耗費大量時間。

2.6 小結

本章介紹了多個採用不同調試方法的嵌入式系統實例。EDA工具的最新發展以及電腦速度和容量的不斷提高，使我們能夠模擬或模擬非常複雜的片上系統平臺，並立即訪問軟體調試符號、代碼步進和硬體信號跟蹤，從而確保在系統環境中輕鬆調用新設備（正在設計中），並根據行業標準驗證IP核或與實際設備的連接進行測試。這反過來又縮短了新器件的上市時間，因為軟體開發人員可以在IP和合理穩定或TLM模型可用後立即開始開發驅動程式和系統軟體。
利用新的回放系統調試方法，還可以在不影響運行時的情況下跟蹤系統中的問題。
嵌入式軟體調試中最重要的要素是：

• 設置最接近目標系統的平臺。
• 在開發過程中儘早開始使用設備或其模型的能力。
• 硬體和軟體工程師的合作（尤其是在早期啟動階段）。
• 適當選擇工具。