hold slack这么大还能修复吗
时间：10-02
整理：3721RD
点击：
Rising edge of clock RCH_STABLE0.00000.0000
Clock Source delay0.00000.0000
Clock Network delay(propagated)4.04914.0491
Clock Skew0.00004.0491
Clock reconvergence pessimism0.00004.0491
Hold time200.0000204.0491
---------------------------------------------------------------------------------
Required time204.0491
Arrival time14.0430
---------------------------------------------------------------------------------
Slack-190.0061(VIOLATED)
Clock Source delay0.00000.0000
Clock Network delay(propagated)4.04914.0491
Clock Skew0.00004.0491
Clock reconvergence pessimism0.00004.0491
Hold time200.0000204.0491
---------------------------------------------------------------------------------
Required time204.0491
Arrival time14.0430
---------------------------------------------------------------------------------
Slack-190.0061(VIOLATED)
约束问题。
建议你检查一下约束
当setup与hold的约束存在矛盾，工具通常会舍弃优化hold
hold time约束肯定有问题，你的始终频率是多少?是不是始终的边沿设置错了。
这条Path的Violation 95%是假的
99%
99.9%假的
肯定timing path分析的不正确的，看下约束吧，
200 这个是约束设的吗 ?有点问题吧
200 是一个otp的hold time。在它的lib文件里就有。
或许考虑在逻辑上修改
那一定是个很慢的信号，一般需要在设计上保证它的时序，sdc里面就直接false/multicycle path了。
如果前端没有做的话，就直接加200ns的延迟。问一下，那个opt的clock period是多少?
hold time的意义理解了就知道约束有问题