電子發燒友App
一、RapidIO串行物理層背景介紹
上篇博文提到RapidIO的物理層支持串行物理層與并行物理層兩種，由于Xilinx 部分FPGA內部已經集成了串行高速收發器，所以用FPGA實現RapidIO大多都是基于串行物理層的。本文將主要討論一下RapidIO串行物理層的包格式與控制符號。
RapidIO串行物理層,通常稱為串行RapidIO，簡稱為SRIO（Serial-RapidIO）。串行物理層定義器件間的全雙工串行鏈路,在每個方向上使用單向差分信號。RapidIO串行物理層支持RapidIO器件間的包傳送，包括包和控制符號的傳送、流量控制、錯誤管理和其他器件到器件的功能。
RapidIO串行物理層有如下特征：
1、采用8B/10B編碼方案將時鐘嵌入到數據中。
2、在每個方向上支持一個串行差分對，稱為1通道；或支持四個并列的串行差分對，稱為4通道。
3、使用專用的8B/10B碼(稱為K碼)來管理鏈路。管理內容包括流量控制、包定界和錯誤報告。
4、允許在RapidIO 1x/4x LP-Serial(串行RapidIO)端口和RapidIO物理層8/l6 LP-LVDS（并行RapidIO）端口之間進行包傳輸而無需包處理。（LP=Link Protocol）
5、使用與并行RapidlO物理層相似的重傳和錯誤恢復協議。
6、支持每通道1.25G、2.5G和3.125G波特率(數據速率為1.0Gbps、2.0 Gbps和2.5 Gbps)的傳送速率。
二、RapidIO串行物理層的包格式
2.1 串行物理層包格式與并行物理層包格式的區別
RapidIO并行物理層包格式和串行物理層包格式的邏輯層和傳輸層字段完全相同，唯一不同的是物理層字段有所區別。總體來說，并行RapidIO包和串行RapidIO包在物理層有以下兩方面不同：
1、因為并行RapidlO包和控制符號在同樣的數據線路中傳送，并且并行接口不使用K碼來為包和控制符號定界，所以并行包的第一位用來區分包和控制符號。而串行包不包括用來區別包和控制符號的S字段。
2、串行物理層提供5比特的ackID而并行物理層僅提供3比特的ackID。這意味著在兩個串行鏈路端口之間最多可以包含32個未完成的事務，而對于并行接口兩個端口之間最多只能有8個未完成的事務。串行鏈路接口覆蓋范圍更大，因為串行接口更可能運行在需要較長距離通信的情況，更可能在兩個端口之問有較多的未確認的活動事務。
下圖是RapidIO串行物理層包格式與并行物理層包格式的對比圖
由上圖可以看出，串行物理層的包格式與并行物理層的包格式僅僅只有前6-bit不同，而其余的字段完全相同。所以包格式最后的CRC校驗碼的計算范圍不包括包的前6-bit。
2.2 RapidIO串行物理層包格式
RapidIO串行物理層的包格式如下圖所示
其中邏輯層和傳輸層各個字段的含義與上篇文章并行物理層包格式字段含義完全相同。這里不再贅述，串行包格式物理層各個字段的含義如下表所示
| 字段 | 描述 |
| ackID[0-4] | ackID是返回給包發送者的包標識符。串行物理層為該字段定義了5位。這足以在兩個器件間唯一的識別最多32個未完成的事務 |
| rsvd[0-2] | ackID字段后面的兩個0就是rsvd字段。產生包時這兩位必須置0，接收包時，這兩位需要忽略 |
| crf | 關鍵請求流(Critical Request Flow)，與prio字段共同決定包的優先級 |
| prio[0-1] | 設置包的優先級，2’b11的優先級最高，2’b00的優先級最低 |
| crc[0-15] | 使用16位循環校驗碼檢查包中的錯誤 |
串行RapidIO包的長度應該是32位的整數倍。因為內部數據的寬度一般是32位的整數倍，所以使串行RapidIO包的長度等于32位的整數倍可以簡化發送和接收端口邏輯的設計。如果包的長度是16位的奇數倍(包括循環冗余校驗碼字段)，值為0x0000的16位數據會填充到包尾。填充后的包長度是32位的整數倍。
2.3 RapidIO串行物理層包保護
串行物理層在每個包中加入16位循環冗余校驗碼以提供錯誤檢測機制。該碼覆蓋了除ackID字段和rsvd字段首位外的整個包，循環冗余校驗碼計算時將未覆蓋的部分視為0。下圖顯示了循環冗余校驗碼未覆蓋的串行物理層包頭的前6位(ackID和第一個保留位)。
由于包通過交換結構傳輸時不要求為每個鏈路重復計算循環冗余校驗碼，所以該結構允許ackID在每條鏈路上改變。由于在每條鏈路上為每一后續傳送的包分配的ackID是連續的，所以很容易檢測到ackID字段的錯誤。
有兩種方式將循環冗余校驗碼附加在包尾。對除循環冗余校驗碼外長度等于或少于80字節的包來說，在邏輯層字段尾附加一個單獨的循環冗余校驗碼。下圖是長度小于80字節的被填充過的包的示例
對除循環冗余校驗碼外長度大于80字節的包來說，在前80字節后附加一個循環冗余校驗碼。在邏輯層字段尾的加另一個循環冗余校驗碼。第二個循環冗余校驗碼是第一個的延續。第一個循環冗余校驗碼包含在運行(running)計算中，這意味著在運行循環冗余校驗碼值插入到包的前80個字節后面之后不再重新初始化。這允許相關器件將嵌入的循環冗余校驗碼值視為2字節的數據載荷以進行循環校驗碼的校驗。如果附在邏輯層后面的循環冗余校驗碼不能使包尾部對齊32位邊界的話， 2字節的全邏輯0填充就會加在包尾部。該邏輯0填充區有助于保證循環冗余校驗碼校驗總在32位邊界完成。接收處理部件使用前一個循環冗余校驗碼來檢査較大包頭的有效性并在接收到整個包前開始處理數據，這樣可以更早地釋放資源并減少完成事務的延遲。
下圖是一個長度大于80字節的被填充過的包的示例。這個包包括兩個循環冗余校驗碼和一個位于包尾的填充區。包的總長度為32位的整數倍。
使用ITU(國際電信聯盟)多項式X16+X12+X5+1可以產生包16位的循環冗余校驗碼。在每個包的開始循環冗余校驗碼的值初始化為0xFFFF（全部邏輯1）。在循環冗余校驗碼計算時把未覆蓋的6位視為邏輯0。具體的實現過程請參考RapidIO官方手冊(參考文獻1)第465頁。
三、RapidIO串行物理層的控制符號
3.1 控制符號介紹
控制符號是被串行鏈路端口使用的消息單元，它用來管理串行鏈路操作的各個功能，包括鏈路維護，包界定，包應答，錯誤報告和錯誤恢復。
SRIO中定義了兩種控制符號。第一種控制符號長度為3個字節，被稱為短控制符號（Short Control Symbol），第二種控制符號長度為6個字節，被稱為長控制符號（Long Control Symbol）。短控制符號是SRIO最先定義的一種控制符號，它適用于串行鏈路的線速率低于5.5Gbps，并且接收方并未對數據進行判決反饋均衡（Decision Feedback Equalization，DFE）的情況，它提供了串行鏈路協議需要的基本功能以及一些擴展功能。長控制符號是對短控制符號的擴展，它適用于串行鏈路的線速率高于5.5Gbps，并且接收方對數據進行判決反饋均衡（Decision Feedback Equalization，DFE）的情況。由于接收方對數據進行判決反饋均衡（Decision Feedback Equalization，DFE）容易產生數據的突發錯誤（Burst Error），所以長控制符號提供了一些額外的功能去加強突發錯誤的錯誤檢測能力。同時，長控制符號還提供了一些短控制符號不具備的其他擴展功能。當然，長控制符號也支持串行鏈路的線速率低于5.5Gbps的情況，在這種情況下，長控制符號可以替代短控制符號提供更多的控制符號功能。
3.2 控制符號格式
控制符號包括長控制符號和短控制符號兩種。長控制符號是對短控制符號功能的擴展。
所有的短控制符號長度都為24位（3個字節），格式如下圖所示
短控制符號一共承載了兩個功能，一個功能由stype0字段決定，另一個功能由stype1字段決定。其中，parameter0字段和parameter1字段被stype0字段所代表的功能所使用，而cmd字段是被stype1字段所代表的功能所使用。stype0字段所代表的功能主要包括端口傳輸控制符號過程中的狀態信息，而stype1字段所代表的功能主要是傳輸RapidIO包的界定符和一些接收端口的請求。
所有的長控制符號長度都為48位（6個字節），它的格式如下圖所示
長控制符號各個字段的含義與短控制符號各個字段的含義完全相同，唯一的不同之處在于短控制符號的parameter0字段和parameter1字段長度為5位，而長控制符號的parameter0字段和parameter1字段長度為6位。
控制符號中各個字段的詳細定義如下表所示
| 字段 | 定義 |
| stype0 | 為使用了parameter0和parameter1字段的控制符號編碼 |
| Parameter0 | 與stype0編碼一起使用 |
| Parameter1 | 與stype0編碼一起使用 |
| Stype1 | 為使用cmd字段的控制符號編碼 |
| Cmd | 與stype1字段一起用來定義鏈路維護命令 |
| Crc-5 | 用來檢測控制符號傳輸錯誤的5位循環冗余校驗碼 |
| Crc-13 | 用來檢測控制符號傳輸錯誤的13位循環冗余校驗碼 |
只有一種功能的控制符號以它所表示的功能的名字來命名。有兩種功能控制符號以它所表示的某個功能的名字來命名。例如, stype0設置為接收包(packet-accepted)而stype1設量為NOP的控制符號稱為接收包控制符號。其stype0設置為接收包而stype1設置為從重傳處重啟(restart-from-retry)的控制符號被稱為接收包控制符號或從重傳處重啟控制符號，這取決于上下文。
可以傳達兩種功能的能力是控制符號特有的屬性。這樣包確認控制符號和包定界控制符號就能由同一控制符號表示。鏈路傳送的控制符號流中大多數是包確認控制符號和包定界控制符號。有的時候在一個控制符號中攜帶確認(或狀態)和包定界符能顯著降低鏈路開銷并增加傳送包的鏈路帶寬。
3.3 stype0控制符號
下表列出了stype0控制符號的編碼和功能以及parameter0字段和parameter1字段所代表的含義
?
| Stype0 | 功能 | 內容 | |
| Parameter0 | Parameter1 | ||
| 3’b000 | 可接收的包 | Packet_ackID | Buf_status |
| 3’b001 | 包重傳 | Packet_ackID | Buf_status |
| 3’b010 | 不可接收的包 | 任意值 | Cause |
| 3’b011 | 保留 | —— | —— |
| 3’b100 | 狀態 | ackID_status | Buf_status |
| 3’b101 | 虛擬通道狀態 | VCID | Buf_status |
| 3’b110 | 鏈路響應 | ackID_status | Port_status |
| 3’b111 | 用戶定義 | 用戶定義 | 用戶定義 |
?
上表中各個字段的含義如下表所示
?
| 參數 | 定義 |
| Packet_ackID | 被應答控制符號的ackID |
| ackID_status | 端口預期接收的下一個包的ackID的值。這個值比上一次收到的包的ackID值大1， |
| Buf_status |
端口在指定的虛擬通道可接收的最大包的個數 對于短控制符號： 值為0~29：該編碼值定義了端口在指定的虛擬通道件可以接收的新的最大包的個數。例如，值0表示端口在指定的虛擬通道沒有包緩沖，因此不能接收新包 值為30:端口在指定的虛擬通道件可以接收的新的最大包的個數為30個 值為31: 端口在指定的虛擬通道件可以接收的新的最大包的個數未定義，包的個數取決于流控制的重傳協議 對于長控制符號： 值為0~61：該編碼值定義了端口在指定的虛擬通道件可以接收的新的最大包的個數。例如，值0表示端口在指定的虛擬通道沒有包緩沖，因此不能接收新包 值為62:端口在指定的虛擬通道件可以接收的新的最大包的個數為30個 值為63: 端口在指定的虛擬通道件可以接收的新的最大包的個數未定義，包的個數取決于流控制的重傳協議 |
| Cause |
這個參數指的是包不被接收的原因。 5’b00001：接收包中的ackID值錯誤 5’b00010：接收控制符號的循環冗余校驗碼錯誤 5’b00011：非維護的接收包被阻止 5’b00100：接收包的循環冗余校驗碼錯誤 5’b00101：接收了無效的字符或者有效但不合法的字符 5’b00110：缺乏資源 5’b00111：解交織同步信號丟失 5’b11111：普通錯誤 |
| Port_status |
端口狀態： 5’b00010：端口遇到了不可恢復的錯誤 5’b00100：重傳停止（Retry-stopped） 5’b00101：錯誤停止（Error-stopped） 5’b10000：正常（OK） 其他值均為保留值。 |
?
接收包（Paket-Accepted）控制符號：
???????接收包的控制符號表明接收器件已經把包發送到其最終目的地并且可以釋放由發送器件分配的資源。該控制符號應該僅在已接收到整個包并且沒有發現可檢測的錯誤之后產生。接收包控制符號的格式如下圖所示
重傳包（Paket-Retry）控制符號：
重傳包控制符號表明接收器件由于某些臨時的資源沖突，如緩沖區不足而不能接收包，發送者應該重新發送包。重傳包控制符號的格式如下圖所示
未接收包（Packet-not-accepted）控制符號：
未接收包控制符號用來向包發送者表明接收端口沒有接收到包的原因。控制符號包含一個指示無法接收包的原因的cause字段和一個packet_ackID字段。如果接收器件不能確定原因，或原因不屬于定義的原因選項，就使用一般錯誤編碼。Cause字段的定義在上表已經給出，未接收包控制符號的格式如下圖所示
狀態（Status）控制符號：
狀態控制符號默認為stype0編碼。它在控制符號不傳達另一個stype0功能時使用。狀態控制符號包含ackID_status和buf_status字段。buf_status字段向接收端口指示發送端口在產生控制符號時擁有的可用來接收包的可容納最大長度包的緩沖區數量。ackID_status字段允許接收端口判定該端口和發送端口是否關于發送端口期望接收到的下一個ackID值同步。下圖是狀態控制符號的格式
鏈路響應（Link-Request）控制符號：
器件用鏈路響應控制符號響應鏈路請求（link-request）控制符號。在狀態字段中報告的狀態是在接收到相關鏈路請求/輸入狀態（link-request/input-status）控制符號時端口的狀態。下圖是鏈路響應控制符號的格式，port_status字段的功能在上表已經描述
3.4 stype1控制符號
下表列出了stype1控制符號的編碼和功能以及cmd字段所代表的含義
| Stype1 | Stype1功能 | cmd | Cmd功能 | 包定界符 |
| 3’b000 | 包開始 | 3’b000 | 包開始 | 是 |
| 3’b001~3’b111 | 保留 | 否 | ||
| 3’b001 | 包取消 | 3’b000 | 包取消 | 是 |
| 3’b001~3’b111 | 保留 | 否 | ||
| 3’b010 | 包結束 | 3’b000 | 包結束 | 是 |
| 3’b001~3’b111 | 保留 | 否 | ||
| 3’b011 | 從重傳處重啟 | 3’b000 | 從重傳處重啟 | * |
| 3’b001~3’b111 | 保留 | 否 | ||
| 3’b100 | 鏈路請求 | 3’b000~3’b010 | 保留 | * |
| 3’b011 | 復位設備 | |||
| 3’b100 | 輸入狀態 | |||
| 3’b101~3’b111 | 保留 | |||
| 3’b101 | 多播事件 | 3’b000 | 多播事件 | 否 |
| 3’b001~3’b111 | 保留 | 否 | ||
| 3’b110 | 保留 | 3’b000~3’b111 | 保留 | 否 |
| 3’b111 | NOP（忽略）** | 3’b000 | NOP（忽略）** | 否 |
| 3’b001~3’b111 | 保留 | 否 |
* 表示如果包在轉發過程中，從重傳處重啟并且鏈路請求控制符號可能只是包定界符。
** 表示雖然NOP（忽略）沒有作為控制符號定義，但是它是在控制符號不傳達另一個stype1功能時的默認值。
包開始（Start-Of-Packet）控制符號：
包開始控制符號用來界定包的起始位置，它的格式如下圖所示
包取消（Stomp）控制符號：
包取消控制符號用來取消一個正在發送的包，它的格式如下圖所示
包結束（End-Of-Packet）控制符號：
包結束控制符號用來界定一個包的結束位置，它的格式如下圖所示
從重傳處重啟（Restart-from-Retry）控制符號：
從重傳處重啟控制符號會取消一個當前的包。該控制符號可能在空閑鏈路上傳送。用該控制符號標記重傳包的開始可使接收者知道在其請求重傳一個包后什么時候開始接收包。它的格式如下圖所示
鏈路請求（Link-Request）控制符號：
器件使用鏈路請求控制符號發起一個命令到相連器件或請求相連器件的輸入端口狀態。鏈路請求控制符號取消當前包并可在包之間發送。在錯誤情況下,鏈路請求/輸入狀態控制符號的作用與鏈路請求/從錯誤處重啟控制符號的作用相同。鏈路請求控制符號的格式如下圖所示。
鏈路請求控制符號的第二個字段是一個3位的命令(cmd)字段。該字段包含發送到鏈路的命令。定義了兩個命令:器件復位(reset-device)和輸入狀態(input-status)，cmd字段詳細的描述如下表所示
?
| Cmd的值 | 命令名稱 | 描述 |
| 3’b000~3’010 | ? | 保留 |
| 3’b011 | 復位設備（reset-device） | 復位接收設備 |
| 3’b100 | 輸入狀態（input-status） | 返回輸入端口狀態；在錯誤情況下和鏈路請求（從錯誤處重啟）控制符號的功能相同 |
| 3’b101~3’b111 | ? | 保留 |
?
復位設備命令引起接收器件執行復位或上電過程; 所有狀態機和寄存器都復位到上電初始狀態。復位設備命令不會產生鏈路響應控制符號。由于各系統設計的可靠性并不確定, 在鏈路響應控制符號的復位功能上設置保護是必要的。設備接收到鏈路響應控制符號中的復位設備命令時并不執行復位功能，除非它收到四個連續的復位器件命令。這些連續的命令之間不應有除狀態控制符號外的任何其他插入的包或控制符號。這樣做能防止假復位命令在無意中復位器件。
輸入狀態命令請求正在接收的器件返回在其輸入端口期望接收到的來自發送者的下一個ackID值，同時返回該輸入端口當前的工作狀態。該命令使接收端刷新其輸出端口在輸入狀態命令之前接收到的由包產生的所有控制符號。刷新輸出端口是與具體實現相關的，可能導致丟棄接收緩沖區的內容或在鏈路上發送控制符號，然后接收者產生鏈路響應控制符號作為響應。
多播事件（Multicast-Event）控制符號：
多播事件控制符號與其他的控制符號不同，不同之處在于它攜帶的信息與鏈路傳輸的控制符號無關。多播事件控制符號允許把用戶定義事件的發生廣播到整個系統。它的格式如下圖所示
3.5 控制符號保護
控制符號的錯誤檢測是通過循環冗余校驗碼（Cyclic Redundancy Check，CRC）來完成的。
對于短控制符號來說，RapidIO協議使用一個5位的CRC對錯誤進行檢測。它能為8B/10B解碼模塊解出來的24位短控制符號檢測最多5位的突發錯誤（Burst Error），5位的突發錯誤是最長的突發錯誤，8B/10B解碼模塊組的頂層如果出現單比特的傳輸錯誤就有可能導致5位的突發錯誤。
對于長控制符號來說，RapidIO協議使用一個13位的CRC對錯誤進行檢測。它能為8B/10B解碼模塊解出來的48位長控制符號檢測任意位數的突發錯誤（Burst Error），11位的突發錯誤最多可以破壞兩個8B/10B碼組。
CRC-5循環冗余校驗碼
使用ITU多項式X5+X4+X2+1為控制符號產生5位循環冗余校驗碼。循環冗余校驗碼的校驗位占用了控制符號的最后5位。應該注意的是，5位循環冗余校驗碼必須由發送者產生并由接收者檢驗。在計算5位循環冗余校驗碼前應該將循環冗余校驗碼字段設置為全1 (5’b11111 )。為了使各種類型的循環冗余校驗碼實現更加靈活，在控制符號字段中加人了一個虛擬的第20位。對所有的計算來說，第20位是應用的最后1位,并且總是置為邏輯0。
CRC-13循環冗余校驗碼
使用ITU多項式X13+X10+X8+X5+X2+1為控制符號產生13位循環冗余校驗碼。循環冗余校驗碼的校驗位占用了控制符號的最后13位。應該注意的是，13位循環冗余校驗碼必須由發送者產生并由接收者檢驗。在計算13位循環冗余校驗碼前應該將循環冗余校驗碼字段設置為全0 (13’b0000000000000 )。
關于CRC碼的具體產生方法請閱讀RapidIO官方手冊（參考文獻1）的第481頁。
四、總結
RapidIO串行物理層的控制符號就是上文介紹的幾種情況，關于并行物理層的控制符號不屬于本文的討論范圍，感興趣的請閱讀RapidIO官方手冊（參考文獻1）的第209頁。為了便于大家以后的查看，下面列出一張比較精簡的控制符號的圖方便大家快速的查看各個字段的意義。
上圖列出的是短控制符號的定義。右下角關于K碼的內容請看下一篇博客。上篇文章和這篇文章講的都是Rapid協議相關的東西，可能比較抽象，仍然不知道在FPGA里面如何實現RapidIO協議。我建議大家初學RapidIO協議可以把這兩篇文章和下一篇文章快速瀏覽一遍對相關的包和控制符號的概念有個印象即可，等你自己最后把所有的事務都在Vivado里面仿過一遍以后再回過頭來看這些東西就覺得很合理了。
五、參考資料
1、RapidIO?Interconnect Specification，下載鏈接 https://pan.baidu.com/s/1ek-3AAhetLAcxTuOE2IyMg
3、Xilinx的pg007_srio_gen2，下載地址 https://china.xilinx.com/support/documentation/ip_documentation/srio_gen2/v4_0/pg007_srio_gen2.pdf
編輯：黃飛
?
工商網監
評論