时序违例分类：setup违例、hold违例、transition违例、clock skew与jitter的影响

时序违例，说白了就是芯片里的信号没能在规定时间内到达该去的地方。我做了十几年后端，见过太多因为时序问题导致流片失败的案例。今天咱们就把这些违例类型掰开揉碎了讲清楚。

核心观点：时序违例不是单一问题，setup、hold、transition各有各的脾气，clock skew和jitter更是火上浇油。你得先分清敌人是谁，才能对症下药。

Setup违例是最常见的时序问题。简单说，就是数据在时钟沿到来之前，没能在寄存器输入端稳定下来。

我刚开始做后端时，总觉得setup违例就是路径太长。后来发现，其实很多时候是组合逻辑太深，或者cell驱动能力不够。嗯，这里要注意，setup违例通常发生在最差工艺角（worst case），因为这时候cell速度最慢。

典型场景：

我的经验：我曾经遇到一个项目，setup违例集中在某条关键路径上。查了半天，发现是综合时没加足够多的约束，导致工具把逻辑推得太深。后来我习惯在综合阶段就做一次粗略的STA，提前发现这类问题。

Hold违例和setup正好相反。数据在时钟沿之后，没能保持足够长的时间。说白了，就是信号跑得太快了，把上一拍的数据给冲掉了。

你想想看，hold违例通常发生在最快工艺角（best case），因为这时候cell速度最快。很多新手只关注setup，忽略了hold，结果流片回来发现芯片在低温高压下工作不正常。

Hold违例的常见原因：

避坑指南：我曾经在一个28nm项目中，hold违例修了整整两周。原因是时钟树综合时没考虑hold margin，导致时钟路径延迟过大。后来我建议在时钟树综合阶段就加入hold约束，效果立竿见影。

Transition违例，也叫slew违例。指的是信号从0变1或者从1变0的时间太长。这个指标虽然不像setup/hold那么致命，但会引发连锁反应。

为什么会这样？因为transition太慢，会导致下一级cell的延迟变大，进而引发setup违例。我见过一个案例，芯片功耗异常高，查到最后发现是transition违例导致短路电流增大。

Transition违例的典型表现：

经验之谈：我个人习惯在floorplan阶段就预估长线的transition问题。如果某条线要走很远，我会提前插入buffer，而不是等到route阶段再处理。这样能省下不少迭代时间。

Clock skew，就是同一个时钟信号到达不同寄存器的时刻不一样。这玩意儿是时序分析的噩梦。

Skew分两种：

类型	定义	影响
Positive skew	目标寄存器比源寄存器晚到	有利于setup，不利于hold
Negative skew	目标寄存器比源寄存器早到	有利于hold，不利于setup

我记得有一次，一个同事设计的芯片在量产时出现大量失效。分析后发现是clock tree没做好，skew达到了200ps，直接导致hold违例。从那以后，我每次做时钟树综合都会盯着skew报表看。

Jitter是时钟周期的瞬时变化。它不像skew那样是固定的，而是随机的、不可预测的。

Jitter对setup的影响特别大。因为setup检查的是最坏情况，而jitter会吃掉一部分时钟周期。我习惯在时序约束里留出10%~15%的jitter margin，具体比例看PLL的规格书。

Jitter的来源：

实用技巧：我曾经在一个项目中，发现jitter导致setup margin不足。后来通过优化PDN（电源分配网络），把电源噪声降下来，jitter也跟着减小了。所以说，时序和PDN是分不开的。

这四种违例不是孤立的。它们之间会相互影响，甚至相互转化。

举个例子：transition违例会导致cell延迟变大，进而引发setup违例。而clock skew如果控制不好，又会加剧hold违例。jitter则像一颗定时炸弹，随时可能引爆setup违例。

我个人习惯在做时序分析时，把这四个维度放在一起看。先看transition，再看skew，最后看setup和hold。顺序不能乱，因为transition和skew是基础，它们出问题了，setup和hold肯定好不了。

核心总结：

这张图展示了四种违例的层级关系。注意看，Transition违例会通过箭头指向Setup违例，表示它们之间的因果关系。Clock问题则同时影响Setup和Hold，是时序分析中的关键变量。

最后提醒：别指望一次把所有违例都修完。我习惯的做法是：先修transition，再修setup，最后修hold。这个顺序能让你少走很多弯路。至于clock skew和jitter，那是贯穿整个流程的，得时刻盯着。