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

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

迄今為止，我們已通過前文 https://forums.xilinx.com/t5/Design-and-Debug-Techniques-Blog/RF-Data-Co... 學(xué)習(xí)了有關(guān) RF Data Converter 軟件驅(qū)動的知識，并已深入了解了支持您對任意開發(fā)板上的任意器件上的 RF-ADC 和 RF-DAC 進(jìn)行調(diào)試的 RF Analyzer。

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

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

“多塊同步”是實(shí)現(xiàn)大規(guī)模 MIMO、波束成形和相位陣列雷達(dá)應(yīng)用的關(guān)鍵。

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

由此可見，需要使用大量數(shù)據(jù)轉(zhuǎn)換器來構(gòu)建陣列，并且在天線陣列中的所有通道之間存在時延對齊要求。

讓我們將此情境下應(yīng)用時延對齊的構(gòu)想進(jìn)一步擴(kuò)展。這可分為時延對齊和時延確定性。

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

在啟動 RF Data Converter 時，轉(zhuǎn)換器是單個始終對齊的 Tile，但無法保證確定性時延。在多塊系統(tǒng)中，Tile 間無法保證確定性時延，甚至無法保證時延對齊。這意味著我們必須提供相應(yīng)的機(jī)制來將這些 Tile 對齊。這是在 IP 內(nèi)部實(shí)現(xiàn)的，由軟件驅(qū)動中的 API 調(diào)用來管理。

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

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

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

我已經(jīng)對各 Tile 之間的時延不匹配的各種原因進(jìn)行了編號：

1. 采樣時鐘偏差：

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

2. Tile PLL 分頻器相位：

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

3. DUC/DDC 數(shù)字時鐘分頻器相位：

同理，RF-ADC 和 RF-DAC Tile 的數(shù)字部分在轉(zhuǎn)換器采樣時鐘的分配版本上運(yùn)行。在 Tile 間無法保證這些分頻器完成復(fù)位時處于相同相位。這些分頻器需達(dá)成統(tǒng)一的復(fù)位狀態(tài)。

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

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

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

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

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

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

在設(shè)計(jì)中，必須為要在 IP 中同步的 Tile 啟用 MTS。

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

軟件應(yīng)用必須包含 API 調(diào)用才能在運(yùn)行時執(zhí)行多塊同步。

另一個實(shí)用的步驟是將 metal 日志的日志級別設(shè)置為 DEBUG，以便對設(shè)置中的 MTS 進(jìn)行測試。metal 日志提供了 MTS 過程的詳細(xì)信息，調(diào)試 MTS 問題時此日志至關(guān)重要。

在軟件應(yīng)用中，需聲明 ADC 和 DAC 同步組的結(jié)構(gòu)。

您將需要初始化并設(shè)置這些結(jié)構(gòu)才能執(zhí)行 MTS。

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

那么 API 運(yùn)行時究竟會做什么呢？

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 值。這是時鐘周期中的穩(wěn)定部分，由表示轉(zhuǎn)換的 1/2/3 綁定。您將看到掃描置入 1 個 # 和 1 個 *。井號表示起點(diǎn)，星號表示所在的 DTC 代碼。它將使用所選代碼來為下一個 Tile 設(shè)置 DTC 起點(diǎn)。在 Tile 0 處可看到，它在抽頭 44 處找到理想代碼，然后在 Tile 1 中以代碼 44 開始，嘗試幾條代碼，最終止于代碼 47 上。

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

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

完成此分頻器復(fù)位后，在所有 Tile 將實(shí)現(xiàn)有效的公用時鐘。Tile 內(nèi)部所有一切都會實(shí)現(xiàn)對齊?；乜辞拔闹酗@示時延不對齊問題來源的圖示，可以看到我們已經(jīng)解決了其中第 2 和第 3 項(xiàng)。

但任務(wù)并沒有結(jié)束，因?yàn)槲覀冃枰紤] Tile 之間源自雙時鐘 FIFO 的固有不匹配問題。具體該怎么辦呢？

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

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

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

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

metal 日志中顯示了標(biāo)記計(jì)數(shù)器讀數(shù)以及執(zhí)行的所有調(diào)整。

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 調(diào)整報(bào)告。

=== 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

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

以下捕獲顯示了執(zhí)行 MTS 后 28DR 上全部 8 個 ADC 的單調(diào)輸入結(jié)果。

遵循所有準(zhǔn)則的前提下，應(yīng)在 +/-1 T1 時鐘周期規(guī)格內(nèi)實(shí)現(xiàn)對齊。

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

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

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

MTS 的數(shù)據(jù)結(jié)構(gòu)成員之一是 Target_Latency?？赏ㄟ^設(shè)置此值來提供 IP 調(diào)整目標(biāo)，以便在 FIFO 處始終得到相同時延。

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

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

請謹(jǐn)記，MTS 的默認(rèn)行為是將 Tile 對齊，因此如果目標(biāo)設(shè)置過低，metal 日志將發(fā)出警告，表明它無法滿足該目標(biāo)值并且僅對 Tile 進(jìn)行同步。

最后點(diǎn)評：

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

在 metal 日志中還包含許多其它錯誤報(bào)告方面的功能，這些功能可為將來 MTS 故障調(diào)試相關(guān)博文提供基礎(chǔ)。