介紹

日常生活中，我們不會注意到最常用設備核心的復雜芯片 — 它們通常隱藏在設備內部。另一方面，芯片的功能卻非常引人注目：它們能讓我們使用手機拍攝高質量的照片，駕駛時提醒我們注意行人，以及檢測和識別我們向虛擬助手發出的命令。在本系列文章中，我將重點討論驗證芯片功能所面臨的挑戰。

正如廣告宣傳的那樣，在設備光鮮亮麗的外表下，隱藏著一支杰出的人才隊伍 — 研究人員、硬件架構師、硬件設計師、軟件開發人員、集成商和質量保證工程師 — 他們確保了每一塊芯片在任何可能的情況下都能平穩運行。這些人員即使處于不同時區空域，也必須努力協作。他們的任務就是確保拼圖的各個部分完美地組合在一起，并通過大量的軟件代碼行和硬件邏輯塊來確保所需要的功能順利實現，以滿足消費者的預期要求。實現這些芯片功能的最大挑戰之一在于軟件和硬件之間的邊界。

硬件調試

我假定垂閱這篇文章的您已對嵌入式設計領域有所了解，但我仍需快速扼要地復述一些主要的挑戰，特別是當開放嵌入式 DSP軟件時的挑戰。

首先，為什么您想使用 DSP？CEVA DSP 專門用于多個應用領域，如人工智能、計算機視覺、語音識別和移動通信。相比通用 CPU，使用 DSP 可以實現更高的性能和更低的功耗，同時仍能保持軟件編程的靈活性。CEVA DSP 可在必要時運行實時操作系統，以保證 DSP 應用程序通常所需要的實時性能。應用程序既可以在多核系統上同時運行多個線程，又可以在單核系統上分時運行。然后，線程可以異步處理多個并行進程，從而控制系統的不同硬件元素以及處理數據。

舉個 DSP 操作的例子，它可以通過增強顏色或對比度、采用高動態范圍 (HDR)算法將多個圖像融合為一個圖像、自動檢測場景內容、或穩定快速行駛期間手持電話拍攝的抖動視頻來處理相機的圖像。或者，它還可以對來自兩個傳感器的兩個每秒 120 幀/12 位采樣率/超高清 8K分辨率視頻流來執行上面所有這些功能，。在這種復雜運算時，數據傳輸率可超過每秒 33GB，因此，確保該過程每一步都能按預期運行具有非常大的復雜性和挑戰性。

DSP 架構可能相當復雜，相應的匯編操作可能跨越多條線路。為了滿足預期吞吐量，需要通過專用編譯器或由程序員手動對代碼進行性能優化。這包括展開循環、重新排序指令并將其組合在一起以便在單個循環內并行執行等等。調試此類代碼可能非常困難，且需要非常先進的調試工具。

通常，新功能的開發都從高級開發語言環境開始，例如Matlab、Visual Studio 或在PC 上運行的GNU 開發/調試工具。這些環境在軟件開發人員中很受歡迎，文檔完善，擁有很多針對各種算法的現成方法，并且通常以開源方式分發。這樣可以快速提升軟件、重用代碼、利用高級編程環境并采用快速服務器基礎設施。工程師可以很便捷地進行通信，共享代碼并在多個開發人員甚至團隊之間分工協作。這些開發環境可提供一種簡單而舒適的調試體驗：程序員可在運行時在應用程序內部進行步進操作，以檢查內存和變量值、設置斷點、手動操縱資源并檢查結果，有時，甚至可以在不停止調試應用程序的情況下重新編譯代碼，從而相對容易地跟蹤漏洞和實施過程中發生的故障。

但最終，該軟件需要能夠運行起來，并且在嵌入式目標上有效運行。那時，開發人員必須有能夠在實際芯片上進行調試和優化軟件的工具。這就需要主流的開發和調試工具有更高的能力的。

硬件調試領域的各項挑戰

由于目標芯片或設備在我們的桌面工作環境中屬于“外來”元素，因此在目標硬件上調試軟件會面臨一系列不同的挑戰。桌面工作環境及其操作系統對自身的計算引擎（在一定程度上）有所了解，但通常沒有訪問外部硬件內部狀態的通用方法。這就是為什么最終您必須采用硬件供應商提供的嵌入式開發環境的原因。這些嵌入式開發工具可以與目標設備進行通信，并觀測或操縱內部狀態。當您在不同的調試環境中進行這種詳細調試和優化時，會希望這些工具能提供易于使用的調試體驗，并且能夠完全支持您在這個階段的所有需求。

對于目標硬件的調試可能具有挑戰性，因為很多情況在您的早期開發中都無法預見。您只要與 DUT（被測設備）建立調試連接，就可能會遇到一些匪夷所思的通信問題。更為普遍的是，硬件調試問題可能發生在各個階段：在初始連接、設備重置、應用程序加載、分步調試程序或查看內存和變量值時；這些問題的原因可能并不明顯。基于主機或通用的開發和調試工具對目標平臺并不了解，因此，在分析此類問題方面幾乎沒有幫助。您只能寄希望于一個充分了解你所構建系統的開發/調試平臺。