前言

承接上文，本文主要介紹了關于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 斷言的推薦過程。

image-20220602203551582

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 (C)

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)，以及內核或示例設計中的時鐘和復位邏輯。

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

共享邏輯的內容取決于物理接口和目標設備。共享邏輯包含收發器差分緩沖區 (IBUFDS_GTE2/IBUFDS_GTE3) 的實例、支持復位邏輯和 _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

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 協議規范 ，使用內核生成標準時鐘補償模塊 _standard_cc_module.v[hd]。standard_cc_module 處理時鐘補償字符的生成周期，如下表中所述。可以使用 CC_FREQ_FACTOR 控制周期性。

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

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

使用小端支持

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

reference

PG046