当setup的slack不足时，如何修hold？

出现这样的情况觉得就只能修时钟了，降低时钟的uncertainty与transition或者其他的时钟不确定性相关参数，否则你所说的情况应该永远不可能修掉的吧。 纯理论分析，个人理解，么有实践经验，若有说错的地方，还请多多指点。 还有个叫margin的是不是设的过大?

是不是还有其他方法呢?

多半情况是约束设错了

就小弟见识，你所说的这种情况，如果时钟按照ideal的话，应该不存在这样的路径，因为只是触发器的setup与hold时间就大于了一个时钟周期了，这还怎么做设计，组合逻辑的延时难道要成负的不成?

是因为uncertainty对hold和setup设得不一样吗?还有其他参数问题和衡量问题吗?能否具体点?我这里概念很模糊···
还有一问题就是一个设计中，为何会同时出现setup和hold为例，该怎么处理呢?
还请陈小编指教~

这个要看具体的timing report

这相当于setup与hold约束矛盾
还是再看一下约束吧

我的理解是在计算setup与hold的过程中，都会加入冗余。
即setup的startpoint 时钟会被加上uncertainty，endpoint ff时钟会被减掉uncertainty。hold正好相反。 这样的情况下就有可能造成你所说的情况

额，不太理解，在sta时，不是计算setup和hold时数据路径都加上相应的uncertainty吗?时钟路径上貌似不加吧

恩，数据路径也是由前一级的时钟路径驱动的，貌似约束都是加在始终源上的。

明白了！才想起来uncertainty是针对时钟设的，包括jitter或skew（pre-cts）。谢谢~

那到底是加还是减呢?

计算的时候减去就行了，uncertainty就是让你的slack计算结果更小

修不掉