一：綜合策略
top-down & bottom-up
1：top-down
層次化結構，只對頂層設計進行全面約束，針對個別模塊有特殊約束；比如管理模塊（clock模塊，reset模塊等）的綜合不會與工作模塊（頂層模塊）放在一起綜合的。
2：bottom-up
對底層的各個模塊定為current_design，進行綜合，加上dont touch屬性；若各層之間有group logic（如與門），還需要對group logic約束；這種風格的綜合約束復雜且多。
所有top-dowm方式用得更多
3：綜合里的關鍵字
邊界優化， ungroup（模塊被打散，只能看到頂層設計），掃描鏈（DFT）。。。。
二：compile_ultra的三級分類
虛擬機不支持，是對compile進行優化；
將模塊全部打散，對於后端來說，全部打散不方便后續操作，只能看到各個與或非門，無法得到具體模塊與模塊之間的關系或者問題。
對關鍵路徑優化，循環迭代優化。目標是滿足時序要求的同時保證面積最小。
分為三個階段的優化：
主要包括：第一階段的結構級的優化(Architectural-Level Optimization)、第二階段的邏輯級優化(Logic-Level Optimization)、最后階段的門級優化(Gate-Level Optimization)。
1：結構級優化（archiiture-level）
結構級優化包括的內容如下：
包括：設計結構的優化，數據通路的優化，共享共同的子表達式，資源共享，重新排序運算符號（詳見http://www.cnblogs.com/IClearner/p/6636176.html）
例如：加法器有普通加法器，超前進位加法器，DC會根據應用場合挑選出合適的加法器。
2：邏輯級優化（logic-level）
一個邏輯表達式可以是與非格式，也可以是或非格式，DC會選擇合適的邏輯表達式來描述邏輯功能。
邏輯優化的內容如下：
做完結構的優化后，電路的功能以GTECH的器件來表示。在邏輯級優化的過程中，可以作結構(Structuring)優化和展(開)平(Flattening)優化。
3：門級優化（Gate-level）
得到網表后的優化，局部優化。
三：其他知識點
1：re-synthesis
網表文件生成后，靜態時序分析時，DC工具對路徑進行分析，對關鍵路徑進行優化，邏輯級優化與門級優化可以迭代使用（若路徑延時過大，不滿足設計規則，DC會resynthesis，一直到路徑延遲滿足要求）。
2：DesignWare Library
IP庫，包含算術操作，標准IP；優點在於設計更快更可靠；在使用compile_ultra會自動使用該庫。
3：綜合最基本的要求是滿足時序要求；
4：CSA算法優化數據通路的設計
5：常見算術優化方法
尤其是第五條，乘法運算改為移位運算，減少資料占用。
6：邏輯復制（logic duplication）
對關鍵路徑部分的負載放在其他路徑上，減少關鍵路徑延時，以面積換速度。
7：庫分析
一個邏輯表達式可由不同的表達方式表達，DC挑選出合適的庫單元實現邏輯。
三：其他有關命令的時序優化及方法
DC綜合之后，我們查看詳細的報告，如果沒有違規，設計既能滿足時間和面積的要求又不違犯設計規則，那么綜合完成。可以把門級網表和設計約束等交給后端(backend)工具做布局(placement )、時鍾樹綜合(clock tree synthesis)和布線(route)等工作，產生GDSII文件。如果設計不能滿足時間和面積的要求或違犯設計規則等，就要分析問題所在，判斷問題的大小，然后采取適當的措施解決問題。問題往往是時序的問題，發生時序違規時可以采取相應的措施，如下圖所示：
（1）當違規得比較嚴重時，也就是時序的違規（timing violation）在時鍾周期的25%以上時，就需要重新修改RTL代碼了。
（2）時序違規在25%以下，有下面的時序優化方法：
①使用compile_ultra命令（在拓撲模式下運行）
compile_ultra跟compile一樣，是進行編譯的命令。compile_ultra命令適用於時序要求比較嚴格，高性能的設計。使用該命令可以得到更好的延遲質量( delay QoR )，特別適用於高性能的算術電路優化。該命令非常容易使用，它自動設置所有所需的選項和變量。下面是這個命令的一些介紹：
compile_ultra命令包含了以時間為中心的優化算法，在編輯過程中使用的算法有:A以時間為驅動的高級優化(Timing driven high-level optimization);B為算術運算選擇適當的宏單元結構;C從DesignWare庫中選擇最好的數據通路實現電路;D映射寬扇入(Wide-fanin)門以減少邏輯級數;E積極進取地使用邏輯復制進行負載隔離;F在關鍵路徑自動取消層次划分(Auto-ungrouping of hierarchies)。
compile_ultra命令支持DFT流程，此外compile_ultra命令非常簡單易用，它的開關選項有:
部分解釋如下所示：
-scan ：做可測試(DFT)編輯；
-no_autoungroup ：關掉自動取消划分特性；
-no_boundary_optimization ：不作邊界優化；
-no_uniquify : 加速含多次例化模塊的設計的運行時間
-area_high_effort_script : 面積優化
-timinq_high_effort_script : 時序優化
上面的開關部分說明如下所示：
**Boundary optimization邊界優化
在編輯時，Design Compiler會對傳輸常數，沒有連接的引腳和補碼信息進行優化，也就是說邊界優化會把邊界引腳一些固定的電平，固定的邏輯進行優化。但是在formility（形式驗證），需要告訴formility電路結構發生了改變。這個改變存放在DC的生成文件里。
以下命令會禁止邊界優化
set_boundary_optimization<cells_designs> false
compile_ultra -no_boundary
**Auto-ungrouping及其取消
compile默認不打散，compile_ultra會自動將模塊打散，打散后只能看到top層和具體實現；
set_ungroup <reference_or_cells> false ;#禁止cell打散
set_app_var compile_ultra_ungroup_dw false ；#禁止打散，使用designware層次
set compile_ultre_ungroup_dw true ;#允許打散，取消desigware層次。也就是說，你你調用的一個加法器和一個乘法器，本來他們是以IP核的形式，或者說是以模塊的形式進行綜合的，但是設置了上面那么變量之后，綜合后那個模塊的界面就沒有了，你不知道哪些門電路是加法器的，哪些是乘法器的。
compile_ultra -no autoungroup ;#全部都不打散
為了使設計的結果最優化，我們建議將compile_ultra命令和DesignWare library一起使用。也就是說不打散較好。
**scan掃描鏈
掃描鏈是在寄存器前加入選擇器，在DFT時可能會有影響，如果想加入scan掃描鏈，在綜合的時候必須評估掃描鏈寄存器的影響，即加入-scan命令。
scan寄存器只是換成mux選擇器，並沒有形成一個鏈。
在多級寄存器級聯時，中間加入buffer或者反相器，只在第一級加入掃描鏈。
**-timing
compile_ultra -timing 關鍵路徑上時序的優化，但如果時序余量較大，不適宜使用該命令，否則會使時序優化的優先級大於DRC（DRC,時序優化，面積優化）
寄存器復制
**Behavior Retiming（簡稱BRT技術）
對門級網表的時序進行優化，也可以對寄存器的面積進行優化。BRT通過對門級網表進行管道傳遞(pipeline)（或者稱之為流水線），使設計的傳輸量(throughput)更快。BRT有兩個命令:
optimize_registers ：適用於包含寄存器的門級網表（不是compile_ultra的開關選項）。
pipeline_design ：適用於純組合電路的門級網表。
對於寄存器的的優化，舉例如下，對於下面的電路，既包含有組合邏輯電路又包含有寄存器：
后級的寄存器與寄存器之間的時序路徑延遲為10. 2 ns，而時鍾周期為10 ns,因此，這條路徑時序違規。但是前級的寄存器與寄存器之間的時序路徑延遲為7. 5 ns，有時間的冗余。使用optimize_registers命令，可以將后級的部分組合邏輯移到前級，使所有的寄存器與寄存器之間的時序路徑延遲都小於時鍾周期，滿足寄存器建立時間的要求。optimize_registers命令首先對時序做優化，然后對面積作優化。優化后，在模塊的入/輸出邊界，電路的功能保持不變。該命令只對門級網表作優化。
除了單獨使用這個命令之外，還可以在編譯的時候往往加上選項-retime（這個好像只有compile_ultra才有這個開關選項）。
-retime與optimize_registers區別：-retime針對一般邏輯，optimize_reggisters針對pipeline結構進行優化；兩者可以同時使用。
-retime選項的功能也就是：當有一個路徑不滿足，而相鄰的路徑滿足要求時，DC會進行路徑間的邏輯遷移，以同時滿足兩條路徑的要求，這也叫adaptive retiming,如下圖所示：
retime主要通過moving，spliting，merging來進行優化，如下圖
當不需要DC遷移某器件時，例如寄存器輸出，不希望改變，可使用set_dont_retime <cells or designs> true
對於純組合邏輯的流水線（管道）優化，舉例如下，對於純組合邏輯電路進行優化如下所示：
左邊電路，是一個純組合電路，它的路徑延遲為23. 0 ns。對這個電路進行管道傳遞優化后，得到右邊所示的電路。顯然，電路的傳輸量(throughput)加快了。需要注意的是，在使用這個命令時，需要在RTL設計中把寄存器預置好，否則DC不知道這些寄存器是怎么來的。
**路徑分組group_path
DC為了便於分析電路的時間，時序路徑又被分組。路徑按照控制它們終點的時鍾進行分組。如果路徑不被時鍾控制，這些路徑被歸類於默認(Default)的路徑組。我們可以用report_path_group命令來報告當前設計中的路徑分組情況。
Design Compiler中，常用report_timing命令來報告設計的時序是否滿足目標。執行report_timing命令時，DC做4個步驟:
·把設計分解成單獨的時間組;
·每條路徑計算兩次延遲，一次起點為上升沿，另一次起點為下降沿;
·在每個路徑組里找出關鍵路徑(critical path)，即延遲最大的路徑;
·顯示每個時間組的時間報告。
關於怎么閱讀時序報告，我們后面進行介紹。
如果DC不進行專門的分組，只有默認（Default）的路徑組，DC只對默認組的關鍵路徑進行優化，當它不能為關鍵路徑找到一個更好的優化解決方案時，綜合過程就停止。DC不會對次關鍵路徑(Sub-critical paths)作進一步的優化。因此，如果關鍵路徑不能滿足時序的要求，違反時間的約束，次關鍵路徑也不會被優化，它們僅僅被映射到工藝庫，如下圖所示：
對於下面的電路，假設加設計約束后，所有的路徑屬於同樣的時鍾組，也就是只有一個路徑組：
如果組合電路部分的優化不能滿足時序要求，並且關鍵路徑在組合電路里，根據DC的默認行為，組合電路中關鍵路徑的優化將會阻礙了與它屬於相同時鍾組的寄存器和寄存器之間路徑的優化。防止出現這種情況可用下面兩種方法:自定義路徑組和設置關鍵范圍。
**多核優化：
report_host_options 顯示有多少核
多核時：set_host_options -max_cores 4 ;#申請4個內核，系統不一定給4個核
compile -ultra
一般一個license只支持2個核，多個license支持多個核；
關掉多個核：remove_host_options
set_host_options -max_cores 1
四：group_path繼續研究（自定義路徑與設置關鍵范圍）
1：自定義路徑
綜合時，工具只對一個路徑組的最差(延時最長)的路徑作獨立的優化，但並不阻礙另外自定義路徑組的路徑優化。產生自定義路徑組也可以幫助綜合器在做時序分析時采用各自擊破(divide-and-conquer)的策略，因為report_timing命令分別報告每個時序路徑組的時序路徑。這樣可以幫助我們對設計的某個區域進行孤立，對優化作更多的控制，並分析出問題所在，如下圖所示的：
產生自定義路徑組的命令如下所示：
#Avoid getting stuck on one path in the reg-reg group
group_path -name INPUTS -from [all_inputs]
group_path -name OUTPUTS -to [all_outputs]
group_path -name COMBO -from [all_inputs] -to [all_outputs]
上面的命令產生三個自定義的路徑組，加上原有的路徑組，即寄存器到寄存器的路徑組（因為受CLK控制，默認的是CLK的路徑組），現在有4個路徑組。組合電路的路徑，屬於“COMBO”組，由於該路徑組的起點是輸入端，在執行“group_path -name INPUTS -from [all_inputs]”命令后,命令中用了選項“-from [all_inputs]"，它們原先屬於“INPUTS”組。在執行“group_path -name OUTPUTS -to [all_outputs]”命令后，組合電路的路徑不會被移到“OUTPUTS”組，因為開關選項‘'-from”的優先級高於選項”-to”，因此組合電路的路徑還是留在“INPUTS”路徑組。但是由於“group_path -name COMBO -from [all_inputs] -to [all-outputs]”命令中同時使用了開關選項“-from”和“-to" ,組合電路路徑的起點和終點同時滿足要求，因此它們最終歸屬於“COMBO”組。DC以這種方式工作來防止由於命令次序的改變而使結果不同。我們可以用report_path_group命令來得到設計中時序路徑組的情況。
產生自定義的路徑組后，路徑優化如下圖所示，此時，寄存器和寄存器之間的路徑可以得到優化：
DC可以指定權重進行優化，當某些路徑的時序比較差的時候，可以通過指定權重，着重優化該路徑。權重最高5，其次是2，默認是1；因此最差的要設置5；如下圖所示，下面的命令就是着重優化CLK這個路徑組：-weight
2：設置關鍵范圍
-critical_range:對路徑優化的范圍設置，每個組內在范圍內的路徑都會被優化
set_critical_range 2 [current_design]
使用上面的命令之后，DC會對在關鍵路徑2ns的范圍內的所有路徑作優化，解決相關次關鍵路徑的時序問題可能也可以幫助關鍵路徑的優化。時序優化的示意圖如下所示：
如果在執行set_critical_range命令后，優化時使關鍵路徑時序變差，DC將不改進次關鍵路徑的時序。我們建議關鍵范圍的值不要超過關鍵路徑總值的10%。
3: 自定義路徑組+關鍵范圍
上圖第四句對CLK組加強優化（weight=5），關鍵范圍為0.2
4：自定義路徑組與關鍵范圍的區別
自定義路徑組: 用戶自定義路徑組后，如果設計的總性能有改善，DC允許以犧牲一個路徑組的路徑時序(時序變差)為代價，而使另一個路徑組的路徑時序有改善。在設計中加入一個路徑組可能會使時序最差的路徑時序變得更差。
關鍵范圍: 關鍵范圍不允許因為改進次關鍵路徑的時序而使同一個路徑組的關鍵路徑時序變得更差。如果設計中有多個路徑組，我們只對其中的一個路徑組設置了關鍵范圍，而不是對整個設計中的所有路徑組都設置了關鍵范圍，DC只會並行地對幾條路徑優化，運行時間不會增加很多。
五：實戰
1：打開DC
2：讀入verilog代碼檢查等等
3：讀入約束然后compile -map_effort high -area_effort high;最大compile，相當於compile ultra
**沒有路徑組約束時，
report_timing -delay_type max 檢查最差路徑
看到Path Group只有一條默認組Clk；report_path_group
**加入路徑組約束（簡單加入）
再次source ./rtl/scripts/TOP.con
report_path_group會得到四條路徑
report_timing -delay_type max 檢查最差路徑
顯示四條路徑的各個最差路徑。