修复Hold Violation的方法

RTL设计实现时，尤其是算法RTL，综合阶段或者Place阶段遇到setup timing不满足时，我们可以通过插入pipeline的方式修改RTL来解决setup violation，但是hold timing vioation往往CTS后才能发现且只能通过后端修复。遇到hold violation时检查以下几点：

首先，检查SDC约束；

• 保持时间的margin是否合理,hold uncertainty可从foundry的SOD获得;
• 时钟树transition/target skew/fanout target等设置是否合理；

其次，检查CTS阶段后clock skew是否合理范围内；

再次，对CTS友好的FloorPlan和Placement也非常重要；

• 比如，友好的FloorPlan不希望PLL在die的右下角，而Flip-Flop在左上角，latency/insertion delay很大。
• 比如，友好的Placement不希望堆叠的memory之间的channel中摆放Flip-Flop，latency/insertion delay很大。

若多次迭代仍然不能解决hold违例，推荐如下方法：

• optDesign -postRoute -hold

根据hold slack的违例值，修改set_clock_uncertainty -hold，过约束hold margin，然后打开Route后的database，用optDesign -postRoute -hold修复hold。此方法简单，无需编写脚本，缺点是原本无hold违例的路径也被修复，会插入冗余的buffer，导致功耗升高、面积变大(一些buffer也会被sizedown)。重修跑绕线后的hold优化花费时间也很多，所以经常看凌晨三点的东方鱼肚白。

• optDesign -postCTS -hold

若绕线后的hold违例路径过多，上面第一种方法仍然无法解决，可回到CTS阶段，设置合适的hold margin进行修复。这样花费的时间更多，修复的效果也更好。

• 精准修复

方法1、2适用于规模小，功耗、面积要求不高且hold violation较多的设计，对于规模大的设计，我们需要抓出并分析所有hold violation的data path，再对这些路径进行精准修复。回到绕线优化阶段，修改hold margin，将违例路径的endpoint加入到terms.list，工具只定向修复违例的路径，因此会节省大量时间。optDesign -postRoute -hold -selectedTerms terms.list- 分组精准修复

根据slack大小将违例路径进行分组，set_path_adjust -0.05 -hold \-path_adjust_group Group1 -view xx_hold_view
set_path_adjust -0.10 -hold \-path_adjust_group Group2 -view xx_hold_view在绕线优化阶段执行：

optDesign -postRoute -hold -selectedTerms terms.list- 读入Tempus写出的sdf

在绕线优化阶段，读入Tempus写出的sdf：read_sdf -view xx_hold_view ./xx_hold.sdf

read_sdf -view xx_setup_view ./xx_setup.sdf

然后执行optDesign -postRoute -hold -expandedViews -useSDF该方法避免了PR工具与签核工具的误差，使修复结果更为准确，总体上来说，方法二最直接有效。

转载：全栈芯片工程师