在建立嵌入式系統的後期階段,當每件事都似乎出了問題時,大家無可避免的會歸咎於硬體設計中的瑕疵。是不是控制或時序出了差錯?或是開機載入的順序異常?因為似乎成為產品上線的唯一阻礙,以致時程緊迫使工程師倍感壓力。這看來應該輕而易舉,但是否確實如此?大家都認為錯誤應該都已在元件測試期間發現並排除,唯一需要的就是按照清單跑一次檢查,解決偶爾出現的疏漏,但是為什麼花了這麼長的時間卻還不能過關?

20190422TA01P1 圖1 展示整合大量功能性小零組件為一套系統時,可能產生的複雜性的車輛「明細視圖」。(圖片來源:CEVA)

我們都曾這麼想。別人通常假設絕大多數錯誤都已被發現和修復,但一些不起眼的疏忽會蔓延成為難以發現的問題。也許是個單一性的問題:工程師費盡心力設定程式,成功的避免未來相同的問題再次發生,從此一勞永逸。但在SoC軟體整合過程中會需要將個別軟體元件載入系統,而載入的過程會有一連串的鏈接。

必須首先在PC上構建程式,然後載入系統的快閃記憶體,記憶體中的某個簡單控制器再(從專用的記憶體)載入自己的一個簡單程式,再用這個簡單程式解聚開機數據並上傳到主記憶體。控制器隨後觸發一個特殊的開機載入指令到DSP等主處理器,然後啟動該處理器執行次一階段的解聚,並從主記憶體載入緊靠處理器的高速緊密耦合記憶體(TCM)。

這中間有很多個步驟,其中只要稍有(基本上你可能完全毫無所知)閃失,就會使整個系統完全卡住。

從檔案名稱開始。名稱輸入錯誤真的是自己的問題?微軟(Microsoft)的「長短破折號」問題有沒有考慮到?雖然MS工具有時會自動修正此一問題,但即使在複製/貼上這樣不可能出錯的單純字串轉傳的過程,也可能疏於注意此一問題而造成確實發生的錯誤,請參考以下遭遇到的實例。在本例中需要上傳多個檔案,但其中一個有問題開機程式就沒法完成,最終追查出是某個程式設計師在更新控制器軟體時,將檔案名稱從韌體程式設計師的電子郵件複製/貼上過來,而正是這個複製/貼上帶來此一錯誤。

再以控制器為例,任何人都有過以下的經歷:在十萬火急的軟體更新過程中漏掉了一個控制器軟體所需的檔案。開機程式的第一個環節因此使用了未更新的檔案,導致後續的開機流程完全失敗。真心不騙,找出這個錯誤所花的時間超乎想像。

再看一個可以灌入自訂指令的處理器。這些指令可能會在設計過程中調整,開發過程中設計團隊可能切換處理器版本型號,無論是出於何種原因,這些變更未隨軟體一起更新。當上傳軟體時有些會因為被對應到非預期的操作而產生非預期的行為,由於軟體與硬體只是略微不同步,因此在模擬檢測中未被發現。

複雜的問題也可能發生,但我的經驗顯示它們很少會成為「啟動失敗」的根本原因。從程式碼撰寫、配置、複雜的啟動程式到最終執行操作的整個序列,其中各種部份導致小小的錯誤並不意外。控制此一程式免於意外必須輔以基於對軟硬體充分瞭解的嚴密配置管理及除錯程式,僅憑一己之力想找出PCB上的任何問題並加以處理,絕對會帶來令人頭疼的結果。

硬體除錯的複雜性

在日常生活中常常疏於注意藏身於常用裝置核心的複雜晶片,即使它們的功能顯而易見:它讓我們用手機拍出高品質的照片、行車中提醒我們周遭的行人、檢測和辨識我們向虛擬助手發出的命令。本文此段的重點就是驗證晶片功能的挑戰性。

任何外觀亮麗的裝置內部都有多個晶片,每一組晶片後面都有一群包括研發、硬體架構、硬體設計、軟體開發、整合、QA的高手,確保裝置能依廣告所稱的方式順利操作。這些人員必須在不同的時空互相協調,確保各個組件即使有大量的軟體指令和硬體總成,仍能完美搭配依消費者的期望順利完成所需的功能;其中最大的挑戰出現於軟硬體交界之處。

硬體除錯

由於你正在閱讀這篇文章,因此我認為你對嵌入式設計並不陌生,且容我簡略說明一下其中的主要挑戰,特別是針對嵌入式DSP的軟體開發部分。

首先,為什麼要使用DSP?DSP可用於多種應用領域,例如人工智慧(AI)、電腦視覺、語音辨識、行動通訊。與通用CPU相比,DSP效能高功耗低,同時兼具用軟體改變操作的靈活性。DSP可依需要運作即時作業系統,以保證DSP應用通常需要的即時性。應用程式可在多核心系統上同時運作多個線程,也可在單個核心進行分時運行;個別線程能異步處理多個平行進程,以控制系統的不同硬體元件並處理數據。

DSP的應用實例之一是處理來自攝影機的影像,包括:增強顏色或對比度、透過高動態範圍(HDR)演算法融合多個影像、自動檢測現場內容、穩定快速行駛中用手機拍攝的晃動視訊,或對來自兩個感測器的視訊串流執行上述各功能(品質可達每秒120訊框、12位元取樣點的超高清8K影像)。在此一複雜程度下數據量可能超過33Gbps,更加深確保本程式各點依預期作業的複雜性和挑戰性。

DSP架構可能更為複雜,相應的組合操作會跨越多條線路。為滿足產出速率,程式碼需以專用編譯器或程式人員對性能進行大量最佳化,包括展開循環、重新排序指令、加以組合在單一循環中平行執行。程式碼除錯可能非常困難,需要特別強大的除錯工具。

新功能的開發通常始於在PC上運作的MATLAB、Visual Studio或GNU開發/除錯工具等高階環境;後者在軟體開發人員中很普及、文件很齊全,並且有許多適用於各種演算法的現成開放原始碼元件便於快速提升軟體、重用程式碼、利用高階編程環境、在高速伺服器架構上作業。工程師可以輕易交流、共享程式碼、在多個開發人員甚至團隊之間分工。這些開發環境具備簡單好用的除錯工具:程式人員可以逐步運作應用程式以追查程式碼錯誤及實施故障、檢查記憶體和變量值、設置斷點、手動操作資源和檢查結果,甚至在不停止被除錯程式執行的情形下重新編譯程式碼。

但最終這個軟體需要在被嵌入的實體上有效執行。開發人員此時需要能在實際晶片上除錯和最佳化軟體的工具;這需要比主流開發和除錯工具更深入的洞察力。

硬體除錯的挑戰性

目標硬體上的除錯軟體必須面對各種不同的挑戰,因為目標晶片或裝置是桌面工作環境的「外在」元素。桌面工作環境及其作業系統或多或少瞭解自己的運算引擎,但通常沒有標準方法以存取外部硬體的內部狀態,因此終究必須使用硬體供應商提供的嵌入式開發環境。這些嵌入式開發工具可與目標裝置通訊,並觀察或操縱內部狀態,在除錯和最佳化的細節階段使用不同的除錯環境時,這些工具必須提供易於使用的除錯工具,並充分支援工程師在此一階段的所有需求。

目標硬體除錯的挑戰性肇因於多個早期開發階段沒有的因素:其一是與待測裝置(DUT)建立除錯連接,遭遇可能難以捉摸的通訊問題。更常見的是硬體除錯問題可能發生在各個階段:初始連接、裝置重啟、應用程式加載、逐步除錯整個程式或查看記憶體和變量的值。這些問題的原因可能並不明顯,主機或一般型開發和除錯工具在隔離此類問題時,因為不瞭解目標平台而成效欠佳,因此必須借助於瞭解構建中系統的開發/除錯平台。

可解決DSP編程及除錯挑戰的軟體開發工具

本文前面已針對程式人員將軟體嵌到晶片的複雜性及在除錯時的挑戰性略作說明,包括將軟體導入複雜環境時各方面可能遇到的困難;此一環境通常是由大量純手工軟體和硬體組成。本節開始則將探討軟體開發工具及其提供的功能,以便管理DSP編程和除錯的挑戰。

軟體開發工具

SDT軟體開發工具包括軟體工程師能輕易對CEVA DSP平台編程所需的各種工具。如在軟體模擬平台或硬體上編譯、鏈接、除錯、分析DSP應用程式,提供可靠、清晰和方便的方法,來觀察和控制硬體目標上的軟體和硬體的內部狀態,SDT及下述各種工具間的關係說明如圖2。

20190422TA01P2 圖2 SDT元件方塊圖。SDT IDE可用編譯器及二進位工具觸發建置流程、產生DSP應用、提供對實體晶片或DSP軟體模擬的除錯功能。

編譯器

由於DSP具有不同的硬體功能,因此用於編程這些處理器的assembly語言需為CEVA獨有。CEVA的C/C++編譯器將從用戶源程式碼產生最佳化的assembly操作,並生成精簡且快速的assembly程式碼。在多數情況下編譯程式碼的執行時間與人工最佳化assembly程式碼的執行時間相當;但如有手動調整應用程式程式碼之需,還是可以自己編寫assembly程式碼。

鏈接器

鏈接器整合是由C/C++編譯器和assembler生成的二進位目標檔案、鏈接靜態庫(由CEVA或第三方提供)、解析所有地址引用生成可在CEVA DSP目標(軟體模擬或實際硬體)執行的應用程式;後者的執行可用CEVA除錯器控制,或在headless模式(例如以板載閃存啟動)下執行。鏈接器的一個獨特功能是能執行全局程式最佳化,盡量減少程式碼記憶體中符號引用所使用的記憶體量。

除錯器及Profiler

兼具Eclipse IDE插件或標準SystemC API性質的除錯器可在CEVA DSP Simulator或實際硬體目標上執行應用程式;不但除錯,還會在執行期間收集資訊以廓繪反饋、找出執行時間或RAM使用情況的瓶頸,並以圖形方式顯示以便查看。

20190422TA01P3 圖3 CEVA SDT ToolBox IDE廓繪產生的呼叫圖形:程式流程的具象顯示。

20190422TA01P4 圖4 CEVA SDT ToolBox IDE廓繪產生的記憶體事件圖形:導致循環遲滯的記憶體事件。

除錯器自動化可用Eclipse ISE內建腳本支持(EASE),或將除錯器整合到SystemC環境中來達成。兩者均可簡化測試自動化以執行多種可能的方案,實現軟體的高覆蓋率(例如對安全性要求極高的應用程式所需)。除錯器可用Target Connectivity Server(TCS)Manager配置到目標,以便融合CEVA經驗與可能的硬體除錯連接問題和故障,並用圖形用戶介面簡化目標選擇、連接配置和狀態檢查。

硬體除錯配置介面需求

有經驗的程式人員都知道在硬體上進行除錯絕非易事。TCS旨在幫助工程師輕鬆配置除錯目標和優先通訊機制,配置介面還提供硬體連接基本狀態或硬體版本不匹配問題的立即指示;已經限制對許可記憶體存取的簡單方式,以免因存取不存在的記憶體導致無垠的等待。

驅動程式配置

可設定目標連接伺服器驅動程式選擇提供實際硬體連接的組件。執行除錯器的裝置經網路連接驅動程式,以便後者用JTAG協議與所選硬體通訊,用TCS介面選擇驅動程式的程式說明如圖5。

20190422TA01P5 圖5 TCS驅動程式選擇功能表。

選定驅動程式後,可在同一介面直接選擇配置選項(圖6)。

20190422TA01P6 圖6 TCS驅動程式配置選項。

系統設定

硬體方面可設定要除錯的系統組件。TCS提供指定硬體系統架構內個別組件配置的機制(圖7)。

20190422TA01P7 圖7 TCS系統使用者介面說明。

TCS提供一個很重要的「驗證」鈕,可供立即檢查系統的連接性。本按鈕會觸發一系列執行基本測試的健全性檢查器,以確保所有組件都已備便進行連接和有效的除錯期,確保各驅動程式已連接且啟動執行所支持的韌體版本、目標硬體已連接並供電、所要的CEVA處理器版本與實際硬體相符等。執行這些健全性測試有助於避免在啟動和除錯時浪費大量時間。

20190422TA01P8 圖8 TCS驗證鈕執行結果。

TCS還可配置其他功能,例如:複雜的問題不一定顯示為明確的硬體錯誤。為隔離這些內容,TCS使用者介面內建一組日誌機制於各叢集,以便擷取除錯器和驅動程式之間的完整通訊;在多數情況下這很快就會找到故障的根本原因。

另一個非常有用的配置選項是依定義的核心叢集指定專用的記憶體屏障,這樣的核心叢集通常映射到固定範圍的實體記憶。在這種情況下可能會有對此群集無效的記憶體範圍,對範圍外記憶的存取可能導致無休止的等待。對無效記憶單元的存取不一定是有意之舉,捲動記憶視圖視窗也可能導致這樣的錯誤。記憶屏障有助於防止這些問題,以便除錯器忽略對無效記憶體的存取請求(亦即不發送給驅動程式)。

總結

本文除檢視晶片編程和除錯的挑戰性外,也列出藉由與硬體平台有效且良好保護的連接,紓解程式人員工作難度的方法。