如何做一条合格的path？同一条path在物理设计不同阶段的变化

Delay值是多少才算合格呢？这一篇开始讲解路径(Path)的概念，以及衡量Path Delay是否合格的标准----建立时间(setup time)和保持时间(hold time)。最后会用实际的例子来介绍同一条path在物理设计的不同阶段的变化，在什么阶段会修setup，什么时候会开始修hold等实践知识？

四种路径

STA是基于路径（Path Based）进行检查的，一般路径的起点（Startpoint）和终点（Endpoint）都是存储单元，即使是输入输出相关的路径，我们也是假设存在一个虚拟的外部寄存器作为时序路径的起点或者终点。然而，按照一般的分法，路径分为四种类型，如图所示：

上图中，四类Path的起点和终点如下表所示：

当然，设计中也可能有一些到clock gate的path，或者跟memory相关的path，暂时都把这些当成寄存器来分类就可以。在编写时序约束文件（SDC）时，要照顾到每一种类型的path，避免遗漏。现在的后端流程一般会把这四类path进行分组（Path Group），分别为IN2REG (Path 1)，REG2REG (Path 2)，REG2OUT (Path 3)， IN2OUT (Path 4)，方便工具按照不同的权重对它们分别优化，避免相互影响。标准的SDC命令是“group_path”，各家工具都支持。

Setup/Hold Time

为什么会有setup time，hold time的要求呢？这与时序单元的工作方式有关，数据从发送寄存器（Launch flop）传输到接收寄存器（Capture flop），它是在时钟沿采样的（上升或者下降沿），数据是以流水线的方式一个周期往后打一拍，所以保证采样时刻数据的正确性至关重要，setup就是要求在采样时刻数据已经正确且稳定，hold就是要求下一个数据传来之前在上一个数据已经完成采样，不会把上一个数据覆盖。下图非常清楚地解释了setup和hold的概念，真的是“一盗图值千言”。

Path示例

Setup概念图示

Hold概念图示

这里经常有个奇怪的面试问题： 是setup重要还是hold重要？ 大概是考验大家的实际项目经验吧，setup不满足还可以通过降低频率来测试，hold不满足就没什么办法了。但是项目中，由于hold修复方法比较简单直接，一般是在setup可控的前提下再修复，所以一般在布局阶段只考虑setup，而在建立时钟树后再去考虑hold。把hold放在后面去修复，并不代表不重要，只是体现了修复的难易程度罢了。

实例分析

上面说过，数据采样可以是上升沿，也可以是下降沿，下面以一条半周期的path为例，展示它在整个物理设计过程中可能的变化过程，也借此提供一个分析时序问题的纵向比较的方法学：

布局（place）之前：

这条path的详细介绍如下，其中clock周期是2ns：

• “ Startpoint ”是LvdsClkCnt_reg_0_，它是“ADC_CLK”的上升(r)沿采样的
• “ Endpoint ”是SortData_neg_reg_5_，它是“ADC_CLK”的下降（f）沿采样的
• “ Scenario ”代表了这条path上所用的cell的工作的PVT
• “ Path Group ”表示path的类型分组，在上一节介绍过
• “ Path Type ”表示path类型，可能是max(表示setup)，min(表示hold)，或其它。
• clock network delay是ideal的，因为没有建立时钟树
• 从“ADC_CLK” clock的源头到LvdsClkCnt_reg_0_/CP（正沿），再到SortData_neg_reg_5_/D的整个path每一级的delay加总起来是0.6227ns（叫做arrival time），这一段叫 launch path
• 从“ADC_CLK” clock的源头到SortData_neg_reg_5_/CPN（负沿），加上clock reconvergence pessimism ( CRPR )，clock uncertainty，以及capture寄存器库自带的setup time等，形成了required time（0.7304ns），这一段叫 capture path
• **slack ** = required time - arrival time 不小于0表示setup合格

可以看出此时的path，setup time还是满足的。

刚刚布局（place）之后，但还没有建立时钟树（cts）：

可以看出在path中，有些stdcell被优化了，也多了一些inverter，这是工具的行为，但是最终slack为负数，说明setup time不达标了。

建立时钟树（cts）之后，布线（route）之前：

此时的path中已经有了真实的clock tree，所以clock network delay从ideal变成了propagated，delay值也从0变为1.8731ns，而且到两个寄存器的clock pin的delay也不一样，差值就叫clock skew，这条path的skew对setup time是有害的，不过此时的CRPR也不是0了，而是0.1609ns，抵消掉部分clock skew的影响。这个阶段工具其实又做了一些优化，比如icc_place134这个cell，从原先的INVD3BWP12T变大到INVD4BWP12T（sizeup）等等。

布局（place）+ 建立时钟树（cts）+ 布线（route）之后：

此时的path相比之前，有了真实的绕线，Net Delay会更差，而且也会引入串扰噪声，工具会进一步进行优化，比如icc_place147和U270等，都变大了。不过最终的slack还是负数，并没有达标。

对于实践方面，大概率（80%以上）还有一个面试问题：“项目中有没有碰到timing/routing比较难的设计，你是怎么解决的？”，必须要结合项目经历准备，可以思考上面的path最后setup还是没满足，有怎么解决办法？