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