Aurora 8B/10B IP概述

介紹

Aurora 8B/10B 內(nèi)核支持 AMBA協(xié)議、AXI4-Stream 用戶接口。 該內(nèi)核使用 Zynq、Artix-7、Kintex-7 和 Virtex-7 系列、UltraScale和 UltraScale+系列上的高速串行收發(fā)器實現(xiàn) Aurora 8B/10B 協(xié)議。

特點

• 吞吐量范圍為 480 Mb/s 至 84.48 Gb/s 的通用數(shù)據(jù)通道。
• 支持多達 16 個連續(xù)鍵合的 7 系列 GTX/GTH、UltraScale GTH 或 UltraScale+ GTH 收發(fā)器和多達四個鍵合 GTP 收發(fā)器。
• Aurora 8B/ 符合 10B 協(xié)議規(guī)范 v2.3。
• 資源成本低。
• 易于使用的基于 AXI4-Stream 的幀（或流）和流控制接口。
• 自動初始化和維護通道。
• 全雙工或單工操作。
• 16 位加擾器/解擾器。
• 用于用戶數(shù)據(jù)的 16 位或 32 位循環(huán)冗余校驗 (CRC)。
• 熱插拔邏輯。
• 可配置的 DRP/INIT 時鐘。
• GTREFCLK 和內(nèi)核 INIT_CLK 的單/差分時鐘選項。

IP概述

Vivado工具可以為具有可配置數(shù)據(jù)路徑寬度的 Aurora 8B/10B 內(nèi)核生成源代碼。 內(nèi)核可以是單工或全雙工的，并具有兩個簡單的用戶界面之一和可選的流量控制。Aurora 8B/10B 通道使用結構如下圖，是用于高速串行通信的可擴展、輕量級鏈路層協(xié)議。 該協(xié)議是開放的，可以使用 Xilinx FPGA 技術來實現(xiàn)。 該協(xié)議通常用于需要簡單、低成本、高速率數(shù)據(jù)通道的應用中，并用于使用一個或多個收發(fā)器在設備之間傳輸數(shù)據(jù)。

Aurora 8B/10B 內(nèi)核在連接到 Aurora 通道時會自動初始化通道，并以幀或數(shù)據(jù)流的形式在通道中自由傳遞數(shù)據(jù)。

Aurora 幀可以是任意大小，并且可以隨時中斷。 有效數(shù)據(jù)字節(jié)之間的間隙會自動填充空閑以保持鎖定并防止過度的電磁干擾。 流控制可用于降低傳入數(shù)據(jù)的速率或通過通道發(fā)送簡短的高優(yōu)先級消息。 流是單一的、無休止的幀。 在沒有數(shù)據(jù)的情況下，傳輸空閑以保持鏈路活動。  Aurora 8B/10B 內(nèi)核使用 8B/10B 編碼規(guī)則檢測單比特和大多數(shù)多比特錯誤。 過多的位錯誤、斷開連接或設備故障會導致內(nèi)核復位并嘗試重新初始化新通道。

應用

Aurora 8B/10B 內(nèi)核資源成本低、吞吐量可擴展和數(shù)據(jù)接口靈活，因此可用于各種應用。 核心應用示例包括：

• 芯片到芯片鏈接：用高速串行連接代替芯片之間的并行連接可以顯著減少 PCB 上所需的走線和層數(shù)。 該內(nèi)核以最低的 FPGA 資源成本提供使用 GTP、GTX 和 GTH 收發(fā)器所需的邏輯。
• 板對板和背板鏈路：內(nèi)核使用標準的8B/10B 編碼，使其與許多現(xiàn)有的電纜和背板硬件標準兼容。  Aurora 8B/10B 內(nèi)核可以在線路速率和通道寬度方面進行擴展，以允許在新的高性能系統(tǒng)中使用廉價的傳統(tǒng)硬件。
• 單工連接（單向）：Aurora 協(xié)議提供了執(zhí)行單向通道初始化的替代方法，從而可以在沒有反向通道的情況下使用 GTP、GTX 和 GTH 收發(fā)器，并降低由于未使用的全雙工資源而導致的成本。

內(nèi)核結構

下圖顯示了 Aurora 8B/10B 內(nèi)核的實現(xiàn)框圖。

Aurora 8B/10B 內(nèi)核的主要功能模塊有：

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

延遲性能簡述

通過 Aurora 8B/10B 內(nèi)核的延遲是由通過協(xié)議引擎 (PE) 和收發(fā)器的流水線延遲引起的。  PE 流水線延遲隨著 AXI4-Stream 接口寬度的增加而增加。 收發(fā)器延遲取決于所選收發(fā)器的特性和屬性。本節(jié)概述了 Aurora 8B/10B 內(nèi)核 AXI4-Stream 用戶界面在每通道 2 字節(jié)和每通道 4 字節(jié)設計的 user_clk 周期方面的預期延遲。 為了說明延遲，Aurora 8B/10B 模塊被劃分為收發(fā)器邏輯和協(xié)議引擎 (PE) 邏輯，后者在 FPGA 可編程邏輯中實現(xiàn)。下圖說明了默認配置的數(shù)據(jù)路徑延遲。 延遲可能因設計中使用的收發(fā)器和 IP 配置而異。

在默認內(nèi)核配置的功能仿真中，從 s_axi_tx_tvalid 到 m_axi_rx_tvalid 的兩字節(jié)幀設計的最小延遲約為 37 個 user_clk 周期，見下圖：

在功能仿真中，從 s_axi_tx_tvalid 到 m_axi_rx_tvalid 的默認四字節(jié)幀設計的最小延遲約為 41 個 user_clk 周期。流水線延遲旨在保持時鐘速度。 如果沒有依賴關系，請檢查是否可以通過其他可選功能添加延遲。

吞吐量性能簡述

Aurora 8B/10B 內(nèi)核吞吐量取決于收發(fā)器的數(shù)量和目標線路速率。 單通道設計到 16 通道設計的吞吐量分別從 0.4 Gb/s 到 84.48 Gb/s 不等。 吞吐量是使用 Aurora 8B/10B 協(xié)議編碼的 20% 開銷和 0.5 Gb/s 至 6.6 Gb/s 線速范圍計算得出的。

端口描述

用于生成每個 Aurora 8B/10B 內(nèi)核的參數(shù)決定了可用于該特定內(nèi)核的接口。選擇 Little Endian Support 選項時使用 [n:0] 總線格式。選擇支持 Big Endian 選項時使用 [0:n] 總線格式。除非另有說明，端口一般為高電平有效。

用戶接口

用戶接口 Aurora 8B/10B 內(nèi)核可以使用成幀或流式用戶數(shù)據(jù)接口生成。 該接口包括流式傳輸或成幀數(shù)據(jù)傳輸所需的所有端口。幀用戶接口符合 AMBA AXI4-Stream 協(xié)議規(guī)范，并包含傳輸和接收成幀用戶數(shù)據(jù)所需的信號。流接口允許在沒有幀分隔符的情況下發(fā)送數(shù)據(jù)，操作更簡單，并且比幀接口使用更少的資源。

數(shù)據(jù)端口寬度取決于通道寬度和所選通道數(shù)。

頂層架構

Aurora 8B/10B 內(nèi)核頂層文件例化了通道邏輯模塊、TX 和 RX AXI4-Stream 模塊、全局邏輯模塊和收發(fā)器的封裝。 示例設計中還實例化了時鐘、復位電路、幀生成器和檢查器模塊。下圖顯示了雙工配置的 Aurora 8B/10B 內(nèi)核頂層。

AXI4-Stream Bit Ordering （AXI4-Stream 位排序）

Aurora 8B/10B 內(nèi)核使用升序排列。 它們首先發(fā)送和接收最高有效字節(jié)的最高有效位。 下圖顯示了 Aurora 8B/10B 內(nèi)核的 AXI4-Stream 數(shù)據(jù)接口的 n 字節(jié)示例的組織結構。

用戶接口端口

下表列出了雙工和單工內(nèi)核 AXI4-Stream TX 和 RX 數(shù)據(jù)端口說明。

USER_DATA_S_AXI_TX

USER_DATA_M_AXI_RX

幀接口

下圖顯示了 Aurora 8B/10B 內(nèi)核的幀用戶接口，帶有用于 TX 和 RX 數(shù)據(jù)的 AXI4-Stream 兼容端口。

傳輸數(shù)據(jù)

為了傳輸數(shù)據(jù)，用戶應用程序操縱控制信號使內(nèi)核執(zhí)行以下操作：

• 當 s_axi_tx_tvalid 和 s_axi_tx_tready 信號置位時，從 s_axi_tx_tdata 總線上的用戶接口獲取數(shù)據(jù)。
• 通過Aurora 8B/10B 通道中的通道串行化數(shù)據(jù)。
• 使用s_axi_tx_tvalid 信號傳輸數(shù)據(jù)。 用戶應用程序可以置低 s_axi_tx_tvalid 以在線路上插入空閑（引入停頓或暫停）。
• 暫停數(shù)據(jù)（即插入空閑）（s_axi_tx_tvalid 無效）。

當內(nèi)核接收數(shù)據(jù)時，它會執(zhí)行以下操作：

• 檢測并丟棄控制字節(jié)（空閑、時鐘補償、通道開始 PDU (SCP)、通道結束協(xié)議數(shù)據(jù)單元 (ECPDU) 和 PAD。
• 斷言成幀信號 (m_axi_rx_tlast) 并指定最后一個數(shù)據(jù)節(jié)拍中的有效字節(jié)數(shù) (m_axi_rx_tkeep)。
• 從通道中恢復數(shù)據(jù)。
• 通過置位m_axi_rx_tvalid 信號，拼接數(shù)據(jù)傳遞給m_axi_rx_tdata 總線上的用戶接口。

Aurora 8B/10B 內(nèi)核僅在 s_axi_tx_tready 和 s_axi_tx_tvalid 均置位（高）時對數(shù)據(jù)進行采樣。

AXI4-Stream 數(shù)據(jù)僅在成幀時有效。 幀外的數(shù)據(jù)被忽略。

要開始一幀，請在數(shù)據(jù)的第一個字位于 s_axi_tx_tdata 端口上時斷言 s_axi_tx_tvalid。

要結束一幀，請在數(shù)據(jù)的最后一個字（或部分字）位于 s_axi_tx_tdata 端口上時斷言 s_axi_tx_tlast，并使用 s_axi_tx_tkeep 指定最后一個數(shù)據(jù)節(jié)拍中的有效字節(jié)數(shù)。

對于單個字長或更短的幀，s_axi_tx_tvalid 和 s_axi_tx_tlast 同時被斷言。

Aurora 8B/10B 幀

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 幀。

長度

用戶應用程序通過操縱 s_axi_tx_tvalid 和 s_axi_tx_tlast 信號來控制通道幀長度。  Aurora 8B/10B 內(nèi)核分別以幀開始和幀結束有序集 /SCP/ 和 /ECP/ 進行響應。

傳輸示例

簡單數(shù)據(jù)傳輸

下圖顯示了在 n 字節(jié)寬的 AXI4-Stream 接口上進行簡單數(shù)據(jù)傳輸?shù)氖纠?/p>

在這種情況下，發(fā)送的數(shù)據(jù)量為 3n 字節(jié)，因此需要三個數(shù)據(jù)節(jié)拍。  s_axi_tx_tready 置位，表示 AXI4-Stream 接口已準備好傳輸數(shù)據(jù)。 用戶應用程序在前 n 個字節(jié)期間置位 s_axi_tx_tvalid 以開始數(shù)據(jù)傳輸。  /SCP/ 有序集放置在通道的前兩個字節(jié)上，以指示幀的開始。 然后將前 n–2 個數(shù)據(jù)字節(jié)放在通道上。 由于 /SCP/ 所需的偏移量，每個數(shù)據(jù)節(jié)拍中的最后兩個字節(jié)總是延遲一個周期，并在通道的下一個節(jié)拍的前兩個字節(jié)上傳輸。

為了結束數(shù)據(jù)傳輸，用戶應用程序在 s_axi_tx_tkeep 總線上置位 s_axi_tx_tlast、最后一個數(shù)據(jù)字節(jié)和適當?shù)闹怠?在此示例中，s_axi_tx_tkeep 在波形中設置為 N，以指示所有字節(jié)在最后一個數(shù)據(jù)節(jié)拍中均有效。 當 s_axi_tx_tlast 被置位時，s_axi_tx_tready 在下一個時鐘周期被置低，內(nèi)核使用數(shù)據(jù)流中的間隙發(fā)送最終的偏移數(shù)據(jù)字節(jié)和 /ECP/ 有序集，指示幀結束。  s_axi_tx_tready 在下一個周期重新置位以允許數(shù)據(jù)傳輸繼續(xù)。

使用填充的數(shù)據(jù)傳輸

下圖顯示了一個需要使用填充的 (3n–1) 字節(jié)數(shù)據(jù)傳輸示例。

Aurora 8B/10B 內(nèi)核根據(jù)協(xié)議要求為具有奇數(shù)字節(jié)的幀附加填充字符。 傳輸 3n–1 個數(shù)據(jù)字節(jié)需要兩個完整的 n 字節(jié)數(shù)據(jù)字和一個部分數(shù)據(jù)字。 在此示例中，s_axi_tx_tkeep 設置為 N–1 以指示最后一個數(shù)據(jù)字中的 n–1 個有效字節(jié)。

帶暫停的數(shù)據(jù)傳輸

下圖顯示了用戶接口如何在幀傳輸期間暫停數(shù)據(jù)傳輸。 在此示例中，用戶應用程序在前 n 個字節(jié)之后通過置低 s_axi_tx_tvalid 暫停數(shù)據(jù)流，并改為傳輸空閑。 暫停一直持續(xù)到 s_axi_tx_tvalid 被取消斷言。

Aurora 8B/10B 內(nèi)核在發(fā)送時鐘補償序列時會自動中斷數(shù)據(jù)傳輸。 時鐘補償序列每 10,000 個字節(jié)對每個通道施加 12 個字節(jié)的開銷。下圖顯示了 Aurora 8B/10B 內(nèi)核如何在時鐘補償序列期間暫停數(shù)據(jù)傳輸。

由于每通道每 10,000 字節(jié)需要進行時鐘補償（每通道 2 字節(jié)設計需要 5,000 個時鐘；每通道 4 字節(jié)設計需要 2,500 個時鐘），因此您無法連續(xù)傳輸數(shù)據(jù)，也無法連續(xù)接收數(shù)據(jù)。 在時鐘補償期間，數(shù)據(jù)傳輸暫停六個或三個時鐘周期。

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

RX 子模塊沒有用于用戶數(shù)據(jù)的內(nèi)置彈性緩沖區(qū)。 因此，RX AXI4-Stream 接口上沒有 m_axi_rx_tready 信號。 用戶應用程序控制來自 Aurora 8B/10B 通道的數(shù)據(jù)流的唯一方法是使用IP可選流控制功能之一。

m_axi_rx_tvalid 信號與來自 Aurora 8B/10B 內(nèi)核的每個幀的第一個字同時置位。  m_axi_rx_tlast 與每幀的最后一個字或部分字同時置位。  m_axi_rx_tkeep 端口指示每幀最后一個字中的有效字節(jié)數(shù)。m_axi_rx_tkeep 信號僅在 m_axi_rx_tlast 置位時有效。

Aurora 8B/10B 內(nèi)核可以隨時取消斷言 m_axi_rx_tvalid，甚至在一幀期間。即使幀最初是在沒有暫停的情況下傳輸?shù)?，?nèi)核偶爾也會置低 m_axi_rx_tvalid。 這些停頓是框架字符解碼和左對齊過程的結果。

下圖顯示了一個 3n 字節(jié)的接收數(shù)據(jù)被暫停中斷的示例。

image-20220602105222294

數(shù)據(jù)顯示在 m_axi_rx_tdata 總線上。 當前 n 個字節(jié)放置在總線上時，m_axi_rx_tvalid 被置位以指示數(shù)據(jù)已準備好供用戶應用程序使用。 內(nèi)核在第一個數(shù)據(jù)節(jié)拍之后的時鐘周期內(nèi)將 m_axi_rx_tvalid 置低，以指示數(shù)據(jù)流暫停。暫停后，內(nèi)核置位 m_axi_rx_tvalid 并繼續(xù)在 m_axi_rx_tdata 總線上組裝剩余數(shù)據(jù)。 在幀結束時，內(nèi)核斷言 m_axi_rx_tlast。 內(nèi)核還計算 m_axi_rx_tkeep 總線的值，并根據(jù)幀最后一個字中的有效字節(jié)總數(shù)將其呈現(xiàn)給用戶應用程序。

成幀效率

有兩個因素會影響 Aurora 8B/10B 內(nèi)核的成幀效率：

• 幀大小。
• 數(shù)據(jù)路徑的寬度。

CC 序列（每 10,000 字節(jié)在每個通道上使用 12 個字節(jié)）消耗大約 0.12% 的總信道帶寬。

Aurora 8B/10B 內(nèi)核中的所有字節(jié)都以兩字節(jié)代碼組發(fā)送。 具有偶數(shù)字節(jié)的 Aurora 8B/10B 幀有四個字節(jié)的開銷，兩個字節(jié)用于 SCP（幀開始）和兩個字節(jié)用于 ECP（幀結束）。 具有奇數(shù)字節(jié)的 Aurora 8B/10B 幀具有 5 個字節(jié)的開銷、4 個字節(jié)的成幀開銷以及一個用于填充字節(jié)的附加字節(jié)。

IP僅在通道的特定通道中傳輸幀定界符。  SCP 僅在最左側（最重要）的通道中傳輸，而 ECP 僅在最右側（最不重要）的通道中傳輸。 在最后一個有數(shù)據(jù)的代碼組和 ECP 代碼組之間的信道中的任何空間都用空閑填充。 結果是降低了設計的資源成本，但以最小的額外吞吐量成本為代價。 盡管 SCP 和 ECP 可以針對額外的吞吐量進行優(yōu)化，但用戶界面施加的每周期單幀限制會使這種改進在大多數(shù)情況下無法使用。

使用公式中所示的公式計算任意通道數(shù)、任意接口寬度和任意字節(jié)數(shù)幀的設計效率。該公式包括時鐘補償?shù)拈_銷。

其中：

• E = 指定 PDU 的平均效率。
• n = 用戶數(shù)據(jù)字節(jié)數(shù)。
• 12n/9988 = 時鐘校正開銷。
• 4 = SCP + ECP 開銷。
• 0.5 = 平均 PAD 開銷。
• IDLE = IDLE 開銷 = (  w/2) – 1。
• w = 接口寬度。

表 2-4 是根據(jù)公式 2-1 計算得出的示例。 它顯示了 8 字節(jié)、4 通道通道的效率，并說明效率隨著通道幀長度的增加而增加。

表 2-5顯示了通過四個通道傳輸 256 字節(jié)幀數(shù)據(jù)時 8 字節(jié) 4 通道通道的開銷。 由于開始和結束字符以及填充通道所需的空閑，生成的數(shù)據(jù)單元為 264 字節(jié)長。 這相當于發(fā)射機開銷的 3.03%。 此外，每 10,000 個字節(jié)在每個通道上發(fā)生一個 12 字節(jié)的時鐘補償序列，這會增加少量的開銷。 接收器可以處理稍微更有效的數(shù)據(jù)流，因為它不需要任何空閑模式。

表 2-6 顯示了 s_axi_tx_tkeep 的每個值產(chǎn)生的開銷。在 Vivado中選擇 Little Endian 選項時，s_axi_tx_tkeep 位順序從 MSB 更改為 LSB。

流接口

下顯示了一個配置有流式用戶界面的 Aurora 8B/10B 內(nèi)核示例。

流接口端口

USER_DATA_S_AXI_TX

USER_DATA_M_AXI_RX

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

流接口允許 Aurora 8B/10B 通道用作管道。 初始化后，通道始終可用于寫入，發(fā)送時鐘補償序列時除外。 核心數(shù)據(jù)傳輸符合 AXI4-Stream 協(xié)議。

當 s_axi_tx_tvalid 被置低時，字之間會產(chǎn)生間隙并保留間隙，除非正在傳輸時鐘補償序列。當數(shù)據(jù)到達 Aurora 8B/10B 通道的 RX 側時，它會呈現(xiàn)在 m_axi_rx_tdata 總線上，并且 m_axi_rx_tvalid 被置位。 數(shù)據(jù)必須立即讀取，否則會丟失。 如果這是不可接受的，則必須將緩沖區(qū)連接到 RX 接口以保存數(shù)據(jù)，直到可以使用為止。

傳輸示例

TX 流數(shù)據(jù)傳輸

下圖顯示了流數(shù)據(jù)的典型示例。

Aurora 8B/10B 內(nèi)核通過置位 s_axi_tx_tready 來指示它已準備好傳輸數(shù)據(jù)。 一個周期后，用戶邏輯通過置位 s_axi_tx_tdata 總線和 s_axi_tx_tvalid 信號來指示它已準備好傳輸數(shù)據(jù)。 因為兩個就緒信號現(xiàn)在都已置位，所以數(shù)據(jù) D0 從用戶邏輯傳輸?shù)?Aurora 8B/10B 內(nèi)核。 數(shù)據(jù) D1 在下一個時鐘周期傳輸。 在此示例中，Aurora 8B/10B 內(nèi)核將其就緒信號 s_axi_tx_tready 置低，直到下一個時鐘周期再次置位 s_axi_tx_tready 信號時才傳輸數(shù)據(jù)。 然后用戶邏輯在下一個時鐘周期將 s_axi_tx_tvalid 置低，直到兩個就緒信號都置位后才傳輸數(shù)據(jù)。

RX 流數(shù)據(jù)傳輸

下圖顯示了數(shù)據(jù)傳輸?shù)慕邮斩恕?/p>

流量控制

本節(jié)介紹如何使用 Aurora 8B/10B 流量控制。 使用幀接口的內(nèi)核上有兩個可選的流控制接口。 本機流量控制 (NFC) 調(diào)節(jié)全雙工通道接收端的數(shù)據(jù)傳輸速率。 用戶流控制 (UFC) 為控制操作提供高優(yōu)先級消息。

用戶流控制接口

UFC 接口是在生成內(nèi)核并啟用 UFC 時創(chuàng)建的，如下圖。

TX 側的 UFC s_axi_ufc_tx_tvalid 和 s_axi_ufc_tx_tready 端口啟動 UFC 消息，3 位 s_axi_ufc_tx_tdata 端口指定消息的長度。斷言 s_axi_ufc_tx_tready 后，可以將 UFC 消息提供給數(shù)據(jù)端口。

UFC 接口的 RX 端由一組 AXI4-Stream 端口組成，允許將 UFC 消息作為幀讀取simplex留在支持的方向上發(fā)送數(shù)據(jù)所需的接口。

UFC I/O 端口描述

UFC_S_AXIS_TX

UFC_M_AXIS_RX

傳輸 UFC 消息

UFC 消息可以攜帶從 2 到 16 的偶數(shù)數(shù)據(jù)字節(jié)。用戶應用程序通過驅動 s_axi_ufc_tx_tdata 端口上的 SIZE 代碼來指定消息的長度。 下表 顯示了 UFC 消息的合法 SIZE 代碼值。

要發(fā)送 UFC 消息，用戶應用程序在使用所需 SIZE 代碼驅動 s_axi_ufc_tx_tdata 端口時斷言 s_axi_ufc_tx_tvalid。  s_axi_ufc_tx_tvalid 信號必須保持到 Aurora 8B/10B 內(nèi)核置位 s_axi_ufc_tx_tready 信號。UFC 消息的數(shù)據(jù)必須放在 s_axi_tx_tdata 端口上，從 s_axi_ufc_tx_tready 置位后的第一個周期開始。 當 s_axi_tx_tdata 端口用于 UFC 數(shù)據(jù)時，內(nèi)核將 s_axi_tx_tready 置低。只有在完成當前的 UFC 請求后才能發(fā)出 UFC 請求；  IP 可能不支持背靠背的 UFC 請求。

下圖顯示了一個用于將 TX_D 從發(fā)送常規(guī)數(shù)據(jù)切換到 UFC 數(shù)據(jù)的電路。

表 2-9 顯示了根據(jù) AXI4-Stream 數(shù)據(jù)接口的寬度傳輸不同大小的 UFC 消息所需的周期數(shù)。 在所有消息數(shù)據(jù)可用之前，不應啟動 UFC 消息。 與常規(guī)數(shù)據(jù)不同，UFC 消息在 s_axi_ufc_tx_tready 被斷言后不能被中斷，直到當前 UFC 消息完成。

傳輸單周期 UFC 消息

傳輸單周期 UFC 消息的過程如下圖所示。在這種情況下，在 4 字節(jié)接口上發(fā)送 4 字節(jié)消息。s_axi_ufc_tx_tready 信號在兩個周期內(nèi)被置低。  Aurora 8B/10B 內(nèi)核使用數(shù)據(jù)流中的這個間隙來傳輸 UFC 標頭和消息數(shù)據(jù)。

傳輸多周期 UFC 消息

傳輸兩周期 UFC 消息的過程如下圖所示。 在這種情況下，用戶應用程序使用 2 字節(jié)接口發(fā)送 4 字節(jié)消息。s_axi_tx_tready 斷言三個周期：一個周期用于在 s_axi_ufc_tx_tready 周期期間發(fā)送的 UFC 標頭，兩個周期用于 UFC 數(shù)據(jù)。

接收UFC消息

當 Aurora 8B/10B 內(nèi)核接收到 UFC 消息時，它會通過專用的 UFC AXI4-Stream 接口將數(shù)據(jù)傳遞給用戶應用程序。 數(shù)據(jù)呈現(xiàn)在 m_axi_ufc_rx_tdata 端口上；  m_axi_ufc_rx_tvalid 表示消息數(shù)據(jù)的開始，m_axi_ufc_rx_tlast 表示結束。  m_axi_ufc_rx_tkeep 用于顯示消息的最后一個周期內(nèi) m_axi_ufc_rx_tdata 上的有效字節(jié)數(shù)。

接收單周期 UFC 消息

下圖顯示了具有 4 字節(jié)數(shù)據(jù)接口的 Aurora 8B/10B 內(nèi)核接收 4 字節(jié) UFC 消息。 內(nèi)核通過置位 m_axi_ufc_rx_tvalid 和 m_axi_ufc_rx_tlast 來向用戶應用程序提供此數(shù)據(jù)以指示單個周期幀。m_axi_ufc_rx_tkeep 設置為 4'hF，表示只有接口的四個最高有效字節(jié)有效。

接收多周期 UFC 消息

下圖顯示了具有 4 字節(jié)接口的 Aurora 8B/10B 內(nèi)核接收 8 字節(jié)消息。生成的幀長兩個周期，m_axi_ufc_rx_tkeep 在第二個周期設置為 4'hF，表示數(shù)據(jù)的所有四個字節(jié)都有效。

Native Flow Control

Aurora 8B/10B 協(xié)議包括本機流量控制 (NFC) 接口，如下圖所示。

該接口允許接收器通過指定必須放入數(shù)據(jù)流中的空閑數(shù)據(jù)節(jié)拍數(shù)來控制接收數(shù)據(jù)的速率。 甚至可以通過請求發(fā)送器暫時僅發(fā)送空閑 (XOFF) 來完全關閉數(shù)據(jù)流。NFC 通常用于防止 FIFO 溢出情況。

原生流控制接口

NFC 接口是在生成內(nèi)核并啟用 NFC 選項時創(chuàng)建的。 此接口包括用于發(fā)送 NFC 消息的請求 (s_axi_nfc_tx_tvalid) 和確認(s_axi_nfc_tx_tready) 端口，以及用于指定請求的空閑周期數(shù)的 4 位 s_axi_nfc_tx_tdata 端口。

下表列出了僅在全雙工 Aurora 8B/10B 內(nèi)核中可用的 NFC 接口端口。

NFC I/O Ports

NFC_S_AXIS_TX

NFC_M_AXIS_RX

下表顯示了本機流量控制 (NFC) 的代碼。 這些值在大端格式的 [0:3] 位和小端格式的 [3:0] 位上驅動。

用戶應用程序斷言 s_axi_nfc_tx_tvalid 并將 NFC 代碼寫入 s_axi_nfc_tx_tdata。  NFC 代碼指示通道合作伙伴應在其 TX 數(shù)據(jù)流中插入的最小空閑周期數(shù)。 用戶應用程序必須保持 s_axi_nfc_tx_tvalid 和 s_axi_nfc_tx_tdata，直到 s_axi_nfc_tx_tready 被置位。  Aurora 8B/10B 內(nèi)核在發(fā)送 NFC 消息時無法傳輸數(shù)據(jù)。s_axi_tx_tready 總是在 s_axi_nfc_tx_tready 斷言之后的周期被取消斷言。

發(fā)送 NFC 消息示例

下圖顯示了用戶應用程序向通道伙伴發(fā)送 NFC 消息時的傳輸時序示例。s_axi_nfc_tx_tready 信號被置低一個周期（假設 n 至少為 2）以在放置 NFC 消息的數(shù)據(jù)流中創(chuàng)建間隙。

接收插入了 NFC 空閑的消息示例

下圖顯示了接收到 NFC 消息時 TX 用戶界面上的信號示例。 在這種情況下，NFC 消息的代碼為 0001，請求兩個空閑數(shù)據(jù)節(jié)拍。 核心在用戶界面上置低 s_axi_tx_tready，直到發(fā)送了足夠的空閑來滿足請求。 在此示例中，內(nèi)核在立即 NFC 模式下運行，其中立即插入 NFC 空閑。  Aurora 8B/10B 內(nèi)核也可以在完成模式下運行，其中 NFC 空閑僅插入幀之間。 如果完成模式核心在傳輸幀時收到 NFC 消息，它會在取消斷言 s_axi_tx_tready 以插入空閑之前完成傳輸幀。

狀態(tài)、控制和收發(fā)器接口

Aurora 8B/10B 內(nèi)核的狀態(tài)和控制端口允許應用程序監(jiān)控通道并使用收發(fā)器的內(nèi)置功能。 本節(jié)提供狀態(tài)和控制接口、收發(fā)器串行 I/O 接口以及專用于單工模塊的邊帶初始化端口的圖表和端口說明。

狀態(tài)和控制端口

下表描述了 Aurora 8B/10B 內(nèi)核的每個狀態(tài)和控制端口的功能。

全雙工內(nèi)核

全雙工狀態(tài)和控制端口

全雙工內(nèi)核提供 TX 和 RX Aurora 8B/10B 通道連接。 下圖顯示了全雙工 Aurora 8B/10B 內(nèi)核的狀態(tài)和控制界面。

錯誤狀態(tài)信號

設備問題和通道噪聲可能導致 Aurora 8B/10B 通道操作期間出現(xiàn)錯誤。  8B/10B 編碼允許 Aurora 8B/10B 內(nèi)核檢測通道中發(fā)生的所有單位錯誤和大多數(shù)多位錯誤，并在每個周期置位 soft_err。

TX 單工內(nèi)核不包括 soft_err 端口。 除非存在設備問題，否則假定所有傳輸數(shù)據(jù)在傳輸時都是正確的。該內(nèi)核還監(jiān)視每個收發(fā)器的硬件錯誤，例如緩沖區(qū)溢出/下溢和失鎖，并斷言 hard_err 信號。 使用 rx_hard_err 信號報告單工內(nèi)核中的 RX 端硬錯誤。 災難性的硬件錯誤也可以表現(xiàn)為軟錯誤的爆發(fā)。 內(nèi)核使用 Aurora 8B/10B 協(xié)議規(guī)范 描述的漏桶算法來檢測短時間內(nèi)發(fā)生的大量軟錯誤，并斷言 hard_err 或 rx_hard_err 信號。

每當檢測到硬錯誤時，內(nèi)核都會自動重置并嘗試重新初始化。 這允許通道重新初始化并在導致硬錯誤的硬件問題得到解決后立即重新建立。 除非在短時間內(nèi)發(fā)生足夠多的軟錯誤，否則不會導致復位。

具有 AXI4-Stream 數(shù)據(jù)接口的 Aurora 8B/10B 內(nèi)核還可以檢測 Aurora 8B/10B 幀中的錯誤并斷言 frame_err 信號。 幀錯誤可以是沒有數(shù)據(jù)的幀、連續(xù)的幀開始符號和連續(xù)的幀結束符號。 該信號不適用于單工 TX 內(nèi)核。 當可用時，該信號通常在接近 soft_err 斷言時被斷言，軟錯誤是幀錯誤的主要原因。 下表總結了 Aurora 8B/10B 內(nèi)核可以檢測到的錯誤情況以及用于提醒用戶應用程序的錯誤信號。

全雙工初始化

全雙工內(nèi)核在上電、復位或硬錯誤后自動初始化，并執(zhí)行 Aurora 8B/10B 初始化程序，直到通道準備好使用。  lane_up 總線指示通道中的哪些通道已完成通道初始化過程。 該信號可用于幫助調(diào)試多通道通道中的設備問題。

只有在內(nèi)核完成整個初始化過程后才會斷言 channel_up。在聲明 channel_up 之前，Aurora 8B/10B 內(nèi)核無法接收數(shù)據(jù)。 僅應使用用戶界面上的 m_axi_rx_tvalid 信號來限定傳入數(shù)據(jù)。channel_up 可以反轉并用于復位驅動全雙工通道的 TX 側的模塊，因為在 channel_up 之后才能進行傳輸。 如果用戶應用程序模塊需要在數(shù)據(jù)接收之前復位，可以反轉并使用其中一個 lane_up 信號。 直到所有 lane_up 信號被置位后才能接收數(shù)據(jù)。

單工內(nèi)核

單工 TX 狀態(tài)和控制端口

單工 TX 內(nèi)核允許用戶應用程序將數(shù)據(jù)傳輸?shù)絾喂?RX 內(nèi)核。 他們沒有 RX 連接。 下圖顯示了單工 TX 內(nèi)核的狀態(tài)和控制接口。

單工 RX 狀態(tài)和控制端口

單工 RX 內(nèi)核允許用戶應用程序從單工 TX 內(nèi)核接收數(shù)據(jù)。下圖顯示了單工 RX 內(nèi)核的狀態(tài)和控制接口。

初始化

Simplex 內(nèi)核不依賴于來自 Aurora 8B/10B 通道的信號進行初始化。相反，單工通道的 TX 和 RX 側通過一組邊帶初始化信號傳達其初始化狀態(tài)：對齊、綁定、驗證和復位； 一組用于帶有 TX_ 前綴的 TX 側，一組用于帶有 RX_ 前綴的 RX 側。 綁定端口僅用于多通道內(nèi)核。使用單邊初始化信號初始化單工模塊的方法有兩種：

• 將信息從 RX 邊帶初始化端口發(fā)送到 TX 邊帶初始化端口。
• 使用定時初始化間隔獨立于 RX 邊帶初始化端口驅動 TX 邊帶初始化端口。

使用反向通道

反向通道是在 RX 和 TX 之間沒有通道的情況下初始化和維護單工通道的最安全方法。 反向通道只需將消息傳遞到 TX 側，以指示在信號變化時斷言哪個邊帶初始化信號。包含在 example_design 目錄中的帶有單工 Aurora 8B/10B 內(nèi)核的示例設計顯示了一個簡單的側通道，該通道在器件上使用了三個或四個 I/O 引腳。

使用定時器

如果反向通道是不可能的，串行通道可以通過使用一組定時器驅動 TX 單工初始化來初始化。 必須仔細設計定時器以滿足系統(tǒng)的需要，因為初始化的平均時間取決于許多特定于通道的條件，例如時鐘速率、通道延遲、通道之間的偏移和噪聲。

C_ALIGNED_TIMER、C_BONDED_TIMER 和 C_VERIFY_TIMER 是分別用于斷言 tx_aligned、tx_bonded 和 tx_verify 信號的定時器。 這些計時器使用從極端情況功能仿真中獲得并在 _core 模塊中實現(xiàn)的最壞情況值。

Aurora 8B/10B 模塊中的一些初始化邏輯使用看門狗定時器來防止死鎖。 這些看門狗定時器用于通道的 RX 側，可能會干擾 TX 初始化定時器的正常運行。 如果 RX 單工模塊從對齊、綁定或驗證變?yōu)閺臀?，請確保這不是因為 TX 邏輯在這些狀態(tài)之一中花費了太多時間。 如果需要特別長的定時器來滿足系統(tǒng)的需要，可以通過編輯模塊來調(diào)整看門狗定時器。 在大多數(shù)情況下，這不是必需的，也不建議這樣做。

Aurora 8B/10B 通道通常僅在發(fā)生故障時才會重新初始化。 當沒有可用的反向通道時，對于大多數(shù)錯誤來說，事件觸發(fā)的重新初始化是不可能的，因為通常情況下，RX 側檢測到故障，而條件必須由 TX 側處理。 解決方案是讓定時器驅動的 TX 單工模塊定期重新初始化。 如果發(fā)生災難性錯誤，通道將在下一個重新初始化周期到來后重置并再次運行。 系統(tǒng)設計人員應平衡重新初始化所需的平均時間與系統(tǒng)可以容忍不工作通道的最長時間，以確定系統(tǒng)的最佳重新初始化周期。

收發(fā)器接口

該接口包括收發(fā)器的串行 I/O 端口，以及控制和狀態(tài)。

時鐘接口

時鐘接口具有用于收發(fā)器參考時鐘的端口，以及 Aurora 8B/10B 內(nèi)核與應用邏輯共享的并行時鐘。下表描述了 Aurora 8B/10B 內(nèi)核時鐘端口。

Clock Ports for Aurora 8B/10B Core

下表提供了有關由于選擇共享邏輯選項而導致的端口更改的詳細信息。

CRC

CRC 模塊提供 16 位或 32 位 CRC，用于用戶數(shù)據(jù)。下表描述了 CRC 模塊端口。

生成無 GT 的 Aurora

此選項僅在 UltraScale 和 UltraScale+ 器件中可用。 啟用后，它會生成不帶 GT 的 Aurora 內(nèi)核，并將收發(fā)器從內(nèi)核移至示例設計中的支持級別。 下表提供了用于在 Aurora IP 之外與 GT 收發(fā)器交互的端口列表。

reference

PG046