一、时序收敛概述

1.1 什么是时序收敛？

时序收敛，说白了就是你的设计能在目标频率下稳定工作。

我经常跟团队里的新人说：时序收敛不是玄学，是数学。它本质上是在验证——每个寄存器的数据路径，能不能在规定时间内完成传输。

举个例子。你设计了一个图像缩放模块，目标跑 200MHz。时序收敛意味着：从第一个寄存器发出数据，到第二个寄存器捕获数据，这中间的所有逻辑延迟、布线延迟，加起来不能超过 5ns（一个时钟周期）。

如果超过了呢？那就是时序违例。轻则功能异常，重则芯片直接报废。

我个人习惯把时序收敛比作「赶火车」。数据就像乘客，时钟就像发车时刻表。乘客必须在发车前上车（建立时间），也不能在发车后突然跳上车（保持时间）。

1.2 为什么在图像加速中如此重要？

图像加速，说白了就是跟像素赛跑。

你想想看，一张 4K 图像有 800 多万个像素。如果做一次边缘检测，每个像素要经过 5-10 级流水线。再乘上 60fps 的帧率——这计算量，啧啧。

我在项目中遇到过这样一个案例：一个视频缩放模块，功能仿真全过，上板测试却出现画面撕裂。查了三天，最后发现是某条关键路径的建立时间余量只有 20ps。温度一高，直接崩了。

图像加速对时序的要求，有这几个特点：

• 高吞吐：像素数据流不能断，一断就丢帧
• 低延迟：尤其是实时视频处理，延迟大了用户体验极差
• 确定性：每帧的处理时间必须固定，不能忽快忽慢

嗯，这里要注意：图像加速里很多模块是流水线结构。一条流水线里，只要一级时序出问题，整条线都得停。这就是所谓的「木桶效应」。

1.3 时序收敛的三大核心要素

聊到核心要素，我得先画个图，帮你建立整体认知。

好，图看完了。咱们一个一个聊。

1.3.1 建立时间（Setup Time）

定义：在时钟有效沿到来之前，数据必须保持稳定的最短时间。

为什么要有这个要求？因为寄存器内部需要时间把数据「读进去」。就像你刷卡进地铁，闸机需要几百毫秒来验证——数据也得给寄存器留出「验证时间」。

建立时间的检查公式：

T_clk + T_skew > T_co + T_logic + T_setup

其中：

• T_clk：时钟周期
• T_skew：时钟偏斜（正偏斜有帮助）
• T_co：寄存器输出延迟
• T_logic：组合逻辑延迟
• T_setup：建立时间要求

1.3.2 保持时间（Hold Time）

定义：在时钟有效沿到来之后，数据必须保持稳定的最短时间。

保持时间违例比建立时间违例更隐蔽。为什么？因为建立时间违例可以通过降频来验证（降频后建立时间要求变宽松），但保持时间跟频率无关。

我曾经在一个图像锐化模块里遇到保持时间违例。综合报告里显示违例路径只有 -0.02ns。我当时想：「这么小，应该没事吧？」结果后端工程师告诉我：保持时间违例是硬伤，必须修。

保持时间的检查公式：

T_co + T_logic > T_hold + T_skew

1.3.3 时钟抖动（Clock Jitter）

定义：时钟边沿在时间上的不确定性偏移。

时钟抖动是真实世界的产物。理想时钟的边沿是完美的，但实际 PLL 产生的时钟，每个边沿都会有一些随机偏移。这个偏移就是抖动。

抖动对时序的影响：

• 周期抖动：相邻两个时钟周期的差异，影响建立时间
• 长期抖动：多个周期后的累积偏移，影响保持时间

在图像加速中，时钟抖动尤其要关注。因为很多图像处理 IP 需要多相时钟（比如 DDR 接口、像素时钟域），不同时钟域之间的抖动叠加，会让时序分析变得复杂。

嗯，聊到这里，我想起一个真实的教训。有个做图像拼接的同事，设计里用了三个 PLL 产生不同频率的时钟。仿真一切正常，但上板后画面时不时出现「花屏」。最后定位到是 PLL 之间的抖动耦合，导致跨时钟域的数据采样出错。

从那以后，我养成了一个习惯：做时序分析时，永远给时钟抖动留出 20% 的余量。这不是标准要求，但这是经验。

好了，时序收敛的概述就聊到这儿。记住：时序收敛不是后端工程师一个人的事，前端设计时就要考虑。你写的每一行 RTL，都在决定最终的时序质量。