在綜合的時候，可能大家最關心的是如何設置提高timing QoR。在DC中有一個比較常用的方法，使用set_cost_priority -delay。

DC綜合過程中默認的優化是有優先級順序的，即DRC>timing。有的時候會出現某些路徑的優化考慮了DRC而忽略timing，導致timing violation的出現。比如以下這種情況：

上圖所示的電路中第一級buffer驅動了fanout為3的buffer tree（這里只畫了fanout=3，一般情況下遠遠不止），這段net因為fanout較多有可能會有max transition，max capacitance甚至max fanout的DRC違例。但是起點寄存器到終點寄存器之間都只有2級buffer，timing情況還比較樂觀，不太容易出現timing violation。在默認情況下，DC為了避免DRC問題，不會將電路優化成這種樣子，更有可能是以下的電路：

這段電路從功能上與上一圖中電路是一致的，在優化過程中為了避免DRC違例，DC將buffer tree拉長，并將連接到終點寄存器的節點分散，這樣每個buffer只驅動一個寄存器以及一個buffer，比起圖1中一個buffer驅動3個buffer，fanout的數量減小了。乍一看只是從3減小為2，但如果在圖1中第一級buffer驅動的是15個fanout，那么這里的將會是15->2的fanout的優化，可以大大避免DRC問題。

DRC的問題避免了，但我們可以明顯看到圖二中從起點寄存器到終點寄存器中間經過的buffer數量增加了（最多經過4個buffer），而這條path比起圖一中的timing path，無疑timing會更差（這里即便考慮到圖1中high fanout的net的big transition可能帶來的單級較大delay，也不會差過多級buffer相連接，如果buffer數量增加，delay差距更加明顯）。

在這種情況下，set_cost_priority -delay這個命令就能使綜合工具在優化過程中優先考慮timing，從而綜合出圖1的網表，即便有一些DRC violation，我們也可以放到后端去修復。因此，我們如果在分析綜合網表的時候（在DC中使用report_timing)看到有較長的buffer tree導致的timing violation，并且每級buffer的fanout都較小，可以考慮使用這個命令來實現改善。