现代 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 故障调试相关博文提供基础。
文章转载自： XILINX技术社区微信公众号
