关于report_clock_tree和report_clock_timing报出的skew

report_clock_tree和report_clock_timing报出的skew有什么不同?我看有资料说如果no timing duration前者的skew会比后者大，否则前者的skew 会小一点。

自己顶一下。哎呀呀！求指点啊！谢谢啦！

不好意思，我没看到叫做report_clock_tree的命令

report_clock_timing
-type [skew | interclock_skew | jitter | summary | latency
[ [-launch | -capture]
[-rise | -fall]
| [-histogram [-histogram_range interval size ]]
[-logic_level [-source {clock_root | generated_clock}]]
]
]
[-early | -late]
[-clock clock_list ]
[-from_clock from_clock_list ]
[-to_clock to_clock_list ]
[-from from_list ]
[-to to_list ]
[-nworst worst_entries ]
[-greater_than lower_limit ]
[-view view_name ]
[-verbose]
[-format column_list ]
[-tcl_list]
[{> | >>} filename ]
Generates a clock skew report for the current design. The software generates a separate report for each specified clock or pair of clocks. You specify the clocks using the -clock parameter, and clock pairs using the -from_clock and -to_clock parameters. You can use the - nworst and -greater_than parameters with the -from_clock and - to_clock parameters to generate reports with skew to the specified sink pins. You can use the - early and -late parameters to specify the type of skew to be reported.
Note: To remove common path pessimism from the reported skew, use the setAnalysisMode -cppr both command before using the report_clock_timing command. The report contains a separate column for common path adjustment values.
You can use the report_clock_timing command to perform MMMC based SSTA analysis. In MMMC mode, the command reports the latency and clock skew for all individual views. You can use the report_clock_timing -view parameter to report clock timing for a user-specified view.

小编比较的应该是ICC中的两条命令，dt的是，EDI中类似的命令可以将结果赋给tcl变量，但ICC的这种命令貌似不行，写script的时候总是要通过文件读写
这个要顶起！回头我也做实验去，小编应该也做实验看看，光看文档不行。

ICC也可以，比如get_timing_path

小编是跟我说话吗?受宠若惊啊……
这个命令都没怎么用过， 回头试试。
要是能提供我要的信息并能在内存中处理那就perfect了~

report_clock_timing报的是local skew
report_clock_tree报的是global skew

report_clock_timing报的是local skew,有timing关系的两条路径之间的skew，考虑derate
report_clock_tree报的是global skew，任意两条路径之间的skew，不一定有timing关系，不考虑derate

有的啊，呵呵！

就是在实际中遇到的问题，呵呵！

是的是的，谢谢啊！
但是我遇到的问题是report_clock_tree中有一个clock的skew比report_clock_timing报出的大，而其他的clock都是前者小。
希望您指点一下。不甚感激！

是的是的，您说的非常对，谢谢啊！
但是我遇到的问题是report_clock_tree中有一个clock的skew比report_clock_timing报出的大，而其他的clock都是前者小。
我的这个设计中有timing deraing。按道理说不是report_clock_tree比report_clock_timing报出的skew小吗?
希望您指点一下。不甚感激！

常理（不设置dereate）是report_clock_tree 的skew比report_clock_timing的大。
如果设置了derate，那就要看你的derate在date和clockpath上设的有多大了，因为report_clock_timing是考虑derate的，所以skew比report_clock_tree报出来的大 或者 小都是有可能的！

哦，您说的有道理，嗯，谢谢啦！
但是在同一个设计中不同clock对相同的derate产生的结果不同吗?
我做了两遍这个设计，之前做的那个是所有的clock都是report_clock_tree比report_clock_timing报出的skew小。不知道这次是怎么回事?难道是时钟树长的不一样?我的脚本都没有改过呢。
菜鸟求指点啊！谢谢谢谢！

要看timing path的latency的呀，skew就白了就是2个latency的差值的最大值，derate是加在这两条path上的，假设你report_clock_tree报出来的skew的两条path，pathA 的latency是1ns ，pathB的latency是2ns ，那么skew是1ns，因为report_clock_timing报的是有timing关系的两条path间的skew，所以假设前面说的pathA 和pathB之间是有timing关系的，那现在如果你的derate是这样加的，1）pathA：1ns * 0.9（derate）latency就是0.9。pathB： 2ns * 1(derate)latency 就还是2ns那么现在skew是 2-0.9 = 1.1 比report_clock_tree报出来的大2） pathA ： 1ns* 1.1 (derate)latency是 1.1ns 。 pathB：2ns * 1（derate） latency是2ns ，现在skew是2-1.1 = 0.9 比report_clock_tree报出来的小。
所以还是要看你的derate的加法的啊。
如果不加derate ，肯定是report_clock_tree 报的skew大。

哦，我明白你的意思了。我根据自己的设计整理了一下，嗯，您说的很对。厉害啊！谢谢谢谢啦！

终于弄明白了，果然如此，膜拜众大神

Have a good job

请问report_clock_timing -type latency,报latency的时候不考虑derate吧?还是乘以derate呢?

report_clock_timing是考虑derate的

太牛逼了，谢谢啊。

正常情况下，report_clock_tree-summary报出的skew会比report_clock_timing -type skew大，因为前者报的是global skew,后者报的是local skew。存在一种情况就是小编的设计中涉及到memory的时钟，report_clock_timing这个命令在报skew的时候会在路径上额外加上memory时钟端到其内部离时钟端最近的寄存器的延迟，而前面那个命令是没有计算这部分的，所以小编可以去关注下report_clock_timing报出来的路径终点是不是memeory的clock 端。

谢谢！