CTS的skew问题
通过分析完成cts之后，以clk_dsp为root的时钟树，用report_clock_timing -type skew的命令，在worst_corner下报出的skew为 1.04。
但是用report_clock_tree命令，报出具体的longest path 和shortest path的延时，longest path=2.679，shortest path=2.570。按照这个计算出的skew为0.109.。
我对这个问题有点 不明白。希望路过大神指点一二。为什么会报出不同的计算结果。哪个的skew值是准确的?
这次问题之前讨论过好多次了
第一个是准的，考虑了OCV
谢谢，，，那我想问一下，，当skew过大不不能满足要求的时候，可以考虑从哪个方面入手分析，，来减少这个skew的值。
再次强调一遍，skew小不等于timing好。
可是，如果过大的话，不是会影响到setup出现违例的情况吗?。
skew的好坏不是绝对的，可能恶化timing，也可能优化timing。
比如early launch、late capture可以增加setup slack，但同时减小hold slack；
反之可以增加hold slack，但同时减小setup slack。
如果要修setup，肯定觉得前者好。（有时，data path上已经不能再继续优化，只有采用这种办法来修setup）
如果要修hold，肯定觉得后者好。（虽然不建议动clock tree来修hold，但这句话至少说明，如果存在这种skew，你不是可以在data path上插更少的buffer来修掉hold违例吗）
但是我们不能完全寄希望于，时钟树中的skew都是对我们有利的。事实上，有利不利都是存在的，跟掷骰子一样。
（不要幻想计算机做大量计算，帮我们找出好skew最多的方案。要知道，一个clock节点关系着可能多条path的时序，加上设计规模越来越大，
即使有这样的算法，其计算量也会是巨大的。所以，计算机都算不过来的事情，就只能看成掷骰子。）
我们当然不希望每次设计电路都在掷骰子，这不是稳定可靠的方法，影响设计迭代的次数、繁琐度。
可靠地方法是，取两种情况的平均——创造skew小的clock tree——不奢望偶然出现的好的skew，但也尽量避免坏的skew。
所以，先做小skew的时钟树，再走线优化，只是目前一种稳定可靠的设计方法。或许有一天，算法、计算机能力都足够先进，总能帮我们恰到好处地创造好的skew、避免坏的skew，前面的方法当然会被抛弃。
但是，始终记住，skew的好坏不是绝对的。
以上是个人理解，恳请各位指正！
好像skew还是性能指标，比较小，对timing，对性能都好。
一般是这样的。所以，这个方法才被采用。但是，不能说“skew大的时钟树，其时序就一定不如skew小的”吧。
用useful skew的观点，很容易造出一个反例。
假设某个寄存器的CK端恰好是clock tree上latency最大的那个点。
该寄存器的D端是关键路径的endpoint，现在该路径违例。
增大CK端的clock latency，可以修复该违例，但也意味着clock tree的skew增大。
skew大的clock tree，时序反而更好。
恩 是的，必要的时候useful skew还是好的。timing毕竟第一位的。性能是skew越小越好，折中就还是在满足timing情况下，skew做最小的好
report_clock_timing -skew 是不是最长路径用max lib,最短路径用min lib? 你用report_clock_timinglatency分别报你上面的最长和最短路径来看看?加我Q每天晚上11点答疑
报skew的时候不要加OCV
没有的，我在分析的时候都采用的func_worst_corner。而这个Corner的设定都是set_operating_conditions -analysis_type on_chip_variation -library smic18_ss -max worst -min worst。所以，不论最长路径和最短路径都是用max_lib进行分析的。我在坛子里看了看，估计是在做local skew的时候，考虑了路径的derate。而我的derate是不是设的偏大了?set_timing_derate -early 0.90set_timing_derate -late1.20
不加ocv的分析，会不会对后续的时序分析有其他的影响?
你先去debug 为什么skew这么大，然后采取针对性措施
亲，这个为什么是考虑了OCV?我好疑惑，可以传授一下吗?谢谢