EETOP 创芯网论坛 (原名：电子顶级开发网)

标题: CTS的skew问题 [打印本页]

作者: 豆沙包 时间: 2014-10-28 14:54
标题: CTS的skew问题
我在做cts的时候，遇到一个问题想请教一下。
通过分析完成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值是准确的？？？

作者: herrzhou 时间: 2014-10-28 15:23

我在做cts的时候，遇到一个问题想请教一下。
通过分析完成cts之后，以clk_dsp为root的时钟树，用report_cl ...
豆沙包发表于 2014-10-28 14:54

登录/注册后可看大图

这次问题之前讨论过好多次了
第一个是准的，考虑了OCV

作者: 豆沙包 时间: 2014-10-28 15:39
回复 2# herrzhou

谢谢，，，那我想问一下，，当skew过大不不能满足要求的时候，可以考虑从哪个方面入手分析，，来减少这个skew的值。

作者: joemool 时间: 2014-10-28 16:59

回复 herrzhou

谢谢，，，那我想问一下，，当skew过大不不能满足要求的时候，可以考虑从哪个方面 ...
豆沙包发表于 2014-10-28 15:39

登录/注册后可看大图

再次强调一遍，skew小不等于timing好。

作者: 豆沙包 时间: 2014-10-28 17:17
回复 4# joemool

可是，如果过大的话，不是会影响到setup出现违例的情况吗？。。。。

作者: shuanghx 时间: 2014-10-28 21:14
本帖最后由 shuanghx 于 2014-10-28 21:20 编辑

回复 joemool

可是，如果过大的话，不是会影响到setup出现违例的情况吗？。。。。
豆沙包发表于 2014-10-28 17:17

登录/注册后可看大图

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的好坏不是绝对的。

以上是个人理解，恳请各位指正！

作者: pengyong820954 时间: 2014-10-28 21:28
回复 6# shuanghx
好像skew还是性能指标，比较小，对timing，对性能都好。

作者: shuanghx 时间: 2014-10-28 21:50
回复 7# pengyong820954

一般是这样的。所以，这个方法才被采用。但是，不能说“skew大的时钟树，其时序就一定不如skew小的”吧。

用useful skew的观点，很容易造出一个反例。
假设某个寄存器的CK端恰好是clock tree上latency最大的那个点。
该寄存器的D端是关键路径的endpoint，现在该路径违例。
增大CK端的clock latency，可以修复该违例，但也意味着clock tree的skew增大。
skew大的clock tree，时序反而更好。

作者: pengyong820954 时间: 2014-10-28 22:42
回复 8# shuanghx

恩是的，必要的时候useful skew还是好的。timing毕竟第一位的。性能是skew越小越好，折中就还是在满足timing情况下，skew做最小的好

作者: IC后端 时间: 2014-10-28 23:15
report_clock_timing -skew 是不是最长路径用max lib,最短路径用min lib? 你用report_clock_timing latency分别报你上面的最长和最短路径来看看？加我Q每天晚上11点答疑

作者: SignOff 时间: 2014-10-29 00:02
报skew的时候不要加OCV

作者: 豆沙包 时间: 2014-10-29 09:37
回复 10# IC后端

没有的，我在分析的时候都采用的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 -late 1.20

作者: 豆沙包 时间: 2014-10-29 09:39
回复 11# SignOff

不加ocv的分析，会不会对后续的时序分析有其他的影响？？

作者: herrzhou 时间: 2014-10-29 10:54

回复 herrzhou

谢谢，，，那我想问一下，，当skew过大不不能满足要求的时候，可以考虑从哪个方面 ...
豆沙包发表于 2014-10-28 15:39

登录/注册后可看大图

你先去debug 为什么skew这么大，然后采取针对性措施

作者: xingyun666666 时间: 2016-1-11 15:35
回复 2# herrzhou

亲，这个为什么是考虑了OCV？我好疑惑，可以传授一下吗？谢谢

作者: 满心欢喜1993 时间: 2018-8-29 11:20
怎么加你好友啊，QQ号多少了

作者: songhao 时间: 2018-9-17 16:16
对skew我也有一个疑问，我们关心的只有local skew，那global skew这个指标有什么用？是不是没有多大意义？

作者: xingyun666666 时间: 2018-9-18 10:24
回复 8# shuanghx

请问师哥，在分析长完tree后的skew时，要看考虑OCV后的skew值，还是不应该看考虑OCV后的skew值？

作者: seuxiaoj 时间: 2018-9-28 11:14
report_clock_timing 是带了derate的值而report_clock_tree是不考虑derate的。
工具在build clock tree的时候显然不会带derate。如果带上derate值，skew会偏大，工具时钟无法找到一个较小的skew。

欢迎光临 EETOP 创芯网论坛 (原名：电子顶级开发网) (https://bbs.eetop.cn/)