我們都知道在postCTS階段做optDesign時序優化時需要進行hold violation的fixing。所以這個過程勢必要通過插hold buffer來解決hold violation。這類hold buffer的名字帶有"PHC"的關鍵詞。
select_obj [dbGet top.insts.name PHC]
llength [dbGet top.insts.name PHC]
在后續的postRoute階段做時序優化階段，工具默認也有一個area reclaim的步驟。這個步驟主要的目的是在設計critical path上進一步把path上的cell面積做小。
工具會把setup critical path上冗余的hold buffer刪掉，來進一步優化setup。
但是工具默認不會刪除non-critical path上冗余的hold buffer。
這就會出現很多timing path的hold timing margin偏大的情況。一個設計要做出一個合理的結果，必須確保IC實現各個環節各個步驟的結果都是合理的。
下面分享解決這個問題的幾個方法。
方法一： 報告timing并做基于hold的面積優化
Legacy UI:
timeDesign -postRoute
reclaimArea -maintainHold
Common UI:
time_design -post_route
opt_area -hold_aware
方法二： 設置opt優化mode
Legacy UI:
setOptMode -postRouteAreaReclaim {none | setupAware | holdAndSetupAware}
optDesign -postRoute
Common UI:
set_db opt_post_route_area_reclaim {none | setup_aware | hold_and_setup_aware}
opt_design -post_route
使用這個方法工具刪除多余的hold buffer后不會引起setup和drv violation。
聽說Latch可以高效修hold違例（Timing borrowing及其應用）
所以，當PT signoff需要插入很多hold buffer，返回PR工具插不進去時，我們可以使用今天的這個方法來刪掉部分冗余的hold buffer來釋放更多的空間。
當然，這個提前是PT和PR之間的timing correlation比較好的情況。
另外，我們還可以自己針對繞線或空間比較緊張的區域，人工刪掉部分帶PHC的hold buffer來釋放點空間。
【思考題】如下所示timing path的removal存在600ps+的violation。請問這個hold violation存在的主要原因是什么？這么大的hold violation應該如何修復呢？
)