Aurora8B10B IP使用 -01- 簡介與端口描述

FPGA and ICer 1星期前 94 閱讀 2 贊 3 收藏 0 評論

Aurora 8B/10B IP概述

介紹

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

特點

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

IP概述

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

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

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

應用

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

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

內核結構

下圖顯示了 Aurora 8B/10B 內核的實現框圖。

Aurora 8B/10B 內核的主要功能模塊有：

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

延遲性能簡述

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

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

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

吞吐量性能簡述

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

端口描述

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

用戶接口

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

數據端口寬度取決于通道寬度和所選通道數。

頂層架構

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

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

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

用戶接口端口

下表列出了雙工和單工內核 AXI4-Stream TX 和 RX 數據端口說明。

USER_DATA_S_AXI_TX

USER_DATA_M_AXI_RX

幀接口

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

傳輸數據

為了傳輸數據，用戶應用程序操縱控制信號使內核執行以下操作：

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

當內核接收數據時，它會執行以下操作：

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

Aurora 8B/10B 內核僅在 s_axi_tx_tready 和 s_axi_tx_tvalid 均置位（高）時對數據進行采樣。

AXI4-Stream 數據僅在成幀時有效。幀外的數據被忽略。

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

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

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

Aurora 8B/10B 幀

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

長度

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

傳輸示例

簡單數據傳輸

下圖顯示了在 n 字節寬的 AXI4-Stream 接口上進行簡單數據傳輸的示例。

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

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

使用填充的數據傳輸

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

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

帶暫停的數據傳輸

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

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

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

接收數據

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

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

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

下圖顯示了一個 3n 字節的接收數據被暫停中斷的示例。

image-20220602105222294

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

成幀效率

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

幀大小。
數據路徑的寬度。

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

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

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

使用公式中所示的公式計算任意通道數、任意接口寬度和任意字節數幀的設計效率。該公式包括時鐘補償的開銷。

其中：

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

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

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

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

流接口

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

流接口端口

USER_DATA_S_AXI_TX

USER_DATA_M_AXI_RX

收發數據

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

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

傳輸示例

TX 流數據傳輸

下圖顯示了流數據的典型示例。

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

RX 流數據傳輸

下圖顯示了數據傳輸的接收端。

流量控制

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

用戶流控制接口

UFC 接口是在生成內核并啟用 UFC 時創建的，如下圖。

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 消息提供給數據端口。

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

UFC I/O 端口描述

UFC_S_AXIS_TX

UFC_M_AXIS_RX

傳輸 UFC 消息

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

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

下圖顯示了一個用于將 TX_D 從發送常規數據切換到 UFC 數據的電路。

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

傳輸單周期 UFC 消息

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

傳輸多周期 UFC 消息

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

接收UFC消息

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

接收單周期 UFC 消息

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

接收多周期 UFC 消息

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

Native Flow Control

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

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

原生流控制接口

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

下表列出了僅在全雙工 Aurora 8B/10B 內核中可用的 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 數據流中插入的最小空閑周期數。用戶應用程序必須保持 s_axi_nfc_tx_tvalid 和 s_axi_nfc_tx_tdata，直到 s_axi_nfc_tx_tready 被置位。 Aurora 8B/10B 內核在發送 NFC 消息時無法傳輸數據。s_axi_tx_tready 總是在 s_axi_nfc_tx_tready 斷言之后的周期被取消斷言。

發送 NFC 消息示例

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

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

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

狀態、控制和收發器接口

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

狀態和控制端口

下表描述了 Aurora 8B/10B 內核的每個狀態和控制端口的功能。

全雙工內核

全雙工狀態和控制端口

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

錯誤狀態信號

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

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

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

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

全雙工初始化

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

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

單工內核

單工 TX 狀態和控制端口

單工 TX 內核允許用戶應用程序將數據傳輸到單工 RX 內核。他們沒有 RX 連接。下圖顯示了單工 TX 內核的狀態和控制接口。

單工 RX 狀態和控制端口

單工 RX 內核允許用戶應用程序從單工 TX 內核接收數據。下圖顯示了單工 RX 內核的狀態和控制接口。

初始化

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

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

使用反向通道

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

使用定時器

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

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

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

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