轉自https://www.cnblogs.com/liujinggang/p/9925859.html
一、RapidIO背景介紹
RapidIO是由Motorola和Mercury等公司率先倡導的一種高性能、 低引腳數、 基於數據包交換的互連體系結構，是為滿足和未來高性能嵌入式系統需求而設計的一種開放式互連技術標准。RapidIO主要應用於嵌入式系統內部互連，支持芯片到芯片、板到板間的通訊，可作為嵌入式設備的背板（Backplane）連接。
RapidI0采用三層分級體系結構,該分級結的如下圖所示
其中邏輯層位於最高層.定又全部協議和包的格式,它們為端點器件發起和完成事務提供必要的信息；傳輸層規范位於中間層,定義了RapidIO地址空間和在端點器件間傳輸包所需要的路由信息,物理層規范在整個分級結構的底部,包括器件級接口的細節,如包傳輸機制、流量控制、電氣特性和低級錯誤管理等功能.
Rapid IO分為並行Rapid IO標准和串行Rapid IO標准，串行RapidIO是指物理層采用串行差分模擬信號傳輸的RapidIO標准。在Xilinx的一部分FPGA里面已經集成了GTP，GTX或GTZ等高速串行收發電路，這些是FPGA實現RapidIO高速傳輸的物理層基礎。
二、RapidIO協議概述
2.1 包與控制符號
RapidIO操作是基於請求和響應事務的。
包是系統中端點器件間的基本通信単元。發起器件或主控器件產生一個請求事務,該事務被發送至目標器件。目標器件於是產生一個響應事務返回至發起器件來完成該次操作。 RapidIO事務被封裝在包中,而包則包含確保將事務可靠傳送至目標端點的所有必需的位字段。通常不會將RapidIO端點相互直接連在一起,而是通過介於其間的交換結構(fabric)連接。名詞“交換結構”指的是提供系統互連的單個或多個交換器件的集合。
控制符號用於管理RapdIO物理層互連的事務流,也用於包確認、流量控制信息和維護功能。下圖顯示了如何在 RapidIO系統中傳送事務。
上圖中,系統中的發起器件(Initiator)通過產生一個請求事務(Request)開始一次操作。該請求包傳送至交換結構器件(Fabric),通常是一個交換機,交換結構器件發出控制符號確認收到了該請求包,然后交換結構將該包轉發至目標器件(Target),這就完成了此次操作的請求過程。目標器件(Target)完成要求的操作,產生響應事務(Response)。通過交換結構(Fabric)將承載該事務的響應包傳送回發起器件(Initiator).傳送時使用控制符號對每一跳(hop)進行確認。一旦響應包到達發起器件(Initiator)並得到確認，就可認為此次操作已經完成。
2.2 包格式
RapidIO包由代表3級規范體系結構的多個字段組成。下圖顯示了典型的請求包和響應包的格式,這些包的格式屬於並行物理層包格式,串行物理層包的格式與此稍有不同。某些字段是依賴於具體的上下文的, 並不會在所有的包中出現。
請求包以物理層字段開始, S位指示這是一個包還是一個控制符號(S=0表示是一個包，S=1表示是控制符號), AckID表明交換結構器件將用控制符號來確認哪一個包。PRIO字段指示用於流量控制的包優先級。TT、目標地址( Target Address)和源地址( Source Address)字段指示傳輸地址的機制類型、包應被傳送到的器件的地址和產生包的器件的地址。Ftype和事務(Transation)指示正被請求的事務。長度(Size)字段等於編碼后事務的長度, RapidIO事務數據的有效裁荷(Payload)長度從1到256字節不等。SrcTID(源事務ID)指示事務ID, RapidIO器件在兩個端點器件間最多允許有256個未完成的事務。對於存儲器映射事務,跟隨在srcTID后面的是器件偏移地址 (Device Offset Address ) 字段。寫事務必須附帶數據的有效裁荷,所有包以16位(2個字節)循環冗余校驗碼(CRC)結束。
響應包與請求包類似。狀態(Status)字段指示是否成功完成了事務。目標TID(目標事務ID)字段的值與請求包中源事務 ID字段的值相等。下圖是請求包與響應包的包格式示意圖
對於用戶來說，最需要關注的就是邏輯層（上圖中藍色部分）各個字段的含義，邏輯層中Ftype與Ttype(Ttype字段和上圖中的Transaction字段是同一個字段，只不過叫法不同而已)兩個字段唯一的確定了這個請求包的功能。下表列出了Ftype與Ttype所確定的包含義
| Ftype (Format Type) |
Ttype (Transaction Type) |
包類型
|
功能 |
| 0~1 |
—— |
Reserve |
無 |
| 2 |
4’b0100 |
NREAD |
讀指定的地址 |
| 4’b1100 |
ATOMIC increment |
先往指定的地址中傳遞數據，在把傳遞的數據加1，此操作為原子操作，不可打斷 |
|
| 4’b1101 |
ATOMIC decrement |
先往指定的地址中傳遞數據，在把傳遞的數據減1，此操作為原子操作，不可打斷 |
|
| 4’b1110 |
ATOMIC set |
把指定地址中的數據每個bit全部寫1 |
|
| 4’b1111 |
ATOMIC clear |
把指定地址中的數據清0（每個bit全部清零） |
|
| 3~4 |
—— |
Reserve |
無 |
| 5 |
4’b0100 |
NWRITE |
往指定的地址寫數據 |
| 4’b0101 |
NWRITE_R |
往指定的地址寫數據，寫完成以后接收目標器件(Target)的響應 |
|
| 4’b1101 |
ATOMIC test/swap |
對指定地址中的數據進行測試並交換，此操作為原子操作，不可打斷 |
|
| 6 |
4’bxxxx |
SWRITE |
以流寫方式寫指定的地址，與NWRITE以及NWRITE_R相比，此方式效率最高 |
| 7 |
—— |
Reserve |
無 |
| 8 |
4’b0000 |
MAINTENANCE read request |
發起讀配置，控制，狀態寄存器請求 |
| 4’b0001 |
MAINTENANCE write request |
發起寫配置，控制，狀態寄存器請求 |
|
| 4’b0010 |
MAINTENANCE read response |
產生讀配置，控制，狀態寄存器響應 |
|
| 4’b0011 |
MAINTENANCE write response |
產生寫配置，控制，狀態寄存器響應 |
|
| 4’b0100 |
MAINTENANCE write resquest |
端口寫請求 |
|
| 9 |
—— |
Reserve |
無 |
| 10 |
4’bxxxx |
DOORBELL |
門鈴 |
| 11 |
4’bxxxx |
MESSAGE |
消息 |
| 12 |
—— |
Reserve |
無 |
| 13 |
4’b0000 |
RESPONSE no data |
不帶有效數據的響應包 |
| 4’b1000 |
RESPONSE with data |
帶有效數據的響應包 |
|
| 14~15 |
—— |
Reserve |
無 |
2.3 事務格式與類型
RapidIO事務的類型大概有以下幾種：
| 功能 |
事務類型 |
| I/O非一致功能 |
NREAITED(讀非共享存儲器) |
| NWRITE、NWRITE_R、SWRITE(寫非共享存儲器) |
|
| 原子(ATOMIC)(讀-修改-寫至非共享存儲器) |
|
| 基於端口的功能 |
門鈴(DOORBELL)(產生中斷) |
| 消息(MESSAGE)(對端口寫) |
|
| 系統支持功能 |
維護(MAINTENANCE)(讀寫配置、控制、狀態寄存器) |
| 用戶定義功能 |
對專用事務開放 |
| 高速緩存一致性功能 |
讀(READ)(讀全局共享高速緩存器) |
| READ_TO_DOWN(寫全局共享高速緩存器) |
|
| 拋棄(CASTOUT)(交出全局共享高速緩存器擁有權) |
|
| IKILL(指令緩沖失效) |
|
| DKILL(數據緩沖失效) |
|
| 刷新(FLUSH)(返回全局共享高速緩存器至存儲器) |
|
| IO_READ(讀非緩沖全局共享高速緩存器的副本) |
|
| 操作系統支持功能 |
TLBIE(TLB失效) |
| TLBSYNC(TLB強迫完成失效) |
2.4 消息傳遞
當數據必須被系統中的多個處理器件共享時,必須由協議維護和管理多個器件對共享數據的臨時占用,許多嵌入式系統用軟件機制實現該協議。如果存儲器空間可被多個器件訪問,可以使用鎖或者信號量來保證器件間正確的訪問次序。在其他情況下,處理部件可能只有訪問本地存儲器空間的權利,在這些“非共享”的系統中,需要一種機制把數據從一個處理器件傳遞到另一個器件。使用消息傳遞(Message Passing)信箱(Mailbox)可以實現這種機制。
RapidIO提供了一種有用的消息傳遞機制, RapidlO消息傳遞協議描述了支持信箱和門鈴通信的事務。RapidIO信箱是一個端口，器件間可通過它發送消息。接收器件在消息到達后對其進行處理。RapidIO消息的長度從0到4096字節不等。一個接收器件有1~4個可尋址消息隊列來捕獲輸人的消息。
RapidIO門鈴 (Doorbell )是一種基於端口的輕量級事務,可用於帶內(in-band)中斷。門鈴消息包括一個由軟件定義的16位字段，該字段可用來在兩個器件間傳達多種不同意圖的消息。
2.5 全局共享存儲器
支持全局共享的分布式存儲器系統是RapidIO協議的擴展功能之一。這意味着可以把存儲器放到系統中不同的物理位置上, 可以正確地在不同處理器件間緩存。
RapidIO制定了一種基於目錄的一致性解決方案來支持這種方法。使用這種方法，每個存儲器控制器都有責任跟蹤每個數據元素的當前副本在系統中位於什么位置，為一致域中的每個器件維護一個目錄，跟蹤每個器件的修改、共享、位置(MSL)等簡単的一致性狀態。
2.6 流量控制
流量控制是任何互連技術的重要內容。流量控制是指在任意時間互連技術采用某些規則和機制,根據這些規則和機制決定任意時間從可能獲得的若干事務中選擇哪一事務進行發送。流量控制的目的是使器件完成系統中的事務,避免被其他事務阻塞。基於總線的互連技術使用仲裁算法來確保器件進行恰當的轉發操作,確保高優先級的事務優先於低優先級的事務得到轉發。采用交換的互連技術,事務從系統的不同位置進入，從而無法使用集中式的仲裁機制。這就需要一種管理系統中的事務流的方法。RapidIO使用若干補充機制來獲得系統中平穩的數據流並避免系統死鎖。
2.7 串行物理層
RapidIO邏輯層的包被定義為一連串的比特，並且與物理層實現無關。這意味着RapidIO協議在串行與並行接口，銅線與光纖介質下都能正常工作。在Xilinx FPGA中已經集成了GTP，GTX或GTH等高速串行收發器，所以在FPGA實現RapidIO高速傳輸協議都是采用的串行物理層而並非並行物理層。串行物理層使用8B/10B編碼用到的字符（K碼）完成定界，利用這種方式，發送器件使用K碼作為定界符，為接收器件指明包或控制符號的開始和結束。
串行RapidIO規范使用物理編碼子層(PCS)和物理媒介附屬子層(PMA)在發送方將包轉化成串行比特流。並在接收方提取出該比特流。除了在發送前進行編碼和在接收后進行解碼操作，PCS層還負責空閑序列(idle sequence) 產生、通道分段(lane striping)、通道對齊(lane alignment)、以及接收方通道合並(lane destriping)的操作。PCS層使用8B/10B編碼技術在鏈路上傳送數據，8B/10B編碼模塊把8位數據編碼轉換為10位做據，編碼后的數據包括原始數據和可恢復的時鍾信息。PCS層還提供了一種機制，用於自動決定端口的工作模式是在單通道(1-lane)模式還是四通道(4-lane)模式。PCS層也可彌補發送方和接收方之間的時鍾差。
PMA層負責逐個通道地將10位並行碼組(code-group)數據串行化為串行比特流或將串行比特流並行化為10位並行碼組數據。接收數據時, PMA層獨立地、逐個通道地將接收到的比特流對齊到10位碼組邊界，然后向PCS層提供連續的10位碼組流，每一通道分配一個碼組流，10位碼組對於PCS層以上各層是不可見的。
三、I/O邏輯操作與包格式
3.1 引言
I/O邏輯操作支持RapidIO存儲空間的基本讀寫,它可以通過請求和響應事務對來完成。請求和響應事務對穿越 RapidIO交換結構運行, 但當事務穿越交換結構時RapidIO交換結構並不跟蹤該事務。從交換結構的角度看, 請求事務和與之對應的響應事務間並沒有明確的關系。雖然系統中可能存在多個中間交換器件和由此引起的多次包轉發,但是從RapidlO邏輯層的角度來說，請求事務和響應事務只有一個(如果需要響應的話),中間交換器件不區分請求和響應事務,它們的作用只是轉發事務到它們的最終目的地。
在 RapidIO體系結構中定義了6種基本的I/O操作, 下表給出了這6種基本的I/O操作、用來執行相應操作的事務和對操作的描述,
| 操作 |
使用的事務 |
描述 |
| 讀 |
NREAD、RESPONSE |
從目標器件中讀數據 |
| 寫 |
NWRITE |
往目標器件中寫數據 |
| 有響應寫 |
NWRITE_R、RESPONSE |
往目標器件中寫數據，寫完后等待目標的響應 |
| 流寫 |
SWRITE |
面向大數據量DMA傳輸優化寫數據 |
| Atomic |
ATOMIC、RESPONSE |
原子操作，讀-修改-寫，事務不能被打斷 |
| 維護 |
MAINTENANCE |
以RapidIO專用寄存器為目標的事務 |
3.2 請求包格式
RapidIO處理器發起一個請求包給目標器件(Target)，目標器件收到這個請求包以后給一個響應包到處理器（前提是這個請求包需要目標器件的響應），比如存儲器讀操作。一個典型的請求包的格式如下圖所示
對於用戶來說，最需要關注的就是邏輯層（上圖中藍色部分）各個字段的含義，Ftype與Ttype兩個字段唯一的確定了包的類型，具體的對應關系請參考2.2節。邏輯層各個字段的含義如下表所示
| 字段 |
含義 |
| Ftype |
格式類型(Format Type)，與Ttype共同唯一的確定包的格式 |
| Ttype |
事務類型(Transaction Type)，與Ftype共同唯一的確定包的格式 |
| Wrsize/Rdsize |
此字段根據包的類型來決定是寫事務數據的大小還是讀事務數據的大小，這個字段配合wdptr(word pointer)字段一起使用 |
| Src TID |
包的事務ID(Transaction ID)號 |
| Extended Address |
擴展地址，這是一個可選字段，指定50-bit物理地址的高16-bit或者66-bit物理地址的高32-bit |
| Address |
29-bit的物理地址，由於RapidIO傳輸以一個雙字(double-word)為基本單元，大多數嵌入式系統是32位的，所以一個字（word）占用4個字節，一個雙字(double-word)占用8個字節，所以29-bit的物理地址指向的一個存儲單元實際上是占用8個字節的，這樣用29-bit的物理地址實際上可以訪問4G(2^32)的內存空間 |
| Wdptr |
字指針(Word pointer),配合Wrsize/Rdsize字段來指明數據的大小以及對齊方式，詳細的說明請查看RapidIO_Rev_2.2_Specification第33頁 |
| Xamsbs |
擴展地址最高位(Extended address most significant bits)，把物理地址進一步擴展2位，由於29-bit的地址已經可以訪問4G內存空間，在最高位擴展2位以后就可以訪問16G的內存空間 |
| Data Payload |
要傳輸的數據 |
3.3 響應包格式
當一個RapidIO端點完成由另一個RapidIO端點發起的請求時,該端點就會發送一個響應事務。響應事務包總是以與請求事務包相同的方式被發送和路由。從廣義上說,第12、13、14 和15類格式（Ftype=12表示的就是第12類格式）是響應類事務的格式。通常，第 12和14類是保留的,第15類由具體應用定義, 第13類才是主要的響應類事務。第13類包格式返回狀態，數據(如果需要)和請求者的事務ID。帶有“ERROR”狀態或沒有預期的數據裁荷的響應的RESPONSE包沒有數據載荷。響應包使用第13類格式來響應除維護和無響應寫之外的所有請求包。維護響應包響應維護請求。一個典型的響應包的格式如下圖所示
邏輯層各個字段的含義如下表所示
| 字段 |
值 |
含義 |
| Ftype |
4’b1101 |
格式類型(Format Type)，與Ttype唯一的確定包的格式，對於一個有效的響應包來說，此字段的值固定為4’b1101，也就是16進制的d |
| Ttype |
4’b0000 |
不攜帶數據的響應 |
| 4’b0001~4’b0111 |
保留 |
|
| 4’b1000 |
攜帶數據的響應 |
|
| 4’b1001~4’b1111 |
保留 |
|
| Status |
4’b0000 |
DONE狀態：表示請求事務得到了正確的響應 |
| 4’b0001~4’b0110 |
保留 |
|
| 4’b0111 |
ERROR狀態：表示請求事務出現了不可恢復的錯誤，未能得到正確的響應 |
|
| 4’b1000~4’b1011 |
保留 |
|
| 4’b1100~4’b1111 |
用戶自定義響應 |
|
| Target TID |
—— |
目標事務ID(Transaction ID)號 |
| Data Payload |
—— |
響應包攜帶的數據，如果是不攜帶數據的響應，那么這個字段就不存在 |
3.4 常用的I/O邏輯操作事務
1、讀操作（NREAD）
讀操作由一個NREAD事務和一個RESPONSE事務組成，NREAD事務由請求方（Requestor）發起，目標方（Destination）正確的處理請求方發過來的響應以后會給請求方反饋正確的響應以及請求方讀取的數據。整個操作的示意圖如下所示
2、寫操作（NWRITE）和流寫操作（SWRITE）
寫操作（write operations）和流寫操作（streaming-write operations）分別由NWRITE和SWRITE事務組成。請求方可以用這兩種事務往目標方指定的地址寫入數據。NWRITE事務允許多個雙字（double-word），字（word），半字（half-word）和字節（byte）作為數據負載（Data Payload）進行傳輸，但前提是必須對數據進行適當的補0（padded）並進行8字節邊界對齊。而SWRITE事務相當於用NWRITE事務傳輸雙字（double-word）的情況，並且SWRITE事務具有更少的頭部開銷（SWRITE事務的包格式中把Ttype，Rdsize/Wrsize和srcTID三個字段全部定義為了Extended Address字段的一部分，所以頭部開銷變少）。NWRITE事務和SWRITE事務不需要接收目標方的響應，所以當事務被目標方處理完以后並不會給發起方反饋任何信息。NWRITE事務與SWRITE事務的操作示意圖如下圖所示
3、帶響應的寫操作（NWRITE_R）
帶響應的寫操作（write-with-response operations）由NWRITE_R事務和RESPONSE事務組成。它的整個請求操作和NWRITE事務的請求操作完全相同，但是在目標方正確處理請求方的NWRITE_R事務以后，目標方會給請求方反饋一個響應包告訴請求方事務已經被正確的處理。這種機制可以有效的保證數據傳輸的穩定性。NWRITE_R事務的處理流程如下圖所示
4、原子操作（Atomic Operations）
原子操作（Atomic Operations）又叫做讀-修改-寫操作（Read-modify-Write Operations），它是由ATOMIC事務和RESPONSE事務組成，許多協處理器單元使用該操作來執行非一致性（non-coherent）存儲器的同步。它允許攜帶的數據量為一個字（4個字節），一個半字（2個字節）或者一個字節，其他數據量都是不被允許的。
原子操作既包含了讀操作，也包含了寫操作。目標方讀取指定地址的數據，並把讀取的數據返回給請求方，然后對數據執行相關的操作，最后在寫回指定的地址。這個過程不會被任何其他的事務干擾或者打斷。對數據執行的操作包括加1運算（increment），減1運算（decrement），測試和交換（test-and-swap），置1操作（set）和清0操作（clear），在這些操作中，只有測試和交換（test-and-swap），比較和交換（compare-and-swap）以及交換（swap）需要處理單元提供數據。原子操作的目標數據可以用NWRITE事務進行初始化。原子操作的整個操作示意圖如下圖所示
四、維護操作與包格式
第8類事務維護事務用於訪問 RapidIO能力寄存器（CARs，Capability Registers）、命令和狀態奇存器( CSRs，Command and Status Register) ，本地定義的寄存器（Locally-Refined Registers）以及數據結構（Data Structures）。與其他的請求格式不同,維護操作的請求和響應包格式都是第8類包格式。第8 類包不含地址字段,只含寫請求和讀響應的數據載荷。
WRSIZE字段規定了多雙字事務數據載荷的最大長度。數據載荷的長度不能超過這個最大長度,但是如果需要的話,可以比這個最大長度小。維護讀請求和維護請求都產生正確的維護響應 。
維護事務的請求包格式如下圖所示
維護事務的響應包格式如下圖所示
維護事務包格式中邏輯層各個字段（Hopcount字段不屬於邏輯層，下表同樣列出它的含義）的含義如下表所示
| 字段 |
值 |
含義 |
| Ftype |
8 |
第8類事務代表維護類事務，維護類事務中這個字段固定為8 |
| Ttype |
4’b0000 |
指定一個維護讀請求 |
| 4’b0001 |
指定一個維護寫請求 |
|
| 4’b0010 |
指定一個維護讀響應 |
|
| 4’b0011 |
指定一個維護寫響應 |
|
| 4’b0100 |
指定一個維護寫端口請求 |
|
| 4’b0101~4’b1111 |
保留 |
|
| Hopcount |
|
跳數是一個8-bit字段，用於確定維護事務的目標交換器件。RapidIO交換器件沒有器件ID，跳數是可供選擇的尋址交換器件機制 |
| Config Offset |
|
用於讀寫CAR/CSR寄存器的雙字偏移量 |
| Src TID |
|
維護請求包的事務ID |
| Target TID |
|
維護響應包的事務ID |
| Status |
4’b0000 |
DONE狀態：表明請求的事務成功完成 |
| 4’b0001~4’b0110 |
保留 |
|
| 4’b0111 |
ERROR狀態：檢查到不可恢復的錯誤 |
|
| 4’b1000~4’b1011 |
保留 |
|
| 4’b1100~4’b1111 |
用戶定義 |
維護操作由維護請求事務和維護響應事務組成，處理器可以通過這類事務訪問CARs/CSRs等寄存器中的數據。如果發起的維護請求事務需要一個響應，那么目標方正確處理了維護請求事務以后會給請求方反饋一個維護響應包而不是由NWRITE_R事務或NREAD事務產生的正常響應包。它支持讀取配置寄存器的操作執行長度是字(4字節),也可以是雙字( 8字節)或設計者自已指定的雙字的整數倍長,但執行長度最多不得超過64 字節。所有寫配置寄存器的操作的執行長度規定與讀操作相同。維護操作的示意圖如下圖所示
五、消息操作與包格式
5.1 引言
分布式處理系統的一般方法是使用連接到分布式存儲器部件的緊耦合處理器。這些處理器可能運行在一個単獨的操作系統下。例如,，一個單Linux系統可以在最多數十個處理器上有效地運行。通常一個單操作系統的任務是管理處理器組和存儲器組。多數情況下，處理器可以高效地計算出通用硬件維護的一致性存儲器空間。這允許處理器通過使用信號量(semaphores )、自旋鎖(spin lock)和處理器間中斷來解決任務的初始化和完成的通信問題。操作系統使用頁保護方案集中管理存儲器。這種多處理技術十分成熟，已經使用了幾十年。
在其他分布式系統中,處理器和存儲器的耦合度可能松一些。若干操作系統或者內核可能在同一系統中共存，每個內核負責整個系統的一小部分。這些內核可能來自不同的軟件供應商，可能運行在不同的處理器體系結構上。在這些系統中使用簡單的通信機制是十分有用的；內核可以使用該機制與系統內的其他內核通信。例如，運行Linux的PowerPC處理器可能與運行QNX的TigerSHARC數字信號處理器通信。對於一個給定的應用,可能沒有理由在這些器件間共享存儲器空間。在這種類型的系統中，需要一種在所有器件上可用的通用硬件和軟件接口機制來簡單、經濟地完成高性能通信。在這些系統中,處理器之間通過消息傳遞進行通信。
在這些消息傳遞系統中,經常使用兩種機制將命令或數據從一個器件移動到另一個器件, 第一種機制稱為直接存儲器訪問(DMA)，第二種稱為消息(Message)。這兩種模型的主要差別是，DMA事務由源端操縱，而消息由目標端操縱。這意味着DMA源端不僅需要訪問目標，還必須具有對目標的地址空間的可見性。消息的源端僅需訪問目標，而不需要對目標地址空間的可見性。在分布式系統中，通常DMA和消息機制是結合使用的。
RapidIO體系結構包括一種可以用於消息的包傳輸機制。RapidIO消息模型應滿足下列目標：
1、消息由一個或多個事務組成，這些事務可以通過無序的互連發送和接收。
2、發送者可以有多個正在排隊等待發送的未完成的消息。
3、發送者可以在低優先級消息前發送高優先級消息，也可以為了發送一個高優先級消息而搶占低優先級消息，並在高優先級消息完成后恢復低優先級消息(基於優先級的並發性)。
4、發送者無需了解接收者的內部結構或存儲器映射。
5、消息接收者控制它本身的本地地址空間。
6、如果需要，接收者可以有多個未完成的正在排隊等待服務的消息。
7、如果需要，接收者可以接收多個並發的多事務（multiple-transaction）消息。
RapidIO消息傳遞邏輯規范定義了兩種不同的包格式用於消息事務。第10類包格式用來發送非常短的16位數據載荷，第10類包也稱為門鈴(DOORBELL)事務，門鈴事務很適合發送處理器間的中斷。多事務消息用第11類包發送最多4096字節的數據載荷。下面將分別介紹兩種事務,
5.2 門鈴事務（DOORBELL）
第10類包格式是門鈴事務格式。它沒有數據載荷。門鈴事務的請求包格式如下圖所示
上圖中Ftype字段固定為10，表示這是一個門鈴事務，8位的Reserved字段應該置0，Source TID指的是請求方的事務ID， info(msb)表示的是發送信息的高8位，info(lsb)表示的是發送信息的低8位。如果信息是用數字表示的，而且長度大於8位，那么數據符合低地址存放高字節（big-endian）的格式。比特流中先到達的是高字節。門鈴事務適合向處理器遞送中斷信息，在這種情況下，信息字段用來向接收者傳遞中斷級別和目標信息，除此以外，還可以在處理器件間發送信號量。
一個完整的門鈴操作由DOORBELL事務和RESPONSE事務(通常是DONE響應)組成。處理單元用這個操作將非常短的消息通過互連結構發送到另一個處理器部件。門鈴事務包括用於保持事務信息的信息字段。該事務沒有數據載荷。它的信息字段是由軟件定義的，可以用子任何目的。通常，運行在處理器上的操作系統會定義門鈴事務使用的信息字段的意義。收到門鈴事務的處理器部件將包放進處理器部件中的門鈴消息隊列，該隊列可以在硬件或者本地存儲器中實現。一個完整的門鈴操作如下圖所示
5.3 消息事務
第11類包為消息事務格式包。第11類包總有數據載荷，並且數據載荷長度總是雙字（64-bits或8-bytes）長度的整數倍。沒有規定子雙字(sub-double-word)消息，如果需要的話，可以由軟件管理子雙字消息。一個消息請求包的格式如下圖所示
圖中邏輯層各個字段的含義如下表所示
| 字段 |
值 |
含義 |
| Ftype |
11 |
Ftype=11表示這是一個MESSAGE事務 |
| Msglen |
|
消息長度（Message Length）：指的是組成該消息的包的總數。值為0時表明該包是一個單包消息，值為15(4’b1111)時，表明這是一個由16個包組成的消息。 |
| Ssize |
|
標准消息包數據大小(Stardard message packet data size)。該字段告訴消息接收者一個單獨消息操作除消息中最后一個包外組成消息的所有包的數據載荷大小。這樣可以防止發送者過度延長最后一個包的數據字段並允許接收者正確的將包放入本地存儲器 |
| 4’b0000~4’b1000 |
保留（Reserved） |
|
| 4’b1001 |
8字節（byte） |
|
| 4’b1010 |
16字節（byte） |
|
| 4’b1011 |
32字節（byte） |
|
| 4’b1100 |
64字節（byte） |
|
| 4’b1101 |
128字節（byte） |
|
| 4’b1110 |
256字節（byte） |
|
| 4’b1111 |
保留（Reserved） |
|
| Letter |
|
信件。該字段用來識別信箱（MailBox）中的一個槽（SLOT）。該字段允許發送方同時發送最多4個消息到接收方的同一個信箱中 |
| Mbox |
|
信箱（MailBox）。該字段用來指定目標處理部件中的接收信箱 |
| Msgseg |
|
消息段（Message Segment）。該字段用來表明該包是組成消息的包中的第幾個包。值為0表明該包是消息的第一個包。值為15（4’b1111）表明該包是消息的第16個包。 |
| Xmbox |
|
對於單包數據消息事務，該字段用來指明目標信箱的高四位。該字段與Msgseg占用相同的字段。Xmbox字段和mbox字段組合使用的定義如下： xmbox || mbox : mailbox number 0000 00 ： mailbox 0 0000 01 ： mailbox 1 0000 10 ： mailbox 2 0000 11 ： mailbox 3 0001 00 ： mailbox 4 …… 1111 11 ： mailbox 63 |
盡管RapidIO規范使用信箱(MailBox)、信件(Letter)和消息分段(Message Segment)之類的術語，但是這些字段在邏輯上指的是一個8位的消息標識符信息。消息標識符信息可以用來惟一的標識和管理任意兩個處理部件之間最多256個不同的消息流。接收處理部件的消息傳遞硬件會根據該信息計算應該把事務數據存放在本地存儲器的什么位置。
例如,假設接受處理部件的信箱0、信箱1、信箱2和信箱3的起始地址分別為地址0x1000、0x2000、0x3000和0x4000，處理部件接收到的消息事務帶有下列字段:
A、消息長度為6個包(msglen = 4’b0110)
B、消息段是第3個包(msgseg = 4’b0011)
C、信箱為信箱2(mbox = 2’b10)
D、信件為1(letter = 2’b01)
E、標准大小為32字節(ssize = 4’b1011)
F、數據載荷為32字節(由於這不是最后一個事務, 所以數據載荷應該是32字節)
處理部件的消息傳遞硬件使用這些信息來決定將這部分數據消息所含32字節數據存放到本地存儲器地址0x3040。
目標地址 = 信箱2基地址(Mailbox_2_base) + (消息分段x標准長度)
0x3040 = 0x3000 + (0x0002 x 0x0020)
這個簡單的尋址結構使得接收處理部件很容易計算存儲消息數據的目標存儲結構的地址。不僅計算起來容易，而且接收者的目標存儲器結構的位置對發送者也是不可見的。這允許僅在處理器部件間提供基於消息通信的安全系統研發工作。
消息的響應事務也是由第13類包產生，與NREAD事務和NWRITE_R事務響應包不同的是，消息事務的響應包中的target_info字段占用了普通響應包中的target ID字段的位置，具體的響應包格式見下圖
其中消息響應包中邏輯層Ftype字段，Ttype字段，Status字段以及Data Payload字段的含義與普通響應包中各字段的含義完全相同， Target_info字段由letter，mbox和msgseg三個字段組成，這三個字段的含義與消息請求包中這三個字段的含義完全相同，這里不再贅述。
由消息和響應(一般是DONE響應)事務組成的數據消息操作如下圖所示，處理部件的支持消息傳遞的硬件用它向另一個處理部件發送數據消息。完成一次數據消息操作最多需要16個單獨的消息事務。消息事務數據載荷的大小是雙字長度(8個字節)的整數倍。最大的消息操作載荷是4096字節，該載荷由16個消息事務組成，每個事務攜帶256字節的數據載荷。信件( letter)，信箱(mbox)和消息段(msgseg)組合在一起，惟一地標識系統中每個請求和響應部件對的消息包，與其他請求類型使用的事務 ID的作用一樣。
六、總結
RapidIO的事務大致就上面幾種，下圖把所有的事務都放在一起以便於大家更快的查看相關的包格式與各個字段的位置。
這里有幾點值得注意的是：
1、 每個包的邏輯層字段與上文所講的各個包的邏輯層字段定義完全相同
2、 上圖物理層字段的前10位所代表的字段ackID，rsvd，crf以及prio與正文中包格式的物理層字段有所出入，這是因為正文所講解的包都是並行物理層的包格式，而上圖中是串行物理層的包格式，所以物理層字段會有一點點區別，具體的內容請閱讀下一篇博客。
3、 上圖每個包CRC字段的后面還有一些字段是正文中包格式所沒有講到的。這里特地解釋一下：由於RapidIO包的總長度大於80個字節以后，RapidIO包會對前80個字節生成一個2字節CRC碼並補0使字節邊界對齊。然后80字節以上的數據放在處理完畢以后的數據后面繼續發送，發送完畢以后生成第二個CRC碼並補0使字節邊界再次對齊，其中第二個CRC校驗碼是第一個CRC校驗碼的延續。因此上圖中會出現后面的那些字段。后面我會寫一篇博客教大家怎么使用RapidIO核，到時候看完這種大於80字節傳輸的時序圖就能明白這個過程了。
七、參考資料
1、RapidIO™ Interconnect Specification，下載鏈接 https://pan.baidu.com/s/1ek-3AAhetLAcxTuOE2IyMg
2、RapidIO嵌入式系統互連，電子工業出版社
3、Xilinx的pg007_srio_gen2，下載地址 https://china.xilinx.com/support/documentation/ip_documentation/srio_gen2/v4_0/pg007_srio_gen2.pdf