日本三级视频,啊啊啊啊AV,日本一二区18

1、Aurora 8B/10B 協(xié)議
Aurora 協(xié)議是一個用于在點對點串行鏈路間移動數(shù)據(jù)的可擴展輕量級鏈路層協(xié)議（由Xilinx開發(fā)提供）。這為物理層提供透明接口，讓專有協(xié)議或業(yè)界標準協(xié)議上層能方便地使用高速收發(fā)器。Aurora協(xié)議在Xilinx的FPGA上有兩種實現(xiàn)方式：8B/10B 與 64B/10B。兩個協(xié)議大部分相同，主要區(qū)別在編碼方式上：

Aurora 8B/10B：將8bit數(shù)據(jù)編碼成10bit數(shù)碼進行傳輸，盡量平衡數(shù)據(jù)中“0”和“1”的個數(shù)以實現(xiàn)DC平衡，顯然這個編碼方式的開銷是20%，也就是效率為80%
Aurora 64B/10B：將64bit數(shù)據(jù)編碼成66bit塊傳輸，66bit塊的前兩位表示同步頭，主要由于接收端的數(shù)據(jù)對齊和接收數(shù)據(jù)位流的同步。同步頭有“01”和“10”兩種，“01“表示后面的64bit都是數(shù)據(jù)，“10”表示后面的64bit是數(shù)據(jù)信息。數(shù)據(jù)信息0和1不一定是平衡的，因此需要進行加擾，開銷較小

Aurora 8B/10B 常用于芯片（FPGA）與芯片（FPGA）之間通信。它用于使用一個或多個收發(fā)器在設備之間傳輸數(shù)據(jù)。連接可以是全雙工（雙向數(shù)據(jù)）或單工。最多可實現(xiàn)16個收發(fā)器（GTX，GTP或GTH），吞吐量可從480 Mb / s擴展到84.48 Gb / s。Aurora核心吞吐量取決于收發(fā)器的數(shù)量以及所選收發(fā)器的線路速率。通過使用25％的開銷來計算吞吐量Aurora 8B / 10B協(xié)議編碼和以及線速0.5 Gb / s至6.6 Gb / s的線速范圍來計算，其傳輸吞吐量為從單通道設計的0.4 Gb / s到最高16通道的84.48 Gb / s。

下圖是一個典型的使用兩個全雙工模式、多條lane構成的Aurora 8B/10B 通信系統(tǒng)。

從上圖不難看出：

用戶使用用戶接口與Aurora 8B/10B IP核進行數(shù)據(jù)交互
Aurora 8B/10B IP核是全雙工模式，其數(shù)據(jù)通路由多條Lane組成
發(fā)送的數(shù)據(jù)通過Aurora IP核進行8B/10B編碼后，通過多條Lane發(fā)送到另一個Aurora IP核，該IP核通過用戶接口將接收到的數(shù)據(jù)發(fā)送給用戶

2、Aurora 8B/10B IP核
2.1、IP核組成

接下來我們看一下Aurora 8B/10B IP核的組成：

主要組成部分如下：

Lane Logic（通道邏輯）：每個GT收發(fā)器由通道邏輯模塊的實例驅動，其初始化每個單獨的收發(fā)器并處理控制字符的編碼和解碼以及錯誤檢測。
Global Logic（全局邏輯）：全局邏輯模塊執(zhí)行通道初始化的綁定和驗證。在運行期間，模塊會生成Aurora協(xié)議所需的隨機空閑字符，并監(jiān)視所有通道邏輯模塊的錯誤。
RX User Interface（RX接收端口）：AXI4-Stream RX接收端口將數(shù)據(jù)從通道移動到應用程序，并執(zhí)行流量控制功能。
TX User Interface（TX發(fā)送端口）：AXI4-Stream TX發(fā)送端口將數(shù)據(jù)從應用程序移動到通道，并執(zhí)行流量控制TX功能。標準時鐘補償模塊嵌入在內核中。該模塊控制時鐘補償（CC）字符的周期性傳輸。

看到這里基本就清楚了：Aurora 8B/10B是一個基于GT高速收發(fā)器（物理層）的全雙工點到點協(xié)議，GT高速收發(fā)器的每個Channel就是Aurora協(xié)議的一條Lane。

下圖是IP核的頂層結構示意圖，更好的說明了該IP核與GT高速收發(fā)器的關系。

2.2、延遲（Latency）
由于Aurora 8B/10B IP核的邏輯設計（流水線、編解碼等），用戶端發(fā)送給IP核的數(shù)據(jù)，需要一定的延遲才能通過IP核發(fā)送。這一延遲的近似值為37（2字節(jié)位寬）和41（4字節(jié)位寬），如下圖所示：

2.3、Throughput（吞吐率）：
Aurora 8B/10B IP核吞吐率取決于GT收發(fā)器的數(shù)量和線速率。單通道設計到16通道設計的吞吐率分別為0.4Gb/s到84.48Gb/s。通過Aurora 8B/10B協(xié)議編碼和0.5Gb/s至6.6 Gb/s線路速率范圍的20％開銷來計算吞吐率。

也就是說，使用的GT高速收發(fā)器的通道越多、且其支持的線速率越高，則整個Aurora 8B/10B IP核的吞吐率越高，但是要注意乘以80%，因為8B/10B編碼存在20%的開銷。

2.4、大小端
在IP核的定制中，有一個大小端的選擇問題。所謂的小端，就是我們最常見的多位數(shù)據(jù)定義方式：[n:0] 左邊是高位，右邊是低位，符合Verilog編寫習慣，大端反之。

2.5、數(shù)據(jù)發(fā)送、接收接口
Aurora 8B/10B IP核支持AXI4-Stream協(xié)議，并依據(jù)是否對AXI4-Stream協(xié)議進行再封裝來提供兩種數(shù)據(jù)傳輸接口：Framing 接口（幀傳輸接口）和Streaming接口（流傳輸接口）。

Framing接口（幀傳輸接口）：在AXI4-Stream的基礎上添加了幀頭、幀尾等控制信號，使得傳輸更準確，但是會降低傳輸效率和使用較多資源
Streaming接口（流傳輸接口）：基本上就是一個非常簡化的AXI4-Stream接口，只有數(shù)據(jù)有效、握手和數(shù)據(jù)信號，此種方式傳輸效率高，但無法保證傳輸?shù)臏蚀_性

關于AXI4-Stream協(xié)議可以參考：帶你快速入門AXI4總線--匯總篇（直達鏈接）

2.5.1、AXI4-Stream位排序(AXI4-Stream Bit Ordering)：
Aurora 8B / 10B IP核采用升序排列。首先發(fā)送和接收最高有效字節(jié)的最高有效位。下圖顯示了n字節(jié)的Aurora 8B / 10B IP核的AXI4-Stream數(shù)據(jù)接口示例。

2.5.2、Framing接口
Framing接口示意圖如下：

Framing接口由于存在frame（幀）的概念，所以接口信號較之Streaming接口要復雜一點，主要接口如下：

發(fā)送端（相對于用戶來說）：

接收端（相對于用戶來說）：

如果你熟悉AXI4-Stream協(xié)議的話，基本就能馬上上手數(shù)據(jù)的接收發(fā)送部分了。

發(fā)送數(shù)據(jù)

從發(fā)送端的幾個信號就可以判斷，當s_axi_tx_tready與s_axi_tx_tvalid握手成功后，即可發(fā)送數(shù)據(jù)
使用s_axi_tx_tlast來表示當前發(fā)送最后一個數(shù)據(jù)
s_axi_tx_tkeep來表示最后一個數(shù)據(jù)的有效字節(jié)（應用場景在發(fā)送奇數(shù)個字節(jié)時，IP核會自動添加一個pad到數(shù)據(jù)中，所以存在一個無效字節(jié)需要指出），這一點倒是與AXI4-Stream協(xié)議不太一樣

接收數(shù)據(jù)

接收數(shù)據(jù)不需要握手過程
當m_axi_rx_tvalid為高時，即說明此時的數(shù)據(jù)是有效數(shù)據(jù)，可以拿來用了
m_axi_rx_tkeep與m_axi_rx_tlast的用法與發(fā)送端對應的信號一致

幀結構

TX子模塊將每個接收的用戶幀通過TX接口轉換為Aurora 8B / 10B幀。幀開始（SOF）通過在幀開始處添加2字節(jié)的SCP代碼組來指示。幀結束（EOF）是通過在幀的末尾添加一個2字節(jié)的信道結束通道協(xié)議（ECP）碼組來確定。數(shù)據(jù)不可用時插入空閑代碼組。代碼組是8B / 10B編碼字節(jié)對，所有數(shù)據(jù)都作為代碼對發(fā)送，因此具有奇數(shù)個字節(jié)的用戶幀具有稱為PAD的控制字符，附加到幀的末尾以填寫最終的代碼組。下圖顯示了具有偶數(shù)數(shù)據(jù)字節(jié)的典型Aurora 8B / 10B幀。

4種發(fā)送案例

手冊（PG046）里舉了4種傳輸案例方便我們理解發(fā)送過程：

Example A: Simple Data Transfer（簡單數(shù)據(jù)傳輸）

在valid信號與ready信號握手成功期間傳輸數(shù)據(jù)，傳輸?shù)阶詈笠粋€數(shù)據(jù)DATA2時，拉高tlast信號，表明此時傳輸?shù)氖亲詈笠粋€數(shù)據(jù)。tkeep信號表示最后一個數(shù)據(jù)的那些字節(jié)是有效的。

Example B: Data Transfer with Pad（奇數(shù)字節(jié)數(shù)據(jù)傳輸）

在valid信號與ready信號握手成功期間傳輸數(shù)據(jù)，傳輸?shù)阶詈笠粋€數(shù)據(jù)DATA2時，拉高tlast信號，表明此時傳輸?shù)氖亲詈笠粋€數(shù)據(jù)。tkeep信號表示最后一個數(shù)據(jù)的那些字節(jié)是有效的。由于此時傳輸?shù)氖瞧鏀?shù)個字節(jié)，所以最后一個數(shù)據(jù)中存在無效字節(jié)，故tkeep信號的值為N-1。

Example C: Data Transfer with Pause（帶有暫停的數(shù)據(jù)傳輸）

在握手期間，用戶通過拉低valid信號中斷了握手，實現(xiàn)了數(shù)據(jù)發(fā)送的暫停（流控）。

Example D: Data Transfer with Clock Compensation（帶時鐘補償?shù)臄?shù)據(jù)傳輸）

當Aurora 8B / 10B IP核發(fā)送時鐘補償序列時，會自動中斷數(shù)據(jù)傳輸。時鐘補償序列每10,000字節(jié)加上每個通道的12字節(jié)開銷。其他與上述情況一致。

接收數(shù)據(jù)案例

不同于發(fā)送數(shù)據(jù)的握手過程，接收數(shù)據(jù)過程簡單的很，只需要數(shù)據(jù)有效信號m_axi_rx_tvalid為高時，則表示此時接收的數(shù)據(jù)有效，也用m_axi_rx_tkeep、m_axi_rx_tlast來修飾接收的最后一個數(shù)據(jù)。典型過程如下：

當m_axi_rx_tvalid為高時，接收到的數(shù)據(jù)有效，其他時候則無效。

Framing接口總結：

Framing接口類似被再封裝的AXI4-Streaming接口，IP核自動加入幀頭、幀尾，并在固定時間內完成時鐘補償
發(fā)送端用戶只需要在發(fā)送、接收雙方完成握手后，即可發(fā)送數(shù)據(jù)，通信雙方均可通過握手信號來反壓對方；接收端用戶僅需要在valid信號有效時從總線上拿數(shù)據(jù)即可
由于是幀結構，所以需要有信號來約束幀長度--tlast；由于數(shù)據(jù)的發(fā)送是成對發(fā)送，所以最后一個數(shù)據(jù)可能存在無效字節(jié)的情況，故需要對最后一個數(shù)據(jù)的有效字節(jié)數(shù)進行約束--tkeep

2.5.3、Streaming接口
Streaming接口示意圖如下：

看起來比 Framing接口清爽了很多，因為發(fā)送端和接收端都少了keep和last這兩個信號（共4個）。之前說過，F(xiàn)raming接口的幀框架使得需要使用keep和last這兩個信號來控制幀的長度，所以信號較多。而Streaming接口則沒有幀框架，相當于一條不停流動的管道，所以不需要使用keep和last這兩個信號來控制長度。

用起來也很簡單，發(fā)送數(shù)據(jù)只要在tvalid信號和tready信號握手成功時就可以發(fā)送；接收數(shù)據(jù)就更簡單了，只要tvalid為高則說明此時接收的數(shù)據(jù)是有效的。

直接看圖來加深理解：

Example A: TX Streaming Data Transfer（數(shù)據(jù)發(fā)送）

簡單直白，只有當s_axi_tx_tready、s_axi_tx_tvalid均為高（成功握手）時，才可以發(fā)送數(shù)據(jù)。

Example B: RX Streaming Data Transfer（接收數(shù)據(jù)）

簡單直白，只有當m_axi_rx_tvalid為高時才說明接收到的數(shù)據(jù)為有效數(shù)據(jù)。

Streaming接口總結：

Streaming接口就是經(jīng)典的AXI4-Streaming接口，沒有幀的概念，數(shù)據(jù)總線上數(shù)據(jù)長度是不受限制的
發(fā)送端用戶只需要在發(fā)送、接收雙方完成握手后，即可發(fā)送數(shù)據(jù)，通信雙方均可通過握手信號來反壓對方；接收端用戶僅需要在valid信號有效時從總線上拿數(shù)據(jù)即可

3、其他