作者：Bruce Lee，德州儀器軟件與開發工具工程師

從消費類通信產品到多媒體產品，各種數字信號處理應用都要求具備高性能與高集成度的片上系統 (SoC) ，這無疑向開發人員提出了新的挑戰。其中眾多挑戰源自異構架構（包含多種處理器、協處理器、加速器和外設）的集成、開發、測試以及驗證的內在復雜性。不過，SoC 架構的整體系統方案才能夠使其提供當今主要應用所需的高性能。

典型異構 SoC 由許多子系統和處理器組成。例如，一個多媒體處理器可能包括一個通用處理器 (GPP)、多個 DSP、音頻／視頻接口、編解碼器、加速器、WI-FI 等無線接口、閃存、高速通信鏈路、傳感器以及顯示控制器等。開發人員憑借整套多內核感知工具 (multi-core aware tool) 不僅能夠解決共享資源爭用問題，基于實際應用環境進行性能優化，而且還能跨多內核實現電源管理，從而使他們能夠輕松釋放 SoC 器件的強大功能并對市場快速做出響應。另外，通過對這些子系統的適當調整可以針對具體應用情況實現功能、功耗和性能的優化，開發人員無需像使用集成度較低的架構那樣徹頭徹尾地重新設計產品。

各自為政

過去，異構架構（如 GPP+DSP）設計小組一般至少分為三個組。一個小組為 GPP 編寫代碼，主要負責控制處理；第二個小組為 DSP 和片上協處理器編寫代碼，負責大部分數據處理；第三個小組負責系統集成，將其他兩個小組的設計整合在一起，并且根據新的約束和限制條件動態地重新劃分系統。

大部分編程人員在特定代碼塊方面都會有諸多擔心，如代碼密度、內存占用、功耗以及高速緩存的效率。但是，離開完整的系統，我們無法精確地對這些參數進行單獨測量。代碼的運行效率取決于多個代碼塊之間對處理周期、存儲器以及外設的爭用。

系統級設計小組能夠看清獨立編程小組無法察覺的利弊。例如，將某項功能分配給 GPP 還是 DSP 的決定一般情況下取決于在該處理器上編程該功能的復雜性。GPP 更適合控制及 UI 功能，因此一般會將這些功能劃分給 GPP，而數據處理功能劃分給 DSP。不過，有時候上述顯而易見的劃分并不具有較高的效率。

我們可以看一下數碼相機的自動聚焦功能，其是一種非常適合 DSP 處理的功能。與 GPP 相比，編程人員更易于為 DSP 編寫自動聚焦功能，而且代碼更簡短，運行速度也更快。考慮到 DSP 的功耗也低于 GPP，這一決策顯然不言而喻。

但是，如果考慮到典型的攝像應用模式，相關選擇并非那么簡單。用戶往往在相機打開并且開始聚焦時并不取景或準備拍攝，這意味著并不使用 DSP。如果在 DSP 上實施自動聚焦功能，那么在上述過程中必須同時為 GPP 和 DSP 供電。如果在 GPP 上實施自動聚焦功能（假設有足夠的開銷），則可以使 DSP 保持斷電狀態。在用戶實際拍照時，DSP 可以迅速進入工作狀態，并且以較低時延捕獲圖像。

這方面的利弊是：如果在 GPP 上實施，自動聚焦功能可能效率較低，需要更多 CPU 周期而且反應速度較慢；但是，由于能夠使 DSP 斷電而提高整體電池使用壽命，所帶來的節電優勢會超過上述不足。

動態分組

在權衡系統級的分組優勢時，編程人員必須將使用環境納入考慮范圍。例如，用戶有時候會連續拍攝許多張照片。如果完全利用 GPP，則系統的瓶頸可能在于寫入閃存或硬盤驅動器，其既限制相機排隊的較大照片數量，又會限制連續拍照的速度。通過減輕 GPP 的任務處理負擔可以加快圖像保存速度，從而提高相機的性能。在上述情況下，在 DSP 上實施自動聚焦功能可以實現較高的系統性能。那么，編程人員應該將自動聚焦功能分配在何處呢？

答案是動態分組，這種方法使編程人員能夠同時在兩種處理器上實現某種功能，從而可以在兩種情況下都能夠達到較佳性能。如果照片隊列為空，GPP 會負責自動聚焦，而 DSP 斷電。在拍下第一張照片后，GPP 喚醒 DSP 以采集圖像。同時，它將自動聚焦功能的執行轉移至 DSP。在 DSP 出于工作狀態時負責自動聚焦。在不需要 DSP 時，即用戶在等待拍攝另一張照片時，則 DSP 向 GPP 發送消息，通知準備好再次斷電。GPP 繼續執行自動聚焦功能并通知 DSP 斷電。

可以利用現成的商業實時內核管理自動聚焦功能，如：DSP／BIOS 或其他嵌入式 RTOS。如果功能可以同時在兩種處理器上執行，則可以為 GPP 或 DSP 無縫地創建自動聚焦任務 (AutoFocusTask)。

兩套代碼總比一套好

在實施動態分組時，首要擔心的是編程人員必須為不同的處理器分兩次編寫相同的代碼。在大多情況下，此類代碼均采用 C 語言編寫；因此，在處理器之間移植代碼僅需稍微調整一下相應編譯程序生成的優化代碼即可。需要注意的是，在同時具備兩套代碼的情況下，我們還可以獲得其他優勢。例如，自動聚焦功能在DSP 上會比在 GPP 上運行速度更快而且功耗更低。當今的開發環境為配置存儲器使用（包括高速緩存可視化）、監控功耗以及分析總線流量提供了高級的工具，從而使開發人員確定同時在 GPP 和 DSP 上進行執行功能配置是否合理。

利用兩套代碼，您還可以測試在其他情況下無法評估的、更復雜的分組方案。系統的實際性能并不等于各個部件的總和。它主要取決于具體使用環境和其他工作代碼。對于在 DSP 中產生高負載的視頻等算法，自動聚焦功能可以返回至 GPP。您可以在多種功能之間測試不同的分組情形，以確定哪種能夠提供較低的功耗以及較高的性能。您可以在開發環境中自動執行此類測試，利用各種組合并根據性能和／或功耗要求尋找較佳的配置。采用兩套代碼使系統集成人員能夠測試新配置，而無需要求編程小組進行意外更改。但是，如果必須在一個處理器上運行代碼，則無法實現上述目標。

兩步調試

在異構架構中需要注意的一個系統要素是對電路系統進行調試或仿真。處理器的此類內部電路可以減少代碼的調試工作量，從而使您能夠更準確了解系統的運行時曲線。另外，您還可以更好地設計如何使用存儲器，并且如何能夠更好地優化快速內存的使用。例如，高性能 DSP 包含的高級電路可用于支持無干擾的電路內仿真 (ICE)、管理 JTAG 掃描、監控電源、提高跟蹤能力、監視總線動態、執行高速數據交互、實現系統觸發，以及支持在調試會話過程中提供高系統可視化的其他重要功能。

另一個重要的成分是調試程序以及開發環境中的多內核感知度。您需要能夠同時停止多個處理器，以便解決某些調試問題。由于能夠了解疊加的地方，并且當代碼在疊加部分內部或者處理器之間轉移時能夠更新變量地址和觀察點，因此此類工具可以加快您的開發進程。另外，您可能還需要偶然禁用調試程序。您可能希望測試某個內核退出睡眠模式的反應速度（在提供跟蹤信息時不能處于睡眠狀態）或者需要通信棧連續處理（即使在系統遇到斷點情況下也如此），以便不丟失信息。

需要記住的是，USB 或 IEEE 1394 等協議棧可以在應用不使用它們時用于傳輸有用的調試信息。通過在其中一個內核上實施的協議棧，您可以更輕松地同時調試多個內核。另外，您還可以在不影響整個系統情況下控制如何傳輸和格式化調試數據。例如，如果您只是在調試代碼中使用 printf，那么就有可能造成連接器輸入不屬于系統組成部分的大型庫元素。

僅對該過程某一方面熟悉的開發人員（即，GPP 或 DSP）很難在設計過程前期評估權衡決策。另外，他們也無法為了優化性能或者實現動態分組而重新劃分某個功能，而且在移植代碼方面走進死胡同的小組也無法充分利用在編寫代碼過程中積累的豐富經驗。不過，利用正確的代碼與工具組合，您可以在系統級、而非按照獨立的處理單元來檢查自己的應用。您可以站在更高的層面（“我在調試 MP3 組件”），而非僅考慮 GPP 或 DSP 編程。

渴求效率

節省異構系統的一種方法是按照主／從配置運行多個處理器。主處理器在負責管理系統事件和用戶界面時從處理器處于斷電狀態；在低利用率或者空閑期間不必要讓兩個處理器都耗費電源。一般情況下，GPP 或控制處理器擔當主處理器，因為系統管理和用戶界面功能一般在該處理器上實施。時鐘更新或鍵盤響應等簡單事件的處理無需喚醒 DSP。如果 DSP 是主處理器，則任何事件都會喚醒 GPP 進行處理。這是選擇 GPP 用作主處理器的主要原因，雖然它的功耗一般高于 DSP。

在發生事件處理時，主處理器喚醒從處理器必須執行的功能。對于多功能器件而言，喚醒 DS