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ù)通道。
• 支持多達(dá) 16 個連續(xù)鍵合的 7 系列 GTX/GTH、UltraScale GTH 或 UltraScale+ GTH 收發(fā)器和多達(dá)四個鍵合 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 通道使用結(jié)構(gòu)如下圖，是用于高速串行通信的可擴展、輕量級鏈路層協(xié)議。 該協(xié)議是開放的，可以使用 Xilinx FPGA 技術(shù)來實現(xiàn)。 該協(xié)議通常用于需要簡單、低成本、高速率數(shù)據(jù)通道的應(yīng)用中，并用于使用一個或多個收發(fā)器在設(shè)備之間傳輸數(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ù)多比特錯誤。 過多的位錯誤、斷開連接或設(shè)備故障會導(dǎo)致內(nèi)核復(fù)位并嘗試重新初始化新通道。

應(yīng)用

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

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

內(nèi)核結(jié)構(gòu)

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

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

• Lane Logic（通道邏輯）：每個 GTP、GTX 或 GTH 收發(fā)器（以下稱為收發(fā)器）由通道邏輯模塊的實例驅(qū)動，它初始化每個單獨的收發(fā)器并處理編碼以及控制字符的解碼和錯誤檢測。
• Global Logic （全局邏輯）：全局邏輯模塊執(zhí)行通道初始化的綁定和驗證階段。 在運行過程中，模塊會生成 Aurora 協(xié)議所需的隨機空閑字符，并監(jiān)控所有通道邏輯模塊的錯誤。
• RX User Interface（RX 用戶接口）：AXI4-Stream RX 用戶接口將數(shù)據(jù)從通道移動到應(yīng)用程序并執(zhí)行流量控制功能。
• TX User Interface （TX 用戶接口）：AXI4-Stream TX 用戶接口將數(shù)據(jù)從應(yīng)用程序移動到通道并執(zhí)行流量控制 TX 功能。 標(biāo)準(zhǔn)時鐘補償模塊嵌入內(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é)設(shè)計的 user_clk 周期方面的預(yù)期延遲。 為了說明延遲，Aurora 8B/10B 模塊被劃分為收發(fā)器邏輯和協(xié)議引擎 (PE) 邏輯，后者在 FPGA 可編程邏輯中實現(xiàn)。下圖說明了默認(rèn)配置的數(shù)據(jù)路徑延遲。 延遲可能因設(shè)計中使用的收發(fā)器和 IP 配置而異。

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

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

吞吐量性能簡述

Aurora 8B/10B 內(nèi)核吞吐量取決于收發(fā)器的數(shù)量和目標(biāo)線路速率。 單通道設(shè)計到 16 通道設(shè)計的吞吐量分別從 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ù)。

頂層架構(gòu)

Aurora 8B/10B 內(nèi)核頂層文件例化了通道邏輯模塊、TX 和 RX AXI4-Stream 模塊、全局邏輯模塊和收發(fā)器的封裝。 示例設(shè)計中還實例化了時鐘、復(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é)示例的組織結(jié)構(gòu)。

用戶接口端口

下表列出了雙工和單工內(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ù)，用戶應(yīng)用程序操縱控制信號使內(nèi)核執(zhí)行以下操作：

• 當(dāng) 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ù)。 用戶應(yīng)用程序可以置低 s_axi_tx_tvalid 以在線路上插入空閑（引入停頓或暫停）。
• 暫停數(shù)據(jù)（即插入空閑）（s_axi_tx_tvalid 無效）。

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

• 檢測并丟棄控制字節(jié)（空閑、時鐘補償、通道開始 PDU (SCP)、通道結(jié)束協(xié)議數(shù)據(jù)單元 (ECPDU) 和 PAD。
• 斷言成幀信號 (m_axi_rx_tlast) 并指定最后一個數(shù)據(jù)節(jié)拍中的有效字節(jié)數(shù) (m_axi_rx_tkeep)。
• 從通道中恢復(fù)數(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。

要結(jié)束一幀，請在數(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 接口接收到的每個用戶幀轉(zhuǎn)換為 Aurora 8B/10B 幀。 幀開始 (SOF) 通過在幀開始處添加 2 字節(jié) SCP 代碼組來指示。 幀結(jié)束 (EOF) 通過在幀末尾添加一個 2 字節(jié)的通道結(jié)束協(xié)議 (ECP) 代碼組來指示。 只要數(shù)據(jù)不可用，就會插入空閑代碼組。 代碼組是 8B/10B 編碼字節(jié)對，所有數(shù)據(jù)都作為代碼組發(fā)送，因此具有奇數(shù)字節(jié)的用戶幀在幀末尾附加一個稱為 PAD 的控制字符以填充最終代碼組。 下表顯示了具有偶數(shù)個數(shù)據(jù)字節(jié)的典型 Aurora 8B/10B 幀。

長度

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

傳輸示例

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

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

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

為了結(jié)束數(shù)據(jù)傳輸，用戶應(yīng)用程序在 s_axi_tx_tkeep 總線上置位 s_axi_tx_tlast、最后一個數(shù)據(jù)字節(jié)和適當(dāng)?shù)闹怠?在此示例中，s_axi_tx_tkeep 在波形中設(shè)置為 N，以指示所有字節(jié)在最后一個數(shù)據(jù)節(jié)拍中均有效。 當(dāng) s_axi_tx_tlast 被置位時，s_axi_tx_tready 在下一個時鐘周期被置低，內(nèi)核使用數(shù)據(jù)流中的間隙發(fā)送最終的偏移數(shù)據(jù)字節(jié)和 /ECP/ 有序集，指示幀結(jié)束。  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ù)字和一個部分?jǐn)?shù)據(jù)字。 在此示例中，s_axi_tx_tkeep 設(shè)置為 N–1 以指示最后一個數(shù)據(jù)字中的 n–1 個有效字節(jié)。

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

下圖顯示了用戶接口如何在幀傳輸期間暫停數(shù)據(jù)傳輸。 在此示例中，用戶應(yīng)用程序在前 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é)設(shè)計需要 5,000 個時鐘；每通道 4 字節(jié)設(shè)計需要 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 信號。 用戶應(yīng)用程序控制來自 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。 這些停頓是框架字符解碼和左對齊過程的結(jié)果。

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

image-20220602105222294

數(shù)據(jù)顯示在 m_axi_rx_tdata 總線上。 當(dāng)前 n 個字節(jié)放置在總線上時，m_axi_rx_tvalid 被置位以指示數(shù)據(jù)已準(zhǔn)備好供用戶應(yīng)用程序使用。 內(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ù)。 在幀結(jié)束時，內(nèi)核斷言 m_axi_rx_tlast。 內(nèi)核還計算 m_axi_rx_tkeep 總線的值，并根據(jù)幀最后一個字中的有效字節(jié)總數(shù)將其呈現(xiàn)給用戶應(yīng)用程序。

成幀效率

有兩個因素會影響 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（幀結(jié)束）。 具有奇數(shù)字節(jié)的 Aurora 8B/10B 幀具有 5 個字節(jié)的開銷、4 個字節(jié)的成幀開銷以及一個用于填充字節(jié)的附加字節(jié)。

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

使用公式中所示的公式計算任意通道數(shù)、任意接口寬度和任意字節(jié)數(shù)幀的設(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 通道通道的開銷。 由于開始和結(jié)束字符以及填充通道所需的空閑，生成的數(shù)據(jù)單元為 264 字節(jié)長。 這相當(dāng)于發(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é)議。

當(dāng) s_axi_tx_tvalid 被置低時，字之間會產(chǎn)生間隙并保留間隙，除非正在傳輸時鐘補償序列。當(dāng)數(shù)據(jù)到達(dá) Aurora 8B/10B 通道的 RX 側(cè)時，它會呈現(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 來指示它已準(zhǔn)備好傳輸數(shù)據(jù)。 一個周期后，用戶邏輯通過置位 s_axi_tx_tdata 總線和 s_axi_tx_tvalid 信號來指示它已準(zhǔn)備好傳輸數(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 側(cè)的 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é)。用戶應(yīng)用程序通過驅(qū)動 s_axi_ufc_tx_tdata 端口上的 SIZE 代碼來指定消息的長度。 下表 顯示了 UFC 消息的合法 SIZE 代碼值。

要發(fā)送 UFC 消息，用戶應(yīng)用程序在使用所需 SIZE 代碼驅(qū)動 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 置位后的第一個周期開始。 當(dāng) s_axi_tx_tdata 端口用于 UFC 數(shù)據(jù)時，內(nèi)核將 s_axi_tx_tready 置低。只有在完成當(dāng)前的 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ù)可用之前，不應(yīng)啟動 UFC 消息。 與常規(guī)數(shù)據(jù)不同，UFC 消息在 s_axi_ufc_tx_tready 被斷言后不能被中斷，直到當(dāng)前 UFC 消息完成。

傳輸單周期 UFC 消息

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

傳輸多周期 UFC 消息

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

接收UFC消息

當(dāng) Aurora 8B/10B 內(nèi)核接收到 UFC 消息時，它會通過專用的 UFC AXI4-Stream 接口將數(shù)據(jù)傳遞給用戶應(yīng)用程序。 數(shù)據(jù)呈現(xiàn)在 m_axi_ufc_rx_tdata 端口上；  m_axi_ufc_rx_tvalid 表示消息數(shù)據(jù)的開始，m_axi_ufc_rx_tlast 表示結(jié)束。  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 來向用戶應(yīng)用程序提供此數(shù)據(jù)以指示單個周期幀。m_axi_ufc_rx_tkeep 設(shè)置為 4'hF，表示只有接口的四個最高有效字節(jié)有效。

接收多周期 UFC 消息

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

Native Flow Control

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

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

原生流控制接口

NFC 接口是在生成內(nèi)核并啟用 NFC 選項時創(chuàng)建的。 此接口包括用于發(fā)送 NFC 消息的請求 (s_axi_nfc_tx_tvalid) 和確認(rèn)(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] 位上驅(qū)動。

用戶應(yīng)用程序斷言 s_axi_nfc_tx_tvalid 并將 NFC 代碼寫入 s_axi_nfc_tx_tdata。  NFC 代碼指示通道合作伙伴應(yīng)在其 TX 數(shù)據(jù)流中插入的最小空閑周期數(shù)。 用戶應(yīng)用程序必須保持 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 消息示例

下圖顯示了用戶應(yīng)用程序向通道伙伴發(fā)送 NFC 消息時的傳輸時序示例。s_axi_nfc_tx_tready 信號被置低一個周期（假設(shè) 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)和控制端口允許應(yīng)用程序監(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)信號

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

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

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

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

全雙工初始化

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

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

單工內(nèi)核

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

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

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

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

初始化

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

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

使用反向通道

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

使用定時器

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

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

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

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

收發(fā)器接口

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

時鐘接口

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

Clock Ports for Aurora 8B/10B Core

下表提供了有關(guān)由于選擇共享邏輯選項而導(dǎo)致的端口更改的詳細(xì)信息。

CRC

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

生成無 GT 的 Aurora

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

reference

PG046