| ****************時鍾樹的約束格式***************** 原來的CTS用ctstch文件作為約束，而CCOpt Native直接用命令進行約束，命令基本都能跟ctstch對應上。比如原來的AutoCTSRootPin對應create_ccopt_clock_tree，等等。 無論是原來的CTS還是CCOpt Native，Encounter都提供了sdc轉時鍾樹約束的功能，不過用它做出來的時鍾樹質量基本是娛樂級的...還是自己重新寫一套約束比較好。 *********對需要減小insertion delay寄存器的約束********* 對某些關鍵路徑的寄存器，或是為了優化reg2out，或是為了減小OCV沖擊，我們會希望它們的insertion delay盡可能小。在原來的CTS中，我們會通過定義正的MacroModel來將這些寄存器提前，但定義的值很難把握，稍有不慎就會使主時鍾樹被額外地推后。在CCOpt Native中，可以對這些寄存器創建一個Skew Group，把這個Skew Group的target_insertion_delay設為一個很小的值，工具會自動把這些寄存器提到最前。 *********對需要增加insertion delay寄存器的約束********* 在原來的CTS中，我們會定義負的MacroModel來將這些寄存器推后。在CCOpt Native中，同樣是對這些寄存器創建一個Skew Group，把這個Skew Group的target_insertion_delay設為你期望的推后值即可。 與原先相比的改進是，CCOpt Native中可以定義Delay Cell用來推后時鍾（當然， 需要庫里有上下沿平衡的Delay Cell），以節省面積和功耗。原來的CTS中要想工具自動調用Delay Cell是很困難的。 **************隔離非關鍵寄存器的約束*************** 在原來的CTS中，我們會把非關鍵寄存器丟到LeafPinGroup中，並通過一個小的ExcludeBuffer進行隔離，以防止對非關鍵寄存器的平衡降低主時鍾樹的性能。但有個局限是，一個設計中的寄存器通常並不能非黑即白地划分為“關鍵”和“非關鍵”，還有一些“次關鍵”寄存器，我們既不希望它們拖慢主時鍾樹，又不希望這些寄存器被太小的ExcludeBuffer過多地推后。問題是，ExcludeBuffer只能定義一個Cell，而且一旦被丟進LeafPinGroup，各項優化的優先級都會被降到最低。 在CCOpt Native中，只需對關鍵/次關鍵/非關鍵寄存器創建各自的Skew Group，設置好期望的insertion delay值即可。當開啟advanced_insertion_delay_optimization和recluster_to_reduce_power兩個變量后，工具會自動對“次關鍵”寄存器用大Buffer/Inverter隔離，“非關鍵”寄存器用小Buffer/Inverter隔離，非常智能。 *********手動設置target insertion delay的意義********** CCOpt Native在智能度大大改善的同時，還提供了相當多的手工約束命令，乍一看甚是嚇人...為什么工具可以全自動完成，還要手動設置insertion delay，這要從CCOpt Native的流程來看。CCOpt Native的流程大致可描述為initial cluster -> optDesign -> adjust skew -> optDesign -> adjust skew...（循環）。如果不手動設置target insertion delay，那工具在initial cluster時會把時鍾做成完全平衡的，這時跑optDesign會把datapath往錯誤的方向優化，很可能后面就回不來了...手動設置target insertion delay后，initial cluster就會把時鍾做成你設置的skew值，第二步的optDesign就會收斂得非常快了。 手動設置的target insertion delay不需要特別精確，因為后面的adjust skew步驟里工具會自動幫你Fine Tune。 ***************對Debug的一點Tips***************** 如果你剛剛接觸CCOpt Native，那么建議打開ccopt_worst_chAIn_report_timing_too變量，在每一輪optDesign之后都會報一個timeDesign出來，這時候就可以進行Debug了，而不必等到整個CCOpt Native跑完。 ******************QoR的改變******************** 在以前CTS的流程中，preCTS的時序約束通常需要比postCTS更緊，收緊的值約等於時鍾樹skew值，因為skew可能會劣化Timing。 在CCOpt Native中，postCTS的約束甚至可以比preCTS再緊一點，因為所有的skew都是有益的。這確實是非常令人驚訝的QoR提升... （以preCTS時序約束中Clock Latency已反標為前提） *****************一點改進建議******************** CCOpt Native這種針對Critical Chain的優化，是不能應用於同步鏈的（如果同步鏈的skew被借出去就會損MTBF，雖然Timing看起來是Clean的）。希望后續有方便點的方法來照顧同步鏈... |