📚 课程目录第1章 Versal时序收敛全景

1. Versal时序收敛全景

Versal ACAP（Adaptive Compute Acceleration Platform）不是一颗“更大的FPGA”，而是把标量处理系统（PS）、可编程逻辑（PL）、AI引擎（AIE）、片上网络（NoC）和硬化DDR控制器集成在同一硅片上的异构计算平台。这种异构性带来了性能红利，也彻底改变了时序收敛的工作方式：过去我们主要关心PL内部的时钟树和布线延迟，现在必须同时理解PS到PL的AXI接口、NoC的时钟域跨越、AIE阵列的局部时钟以及DDR MC的物理层时序。时序收敛不再是“跑完实现看WNS”这么简单，而是一个跨域、跨时钟、跨工具链的系统工程。

一、Versal的时钟网络：时序收敛的物理基础

Versal的时钟资源可以粗略分为三层：全局时钟、区域时钟和局部时钟。全局时钟由BUFGCE/BUFGCE_DIV驱动，覆盖整个器件，适合高扇出、低偏斜的时钟；区域时钟由BUFGCE和BUFCE_LEAF组合，覆盖单个或相邻的时钟区域（Clock Region），适合局部高频率逻辑；局部时钟则来自MMCM/PLL输出或GT恢复时钟，直接驱动特定BUFG或BUFCE。理解这三层结构的关键在于：时钟根的位置决定了布线延迟和偏斜的基准。例如，一个从PL侧MMCM输出的200MHz时钟，如果驱动了AIE阵列的接口逻辑，就必须经过NoC或AXI寄存器切片，此时时钟域跨越会引入额外的相位不确定性。

在Versal中，每个Clock Region包含多个BUFCE_LEAF，它们可以独立使能或关闭。这为动态功耗管理提供了便利，但也意味着时序约束必须精确到每个Leaf的时钟定义。如果约束中遗漏了某个Leaf的生成时钟，工具会将其视为异步，导致跨域路径被错误地“放行”，最终在硬件上表现为偶发亚稳态。

二、NoC与AIE的时序交互：被忽视的收敛盲区

NoC是Versal区别于传统FPGA的核心组件。它由NMU（Network Master Unit）、NSU（Network Slave Unit）和NCR（Network Control Register）组成，工作在自己的时钟域noc_clk下。当PL逻辑通过AXI接口访问NoC时，实际上经历了一次时钟域跨越：PL的aclk → NoC的noc_clk → 目标从端（如DDR MC或AIE）。这个跨越点如果没有正确约束，工具会默认按同步处理，但实际两个时钟可能同源不同频，或者完全异步。正确的做法是在XDC中显式声明：

set_clock_groups -asynchronous \
  -group [get_clocks -include_generated_clocks aclk_pl] \
  -group [get_clocks -include_generated_clocks noc_clk]

AIE阵列的时序收敛则更加特殊。AIE内部有独立的指令流和数据流，其时钟由AIE PLL生成，通常为1.25GHz。PL与AIE之间的AXI4-Stream接口需要经过“时钟桥”（Clock Bridge），这个桥内部包含异步FIFO。如果PL侧时钟和AIE侧时钟的频率比不是整数倍，FIFO的深度和标志位阈值就需要仔细计算。例如，PL侧250MHz，AIE侧1.25GHz，频率比为1:5，理论上FIFO深度为8即可覆盖5个周期的相位差，但考虑到布线偏斜和时钟抖动，实际建议深度不小于16。

三、时序收敛的典型挑战与判断依据

在Versal上做时序收敛，最常遇到的挑战可以归纳为四类。第一类是跨时钟域路径被误判为同步，表现为WNS正常但硬件偶发错误。判断方法是检查时序报告中的“Inter-Clock Paths”部分，确认所有跨域路径都有set_clock_groups或set_false_path约束。第二类是NoC接口的吞吐量瓶颈导致时序违例，因为NoC的AXI接口有固定的延迟和信用机制，如果PL侧逻辑在单周期内发起过多请求，会导致反压信号路径过长。第三类是DDR PHY训练后的时序余量不足，这通常表现为WPWS（Pulse Width）违例，需要检查DDR MC的读/写均衡结果。第四类是AIE与PL之间的流接口FIFO溢出或下溢，这需要结合AIE的tile状态和PL侧的流控信号一起分析。

判断依据速查：WNS为负且路径终点在PL内部 → 检查时钟约束和逻辑层级；WNS为正但硬件功能异常 → 检查跨时钟域约束；WPWS违例 → 检查DDR PHY和MMCM输出；AIE流接口错误 → 检查FIFO深度和时钟频率比。

四、建立整体认知框架

要系统性地解决Versal时序收敛问题，建议按以下顺序建立认知：先理解时钟网络的三层结构，明确每个时钟根的来源和覆盖范围；再梳理所有跨时钟域路径，包括PS→PL、NoC→PL、AIE→PL、PL→DDR，逐一施加正确的约束；然后分析NoC和AIE的接口协议，确认FIFO深度和信用机制满足吞吐量要求；最后结合实现报告中的WNS、WHS、WPWS和跨域路径报告，定位违例根因。这个框架不是线性的，而是迭代的：每次修改约束或逻辑后，都需要重新检查跨域路径和接口时序。