STA Timing Report分析

angangang3484

new_tree

对于你这条path，我画了个简单的电路图，如上图。


你这条path明显是同一个clock下的半周期check path。


造成violation的原因是tree没长好，skew太大。


1. 如果你这个module rxRX下的FF不需要和其他module下的FF做balance
我推荐的方法使在common path上找一个buf，作如下设置：


set_clock_tree_exceptions -exclude_pins "$buf/A"

create_clock -name new_clk -period $num -waveform { 0$num/2 } [get_pins {$buf/Z}]

set_clock_uncertainty  $num/10 [get_clocks {new_clk}]

set_clock_transition -rise -max  $num/10 [get_clocks{new_clk}]

set_clock_transition -fall -max  $num/10 [get_clocks{new_clk}]

set_clock_transition -rise -min  $num/10 [get_clocks{new_clk}]

set_clock_transition-fall -min $num/10 [get_clocks {new_clk}]


2.如果你这个module rxRX下的FF需要和其他module下的FF做balance


可以将rxRX的FF设为float pin。


set all_reg [all_registers ]
set dbg_all_regs [get_cells $all_reg -filter "full_name=rxRX/*"]
set dbg_all_regs_pins [get_pins -of $dbg_all_regs -filter "name==CLK"]


foreach_in_collection clk_pin $dbg_all_regs_pins {

set_clock_tree_exceptions -float_pins $clk_pin -float_pin_max_delay_rise -$num   -float_pin_max_delay_fall -$num -float_pin_min_delay_rise -$num -float_pin_min_delay_fall -$num


}



注意两段代码中每个$num，需要你自己set。

angangang3484

楼主，请你一定要尝试下我的方案，并及时反馈结果。
我的方法会增加latency，如果latency达不到你们chip的要求，你可以通过 set_clock_latency -max以及手动fix clock cell等方法来调节。
我这个方法在我遇到的类似的问题中都能很好的解决吧。如果要没解决你的问题，或者不懂，请回复我。

overdriver

一级逻辑不过几十p，clock latency确实够长，report 加个-path full_clock_ex 上来看看。useful skew没什么不好，hold有问题就工具修，很少看到两边顶上的，真要是顶上，可能约束有问题或者其他奇怪的地方。还是先确认采样时钟的半周期问题是否合理，这比什么都重要。然后确认clock latency没问题。

loosin

clock latency 8.82, data requirement 8.81

xjg@hmes

回复 13# angangang3484


    首先，不知道你有没有注意到crpr的设定是same transition。
    另外，skew是长的latency加后derating引起的。不加derating我的skew几乎接近0。
    你说的设floatingpin的方法我在工作之后尝试过，效果不是很明显。
    关于半周期及制约都经过严格确认，没有问题.

angangang3484

回复 16# xjg@hmes


   我没怀疑什么啊。
那你latency那么大，所以我说你tree没长好。
在方法1中，你参考图片上的结构图，在common path的结束点设置新的tree的root点，就是做新的tree，重新计算latency，此时新tree的latency就小了，derating影响小，你的这些path就met了。


你能不能发这条path在dc综合，place后，cts后，route后这四步full clock timing report。
我想看看这条path如何变化。
麻烦顺便把这条path的launch path map和capital path map发出来。

都知道你的latency很大，那就找出为什么这么大的原因撒。

xjg@hmes

回复 17# angangang3484


    首先，非常感谢您的耐心解答。
您说的方法1，制约不能随便修改，clk root改也只能是在cts阶段修改，sta时还是laytency很大。
另外，这个工作3个月前就结束了，数据已经全部删除，很抱歉不能提供您要的一些数据。
还是很感谢您的耐心指点，以后有什么新发现及时和您沟通。

最后，我工作最终减小latency的方法是：
手动配置clock path上的mux、icg等cell，size驱动；
修正clock port作为root的制约；
调试一些cts的制约option；
最终的laytency不到5ns。

我说怀疑制约可能是对另外一位仁兄overdriver 的回答，请不要见怪。
谢谢！

angangang3484

回复 18# xjg@hmes

呵呵，先恭喜你。
   好吧，其实我的意思就是要你在CTS时做。你说的：
手动配置clock path上的mux、icg等cell，size驱动；
修正clock port作为root的制约；
调试一些cts的制约option；


和我给的方法：


方法1和方法2.
“如果latency达不到你们chip的要求，你可以通过 set_clock_latency -max以及手动fix clock cell等方法来调节”





入手点是一样：都是调好这个clock的tree。


因为你这个timing根本就修不下去，所以只有调tree。


减少latency，还可通过mesh等结构来解决的。


后端最简单的回答就是发现问题，找到原因，给出对策。


你这个case不错，一起学习，一起进步。


最后我想问下，你的这个block的latency做到5ns，同一款芯片下的其他人的block的latency都得做得和你差不多才行吧。那他们是怎么做？

xjg@hmes

回复 19# angangang3484


    是个chip，不是block，都是我一个人在做。痛苦的一逼......

angangang3484

回复 20# xjg@hmes


   不错啊，一个人做，那钱都都你一个人拿了。   好差事。