dc下clock_uncertainty的设置问题
我的设计始终74ns；
内部有clk2和clk32分频；
根据我曾经在论坛上看到的uncertainty的设置:
setup 10%clk_period
hold 5%clk_period；
对于clk32这个时钟，时钟周期都是2368ns，按照上述的要求进行设置的话，是否会过大了些?
uncertaity是不是有个设置的上限，或者说一般设置多少就可以了?
补充一下，我感觉uncertainty
setup设个0.5
hold设置0.25就差不多了。
不知道是不是这样啊?
up and look for help！
DC只分析setup吧
dc的时候或许uncertainty可以大一点，不考虑hold时间，不过在后面布局布线的时候通常会改小。
没错，DC确实只分析setup；它要是报了这些min delay的错误，是该忽略?
可以先多留点margin，主要还是要看optimization后timing的结果！
你说的可是在PR之后的opt?
对了，你的意思是说，dc下uncertainty不设置-hold 的时间
然后PR的时候再加上?
DC 主要优化的是datapath path，我们在dc阶段，一般通过把clock period卡到signoff的70%，比如signoff的频率是10ns，那么综合就是按照7ns来run， clock uncertainty的值一般是要看PLL的jitter再加一点margin。
那之后的呢?比如PR的时候的优化，这个时钟还是按照70%来么?PT下呢?
以及分频时钟也取70%?
在时序不紧张的前提下，可以尽量设置的大一点
APR的时候也会进行时序分析的呀，在APR的时候就可以看到hold的时序。我们师兄说如果hold过不了的话可以考虑改变约束。当然面积要够
看EETOP長知識
也就是说dc的时候如果报了hold，也就是min_delay violation，可以不用管。
然后在PR的时候可以修正?其实可以发现，在dc的时候，如果把clock latency或者hold uncertainty设置的大一些，就很容易出现问题。
直接忽略，因为后面布局布线的时候还要插入buffer，而且元器件的位置改变等等都应该会改变线上的延迟时间
，在后面uncertainty的大小可能要改，来满足APR 的时序。
是的，不要去管hold的时序
这个uncertainty的是改大还是改小?
我现在是在dc下只设个setup的uncertainty
然后给PR工具的uncertainty有原来的setup还有新的hold；
然后做完CTS后，就把时钟的相关属性去掉，再加上一个微小的uncertainty去做postRoute OPT
如果你用原来的uncertaity可以过得了hold和setup的timing分析的话就不用改，不然的话就该小，我是这样改的
xuexi
这个setup的uncertaity究竟根据什么来设置?