slew与skew深度辨析：从时序概念到CTS工程实践

slew和skew，这两个词在数字IC后端和FPGA时序分析里经常成对出现。我第一次认真研究它们，还是在很多年前看到一份标题带“【转载】[ZZ]”的旧帖，内容就是slew和skew的辨析。那会儿我刚接触静态时序分析（STA），看报告时总是分不清timing report里哪个是转换时间、哪个是时钟偏斜，问同事也只能得到一句“反正一个是rise/fall时间，一个是时钟到达时间差”。后来踩过几次坑、改过几条真实路径，才算把这两个概念彻底揉碎了吞下去。这篇不是教科书式的概念复述，而是结合我做后端设计和时序收敛的经验，把slew、skew以及热词里常出现的skew group一次性讲明白，适合刚入门数字后端、准备做CTS或正在被时序报告折磨的朋友参考。

1. 概念总览：一字之差，两个完全不同的时序概念

1.1 先给slew和skew一个最简短的定义

slew通常指信号斜率或者转换时间（transition time），描述的是一个信号节点从低电平翻转到高电平、或从高电平翻转到低电平这一段过渡过程所花的时间。单位是纳秒或皮秒，数值越大说明信号沿越“钝”，爬坡越慢。

skew通常指时钟偏斜（clock skew），描述的是同一个时钟源产生的时钟信号，经过不同路径到达不同触发器时钟端时，到达时间不一致的差值。单位同样也是皮秒、纳秒，但度量的对象完全变了：slew关注“单个节点波形”，skew关注“多个节点之间的时间差”。

为了方便对照，我直接把两个概念的关键差异列成一张表：

我自己的记忆口诀就八个字：slew是沿，skew是差。遇到具体报告时先问一句：它说的是“这个pin上过渡沿花了多久”，还是“两棵时钟树到达时间差了多少”。判断对了出发方向，后面大部分分析就不会跑偏。

1.2 为什么新手最容易把两个概念搞混

排除英文拼写长得像这个客观原因，还有两个容易混淆的坑。

第一个坑是报告位置。很多STA工具在一条完整路径报告里会同时出现两类信息：数据路径上每个cell的input slew（转换时间）会一行一行列出来，而到了时钟路径部分又会给出clock latency或者skew相关的数值。粗看都是“时间”，再粗心一点就直接把它们当成同一类参数去理解。

第二个坑更加隐蔽：slew和skew在物理链条上是耦合的。时钟树的缓冲器本身也有slew问题，如果某个分支的transition太大，会导致该分支到达寄存器的延迟发生变化，最终表现为skew变大。也就是说，一个slew问题会在报告里伪装成skew问题。遇到这类情况，如果只盯着skew去调时钟树，往往越修越差。

所以建议所有刚接触时序分析的人，先别急着背公式，先把“沿”和“差”这两个维度在心里竖起来。后续看任何报告，都先分类：这是单个点的波形问题，还是多点之间的相对时间问题。

2. 深入拆解slew：信号“爬坡”快慢的真相

2.1 slew的几种测量标准，以及为什么标准很重要

slew的测量没有唯一的国际标准。常见的有按电源电压比例切点来测的，比如10%到90%、20%到80%、30%到70%。也有按绝对电压阈值来测的，比如从0.2V测到0.8V之类。

为什么测量标准会影响工程判断？因为数字电路真正关心的根本不是全摆幅时间，而是信号穿过逻辑阈值（大约在VDD/2附近）那一段的斜率。如果用10%到90%，会把起始和末尾那段接近饱和、变化极慢的区域也算进去，数值会偏大；用20%到80%或者30%到70%，则更贴近逻辑翻转真正耗时的区间。不同工艺库、不同工具，采用的默认切点可能不一样。我看到过不少新手从两份报告里各抄一个slew数值出来对比，结果发现差了几倍，其实只是因为测量标准不同。

还有一个和库相关的点：在Liberty标准单元库里，每个单元的时序弧延迟表通常以“输入转换时间（input slew）”和“输出负载电容”两个维度建索引。仿真工具会按照当前实际输入slew去查表、插值，才能得到这个单元在当前条件下的延迟。这也就意味着，前一级的输出slew就是后一级的输入slew，它是一个沿着数据路径一级一级传播下去的物理量。

2.2 slew过大或过小，分别会带来什么问题

先说过大，这是最常见的违例类型，危害主要有三类。

第一类影响单元延迟。MOS管不是理想开关，信号沿越缓，管子处于半导通状态的时间越长，输出延迟自然变大。在库里做同一负载下的对比实验，input slew从20ps拉到200ps，反相器延迟可能从30ps涨到100ps以上，翻好几倍很常见。所以slew超标最直接的后果就是路径延迟变大，setup收敛困难。

第二类影响功耗。信号翻转过程中，PMOS和NMOS会有一段同时导通的时间，形成短路电流。slew越慢，这段交叠时间越长，动态功耗增加越明显。对于低功耗设计，大量路径slew超标的代价可能比预期多出10%到20%的动态功耗。

第三类影响信号完整性。信号在缓慢爬坡时，长时间停留在中间电平附近，对相邻信号的串扰（crosstalk）更敏感，严重时可能产生毛刺；反过来，slew过快也不是好事，陡峭的边沿容易引起过冲、下冲、反射，对高速接口设计尤其不友好。

实际操作中，“slew越小越好”绝对是误解，许多设计明明transition已经很小，还要继续加驱动，结果功耗和绕线资源白白浪费。合理的目标是让信号沿足够快，满足库单元延迟建模范围，但不要追求极致陡峭。

2.3 工程上如何约束并修复slew违例

设计里最常用的约束是最大转换时间约束。在综合阶段，代码里通常会写类似这样的命令：

set_max_transition 0.2 [current_design]

含义是把设计里所有信号的最大transition限制在0.2ns以内。对时钟网络，约束通常更严格，因为时钟沿质量直接影响全局时序，往往会单独给时钟树设一个更小的max transition值。

如果布局布线后报告里出现transition violation，修复思路一般是三板斧：

• 第一，加大驱动：把驱动能力不足的cell从低尺寸换成高尺寸，这是最直接的方式。
• 第二，插入缓冲器：对高扇出网络先用buffer把扇出拆开，降低单一cell的等效负载。
• 第三，减少负载：绕线过长时通过布局调整缩短连线，或者把负载分散到不同驱动分支。

这里想分享一个个人经验：不要一看到transition violation就无脑upsize。有时候是扇出太多而不是驱动太弱，硬换大cell反而会在输入端引入更大的输入电容，把上一级的slew拖慢。正确做法是先看上下游，确定瓶颈到底在哪一级，再决定是改尺寸还是加buffer。修复完之后必须重跑STA，因为slew一变化，路径延迟和时钟到达时间都会跟着动，经常出现“修好了A路、搞挂了B路”的情况。

3. 深入拆解skew：时钟到达时间的“不齐整”

3.1 clock skew从哪里来

理想情况下，我们希望同一个时钟源到达所有触发器的时钟端时，边沿完全对齐。但现实中做不到，skew的来源主要有几类。

第一个是物理路径长度差异。时钟从根部走到远端触发器，不同分支的线长不同，RC延迟就不同。这是skew最直观的来源。

第二个是缓冲器级数和负载差异。时钟树通常要逐级加buffer来驱动大量寄存器。不同分支的buffer数量、尺寸、末端负载都可能不一样，导致各级延迟累积后出现偏差。

第三个是工艺偏差，也就是常说的OCV（on-chip variation）。同一片晶圆上，不同位置的晶体管阈值电压、栅氧化层厚度可能存在微小差异，这在先进工艺下尤其不可忽视。

顺便把skew和jitter区分开：skew是同一个时钟边沿到达不同寄存器的时间差，是“空间”上的偏差；jitter是同一个时钟节点本身的边沿在时间轴上随机抖动，是“时间”上的不确定度。修复skew主要靠时钟树平衡和结构设计，修复jitter主要靠电源完整性、PLL设计和抗干扰。两个概念经常同时出现在时序报告里，但一定不要混为一谈。

3.2 skew如何影响setup和hold

这是时序分析里最核心的公式推导，其实不复杂。

假设发射触发器时钟到达时间为Tlaunch，捕获触发器时钟到达时间为Tcapture。又设数据从发射触发器时钟端到输出Q的延迟为Tc2q，组合逻辑延迟为Tcomb，捕获触发器的建立时间为Tsetup，保持时间为Thold，时钟周期为Tperiod。

对于建立时间，要求是：

Tlaunch + Tc2q + Tcomb + Tsetup <= Tperiod + Tcapture

把式子变一下形：

Tc2q + Tcomb + Tsetup <= Tperiod + (Tcapture - Tlaunch)

这里的Tcapture - Tlaunch就是数据路径两端时钟到达时间的差，工程上常简称为skew。注意，如果捕获时钟比发射时钟晚到，即Tcapture大于Tlaunch，式子右边多出一块正值，等于给setup余量加分，这是正skew；如果捕获时钟比发射时钟早到，则setup余量被压缩，是负skew。

对于保持时间，要求是：

Tlaunch + Tc2q + Tcomb >= Thold + Tcapture

变形一下：

Tc2q + Tcomb - (Tcapture - Tlaunch) >= Thold

这里正skew（捕获时钟晚到）反而会吃掉保持时间余量，容易引发hold违例。

所以skew对setup和hold的影响方向是相反的。这也解释了为什么后端做时钟树综合时不能只盯着skew一个指标，必须在setup和hold的双重约束下找到平衡点。

3.3 useful skew：把“坏事”变成优化手段

传统观点认为skew越小越安全，但实际工程中，数据路径的时序余量并不均匀。有些路径setup余量很充裕，有些路径hold余量很紧缺。如果强行把所有寄存器时钟到达时间对齐，整体skew为零，未必是全局最优解。

于是就有了useful skew（有用偏斜）的设计方法：在明确分析过数据路径的前提下，人为让某个捕获时钟相对晚到一定时间，从而多挤出setup余量；或者让捕获时钟早到，帮助hold收敛。本质上是通过“牺牲”某一段路径的余量，去补齐另一段更关键的路径。

我在实际项目中用过一次很典型的useful skew修复：一条长数据路径setup余量差大约80ps，后端逻辑已经很难再做优化，最后就是在CTS阶段把捕获端的时钟到达时间人为调晚约100ps，建立时间余量立刻转正。代价是相邻路径的hold检查紧了，但经过分析确认那些路径原本hold余量很大，于是整体时序顺利收敛。

需要提醒的是，useful skew是一把双刃剑，必须基于全路径、全场景的分析结果来设置，绝不能拍脑袋随意加偏斜。真到了那一步，也要同步重新检查对端、旁路的所有相关时序，防止修一处崩多处。

4. skew group是什么，CTS里怎么用

4.1 为什么需要skew group而不是全局零skew

芯片规模上来以后，一颗SoC里面动辄几十万甚至上百万个寄存器。如果CTS要求所有寄存器的时钟到达时间完全一致，时钟树会出现大量buffer串联，面积、功耗、绕线资源都会爆炸，而且实际也不可能做到真正零skew。

更合理的做法是按功能模块、时序路径和物理位置，把寄存器划分成若干个组。组内做严格平衡，让时钟到达时间尽量一致；组之间允许存在合理的时间差，只要不影响跨组路径的时序收敛。这个组就是skew group。

举个例子，一个CPU核心里某个流水线级的几百个触发器之间数据交互密切，应该放进同一个skew group，要求组内skew尽量小；而一颗芯片上距离很远的两个外设模块，相互之间几乎没有数据交互，完全可以分成两个独立group，组间再留一些skew余量即可。这样的分组策略，既保证了关键路径的时序质量，又避免了无谓的全局平衡开销。

4.2 配置skew group的实操思路

不同EDA工具的skew group配置命令差异比较大，但设计思路是通用的。大致分四步走：

• 第一步，梳理寄存器之间的时序路径关系，找出哪些触发器之间存在直接的setup/hold路径，优先把存在强时序依赖的寄存器划入同一个组。
• 第二步，结合物理布局，把距离过远、没有数据交互的模块拆成不同组，避免强行平衡带来大量绕线。
• 第三步，在CTS工具里创建group，并把对应的leaf pin或寄存器时钟端加入组。有些工具用create_clock_tree_group之类的命令，有些则在gui里操作。
• 第四步，设置每个组的target skew目标值，跑完CTS后检查report，确认组内skew满足目标。

配置时还有一个很容易忽略的点：如果两个寄存器之间存在真正的时序路径，但被误分到两个不同group，组间skew会直接叠加到时序方程里。这种情况下setup和hold分析的余量都会受到额外影响。因此分组前花点时间把关键路径拉出来看一眼，比事后反复调CTS高效得多。

4.3 skew group、clock group、target skew别搞混

这类术语是很容易踩坑的重灾区。skew group描述的是“哪些寄存器要被平衡到同一目标”，clock group则通常是STA里的异步时钟分组，用来告诉工具不同时钟之间不需要做严格的时序检查，比如用set_clock_groups -asynchronous声明两个时钟是异步的。target skew则是CTS阶段的一个目标数值，表示工具期望达到的组内skew上限。

实际项目里，这三者往往一起出现，但作用完全不同。我见过有工程师误把skew group设置成了clock group，结果两个原本需要交互的时钟域被当成异步处理，后续时序报告中跨时钟域路径完全消失，直接在芯片tapeout前爆雷，吓得全组通宵查问题。所以每次用命令前，建议先在工具文档里确认清楚语义，再看报告验证设置效果。

5. 常见问题与排查技巧实录

5.1 快速判断报告里是slew问题还是skew问题

时序报告内容动辄上百行，如果逐行读效率太低。我的习惯是先用关键词定位：如果是transition violation，报告里会出现transition time、max_transition、slew这类字样；如果是skew，会出现在时钟树报告或者report_clock_timing的输出里，典型的字段名是clock skew。

拿一段示意报告来说，时钟部分长这样：

Clock Skew Report Clock: clk Skew: 0.083ns Number of Clock Groups: 1

这是典型的skew信息，描述时钟树内部各级到达时间的不一致程度。

数据路径部分则长这样：

Startpoint: ff1/CK Endpoint: ff2/D Path Group: clk Pin Cell Delay Arrival ----------------------------------------------- ff1/CK (DFF) 0.000 0.000 ff1/Q (DFF) 0.042 0.042 0.042 u_buf_1/A (BUF) 0.031 0.053 0.095 u_buf_1/Y (BUF) 0.011 0.178 0.273 ... Input Transition Time: 0.214ns

这里的Input Transition Time就是数据路径上某个pin的slew情况。判断路径是否因为slew过大而延迟超标，可以逐级看transition是否远超库文件里该cell的最优建模区间。

5.2 一个“假skew”的真实排障记录

曾经有一个项目，CTS报告显示的skew指标完全正常，但跑完STA后setup仍然差了很多。我最初怀疑是useful skew没有生效，于是反复调整时钟树的延迟，连续两轮ECO都没有效果。

后来把数据路径每一级的delay拆开逐项看，才发现问题出在数据路径中间的一个buffer上：那个buffer的input slew已经大到了0.4ns以上，远超数据路径其他节点。因为slew过大，这个buffer的延迟比库表正常预期多了将近一倍，整条数据路径因此被拖长。从一个“宏观”的角度看，像是时钟skew导致setup不够，本质上却是数据路径上单个节点transition恶化造成的delay增量。

这次经历让我养成了一个习惯：拿到违例报告，先查整条路径上所有节点的transition值，把所有slew超标的点标出来，再决定要不要动时钟树。很多时候，先解决slew问题，原本的setup/hold违例会自动消失一大半，根本不需要碰skew。

5.3 一些说话和写文档的习惯建议

最后聊一个很多人不在意但实际很影响协作效率的点：口头和书面表述要固定术语。

在公司内部review timing报告时，经常会听到“这个cell skew有点大”“这条路径slew不对”这类话。如果不追问，根本不知道说的是transition还是clock skew。我自己在文档和邮件里一定会写成“slew（转换时间）违例”或者“clock skew偏大”，必要时直接跟一个具体数值和报告截图。看起来多打了几个字，但能避免同事之间来回猜，尤其在新人较多的团队里，这种表述习惯能省下大量沟通成本。

还有一种常见情况是中文翻译混用，比如把slew翻成“压摆率”，把时钟skew翻成“时钟偏移”，结果和“时钟抖动（jitter）”又混在一起。建议团队统一一个术语表，至少把slew、skew、jitter三个词固定下来，分别对应转换时间、时钟偏斜、时钟抖动。术语统一后，跨部门协作时的误解能少一大半。

最后分享一个个人小习惯：每次拿到后端时序报告，我会先用文本检索工具搜两个关键词，一个是transition或者max_transition，另一个是skew。先把这两类信息单独摘出来，再把它们和数据路径的delay放在一起联合判断。这样处理过的项目里，因为slew和skew概念混淆导致的误判几乎不再出现。slew管的是信号“爬坡”快不快，skew管的是时钟“到得齐不齐”，记住这两句话，再复杂的时序报告也能很快找到方向。