4.Xilinx RapidIO核詳解

轉自https://www.cnblogs.com/liujinggang/p/10072115.html

1、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核的架構以下圖所示：

 

2、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核中配置爲八、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。

3、使用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)，經過上圖可知，有效字節的位置是第七、六、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相比，流寫事務具有如下兩個特色：一、流寫事務傳輸數據的最小單位爲雙字（Double Word）；二、流寫事務的包格式相對於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頁。

 

4、RapidIO核配置

　　一、在IP Catalog中找到RapidIO

 

　　

　　二、雙擊RapidIO核打開配置界面

 

　　三、選擇Mode爲Advanced

 

　　Component Name：IP的的名字，只能爲字母，數字，下劃線，其中首字符必須爲字母。

　　Mode：IP的模式，有基本（Basic）和高級（Advanced）兩種。

　　Link Width：鏈路寬度，可選值爲一、2或者4，鏈路寬度越大，數據的傳輸帶寬越大。

　　Transfer Frequency：傳輸頻率，這個值表示的是每一個串行鏈路的傳輸速率，可選值有1.2五、2.五、3.12五、5.0和6.25。傳輸頻率越大，數據的傳輸帶寬越大。

　　Reference Clock Frequency：參考時鐘頻率，可選值爲125MHz或156.25MHz，它指的是外部時鐘源（晶振或者鎖相環芯片）送給FPGA串行收發器專用時鐘引腳的時鐘。

　　TX Buffer Depth：發送Buffer的深度，可選值爲八、16或32。這個值表示的是發送Buffer中可存儲的包的最大數目。

　　RX Buffer Depth：接收Buffer的深度，可選值爲八、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流控會隨意的發包並使用重試協議。

　　四、Logical Layer標籤

 

　　Source （Initiator） Transaction Support：用來選擇支持的發送事務類型。

　　Destination（Target） Transaction Support：用來選擇支持的接收事務類型。

　　Enable Arbitration：用來使能邏輯層與輸入端口之間的仲裁器。

　　Maintenance Transaction Support：這個選項應該保持一直使能。

　　Local Configuration Space Base Address：本地配置空間基地址，選中這個選項後，RapidIO會檢查I/O事務的高地址位，若是地址匹配，那麼會把事務發給維護端口。因爲手冊沒有提供一種機制去關閉LCSBA，因此在這種狀況下系統的行爲是未定義的。

　　五、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類型。

　　六、Buffer層標籤

 

　　Request Reordering：選中這個選項之後，發送Buffer會根據請求包的優先級從新排序。

　　Flow Control Options：用來選擇優先級水印復位值，詳細內容請查看pg007_srio_gen2.pdf

　　七、物理層標籤

 

　　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相關的內容。

　　八、邏輯層寄存器標籤

 

　　Device Identity CAR：指定了Device ID與Vendor ID，這兩個值不能修改。

　　Assembly Identity CAR：可經過設置這兩個值惟一的肯定RapidIO設備的標識符。這兩個值不影響核的功能。

　　Assembly Information CAR：這個寄存器存儲的是RapidiO子系統的版本信息，這個值不影響核的功能。

　　Processing Element Features CAR：選擇存儲器單元的主功能，默認爲Memory，這個值不影響核的功能。

　　九、物理層寄存器標籤

 

　　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核能被處理器定位，這個選項不影響核的功能。

　　十、共享邏輯標籤

 

       當選中Include Shared Logic in Example Design選項時，MMCM、復位邏輯和GT COMMON塊等共享邏輯被包含在例子設計中。當選中Include Shared Logic in Core選項時，MMCM、復位邏輯和GT COMMON塊等共享邏輯被包含在IP核中。

 

5、總結

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

 

       控制符號：

 

6、參考資料

　　一、pg007_srio_gen2，下載地址 https://china.xilinx.com/support/documentation/ip_documentation/srio_gen2/v4_0/pg007_srio_gen2.pdf

　　二、RapidIO™ Interconnect Specification，下載連接 https://pan.baidu.com/s/1ek-3AAhetLAcxTuOE2IyMg