对于hold time uncertainty和slack的问题

最近做一个项目，由于频率比较低才400k，建立时间没有任何问题，主要是hold time，我想要把hold time的slack做大，那么在开始的时候把能不能把hold time uncertainty设大点，比如说由0.3变成1。
这样即使是在signoff的时候 hold time slack为负值，比如-0.1，这样芯片也能过，不知道这样的想法对不对，求指教。
判断芯片hold time的时序通过与否只能看hold time slack ?还是需要看hold time slack +hold time uncertainty?

uncertainty的设定最好是按照signoff条件来，你设大了为了让所有path的 hold都过，就得加更多的buffer，这样面积和功耗就上去了

hold slack 0.3足够了，要那么大干啥

你可以把Derate加的很大，这样基本不会损面积

这是为什么呢?工具应该会根据计算的timing去做优化吧，如果derate设置大了，那么timing结果就会差些，那么工具就会优化，对于hold来说，工具还是会进行插buffer的操作，还是会影响面积和功耗啊?

crpr会把Derate去掉，但不会把Uncertainty去掉

crpr只能去掉 common path上的derate，在非common path上还是存在的啊！

恩，谢谢小编的回答，那如果说我要判断signoff的hold time是否能够过，是看hold time slack，还是也要看hold time uncertainty。假设那时的hold time uncertainty为 0.3，hold time slack为-0.05，我这样的设计能不能过呢?

恩，再补充下，这时候时钟抖动其实没有那么大，我只是人为的把它设大了很多，因为想多给一些鲁棒性。这样的设计能通过吗?