最新老头与老头同性视频,亚洲成年人网址,综合色区

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

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

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

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

從上圖不難看出：

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

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

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

主要組成部分如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

發送端（相對于用戶來說）：

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

如果你熟悉AXI4-Stream協議的話，基本就能馬上上手數據的接收發送部分了。

發送數據

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

接收數據

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

幀結構

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

4種發送案例

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

Example A: Simple Data Transfer（簡單數據傳輸）

在valid信號與ready信號握手成功期間傳輸數據，傳輸到最后一個數據DATA2時，拉高tlast信號，表明此時傳輸的是最后一個數據。tkeep信號表示最后一個數據的那些字節是有效的。

Example B: Data Transfer with Pad（奇數字節數據傳輸）

在valid信號與ready信號握手成功期間傳輸數據，傳輸到最后一個數據DATA2時，拉高tlast信號，表明此時傳輸的是最后一個數據。tkeep信號表示最后一個數據的那些字節是有效的。由于此時傳輸的是奇數個字節，所以最后一個數據中存在無效字節，故tkeep信號的值為N-1。

Example C: Data Transfer with Pause（帶有暫停的數據傳輸）

在握手期間，用戶通過拉低valid信號中斷了握手，實現了數據發送的暫停（流控）。

Example D: Data Transfer with Clock Compensation（帶時鐘補償的數據傳輸）

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

接收數據案例

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

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

Framing接口總結：

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

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

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

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

直接看圖來加深理解：

Example A: TX Streaming Data Transfer（數據發送）

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