現代 RF 信號鏈對于跨多通道的數據轉換器性能具有極高的要求。換言之，對于賽靈思 RF Data Converter 而言，關鍵要求之一是在多個 ADC/DAC Tile、RFSoC 器件甚至開發板之間都必須保持同步。

了解賽靈思如何探索多塊同步 (Multi-Tile Synchronization) 問題解決之道，以支持實現波束成形、大規模 MIMO (Massive MIMO) 和相位陣列雷達。

迄今為止，我們已通過前文 https://forums.xilinx.com/t5/Design-and-Debug-Techniques-Blog/RF-Data-Co... 學習了有關 RF Data Converter 軟件驅動的知識，并已深入了解了支持您對任意開發板上的任意器件上的 RF-ADC 和 RF-DAC 進行調試的 RF Analyzer。

趁熱打鐵，讓我們來探討下對于使用 RFSoC 的諸多客戶都至關重要的一個話題，即跨單一器件或跨多個器件上的多個 Tile 實現時延對齊的要求。

我們將此要求稱為“多塊同步 (Multi-Tile Synchronization)”。

“多塊同步”是實現大規模 MIMO、波束成形和相位陣列雷達應用的關鍵。

例如，在波束成形中，目標不僅是全向廣播能量，而是使用天線陣列定向傳輸射頻信號。在此應用技巧中，將為每個天線元件單獨饋送要傳輸的信號。隨后，將以建設性和破壞性方式添加每個信號副本的相位和波幅，使其將能量集中于窄波束或波瓣中。

由此可見，需要使用大量數據轉換器來構建陣列，并且在天線陣列中的所有通道之間存在時延對齊要求。

讓我們將此情境下應用時延對齊的構想進一步擴展。這可分為時延對齊和時延確定性。

時延對齊表示所有通道間的相對時延都是相同的，而時延確定性則意味著每次啟動時所有通道間的總時延都保持不變。在某些情況下，時延確定性和時延對齊都是必需的。

在啟動 RF Data Converter 時，轉換器是單個始終對齊的 Tile，但無法保證確定性時延。在多塊系統中，Tile 間無法保證確定性時延，甚至無法保證時延對齊。這意味著我們必須提供相應的機制來將這些 Tile 對齊。這是在 IP 內部實現的，由軟件驅動中的 API 調用來管理。

了解多塊同步如何真正實現對齊的最簡單的方法是首先了解我們嘗試消除的對齊不確定性的來源。 我們將詳細討論這方面的內容，但在此之前有必要先做些功課。

在 IP 中啟用此功能并使用軟件 API 來使 Tile 對齊的必要性毋庸置疑，但這整套機制的作用只是在 Tile 間提供數字化對齊。除此之外還必須遵循 PCB 和時鐘設置規則。欲知詳情，請參閱《PCB 設計用戶指南》。

有鑒于此，我們將聊一聊您將遇到的時延不確定性的來源。請看下圖。

我已經對各 Tile 之間的時延不匹配的各種原因進行了編號：

1. 采樣時鐘偏差：

RF-ADC 或 RF-DAC Tile 時鐘輸入需對齊，其中存在的任意不匹配問題都意味著轉換器無法在同一時刻進行采樣。這永遠無法在內部加以糾正。因此，必須在 PCB 上對走線進行延遲匹配。

2. Tile PLL 分頻器相位：

如果使用“Tile PLL”來創建采樣時鐘，那么在 2 個 Tile 間將無法保證 PLL 上的輸出分頻器相位相同。原因在于，啟動時復位完成的時間無法得到控制。Tile 間的所有這些分頻器都需要同步復位，才能實現對齊。

3. DUC/DDC 數字時鐘分頻器相位：

同理，RF-ADC 和 RF-DAC Tile 的數字部分在轉換器采樣時鐘的分配版本上運行。在 Tile 間無法保證這些分頻器完成復位時處于相同相位。這些分頻器需達成統一的復位狀態。

4. 雙時鐘 FIFO 讀寫指針版本：

在“Tile”與“PL 結構 (PL Fabric)”之間安全傳遞數據的 FIFO 可包含 M 或 M+1 個時延讀取周期，這取決于讀取使能處于已斷言狀態還是寫入狀態。這意味著需要通過某種糾正措施來實現 Tile 同步。

為解決上述問題，我們提供了一種支持跨 Tile 同步的解決方案。它是在 IP 內實現的，并在 RFDC 驅動中包含一組 API 調用以供其控制。此方案的關鍵是我們借用了 JESD204B 使用的 SYSREF 概念。我們將使用 SYSREF 作為系統的公用時序參考。在 (PG269) 和 (UG583) 中涵蓋了 SYSREF 的部分規則，我將在講解過程中將其與同步過程關聯。我們需將 SYSREF 提供給 Tile 和 PL 結構（分別稱為“模擬 SYSREF”和“PL SYSREF”）。原因稍后揭曉。

但首先該怎么做呢？在了解解決方案前，有些 PCB 問題值得注意下。

ADC 和 DAC Tile 采樣時鐘必須全部實現相位對齊，并同時到達 Tile 時鐘輸入。并且，DAC 輸出路徑和 ADC 輸入路徑必須實現延遲匹配。請謹記，該解決方案僅在此處提供數字化對齊，完成 Tile 同步后，時鐘或數據線不匹配將顯示為殘差。

“模擬 SYSREF”和“PL SYSREF”信號必須布線到 RFSoC 以使其能同時到達其各自的輸入。（這至關重要，稍后我們將講解原因。）

在設計中，必須為要在 IP 中同步的 Tile 啟用 MTS。

請謹記，編號最小的 DAC 和 ADC Tile 始終必須包含在同步組中。

軟件應用必須包含 API 調用才能在運行時執行多塊同步。

另一個實用的步驟是將 metal 日志的日志級別設置為 DEBUG，以便對設置中的 MTS 進行測試。metal 日志提供了 MTS 過程的詳細信息，調試 MTS 問題時此日志至關重要。

在軟件應用中，需聲明 ADC 和 DAC 同步組的結構。

您將需要初始化并設置這些結構才能執行 MTS。

在最簡單的情況下，只需指定要同步的 Tile，并調用多塊同步函數 XRFdc_MultiConverter_Sync 以使 IP 對齊 Tile：

那么 API 運行時究竟會做什么呢？

metal 日志可以解答這個問題。

首先，SysRef 將分布到要同步的所有 Tile。 然后，使用 Tile 中的模擬采樣時鐘通過延遲抽頭鏈 (DTC) 來捕獲 SYSREF。如果在 Tile 中已啟用 PLL，那么通過 PLL VCO 同樣可安全捕獲 SYSREF。

在日志中可以看到，它從延遲抽頭鏈中間的抽頭 64 處開始，并通過掃描來查找理想抽頭，以使 SysRef 位于采樣時鐘周期中間。

metal:info: DTC Scan T1

metal:debug: Target 64, DTC Code 7, Diff 57, Min 57

metal:debug: Target 64, DTC Code 44, Diff 20, Min 20

metal:debug: Target 64, DTC Code 93, Diff 29, Min 20

metal: debug: RefTile (0): DTC Code Target 64, Picked 44

metal:info: ADC0:00000000000000011113222220000000000000000000*0000000000000000000#111322222200000000000000000000000000000000000000111122222000000

metal:debug: Tile (1): Max/Min 44/44, Range 0

metal:debug: Tile (1): Code 9, New-Range: 35, Min-Range: 35

metal:debug: Tile (1): Code 47, New-Range: 3, Min-Range: 3

metal:debug: Tile (1): Code 96, New-Range: 52, Min-Range: 3

metal:debug: Tile (1): Code 47, Range Prev 0, New 3

metal:info: ADC1:00000000000000000001111322222000000000000000#00*00000000000000000001111322222000000000000000000000000000000000000000111132222200

請注意 DTC 掃描中的 0 值。這是時鐘周期中的穩定部分，由表示轉換的 1/2/3 綁定。您將看到掃描置入 1 個 # 和 1 個 *。井號表示起點，星號表示所在的 DTC 代碼。它將使用所選代碼來為下一個 Tile 設置 DTC 起點。在 Tile 0 處可看到，它在抽頭 44 處找到理想代碼，然后在 Tile 1 中以代碼 44 開始，嘗試幾條代碼，最終止于代碼 47 上。

因此我們要求 SYSREF 信號必須為高質量、自由運行的低抖動方波。如果有噪聲，那么在捕獲處將出現不匹配，從而導致 Tile 間不匹配。

在 Tile 中安全捕獲后，即可使用 SYSREF 來將 Tile 中數字部分的所有 Tile 同步復位。因此，SYSREF 頻率必須是對其進行采樣的全局時鐘分頻器 GCD（DAC_Sample_Rate/16，ADC_Sample_Rate/16）的整數約數以及任意 PL 端時鐘的整數約數。

完成此分頻器復位后，在所有 Tile 將實現有效的公用時鐘。Tile 內部所有一切都會實現對齊。回看前文中顯示時延不對齊問題來源的圖示，可以看到我們已經解決了其中第 2 和第 3 項。

但任務并沒有結束，因為我們需要考慮 Tile 之間源自雙時鐘 FIFO 的固有不匹配問題。具體該怎么辦呢？

首先，必須捕獲 PL 時鐘域中 PL 用戶 SYSREF 以及 AXI-Stream 時鐘域中的 PL 用戶 SYSREF（如果與前者不同）。這同樣解釋了為什么 SYSREF 必須是所有 PL 時鐘的整數約數。現已安全捕獲 PL 時鐘域中的 SYSREF。

前文中我提到過我會解釋為何需要模擬 Tile 端 SYSREF 和 PL 用戶 SYSREF，以及為何要求它們同時到達其各自的輸入。

MTS 的下一步是有效提取 PL 用戶 SYSREF 和 Tile SYSREF，將 Tile 間這兩者各自的飛行時間進行比較。

由于這兩者在器件球形封裝處對齊，因此可安全捕獲，并同時到達 FIFO 的某一端。因此，“飛行時間”或 Tile 間相對時延的任意不匹配的唯一可能來源就是 FIFO。在此情況下，我們使用 IP 將所謂的標記位插入 FIFO。它用于停止 FIFO 讀取端的標記計數器。隨后，將對標記計數器進行比較。然后，我們即可調整 FIFO 的讀取指針，以使所有 FIFO 都匹配。

metal 日志中顯示了標記計數器讀數以及執行的所有調整。

metal: debug: Marker Read Tile 0,FIFO 0 - 00006000 = 0000: count=41, loc=0, done=1

metal: info: DAC0: Marker: - 41,0

metal: debug: Marker Read Tile 1,FIFO 0 - 0000A000 = 0000: count=41, loc=0, done=1

metal: info: DAC1: Marker: - 41,0

metal: info: SysRef period interms of DAC T1s = 1024

metal: info: DAC target latency =656

metal: debug: Tile 0, latency656, max 656

metal: debug: Tile 1, latency640, max 656

metal: debug: Target 656, Tile 0,delta 0, i/f_part 0/0, offset 0

metal: debug: Target 656, Tile 1,delta 0, i/f_part 0/0, offset 0

最后，可生成 MTS 調整報告。

=== Multi-Tile Sync Report ===

DAC0: Latency(T1) =656, AdjustedDelayOffset(T8) = 0

DAC1: Latency(T1) =656, AdjustedDelayOffset(T8) = 0

DAC2: Latency(T1) =656, AdjustedDelayOffset(T8) = 0

DAC3: Latency(T1) =656, AdjustedDelayOffset(T8) = 0

執行 Tile 同步后，可以觀察硬件中的時延對齊。

以下捕獲顯示了執行 MTS 后 28DR 上全部 8 個 ADC 的單調輸入結果。

遵循所有準則的前提下，應在 +/-1 T1 時鐘周期規格內實現對齊。

實際上，在 T1 小范圍內會出現殘差不匹配。如前文所述，此不匹配實際上來自模擬 I/O 的 PCB 走線和 Tile 輸入時鐘。

那么確定性時延該如何解決？

文初提到在某些情況下啟動時，時延對齊和時延確定性都是必需的。在 MTS API 中內置此功能。

MTS 的數據結構成員之一是 Target_Latency。可通過設置此值來提供 IP 調整目標，以便在 FIFO 處始終得到相同時延。

具體過程是將目標時延設置為 0，并觀察含最大時延測量值的 FIFO，為其添加裕度，然后將該值設置為新目標。

此裕度以采樣時鐘數量來表示。對于 RF-ADC Tile，該值必須為 FIFO 讀取字數量的倍數乘以取樣因數，對于 RF-DAC Tile，顯示常數 16，此常數非常實用。

請謹記，MTS 的默認行為是將 Tile 對齊，因此如果目標設置過低，metal 日志將發出警告，表明它無法滿足該目標值并且僅對 Tile 進行同步。

最后點評：

在本文中，我嘗試解釋 MTS 的工作方式并將其與 metal 日志相關聯。我希望本篇博文能為您提供有關多塊同步解決方案的更多見解，幫助您將來自 IP 產品指南、PCB 指南以及您使用該功能的自身經驗有機結合，并幫助您理解來自 metal 日志的各種消息。

在 metal 日志中還包含許多其它錯誤報告方面的功能，這些功能可為將來 MTS 故障調試相關博文提供基礎。