大家好，最近比較忙好久沒有更新了，今天分享一篇給大家，為了防止斷更，后續會分享更多的比較好的文章，文章出自哪里，本人都會標注清楚，分享僅僅用于交流學習，不用做任何商業行為，如有原作者對此有意見或者建議，可以和本欄專欄作者聯系。

本文鏈接地址：https://mp.weixin.qq.com/s/VR7rT-U9UeLwowQKKmlehg

一、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，定義如下表所示

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類事務是保留事務。詳細的對應關系如下表所示

邏輯層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格式的包如下圖所示

其中，各個字段的定義如下表所示

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串行物理層包格式：

控制符號：