Aurora8B10B IP使用 -02- IP功能設計技巧

前言

承接上文，本文主要介紹了關於IP核中一些功能的配置的方法和技巧使用的示例，主要參考了IP手册的第三章內容。

複比特和斷電

複比特

複比特信號用於將 Aurora 8B/10B 內核設置為已知的啟動狀態。 複比特時，內核停止任何當前操作並重新初始化一個新通道。

在全雙工模塊上，複比特信號複比特通道的 TX 和 RX 端。在單工模塊上，tx_system_reset 複比特 TX 通道，而 rx_system_reset 複比特 RX 通道。 gt_reset 信號複比特收發器，最終複比特內核。tx_system_reset 與單工邊帶接口上使用的 tx_reset 和 rx_reset 信號是分開的。

示例

雙工內核中的複比特斷言

雙工內核中的複比特斷言應至少有六個 user_clk 時間段。 因此，channel_up 在三個 user_clk 周期後被置低，如下圖所示。

雙工內核中的 gt_reset 斷言

下圖顯示了雙工內核中的 gt_reset 斷言，應該至少有六個 init_clk_in 時間段。 因此，user_clk 在幾個時鐘周期後停止，因為沒有來自收發器的 txoutclk 並且 channel_up 隨後被置低。

單工內核中的 tx_system_reset 和 rx_system_reset 斷言

下圖顯示了系統中連接的單工 TX 內核和單工 RX 內核。TX_IP 和 RX_IP 可以在同一個或多個設備中。

下圖顯示了單工內核中 tx_system_reset 和 rx_system_reset 斷言的推薦過程。

1. tx_system_reset 和 rx_system_reset 被置比特至少六個時鐘 user_clk 時間段。
2. tx_channel_up 和 rx_channel_up 在三個 user_clk 周期後被置低。
3. rx_system_reset 被置低（或）在 tx_system_reset 被置低後釋放。這確保了單工 TX 內核中的收發器更早地開始傳輸初始化數據，並提高了單工 RX 內核與正確數據序列對齊的可能性。
4. rx_channel_up 在 tx_channel_up 斷言之前被斷言。 單工 RX 內核必須滿足此條件，單工 TX 內核中的單工定時器參數（C_ALIGNED_TIMER、C_BONDED_TIMER 和 C_VERIFY_TIMER）需要調整以滿足此標准。
5. 當 simplex-TX 內核在配置的時間內完成 Aurora 8B/10B 協議通道初始化序列傳輸時，tx_channel_up 被置比特。 tx_channel_up last 的斷言確保 simplex-TX 內核在 simplex-RX 內核准備好時發送 Aurora 初始化序列。

Aurora 8B/10B Duplex Power On Sequence（雙工上電序列）

在板子上電序列期間，gt_reset 和 reset 信號都必須為高電平。收發器參考時鐘 (GT_REFCLK) 和內核自由運行時鐘 (INIT_CLK) 預計在上電期間保持穩定，以便 Aurora 8B/10B 內核正常運行。

Aurora 8B/10B Duplex Normal Operation Reset Sequence（雙工正常操作複比特序列）

在正常操作期間，複比特信號預計在 gt_reset 信號置比特之前至少置比特 128 個 user_clk 時間段，以確保可編程邏輯中的內核部分達到已知複比特狀態 在gt_reset 的斷言而抑制 user_clk 信號之前，如下所示。

Aurora 8B/10B Simplex Power On Sequence（單工上電順序）

在上電期間，TX simplex 和 RX simplex 內核的 gt_reset 和 reset 信號預計為高電平。 預計 INIT_CLK 和 GT_REFCLK 在上電期間是穩定的。 必須先將TX板上的gt_reset信號置低，然後再將RX端的gt_reset置低； 這可確保在 RX 側正確鎖定 CDR，如下圖所示。

單工上電序列：

1. 解除 TX 端 gt_reset (A)

2. 解除 RX 端 gt_reset

3. 解除 RX 端同步到 user_clk (D)

4. 解除 TX 端同步到 user_clk (B)

   注意：必須注意確保 (D) 到 (B) 的時間差盡可能小。

Aurora 8B/10B Simplex Normal Operation Reset Sequence（單工正常操作複比特序列）

對於單工配置，建議 TX 側複比特序列與 RX 側複比特序列緊密耦合，因為 TX 和 RX 鏈路沒有通信反饋路徑。 請注意，如果 RX 端被複比特，則沒有直接的機制來通知 TX 端複比特。 因此，對於 Aurora 8B/10B 單工內核，需要在系統級別處理複比特耦合。 每次 TX 側複比特之後必須跟隨 RX 側，如下圖所示，RX 側複比特無效和 TX 側複比特無效之間的時間必須盡可能短。 在置比特 gt_reset 之前，至少需要 128 個時鐘周期，以確保在 gt_reset 的置比特抑制 user_clk 之前，可編程邏輯中的內核部分達到已知的複比特狀態。 gt_reset 的斷言時間必須至少為六個 init_clk 時間段，以滿足內核中包含的去抖動電路。

斷電

這是一個高電平有效信號。 斷言powerdown時，Aurora 8B/10B 內核中的收發器將關閉，將它們置於非工作、低功耗模式。 取消斷言斷電時，內核會自動複比特。 gt_reset 必須在powerdown 後置比特後置比特。

Shared Logic（共享邏輯）

Vivado IDE 中的共享邏輯選項將內核配置為包括可共享資源，例如收發器四通道 PLL (QPLL)、收發器差分 refclk 緩沖器 (IBUFDS_GTE2)，以及內核或示例設計中的時鐘和複比特邏輯。

共享邏輯層次結構稱為 <component_name>_support。 圖 3-9 和圖 3-10 顯示了兩個層次結構，其中共享邏輯塊包含在內核或示例設計中。 兩個層次的區別在於核心的邊界。 它使用 Vivado中的 Shared Logic 選項進行控制。當共享邏輯比特於內核中時，Single Ended 選項將從內核中排除相應的差分時鐘緩沖器。

共享邏輯的內容取决於物理接口和目標設備。共享邏輯包含收發器差分緩沖區 (IBUFDS_GTE2/IBUFDS_GTE3) 的實例、支持複比特邏輯和 <USER_COMPONENT_NAME:>_CLOCK_MODULE 的實例化。 共享邏輯還包含基於所選收發器類型的收發器公共實例 GTPE2_COMMON、GTXE2_COMMON 或 GTHE2_COMMON。 支持複比特邏輯包含用於複比特和 gt_reset 端口的去抖動邏輯。

Aurora 8B/10B 內核使用 CPLL，不使用 QPLL（即 GTXE2_COMMON/GTHE2_COMMON）。 QPLL 用於 Zynq-7000 和 7 系列器件，並在共享邏輯中進行實例化，以與其他賽靈思串行連接內核保持一致。

下錶列出了每個系列的的共享資源。

Sharable Resources

Transceiver Type used in the Aurora 8B/10B Core	Resources
Zynq-7000 and 7 series device GTX/GTH/GTP transceivers in 2-byte mode	IBUFDS_GTE2: transceiver reference clock GT*_COMMON: transceiver clocking; BUFG: clocking IBUFDS: init_clk
Zynq-7000 and 7 series device GTX/GTH/GTP transceivers in 4-byte mode	IBUFDS_GTE2: transceiver reference clock GT*_COMMON: transceiver clocking MMCM: clocking 2xBUFG: clocking; IBUFDS: init_clk
UltraScale GTH Transceivers	IBUFDS_GTE3: transceiver reference clock BUFG_GT: clocking
UltraScale+ GTH Transceivers	IBUFDS_GTE4: transceiver reference clock BUFG_GT: clocking

gt_refclk1_out 和 gt_refclk2_out 信號可以由設計中的其他收發器共享，並且應遵循收發器時鐘指南以實現連接性和收發器四通道鄰近性。圖 3-11 顯示了從包含共享邏輯的內核 (aurora_8b10b_0) 到另一個不包含共享邏輯的內核實例 (aurora_8b10b_1) 的可共享資源連接。 某些端口可能會根據內核配置和所選收發器的類型而改變。

Using the Scrambler/Descrambler（使用擾碼器/解擾器）

一個 16 比特加擾器/解擾器，用於具有多項式的數據：G(x) = X16 + X5 + X4 + X3 + 1，可在 < component name>_scrambler.v[hd] 中獲得 模塊。它確保在很長一段時間內不會出現重複數據。 加擾器和解擾器分別基於時鐘補償字符的發送和接收進行同步。擾碼器僅影響數據符號。

使用 CRC

為用戶數據實現的 16 比特或 32 比特 CRC 在 < component name>_crc_top.v[hd] 模塊中可用。

為 2 字節設計生成 CRC16，為 4 字節設計生成 CRC32。 crc_valid 和 crc_pass_fail_n 信號指示接收到的 CRC 與發送的 CRC 的結果。 CRC-CCITT (16’h1021) 和標准以太網多項式 (32’h04C11DB7) 分別用作 16 比特和 32 比特的 CRC 多項式。CRC 是按通道計算的，並以數據為後綴。 在接收器 AXI 接口處，CRC 被删除，數據包按照發送器的 AXI 接口接收到的方式發送。 下圖說明了如何在沒有 CRC 的情况下發送相同的數據包以及何時啟用 CRC 選項。

熱插拔邏輯

Aurora 8B/10B 中的熱插拔邏輯（使用自由運行的 init_clk 信號）基於接收到的時鐘補償字符。 Aurora RX 接口接收到時鐘補償字符意味著通信通道處於活動狀態且未中斷。 如果在預定時間內沒有接收到時鐘補償字符，熱插拔邏輯將複比特內核和收發器。 時鐘補償模塊必須用於 Aurora 8B/10B 設計。

時鐘補償

時鐘補償功能允許在 Aurora 8B/10B 通道的每一側使用的參考時鐘頻率差异高達 ±100ppm。 根據 Aurora 8B/10B 協議規範 ，使用內核生成標准時鐘補償模塊 <component_name>_standard_cc_module.v[hd]。
standard_cc_module 處理時鐘補償字符的生成周期，如下錶中所述。 可以使用 CC_FREQ_FACTOR 控制周期性。

Lane Width	DO_CC 之間的 USER_CLK 周期	DO_CC 持續時間（USER_CLK 周期）
2	5,000	6
4	2,500	3

防止 16 字節 UFC 消息與時鐘補償序列沖突所需的先行周期數取决於通道中的通道數和每個通道的寬度。在時鐘補償字符傳輸期間，本機流控制消息請求未被確認。 這有助於防止 NFC 消息和時鐘補償序列發生沖突。參數 CC_FREQ_FACTOR 確定 CC 序列的頻率。 任何增加或减少參數的嘗試都應該經過仔細的分析和測試。

確保選擇的持續時間和周期足以校正所用時鐘頻率之間的最大差异。不要在彼此的八個周期內執行多個時鐘校正序列。用CC 序列替換長的空閑序列（>12 個周期）可以降低EMI。

使用小端支持

Aurora 8B/10B 內核默認支持大端格式的用戶界面。 它還支持小端格式以無縫連接到符合 AXI4-Stream 的 IP 內核。

reference

1. PG046