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就修不掉的所謂“互卡”現象。