从preroute阶段到routeDesign之后，timing通常会出现degration的情况。

从pr工具的原理上讲，preroute阶段为了能更快素的布局，评估timing等参数，所以使用的shitrial route快速绕线法，通常不考虑drc的问题；另外抽rc的机制以不同，和signoff的实际rc有一定差距。而在绕线之后计算rc的算法更加精确，接近signoff的值。

从实际design的角度讲，在cts的时候trial route没有考虑SI的影响，而在真实绕线之后，考虑到drc问题，绕线会出现detour的情况，再加上preroute的congestion要是严重的话，就会很大概率出现SI问题，而si对时序的影响往往不可预估。

综合以上原因，在绕线之后时序会比cts阶段变差很多。

根据前辈指导推荐一种新的思路，就是分层次绕线，先把critical的path抓出来先绕线，然后在绕其他的，进行clock eco，最后在整体绕线。脚本举例：

#抓取critical的path，并选中net

deselectAll

set x [dbget [dbget -p  [dbget  top.nets {.isClock == 0 && .isCTSClock == 0}].bottomPreferredLayer {.num > 6}].name]

foreach name $x {

selectNet $name

}

然后做clock eco的动作

setDesignMode -flowEffort standard 

routeDesign -clockEco

接着对选中的net进行单独绕线

setNanoRouteMode -routeSelectedNetOnly true

globalDetailRoute

deselectAll

最后回复设置，进行全局的绕线

setNanoRouteMode -routeSelectedNetOnly false

routeDesign

这种方式可以推广开来就是可以给path分优先级，进行绕线。减少detour。当然，这是在绕线阶段进行的整体调整，具体问题还需就具体分析，case by case。