关于CTS的debug过程，还是采取常规的方法--分段定位

1. 首先明确要分析的问题是什么，明确目标
   

2. 按照CTS过程步骤定位到具体step去分析

3. 采用存中间db，控制变量等方法去复现问题进行debug

第一点，明确目标，比如是要看CTS的做的质量问题，skew？timing？drv？不同的问题，入手的角度和具体技巧都有所不同。以timing为例，基于innovus工具跑完ccopt之后，看到timing report发现timing和预期差异交大，那我们就重点关注timing相关信息。分析report确定是cts阶段tree的质量问题skew过大导致的还是opt阶段修timing有问题。

第二点，分步骤去log分析具体段落是否有异常。比如skew 问题，确认是否开了useful skew，同时就在cts阶段检查每个小的step是否正常，clustering，balance等步骤。如果skew没问题，那就看opt过程中的drv是否修的正常，worst chain是否符合预期结构等。

第三点，按照上一步的分析，分步存db去具体定位，比如cts存一个，opt再存一个；更细的就是可以在clustering存一个，preroute，postcondition route等步骤存相应的db。控制变量则可以采取调整skew mode，drv 约束，甚至clone，merge等更小更具体的工具行为来验证推测。

这三点做完之后，问题基本就可以定位了，甚至有的已经顺便解决掉了。剩下的就是有针对性的采取策略，或控制clock spec来长tree，或调整option控制细微的长tree行为，又或者改变opt的优化策略以及优化力度等等。当让，问题的root cause如果找到了，那么后面的策略就不是难点了。关键还在于debug过程如何高效，这里就涉及到对cts log的学习，熟悉cts的具体步骤是在做些什么。然后在遇到问题进行debug的过程就可以更加高效了。更深一层的理解，如果掌握了工具的算法以及行为，那就事半功倍了。不过在实际的项目当中少有时间去研究工具行为，那么平日的积累便是修炼的重点了。

常见的debug方向就是cts config的setting是否合理，mode是否有出入，避免了人为的错误之后，再检查deisgn的约束，例如dont touch了某些instance或者net导致不能正常长tree或者优化等。尽管问题可能千差万别，但是本质上都逃不过CTS的基本行为规则，是否高效处理问题，更多的也是看积累，然后剋快速反应定位。

大体思路先记录这些，后面详细分解cts的step，从而更好理解长tree的过程。