时钟约束：创建时钟、不确定性、延迟与时钟组

各位同学，今天我们来聊聊时钟约束。这是时序分析里最基础、也最容易出错的地方。我刚开始做芯片设计那会儿，就因为在时钟约束上栽过跟头——明明仿真都过了，流片回来就是跑不到目标频率。后来才发现，是时钟约束没写对。

说白了，时钟就是芯片的「心跳」。你给这个心跳定什么规矩，工具就按什么规矩去检查时序。今天咱们把四个核心命令讲透：create_clock、set_clock_uncertainty、set_clock_latency、set_clock_groups。

create_clock 是所有约束的起点。没有它，工具根本不知道你要分析什么频率。

基本语法很简单：

create_clock -name clk_sys -period 10 [get_ports clk_in]

这条命令的意思是：在端口 clk_in 上创建一个名为 clk_sys 的时钟，周期是 10ns，也就是 100MHz。

我个人习惯，-name 一定要起得有意义。别用 clk1、clk2 这种名字。你想想看，项目后期几百个时钟，看到 clk_axi 和 clk_ddr 一目了然，看到 clk1 你只能骂娘。

小技巧： 如果时钟是从 PLL 输出的，建议在约束里加上 -waveform 参数明确占空比。默认是 50%，但有些 PLL 输出不是严格的 50%。

还有一个容易忽略的点——get_ports 和 get_pins 的区别。端口是芯片的物理引脚，引脚是内部单元的 pin。我曾经见过有人把 get_pins 写成 get_ports，结果工具报错说找不到对象。嗯，这种低级错误，犯一次就记住了。

时钟不确定性，说白了就是「时钟信号没那么完美」。抖动、偏斜、PLL 的相位噪声，这些都会吃掉你的时序裕量。

set_clock_uncertainty -setup 0.2 [get_clocks clk_sys]
set_clock_uncertainty -hold 0.05 [get_clocks clk_sys]

这里 setup 设了 200ps，hold 设了 50ps。为什么 hold 比 setup 小？因为 hold 检查的是同一个时钟沿附近的信号，抖动影响相对小一些。

我在项目中遇到过这样的情况：后端工程师把 uncertainty 设得特别大，结果时序怎么都收敛不了。后来发现是 datasheet 里写的抖动是 100ps，他给设了 300ps。白白浪费了两周优化时间。

注意： uncertainty 不是越大越好。设大了，工具会过度约束，导致面积和功耗增加。设小了，芯片可能跑不到目标频率。建议参考芯片 datasheet 或 PLL 手册来设置。

另外，跨时钟域的场景下，uncertainty 要单独考虑。我曾经在异步 FIFO 的约束里忘了设 uncertainty，结果工具报了一堆违例。后来加上 -hold 的 uncertainty 才消掉。

时钟从源端到寄存器时钟端，要经过 buffer 树、走线，这些都会产生延迟。set_clock_latency 就是用来模拟这个延迟的。

set_clock_latency -source -max 1.5 [get_clocks clk_sys]
set_clock_latency -source -min 0.8 [get_clocks clk_sys]

这里 -source 表示的是时钟源到芯片端口的延迟。如果不加 -source，那就是芯片内部时钟树上的延迟。

你想想看，为什么要有 -max 和 -min？因为 PVT 变化会导致延迟有波动。高温低压下延迟大，低温高压下延迟小。工具会分别用 max 和 min 去检查 setup 和 hold。

  关键点： 在综合阶段，时钟树还没建好，latency 是估算值。到了后端布局布线后，工具会用实际的时钟树延迟来替换这个值。所以前期设 latency 时，别太较真，给个合理的范围就行。

我记得有一次，前端工程师把 latency 设成 0，结果综合出来的网表时序全绿。到了后端，一插时钟树，全红了。这就是典型的「前期太乐观，后期哭鼻子」。

一个芯片里通常有多个时钟域。有些时钟之间是异步的，不需要做时序分析。set_clock_groups 就是用来告诉工具：这些时钟之间不用检查。

set_clock_groups -asynchronous -group {clk_sys} -group {clk_axi} -group {clk_ddr}

这条命令把三个时钟分成三个异步组。工具就不会去分析它们之间的跨时钟域路径了。

为什么要这么做？因为异步路径的时序是没法保证的，你硬要分析，只会报一堆假违例。我曾经接手过一个项目，里面有两百多个假违例，全是没设 clock groups 导致的。花了一周才清理干净。

避坑指南： 如果你有多个时钟来自同一个 PLL，但它们之间是同步的，就不要设成 asynchronous。否则工具会漏掉真正的时序问题。我曾经见过有人把所有时钟都设成异步，结果芯片流片回来，跨时钟域路径全挂了。

还有一种情况是 -logically_exclusive 和 -physically_exclusive。前者用于 MUX 选择的时钟，后者用于物理上不会同时存在的时钟。嗯，这两个用得少，但遇到了要能区分。

这四个命令，每个都有它的使用场景和坑点。我个人的经验是：

时钟约束说难不难，说简单也不简单。关键是要理解每个参数背后的物理意义。你把这些搞明白了，时序分析就成功了一半。

可可精品资料库