電信基礎設備、視頻基礎設備以及影像應用等對于帶寬的要求迅速提升,這些系統需要支持具有更高分辨率、更快幀速率以及更出色音質的音視頻流。同時，上述系統還要提高信道密度，降低每信道的功耗。此外，該市場不僅要求提高外設與存儲器的集成度，而且還要進一步縮減電路板面積，從而節約系統成本。開發人員需要高度可擴展的靈活硅芯片器件和工具來幫助他們跟上市場發展趨勢的要求。

用于數字信號處理器(DSP)的一些傳統高性能I/O在可靠性、帶寬充足性以及可擴展性等方面都存在一定的局限性。串行RapidIO(sRIO) 能夠通過提供一種高性能的分組交換式互連技術解決這種局限性問題，這對復雜的DSP拓撲而言非常有用。與其前代技術不同，sRIO不需要與存儲器共享接口，而且既能作為主系統又能作為從系統運行。此外，其還可支持較長的物理連接距離以及硬件級故障檢測/糾錯、狀態/確認反饋以及帶內中斷/信號發送等。

德州儀器(TI)推出的TMS320C6?55等高級DSP現已集成了sRIO接口。這種接口具有極高的效率，能直接連接至DSP的DMA引擎，通過事務處理代理寄存器來降低控制開銷。為了提高DMA系統數據處理的效率，可對數據設定優先級，而且該接口還支持多個事務處理的排隊。

復雜系統拓撲中的sRIO

首先，我們必須了解sRIO在復雜系統拓撲中發揮的作用，明確它在物理系統的實施過程中如何提高靈活性。sRIO可支持芯片之間的通信，速度高達 20Gbps乃至更高。sRIO提供1X和4X寬度的1.25、2.5或3.125GHz雙向鏈接，每向吞吐速率高達10Gbps。

利用sRIO，設計人員能夠確定如何實現多個器件的最佳連接。DSP可直接進行網形、環形以及星形拓撲的連接，也可通過交換機進行多個DSP的連接，彼此之間有無本地連接均可。此外，我們還可采用sRIO一并連接DSP、FPGA和ASIC。這種高度的靈活性使設計人員能根據應用數據流的需要任意安排組件，而不會因為接口或協議的限制影響系統設計。

例如，一個簡單的系統可以具備兩個通過4倍速鏈接相連的DSP。另一個系統則要求更高的計算能力，不過不需要更多I/O。這種系統可以由5個DSP組成，每個DSP都直接通過1倍速鏈接彼此相連。第三個系統也包含5個DSP，它們均采用4倍速鏈接連接至中央交換機，以實現更佳的I/O性能(圖1)。第四個系統則有更繁重的計算要求，其中可能包含12個乃至更多的DSP，它們均通過4倍速鏈接連接至一個或多個交換機的系統架構，從而實現最高的計算能力和I/O帶寬。

圖1：在本例中，sRIO能靈活地連接所有五個DSP。

支持sRIO的系統能夠通過充分利用上述特性顯著提高整體性能。例如，在無線基礎設施系統中，總共三到六個速度達Gbps的天線數據通常由可處理24到48 個天線流(antenna stream)的ASIC或FPGA支持，這時每個基站的速率約為123Mbps。另一方面，用戶數據通常在DSP上處理，每個用戶通道速度約 19Mbps，統一采用共享的EMIF通道。采用鏈接sRIO通道的DSP使用戶數據和天線數據能獨立得到處理。采用DSP所需的成本不僅大大低于 FPGA或ASIC，而且在24到48個天線流的系統中能處理相同的數據速率，每個通道速度約為123Mbps，因此天線數據速度總共能到每秒3到 6Gb。對于用戶數據而言，諸如最新DSP系列的較高核心速度、較快的sRIO I/O速度，以及能釋放外部存儲器帶寬等優異特性，使通道密度能夠提高到每DSP達128個用戶通道，每通道速度為19Mbps，這樣整體而言每個DSP 的用戶數據總速度達2.5Gbps。

消息傳遞

軟件開發人員不僅能夠受益于 sRIO接口具有的更高性能和更高靈活性，而且他們無論采用低級編程技術還是高級編程技術均可進行應用開發。如果使用低級直接I/O方案，編程人員必須指定目標和地址，這種方案在能夠實現最佳性能的同時，還非常適用于在設計時就已知目標緩沖方案的應用，并且應用的分組是固定的。但是，這種方法的缺點是開發人員必須了解遠程處理器的物理存儲器映射，這使第三方集成非常困難。

高級消息傳遞方案能夠在無需進行大量低級器件編程的情況下就能提供一種更抽象的通信方法。這種方法對目標緩沖方案未知的應用最為適用，而且對于應用分組未知或者比較靈活的情況也很適用。此外，消息傳遞接口能夠顯著縮短用于增加或減少應用處理器所需的時間。

數家嵌入式處理器廠商為sRIO提供內核級軟件層支持。例如，在TI DSP中，消息傳遞由DSP/BIOS軟件內核基礎消息隊列(MSGQ)模塊提供支持，這使應用程序開發人員能在更高級的抽象水平上設計軟件。

消息傳遞使應用程序能夠通過sRIO互連更高效地與其它DSP通信。通過這種方法發送的消息，其優先級高于數據緩沖，這一點非常有用，因為以更高的優先級控制數據通常來說是更好的做法。MSGQ能在無需修改源代碼的情況下在處理器中移動讀取器和寫入器，因此我們能在單個處理器上進行開發，而且能方便地針對多處理器系統進行縮放。也就是說，寫入器不用了解讀取器駐留在哪個處理器上，這不僅能簡化集成，而且還能簡化客戶端／服務器應用等的開發工作。

此外，MSGQ還可支持消息的零拷貝傳輸，假定底層物理介質支持處理器間零拷貝。零拷貝基本說來就是指針傳遞(pointer passing)，而不是將消息內容拷貝到其它消息中。我們可在單個的處理器上完成上述操作，也可在共享存儲器的多部處理器完成。由于能從特定集 (pool)分配消息，因而我們能輕松地實現服務質量(QoS)特性，如針對關鍵資源提高性能、加快速度等。

MSGQ模塊

MSGQ模塊包括API接口、分配器以及傳輸程序等(圖2)。API接口將應用程序與傳輸程序和分配器相隔離。分配器為消息分配提供接口，而傳輸程序則為處理器間的消息傳輸提供接口。

圖2.MSGQ模塊

必須首先對在MSGQ模塊中發送的所有消息進行分配。我們能用多個分配器從一個集分配關鍵信息，再從另一個集分配非關鍵信息。我們可以舉一個簡單的分配器的實例，即所謂STATICPOOL的靜態分配機制，由應用程序提供的靜態緩沖器負責管理。在初始化階段，STATICPOOL分配器會接收地址、緩沖器長度以及請求消息的大小。可將緩沖器分為指定的消息大小塊，并放置在鏈接列表中，這有助于簡化消息定位。

接下來，傳輸程序在物理鏈接上將消息發送給另一處理器上的目標消息隊列(圖3)。通過傳輸接口，應用程序能在不改變自身的情況下改變底層通信機制，不過需要配置傳輸程序。這種方案將物理鏈接的具體技術問題隱藏起來，提高了應用的可移植性。

圖3：傳輸功能

消息隊列具有整個系統內唯一的名稱，發送器能通過其名稱來定位消息隊列。所有通過MSGQ模塊發送的消息都必須在第一字段編碼MSGQ_Msg Header，之所以必須是因為內部指令就保存在報頭中，報頭由傳輸程序和MSGQ模塊內部使用。消息發送到不同的處理器時，傳輸程序對消息報頭部分的任何字大小和字節序(endian)差異進行處理。應用程序負責消息專用部分所需的轉換。

由于不同的處理器可能采用不同的調用模塊(系統中的消息隊列)，因此MSGQ模塊允許應用程序寫入器指定通知機制的類型，這非常有用，因為用戶能指定通知機制，并相應地調節MSGQ。不過，一旦將消息發送給讀取器，寫入器就會丟掉消息的擁有權，并且不能再修改或釋放消息，因此在發送之前確保消息的正確性至關重要。當讀取器接收消息后，必須釋放消息或重復使用消息。

消息隊列的定位

MSGQ為每個打開的消息隊列保留一個消息存儲庫，消息隊列的讀取器從消息隊列的存儲庫中獲取消息。如果需要將讀取器或寫入器線程移至另一個處理器，就無需更改讀取器或寫入器代碼。

定位消息隊列有兩種辦法：同步定位和異步定位。采用同步定位法情況下(可能采取阻塞方法)，消息管理每個傳輸程序的查詢，以查找所需消息隊列的位置。采用異步定位法情況下，將消息隊列定位后會發送異步定位消息給指定的消息隊列。

同步法的實施更為簡便，但要求用于阻塞隊列的一些參數，如定位線程等。雖然異步法無需進行阻塞，但實際操作更為困難，難以使用。

我們可通過應用程序指定的通知機制來支持同步或異步操作。用戶可指定通知機制，如信號量和中斷記入等，這樣就不用再遵循特定的調用模式。消息發送器能嵌入消息隊列，消息讀取器則能提取消息隊列并做出回答。

數據流示例

以下我們給出來自某個應用程序的基本數據流程。根據設計，該應用可在兩個DSP之間移動數據。在本例中，我們用多個集來管理不同類型的消息，其中包括應用程序、傳輸程序內部控制消息以及錯誤消息等。采用不同的集并不是必需的，但這樣做有助于簡化應用程序的維護。例如，管理若干個小集有時要比管理單個大集要簡單。此外，如果消息大小有所不同，那么采用單個大集的話就會浪費大量存儲器空間，因為這時必須支持最差情況下的空間要求。

本例中的流程可運行在TI的TMS320C6?55 EVM等*估板上，這款*估板采用兩個通過sRIO實現互連的1GHz TMS320C6?55 DSP。該*估板提供了完整的代碼以供參考：

main()

if processor 0: 打開雇主消息隊列并

創建雇主線程。

if processor 1: 打開雇員消息隊列并

創建雇員線程。

打開錯誤消息隊列并創建錯誤線程。

srio_init to initialize peripheral

workerThread()

Loop

MSGQ_get message from the worker queue

確定發送器

向發送器發送特定數量的消息

bossThread()

MSGQ_locate to locate worker queue

Loop

MSGQ_alloc message

使用要接收的多個消息來填充消息。

MSGQ_setSrcQueue to embedded boss’s message queue

MSGQ_put message to reader

Loop

MSGQ_get message from the boss queue

errorThread()

Loop

MSGQ_get message from the error queue

Log MQT error via LOG_printf

在單個處理器上發送消息

下面將介紹在單個處理器上發送和接收消息的幕后情況，這個過程分為任務一和任務二。任務二由操作系統進行調用，打開MSGQ隊列，并為該消息隊列指定 “pend”與“post”函數。如果沒有消息，則使用“pend”函數，在而向消息隊列發送消息時則調用“post”函數。

如果MSGQ模塊獲得了沒有待決消息的信息，那么就可運行任務一，但必須讀取隊列標識符，并定位適當的隊列，以免其位于不同的處理器上。通常在啟動時定位隊列對性能幾乎沒有什么影響。此外，任務一在向任務二發送消息之前還必須為消息傳輸分配存儲器。

一旦任務一發送消息，就不能再對消息進行處理，因為這時MSGQ已擁有該消息，MSGQ會將該消息分配給適當的隊列。任務二獲得了有消息的信息，并準備接收消息。一旦任務二獲得消息，就能夠對消息進行重復使用，并將其發送回任務一。例如，如果兩個任務要將消息來回傳輸，那么就僅需分配開始的消息。若讀取器接收到消息，就能相應地更新內容，然后將其發回。這樣，任務二就能夠處理消息，一旦處理完成，消息就返回到存儲器管理，任務二也就不能再對該消息進行處理。消息傳輸至此完成。消息傳遞可通過為數據移動提供虛擬接口來顯著簡化復雜處理器通信的開發與維護。