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关注“多个节点之间的时间差”。为了方便对照我直接把两个概念的关键差异列成一张表对比项slewskew英文全称signal slew / transition timeclock skew度量对象单个信号节点的波形转换时间时钟到达多个触发器的时间差本质信号沿的陡峭程度时钟信号在空间上的到达时间偏差常用单位ps、nsps、ns主要影响单元延迟、功耗、串扰setup/hold时序收敛一句话记忆信号“爬坡”快不快时钟“到得齐不齐”我自己的记忆口诀就八个字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数量、尺寸、末端负载都可能不一样导致各级延迟累积后出现偏差。第三个是工艺偏差也就是常说的OCVon-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管的是时钟“到得齐不齐”记住这两句话再复杂的时序报告也能很快找到方向。