【高速介面-RapidIO】4、Xilinx RapidIO核詳解
一、RapidIO核概述
RapidIO核的設計標準來源於RapidIO Interconnect Specification rev2.2，它支援1x，2x和4x三種模式，每通道的速度支援1.25Gbaud，2.5Gbaud，3.125Gbaud，5.0Gbaud和6.25Gbaud五種。
RapidIO核分為邏輯層（Logical Layer），緩衝（Buffer）和物理層（Physical Layer）三個部分。其中邏輯層（Logical Layer）支援發起方（Initiator）和目標方（Target）同時操作；支援門鈴事務（DOORBELL）和訊息事務（MESSAGE），為維護事務（MAINTENANCE）設計了專用的埠；採用AXI4-Lite介面和AXI4-Stream介面，支援簡單的握手機制去控制資料流；支援可程式設計的Source ID，支援16-bit的device IDs（可選）。緩衝層（Buffer）支援8，16和32包的獨立可配置的TX和RX Buffer深度；支援獨立的時鐘，支援可選的傳送資料流控制。物理層（Physical Layer）支援可配置的空閒序列1和空閒序列2；支援關鍵請求流（Critical Request Flow）；支援多播事件。
注意：上面的幾個專業術語的解釋都能在前幾篇部落格中找到解釋，不明白的可以回過頭去看看。
RapidIO互連架構，與目前大多數流行的整合通訊處理器、主機處理器和網路數字訊號處理器相容，是一種高效能、包交換的互連技術。它能夠滿足高效能嵌入式工業在系統內部互連中對可靠性、增加頻寬，和更快的匯流排速度的需求。
RapidIO標準定義為三層：邏輯層、傳輸層和物理層。邏輯層定義了總體協議和包格式。它包括了RapidIO裝置發起和完成事務的必要資訊。傳輸層提供了RapidIO包傳輸過程中的路由資訊。物理層描述裝置級介面細節，例如包傳輸機制、流控、電氣特性和低階錯誤管理。這種劃分不需要對傳輸層或物理層規範進行修改，就可以靈活的給邏輯層規範新增新的事務型別。
整個RapidIO核的架構如下圖所示：
二、RapidIO核介面說明
RapidIO核把三個子核封裝在一起，它提供了一個高層次，低維護的介面。本節介紹了RapidIO各個子核和介面的基本功能檢視。RapidIO核的頂層框圖如下圖所示
2.1 邏輯層介面
邏輯層（LOG）被劃分成幾個模組來控制並解析傳送和接收資料包。邏輯層（LOG）有三個介面：使用者介面（User Interface），傳輸介面（Transport Interface）和配置介面（Configuration Fabric Interface）。
下圖是邏輯介面的示意圖
使用者介面包括能發起和接收包的埠。當生成IP核的時候可以配置埠的數目和事務型別，同時也能通過AXI4-Lite介面發起維護事務對本地或者遠端的暫存器進行訪問與配置。
傳輸介面包含傳送和接收兩個埠，它是用來連線中間的Buffer，對於RapidIO的頂層模組來說，這兩個介面不可見。
配置介面也包含兩個埠。其中配置主機埠（Configuration Master Port）用來讀寫本地配置空間。邏輯配置暫存器埠（LOG Configuration Register Port），它可以用來讀寫一部分邏輯層或傳輸層配置暫存器。
對於RapidIO IP核來說，使用者最需要關注的就是使用者介面，下面著重介紹使用者介面的相關內容。
使用者介面包含I/O埠集和三個可選的埠，三個可選的埠分別為訊息埠（Messaging Port），維護埠（Maintenance Port）和使用者自定義埠（User-Defined Port）。這些介面都在模組的頂層，每種事務型別都在指定的埠上傳輸。其中，任何支援的I/O事務例如NWRITEs，NWRITE_Rs，SWRITEs，NREADs和RESPONSEs（不包括維護事務的responses）全部都在I/O埠上傳送或者接收。訊息（Message）事務能在I/O埠傳輸或者在訊息埠傳輸，這取決於是否在IP核的配置選擇分離I/O埠與Message埠。門鈴（Doorbell）事務只能在I/O埠傳輸，而不能在Message埠上傳輸。維護事務包只能在維護埠上傳輸。如果事務是由使用者自定義的一種不支援的型別，那麼這類事務就可以在使用者自定義埠上傳輸，如果使用者自定義的埠在IP核的配置中未使能，那麼使用者自定義的包會被丟棄。
I/O埠（I/O Port）
I/O埠能被配置為兩種型別：Condensed I/O或Initiator/Target。這兩種型別可以在IP核的配置中進行選擇。I/O埠的資料流協議是AXI4-Stream協議，它支援兩種型別的包格式，分別是HELLO格式與SRIO Stream格式。
Condensed I/O埠型別減少了用於傳送和接收I/O包的埠數目。它只用一個AXI4-Stream通道來發送所有型別的包，同樣，也只用一個AXI4-Stream通道去接收所有型別的包。Condensed I/O埠示意圖如下
Initiator/Target埠型別把請求事務與響應事務分別處理，所以一共有4個AXI4-Stream通道用於I/O事務的傳輸。Initiator/Target埠的示意圖如下圖所示，其中灰色的箭頭表示請求事務，黑色的箭頭表示響應事務。
本地裝置（Local Device）生成的請求（Requests）通過ireq通道傳送，遠端裝置（Remote Device）產生的響應包通過iresp通道接收來完成整個事務的互動過程。
遠端裝置（Remote Device）生成的請求（Requests）通過treq通道接收，本地裝置（Local Device）產生的響應包通過tresp通道傳送來完成整個事務的互動過程。
在頂層模組中，變數名與通道的對應關係如下：
s_axis_ireq* 對應於ireq通道
m_axis_iresp* 對應於iresp通道
m_axis_treq* 對應於treq通道
s_axis_tresp* 對應於tresp通道
訊息埠（Messaging Port）
訊息埠是一個可選的介面，訊息事務既能在I/O埠上傳送，也能在獨立的訊息埠上傳送。獨立的訊息埠型別為Initiator/Target型別。下圖是訊息埠的示意圖
本地裝置（Local Device）生成的請求（Requests）通過msgireq通道傳送，遠端裝置（Remote Device）產生的響應包通過msgiresp通道接收來完成整個事務的互動過程。
遠端裝置（Remote Device）生成的請求（Requests）通過msgtreq通道接收，本地裝置（Local Device）產生的響應包通過msgtresp通道傳送來完成整個事務的互動過程。
在頂層模組中，變數名與通道的對應關係如下：
s_axis_msgireq* 對應於msgireq通道
m_axis_msgiresp* 對應於msgiresp通道
m_axis_msgtreq* 對應於msgtreq通道
s_axis_msgtresp* 對應於msgtresp通道
使用者自定義埠（User-Defined Port）
使用者自定義埠是一個可選的埠，它包括兩個AXI4-Stream通道，一個用於傳送另一個用來接收。使用者自定義埠僅僅支援SRIO Stream格式的事務。下圖是使用者自定義埠的示意圖
在頂層模組中，變數名與介面的對應關係如下：
s_axis_usrtx* 對應於user_io_tx介面
m_axis_usrrx* 對應於user_io_rx介面
維護埠（Maintenance Port）
維護埠使用的是AXI4-Lite介面協議，AXI4-Lite介面允許使用者訪問本地或遠端配置空間。下圖是AXI4-Lite維護埠示意圖
上圖中從右到左的黑色箭頭表示請求（Requests）通道，從左到右的灰色箭頭表示響應（Responses）通道。每個通道有獨立的ready/valid握手訊號。
狀態（Status）
維使用者介面的狀態訊號包括deviceid和port_decode_error，定義如下表所示
| 訊號 |
方向 |
描述 |
| deviceid[15:0] |
輸出 |
Base DeviceID CSR（偏移地址為0x60）暫存器的值 |
| port_decode_error |
輸出 |
此訊號為高說明使用者自定義埠未使能，一個不支援的事務被接收並立即丟棄。當下一個支援的事務包在任意使用者介面被接收以後此訊號被拉低。這個訊號同步於log_clk訊號 |
2.2 Buffer介面
Buffer的目的是對傳送和接收的包進行緩衝。Buffer對於保證包傳送和流控操作是非常有必要的，Xilinx提供了一個可配置的Buffer解決方案，可以在系統性能和資源利用率之間權衡選擇。
傳送Buffer負責把將要發出去的事務放到佇列中，並對發往物理層（PHY）的包流進行管理。接收Buffer和傳送Buffer的大小可以在IP核中配置為8、16或32個包的深度。傳送Buffer是一個儲存和轉發緩衝區，它是用來降低包到包的延遲以最大化流吞吐量。傳送Buffer必須儲存每個包直到包被接收方成功接收，當接收方成功接收包以後，傳送Buffer才會釋放包來給其他包騰出空間。當流控（Flow Control）發生時，通常會有多個未傳送的包滯留在傳送Buffer中，傳送Buffer會根據包的型別與優先順序進行重新排序，然後按照響應包先發送，請求包後傳送的順序把傳送Buffer中的包依次發出去。Buffer的另一個作用是處理跨時鐘域的問題，當生成IP核的時候可以根據需求新增或者移除跨時鐘域邏輯。對於多通道的RapidIO來說，由於物理層的時鐘在start-up場景和traindown場景是動態的，所以推薦把跨時鐘域邏輯加上，這樣可以保證使用者邏輯工作在已知的速率上。
接收Buffer類似於一個FIFO，它用來儲存和轉發接收通路上傳送給邏輯層的資料。接收Buffer也包含跨時鐘域邏輯，這可以保證邏輯層和物理層工作在不同的速率上，和傳送Buffer一樣，對於多通道RapidIO，推薦加上跨時鐘域邏輯。
所有Buffer層的介面對於RapidIO頂層都是不可見的。Buffer層示意圖如下
由上圖可知，在Buffer層的邏輯層與物理層兩側均有兩個AXI4-Stream通道，一個為傳送通道，另外一個為接收通道。還有一個AXI4-Lite通道用於去配置Buffer層的配置空間。
2.3 物理層介面
物理層（PHY）用來處理鏈路訓練（Link Training），初始化（Initialization）和協議（Protocol），同時還包括包迴圈冗餘校驗碼（CRC）與應答識別符號的插入。物理層介面與高速序列收發器相連。序列收發器在IP核中被設計為一個外部的例化模組以降低使用者使用模型的難度。物理層介面的示意圖如下圖所示
物理層與Buffer層通過兩個AXI4-Stream通道相連，同時物理層有一個通道的AXI4-Lite介面與配置結構相連，可以通過這個通道訪問物理層的配置空間。物理層還通過一個序列介面（Serial Interface）與序列收發器（Serial Transceivers）相連。
2.4 暫存器空間
RapidIO的暫存器空間如下表所示
能力暫存器空間（Capability Register Space）
能力暫存器空間的暫存器是隻讀暫存器，它們在邏輯層中實現。能力暫存器對映表如下表所示
命令和狀態暫存器空間（Command and Status Register Space）
命令和狀態暫存器空間的暫存器和能力暫存器一樣都在邏輯層實現，命令和狀態暫存器空間的對映表如下表所示
暫存器空間還包括Extended Feature Space與Implementation-defined Space兩種，關於這兩種暫存器空間的說明請檢視pg007_srio_gen2.pdf。
三、使用RapidIO核
3.1 設計指南
RapidIO協議定義了七種事務型別，每種事務型別執行不同的功能。RapidIO包格式中的FTYPE欄位與TTYPE欄位共同確定了事務的型別，與標準RapidIO協議不同的是，RapidIO核中定義了第9類事務（FTYPE=9）——DATA STREAMING事務，它是一類帶有資料負載的寫事務，而標準RapidIO協議中第9類事務是保留事務。詳細的對應關係如下表所示
| 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 |
—— |
DATA Streaming |
資料流寫，請求事務包含有效資料 |
| 10 |
4’bxxxx |
DOORBELL |
門鈴 |
| 11 |
4’bxxxx |
MESSAGE |
訊息 |
| 12 |
—— |
Reserve |
無 |
| 13 |
4’b0000 |
RESPONSE no data |
不帶有效資料的響應包 |
| 4’b1000 |
RESPONSE with data |
帶有效資料的響應包 |
|
| 14~15 |
—— |
Reserve |
無 |
邏輯層AXI4-Stream序列RapidIO介面用法
RapidIO核事務收發介面採用的協議是AXI4-Stream協議。AXI4-Stream協議用ready/valid握手訊號在主從裝置之間傳輸資訊。AXI4-Stream協議用tlast訊號指示傳輸的最後一個數據從而確定包的邊界，用tkeep位元組使能訊號指示資料中的有效位元組，它還包括有效資料tdata訊號以及使用者資料tuser訊號用來傳輸實際的包資料。
HELLO包格式（重點）
為了簡化RapidIO包的構建過程，RapidIO核的事務傳輸介面（ireq，treq，iresp，tresp）可以配置為HELLO（Header Encoded Logical Layer Optimized）格式。這種格式把包的包頭（Header）域進行標準化，而且把包頭和資料在介面上分開傳輸，這將簡化控制邏輯並且允許資料與傳送邊界對齊，有助於資料的管理。
HELLO格式的包如下圖所示
其中，各個欄位的定義如下表所示
| 欄位 |
位置 |
描述 |
| TID |
[63:56] |
包的事務ID（Transaction ID），RapidIO手冊規定在給定的時機，RapidIO包只能有唯一的TID與Src ID對。 |
| FTYPE |
[55:52] |
包的事務類（Transaction Class），HELLO格式支援的FTYPEs為2,5,6，A，B和D。 |
| TTYPE |
[51:48] |
包的事務型別（Transaction Type），當FTYPE的值為2,5或D時，不同的TTYPE值對應於包的不同功能。 |
| Priority |
[46:45] |
包的優先順序。請求包的優先順序值為0~2，響應包的優先順序值為請求包的優先順序加1 |
| CRF |
[44] |
包的關鍵請求流標誌（Critical Request Flow） |
| Size |
[43:36] |
有效資料負載的位元組數減1，如果這個欄位的值為0xFF，那麼表示有效資料為256（0xFF + 1）個位元組 |
| Error |
[35] |
當這個欄位為1時表示包處於錯誤狀態 |
| Address |
[33:0] |
事務的位元組地址 |
| Info |
[31:16] |
資訊域。僅在門鈴事務（DOORBELL）中包含此欄位 |
| Msglen-1 |
[63:60] |
訊息事務（MESSAGE）中包的個數。僅在訊息事務（MESSAGE）中包含此欄位 |
| Msgseg-1 |
[59:56] |
包中的訊息段，僅在訊息事務（MESSAGE）中包含此欄位，如果是單段（signal-segment）訊息，此欄位保留 |
| Mailbox |
[9:4] |
包的目標郵箱，僅在訊息事務（MESSAGE）中包含此欄位，除了單段（signal-segment）訊息以外，此欄位的高四位是保留位 |
| Letter |
[1:0] |
包的信件，僅在訊息事務（MESSAGE）中包含此欄位，指示了郵箱中的一個插槽 |
| S,E,R,xh,O,P |
[63:56] |
S：起始位，當此欄位為1時表示這個包是新PDU（Protocol Data Unit）的第一個分段。 E：結束位，當此欄位為1時表示這個包是新PDU（Protocol Data Unit）的最後一個分段。當S和E均為1時表示PDU僅包含一個包。 R：保留位。 Xh：擴充套件頭（Extended Header）。目前版本不支援 O：奇數（Odd），當此欄位為1時表示資料負載有奇數個半字。 P：填充位（Pad）。當此欄位為1時，一個填充位元組用於去填充資料到半字（half-word）邊界 |
| Cos |
[43:36] |
服務類（Class of service） |
| StreamID |
[31:16] |
點到點的資料流識別符號 |
| Length |
[15:0] |
協議資料單元（Procotol Data Unit，PDU）長度 |
HELLO格式的包中Size域的值等於傳輸的位元組的總數減1，Size域的有效值範圍為0~255，對應於實際傳輸的位元組數量1~256。HELLO格式中的size和address域必須對應於RapidIO包中有效的size，address和wdptr域，所以HELLO格式的size和address欄位的值存在一些限制條件。RapidIO核不能把Size域中的非法值修正為實際RapidIO包中Size域的有效值，所以需要對HELLO格式包的Size域提供一個正確的值。由於AXI4-Stream協議中tdata訊號為8個位元組，也就是一個雙字（Double Word），所以Size域的值需要分兩種情況討論：傳輸的資料量小於8位元組和傳輸的資料量大於8位元組。
傳輸的資料量小於8位元組（Sub-DWORD Accesses）：
對於傳輸的資料量小於8位元組的情況，address欄位和size欄位用來決定有效的位元組位置（tkeep訊號必須為0xff），但是僅僅能導致RapidIO包中rdsize/wrsize和wdptr為有效值的address和size值組合才是被允許的，下圖是HELLO格式中address和size兩個欄位與有效位元組位置的對應關係示意圖（圖中灰色部分為有效位元組位置）
例如，對size=2，address=34’h1_1234_5675這兩個組合來說，由於size=2，所以往address中寫入的資料個數為3（size+1）個位元組，而address的最低3位為5(3’b101)，通過上圖可知，有效位元組的位置是第7、6、5三個位元組。對於size和address[2:0]值的組合不在上圖中的情況都是非法的，這是應該避免的，比如，size=2， address=34’h1_1234_5673這種組合就屬於非法的組合。
傳輸的資料量大於8位元組（Large Accesses）：
對於傳輸的資料量大於8位元組，並且地址的起始位元組偏移不為0的情況必須把資料分成多次進行傳輸，其中未對齊的小於8位元組的段就可以通過上圖中size和address的有效組合來確定有效位元組的位置。另一種解決辦法是，讀操作的資料量大小可以被增加到下一個支援的大小，然後從對應的響應中剝離出必要的資料。
因此，對於資料量為1個雙字（8個位元組）或更大的情況，address的最低3位必須為0，RapidIO手冊給讀寫事務定義了範圍從1到256個位元組的可支援的資料量。請求事務的資料量如果大於一個雙字（8個位元組），那麼資料量應該通過四捨五入到最接近的支援的值。讀寫事務有效的HELLO格式的資料量為：7，15,31,63,95（僅支援讀事務），127,159（僅支援讀事務），191（僅支援讀事務）,223（僅支援讀事務）和255。
對於寫事務的資料量介於以上這些支援的資料量中間的情況，在通道的tlast訊號為1之前應該給RapidIO核提供必要的資料量，僅僅提供的資料才能被髮送。同理，使用者的設計提供的資料可能少於期望的資料量，那麼實際的資料量應該被寫入，傳輸應該假設完成。
RapidIO協議不支援傳輸的資料量大於256位元組的情況，並且邏輯層（Logical）也不能把大於256位元組的資料量分割為小的資料量進行傳送。如果不滿足這個要求可能會導致致命的鏈路錯誤，在這種錯誤情況下，鏈路可能會不斷重傳資料量大於256位元組的包。
HELLO格式資料的包頭（Header）在使用者介面的第一個有效時鐘上，如果傳送的事務攜帶資料負載，那麼資料負載緊接著包頭（Header）後面進行連續傳送。包的Source ID和Destination ID放在tuser訊號中並與包頭（Header）一樣，在第一個有效時鐘下進行傳送，傳送完畢以後，tuser訊號的資料被忽略。
下圖是攜帶有資料負載HELLO格式包在使用者介面上傳輸的時序圖，這個傳輸有4個雙字（32個位元組）的資料負載，加上包頭，整個傳輸一共花費了5個時鐘週期。使用者只需要把想要傳送的資料按照下圖的時序圖送入RapidIO核的AXI4-Stream介面，RapidIO核就能把它轉化為標準的RapidiO序列物理層的包發出去從而完成一次事務的互動。
下圖是一種更復雜的傳輸示意圖。首先，有兩個背靠背（back-to-back）單週期包（包不帶資料負載，僅包含一個包頭）。包的邊界通過拉高tlast訊號進行指示。在單週期包傳輸完畢以後，主機等待了一個時鐘週期才開始傳送下一個包。在傳送第三個包的過程中，主機（Master）和從機（Slave）分別通過拉低tvalid和tready訊號一個時鐘週期來暫停資料的傳送，由於第三個包的資料負載為2個雙字，所以傳輸第三個包一共消耗了3個有效時鐘，加上2個無效的時鐘週期，一共消耗了5個時鐘週期。
SRIO Stream包格式
使用者介面也能配置為SRIO Stream格式，在這種格式下，使用者介面的包格式各個欄位的定義與RapidIO手冊中標準的RapidIO包中邏輯層和傳輸層各個欄位的定義完全相同，但使用者介面的包格式中還包括標準RapidIO包物理層的prio欄位，整個SRIO Stream的包格式如下圖所示
下圖是SRIO Stream格式的包在使用者介面上傳輸的時序圖，整個傳輸的資料負載為5個雙字，一共消耗了5個有效時鐘週期，CRF/Response位在第一個有效時鐘週期進行傳輸。
SRIO Stream格式用的不多，所以並非本文的重點，更多詳細的內容請檢視pg007_srio_gen2.pdf的第80頁到82頁。
訪問配置空間
每個通過RapidIO連線的處理器單元都有能力暫存器（Capability Register，CARs）和命令狀態暫存器（Command and Status Register，CSRs），可以通過訪問這些暫存器去配置裝置的Capability和Status等相關資訊。配置暫存器的長度都為32-bits，所有的配置暫存器進行讀寫訪問時的地址增量為4個位元組，讀寫保留暫存器正常情況下不會導致裝置進入錯誤狀態，同理，寫CARs（只讀暫存器）正常情況也不會進入錯誤狀態。
維護寫操作例子
對於寫事務，在發起寫事務之前，寫地址和寫資料必須在它們各自維護埠通道上進行傳輸。當邏輯層接收到響應以後，維護埠會在寫響應通道上返回一個狀態。維護埠一次只能處理一個寫事務，在響應傳送完成之前，新的地址和資料不會被接收。下圖是維護埠上完成兩次寫事務的時序圖，因為地址和資料在不同的通道上，所以它們能在通道的任意時刻進行傳輸而不用考慮另外一個
維護讀操作例子
當讀地址在維護埠上進行傳輸後讀事務被立即發起，邏輯層接收到響應以後，維護埠在讀響應通道返回一個狀態。維護埠一次只能處理一個讀事務，在響應傳送完成之前，新的地址不會被接收。下圖是一個讀事務的時序圖
更多通過維護事務訪問暫存器空間的內容請檢視pg007_srio_gen2.pdf的第82頁到91頁。
3.2 時鐘
物理層有兩個時鐘域，第一個是phy_clk，它是最主要的核時鐘，第二個是gt_pcs_clk，它是用於序列收發介面（Serial Transceiver interface）。時鐘gt_clk並未被物理層使用，而是被序列收發介面所使用。gt_pcs_clk的頻率為gt_clk的一半。一般來說，phy_clk與gt_clk的關係如下：
phy_clk = （gt_clk * LW） / 4
其中LW指的是鏈路寬度（Link Width），所以對於操作在2x模式（二通道模式）的核來說，LW的值為2，phy_clk的頻率是gt_clk頻率的一半。序列收發器需要通過專用時鐘引腳提供參考時鐘refclk，參考時鐘的頻率需要在生成RapidIO核的時候進行配置，可選擇的參考時鐘頻率取決於RapidIO核的結構與線速率。下表列出了參考時鐘頻率與線速率的關係
邏輯層工作在log_clk這個時鐘域。為了保證最優的吞吐量，log_clk的頻率應該大於或等於phy_clk的頻率。下面列出了三種不同通道模式下線速率與時鐘頻率的關係
4x模式（4通道模式）
2x模式（2通道模式）
1x模式（1通道模式）
對於7 Series FPGAs來說，內部採用了一個MMCM從參考時鐘refclk得到RapidIO核各個模組的時鐘，整個時鐘方案的框圖如下圖所示
MMCM的倍頻值與分頻值取決於參考時鐘的頻率與線速率。在4x模式（四通道模式）下，log_clk和gt_clk共享一個BUFG。在1x模式（單通道模式）下，log_clk和phy_clk共享一個BUFG（由於phy_clk的頻率只有一種情況，所以不需要BUFGMUX）。除此以外，如果在RapidIO核的配置中選中了Unified Clock選項，則log_clk和phy_clk要求有相同的頻率，這意味著與log_clk/cfg_clk相關的BUFG能被移除，log_clk/cfg_clk與phy_clk相連。
3.3 復位
每個時鐘域都有相關聯的復位訊號。復位訊號應該至少在各自的時鐘域中保持4個時鐘週期，如果RapidIO核的通道寬度減少導致phy_clk的時鐘頻率降低，那麼復位訊號仍然需要保持至少4個時鐘週期。復位參考設計模組（srio_rst.v）有一個單復位輸入sys_rst。這個訊號同步於輸入。這個模組同步復位訊號到每個時鐘域並對復位脈衝進行擴充套件以滿足最小4個時鐘週期的要求。
硬體復位應該被使用者設計產生，當復位RapidIO核的時候必須要注意主機和從機必須同時復位以保證ackID欄位對齊，推薦主機和從機的復位訊號完全重疊以減少包和控制符號的丟失率。
3.4 RapidIO協議簡介
RapidIO的協議已經在這個系列的前面幾篇文章中做了很多介紹了，這裡僅僅做一個總結。
第2類事務（FTYPE=2）為請求類事務，根據TTYPE欄位的不同值，它包括NREAD事務（TTYPE=4’b0100），ATOMIC Increment事務（TTYPE=4’b1100），ATOMIC Decrement事務（TTYPE=4’b1101），ATOMIC Set事務（TTYPE=4’b1110），ATOMIC Clear事務（TTYPE=4’b1111）這幾種。
第5類事務（FTYPE=5）為寫類事務，根據TTYPE欄位的不同值，它包括NWRITE事務（TTYPE=4’b0100），NWRITE_R事務（TTYPE=4’b0101），ATOMIC Swap事務（TTYPE=4’b1100），ATOMIC Compare-and-Swap事務（TTYPE=4’b1101），ATOMIC Test-and-Swap事務（TTYPE=4’b1110）這幾種。
第6類事務（FTYPE=6）為SWRITE事務（流寫事務），請求方可以利用流寫事務往目標方的儲存空間寫入大塊資料。與NWRITE相比，流寫事務具備以下兩個特點：1、流寫事務傳輸資料的最小單位為雙字（Double Word）；2、流寫事務的包格式相對於NWRITE包格式具有更少的頭部開銷。
第10類事務（FTYPE=10）為DOORBELL事務（門鈴事務），門鈴事務不包含資料負載，它只能用來傳輸16-bit的資訊，所以DOORBELL事務適合傳輸中斷或者訊號量。
第11類事務（FTYPE=11）為MESSAGE事務（訊息事務），訊息事務必須攜帶資料負載，完成一次資料訊息操作最多需要16個單獨的訊息事務，其中每個訊息事務攜帶的資料負載最大仍為256位元組，所以訊息操作的最大資料載荷為4096位元組（16*256 Bytes）。
第13類事務（FTYPE=13）為響應類事務，根據TTYPE欄位的不同值，它包括不帶資料響應事務（TTYPE=4’b0000），訊息響應事務（TTYPE=4’b0001）和攜帶資料響應事務（TTYPE=4’b1000）。
第9類事務（FTYPE=9）為Data Streaming事務，在標準的RapidIO協議中第9類事務為保留事務，所以第9類事務是一種自定義的事務。關於第9類事務的詳細內容請檢視pg007_srio_gen2.pdf的第106頁。
四、RapidIO核配置
1、在IP Catalog中找到RapidIO
2、雙擊RapidIO核開啟配置介面
3、選擇Mode為Advanced
Component Name：IP的的名字，只能為字母，數字，下劃線，其中首字元必須為字母。
Mode：IP的模式，有基本（Basic）和高階（Advanced）兩種。
Link Width：鏈路寬度，可選值為1、2或者4，鏈路寬度越大，資料的傳輸頻寬越大。
Transfer Frequency：傳輸頻率，這個值表示的是每個序列鏈路的傳輸速率，可選值有1.25、2.5、3.125、5.0和6.25。傳輸頻率越大，資料的傳輸頻寬越大。
Reference Clock Frequency：參考時鐘頻率，可選值為125MHz或156.25MHz，它指的是外部時鐘源（晶振或者鎖相環晶片）送給FPGA序列收發器專用時鐘引腳的時鐘。
TX Buffer Depth：傳送Buffer的深度，可選值為8、16或32。這個值表示的是傳送Buffer中可儲存的包的最大數目。
RX Buffer Depth：接收Buffer的深度，可選值為8、16或32。這個值表示的是接收Buffer中可儲存的包的最大數目。
Component Device ID：這個引數是復位以後Base Device ID CSR暫存器的復位值。
Device ID Width：裝置ID的寬度，收發雙方的裝置ID寬度應該相同，否則，由於包頭的偏移可能會導致事務被錯誤的解釋。大多數系統Device ID為8位，但是RapidIO核也提供了16位的Device ID供使用者選擇。
Unified Clock：如果使用者設計中log_clk和phy_clk相同，那麼可以選中這個選項，選中這個選項可以減少延時和資源利用率。
Transmitter Controlled：選中這個選項以後，RapidIO核會首先嚐試用transmitter-controlled實現流控，但如果接收方不支援的話那麼會自動切換為receiver-controlled。transmitter-controlled流控可以利用接收buffer的狀態和水印最小化重試條件。receiver-controlled流控會隨意的發包並使用重試協議。
Receiver Controlled：選中這個選項以後，RapidIO核僅能用receiver-controlled實現流控，在這種模式中，receiver-controlled流控會隨意的發包並使用重試協議。
4、Logical Layer標籤
Source （Initiator） Transaction Support：用來選擇支援的傳送事務型別。
Destination（Target） Transaction Support：用來選擇支援的接收事務型別。
Enable Arbitration：用來使能邏輯層與輸入埠之間的仲裁器。
Maintenance Transaction Support：這個選項應該保持一直使能。
Local Configuration Space Base Address：本地配置空間基地址，選中這個選項後，RapidIO會檢查I/O事務的高地址位，如果地址匹配，那麼會把事務發給維護埠。由於手冊沒有提供一種機制去關閉LCSBA，所以在這種情況下系統的行為是未定義的。
5、I/O標籤
Port I/O Style：I/O介面可以配置為Condensed I/O和Initiator/Target兩種型別。其中Condensed I/O接收和傳送均使用一個AXI4-Stream通道。Initiator/Target接收和傳送採用不同的AXI4-Stream通道。
I/O Format：I/O埠能被配置使用HELLO格式包或SRIO Stream格式包，一般情況下，強烈推薦使用HELLO格式
Messaging：用來選擇訊息事務的埠，可選的引數有Combined with IO和Separate Messaging Port兩種。Combined with IO選項表明訊息事務和I/O寫事務採用相同的IO埠，Separate Messaging Port選項表明訊息事務採用一個獨立的埠傳輸，選中這個選項以後IP核會出現訊息事務的AXI4-Stream通道。
Maintainance：用來選擇維護埠型別，維護埠型別只能為AXI4-Lite型別。
6、Buffer層標籤
Request Reordering：選中這個選項以後，傳送Buffer會根據請求包的優先順序重新排序。
Flow Control Options：用來選擇優先順序水印復位值，詳細內容請檢視pg007_srio_gen2.pdf
7、物理層標籤
CRF Support：關鍵請求流（Critical Request Flow），一般不選中
Link Requests before Fatal：用來指定鏈路進入致命錯誤狀態之前鏈路請求的個數，一般選擇預設值
Software Assisted Error Recovery：RapidIO協議定義了3個CSRs用軟體來輔助錯誤恢復。
IDLE Mode Support：空閒模式（IDLE Mode）的選擇與傳輸速率有關，空閒序列1（IDLE1）僅僅支援每通道線速率小於5.5Gbps的情況，選擇空閒序列1時，RapidIO使用的控制符號為短控制符號。空閒序列2（IDLE2）支援每通道線速率大於5.5Gbps的情況，6.25Gbps的線速率必須選擇空閒序列2，空閒序列2提供了一些附加的功能，比如鏈路寬度，鏈路優先順序資訊以及一些用於改善均衡器效能，提高資料恢復率的隨機數。當IDLE1和IDLE2均被選中時，每通道線速率僅支援小於等於5.5Gbps的情況。上一篇文章《RapidIO序列物理層的包傳輸過程》也介紹了空閒序列1和空閒序列2相關的內容。
8、邏輯層暫存器標籤
Device Identity CAR：指定了Device ID與Vendor ID，這兩個值不能修改。
Assembly Identity CAR：可通過設定這兩個值唯一的確定RapidIO裝置的識別符號。這兩個值不影響核的功能。
Assembly Information CAR：這個暫存器儲存的是RapidiO子系統的版本資訊，這個值不影響核的功能。
Processing Element Features CAR：選擇儲存器單元的主功能，預設為Memory，這個值不影響核的功能。
9、物理層暫存器標籤
Extended Features Space：擴充套件特徵空間，一般選擇預設值。
Port Link Time-out Control CSR：指定鏈路控制符號丟失後的超時時間，最大值為0xFFFFFF，對應的超時時間約為4.5s，精確度為33%
Port Response Time-out Control CSR：指定鏈路包丟失後的超時時間，最大值為0xFFFFFF，對應的超時時間在3s到6s之間。
Port General Control CSR：Host選項表明RapidIO裝置是主裝置，這個選項不影響核的功能。Master Enable選項用來控制是否允許RapidiO核發起請求事務，如果未選中，RapidIO核只能發起響應事務而不能發起請求事務。Discovered選項表明RapidIO核能被處理器定位，這個選項不影響核的功能。
10、共享邏輯標籤
當選中Include Shared Logic in Example Design選項時，MMCM、復位邏輯和GT COMMON塊等共享邏輯被包含在例子設計中。當選中Include Shared Logic in Core選項時，MMCM、復位邏輯和GT COMMON塊等共享邏輯被包含在IP核中。
五、總結
整個RapidIO核的介紹到此為止，文中大部分內容都是翻譯的pg007_srio_gen2.pdf，由於自身水平有限，所以有些地方可能翻譯的不太好，建議大家先粗略瀏覽對相關內容有一個大致印象，然後把不明白的地方對照pg007_srio_gen2.pdf原文做進一步理解。
整片文章的重點只有一個，就是設計指南那一節所提到的HELLO格式與HELLO格式的時序，強烈建議對照pg007_srio_gen2.pdf文件多讀幾遍。 事實上，在編寫Verilog程式碼時，就是先根據事務型別組裝對應的HELLO格式的包頭（Header），然後按照HELLO格式的時序，在第一個有效時鐘週期類把包頭（Header）發出去，後面幾個有效的時鐘週期傳送你的資料。在這個過程中，RapidIO核會自動把HELLO格式的包轉化為標準的RapidIO序列物理層的包，並新增控制符號，空閒序列等必要資訊發出去，接收過程則正好相反，RapidIO核接收到標準的RapidIO序列物理層的包，控制符號，空閒序列等資訊後以後，會把接收的資訊轉化為HELLO格式的包給使用者做後續處理。所以對使用者來說只需要理解HELLO格式包的組成與HELLO格式的時序就可以利用RapidIO核實現資料的高速傳輸，而不需要關注RapidIO協議的過多細節。
最後，再來複習一下RapidIO序列物理層的包格式與控制符號來結束全文，下篇文章會教大家如何利用Xilinx官方提供的例子工程來理解請求事務與響應事務Verilog程式碼，並詳細分析各個事務的時序細節。
RapidIO序列物理層包格式：
控制符號：
六、參考資料
1、pg007_srio_gen2，下載地址 https://china.xilinx.com/support/documentation/ip_documentation/srio_gen2/v4_0/pg007_srio_gen2.pdf
2、RapidIO™ Interconnect Specification，下載連結 https://pan.baidu.com/s/1ek-3AAhetLAcxTuOE2IyMg