Aurora 8B/10B IP核（一）—Aurora概述及數(shù)據(jù)接口

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

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

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

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

從上圖不難看出：

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

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

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

主要組成部分如下：

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

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

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

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

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

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

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

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

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

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

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（幀）的概念，所以接口信號(hào)較之Streaming接口要復(fù)雜一點(diǎn)，主要接口如下：

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

接收端（相對(duì)于用戶來說）：

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

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

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

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

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

幀結(jié)構(gòu)

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

4種發(fā)送案例

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

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

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

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

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

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

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

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

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

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

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

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

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

Framing接口總結(jié)：

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

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

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

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

直接看圖來加深理解：

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

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

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

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

Streaming接口總結(jié)：

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

3、其他

• 下一節(jié)我們?cè)賮硪黄饘W(xué)習(xí)下Aurora IP核的時(shí)鐘架構(gòu)、復(fù)位和指示信號(hào)。
• 創(chuàng)作不易，如果本文對(duì)您有幫助，還請(qǐng)多多點(diǎn)贊、評(píng)論和收藏。您的支持是我持續(xù)更新的最大動(dòng)力！
• 關(guān)于本文，您有什么想法均可在評(píng)論區(qū)留言。如果需要整個(gè)工程，請(qǐng)?jiān)谠u(píng)論留下郵箱或者私信我郵箱（注意保護(hù)隱私）。
• 自身能力不足，如有錯(cuò)誤還請(qǐng)多多指出！

參考資料

Aurora 8B/10B Protocol Specification

Aurora 8B/10B v11.1 LogiCORE IP Product Guide

FPGA設(shè)計(jì)心得（3）Aurora IP core 的理論學(xué)習(xí)記錄

審核編輯：符乾江