fix hold violations时，插入buffer或者delay cell的位置，是靠近launch端还是capture端，还是并无任何要求呢？
在逻辑和物理上都应该尽量靠近capture端，也就是endpoint。在逻辑上更靠近endpoint能够保证插入的cells只会影响到有violation的path，物理上更靠近endpoint能够有效避免DRV，因为修hold时加入的cell普遍驱动能力较弱。
同上篇中的setup相同，在实际设计中，因为会有一些margin加入，所以计算公式与上述略有不同，但本质没有改变。那么，遇到hold violation一般怎么修呢？根据上面的公式可以看出，主要有三类方法：
1. 增大data line delay
此方法为后端设计中最常见的手法。具体操作是在data line上插入buffer 或者delay cell去增加delay。在此提出一个问题请大家思考：插入buffer或者delay cell的位置，是靠近launch端还是capture端，还是并无任何要求呢？答案下期揭晓~
2. 增大launch clock delay
增加launch clock delay的方法理论上可行，但是在实际中不到万不得已我们是不希望动到clock的，因为动clock line不仅需要确认前后级path是否有足够的margin，有时候还会遇到影响范围不可控或者实现不方便等诸多限制。
3. 减小capture clock delay
此方法也具有方法2的缺点，同时还因为剪短clock delay在物理上无法实现的风险，因此应用更少。
总结来说，与setup不同，hold因为与clock cycle并无关系，只要clock tree做的比较balance，hold就比较容易收敛。但是因为setup和hold其实是一对相互制约的约束，也就是说修了hold后setup的slack就会变小甚至变负，因此越是高频的path，setup和hold相互制约就越严重，甚至会出现修了setup后hold就修不掉的所谓“互卡”现象。