DC時序分析與內部嵌入的時序分析儀（STA）
一：編譯及編譯后步驟
1: 第一次綜合
compile_ultra | -no_boundary | -no_autoungroup | -scan | -timing | -retime
2: 查看時序
report_constraint -all_violation
report_timing
3: 若第二步時序檢查有violation，則可進行group_path增添路徑，優化多條路徑，改進時序約束等等。
group_path -critical -weight ......
4：再次編譯
complile_ultra......
5: 若violation還有，繼續修改，若violation改進不了，則返回rtl代碼階段，修改代碼。
二：report_timing
1：check_timing與report_timing區別
check_timing:檢查路徑是否都有約束，約束是否完整，在綜合之前檢查；
report_timing:檢查時序有沒有問題，在綜合之后檢查。
2：時序報告的查看
下面主要介紹時序報告的檢測，畢竟timing is everything。關於時序報告的查看，前面也講得很清楚了，這里再來具體講述一下。
Design Compiler中，常用report_timing命令來報告設計的時序是否滿足目標（Check_timing:檢查約束是不是完整的，在綜合之前查看，要注意不要與這個混淆）。
時間報告有四個主要部分：
·第一部分是路徑信息部分，如下所示：
主要報告了工作條件，使用的工藝庫，時序路徑的起點和終點，路徑所屬的時鍾組，報告的信息是作建立或保持的檢查，以及所用的線負載模型。
·第二部分是路徑延遲部分，
這個路徑延遲部分是DC計算得到的實際延遲信息；命令執行后，對於下圖中的路徑，得到的一些路徑信息，有了單元名稱（point），通過該單元的延時（Incr）,經過這個單元后路徑的總延時等信息：
上圖的解釋：
路徑的起點是上一級D觸發器的的時鍾端。
input external delay:(由於上一級D觸發器的翻轉(路徑的起點也就這里)、芯片外部組合邏輯而經歷的)輸入延時約束（set_input_delay），也就是數據到達芯片的數據輸入管腳的延時建模,這個延時是1ns;”r”表示上升延時，”f”表示下降延時
clock network delay(idle):時鍾信號從芯片的端口到內部第一個寄存器的延時是0.5ns；
Data1(in):芯片輸入端口到芯片內部真正數據輸入端之間的線延時，是0.04ns。（可以認為是管腳的延時）
U2/y : 這里，前面0.12表示u2這個器件的翻轉/傳輸延時，意思是從這個器件的數據輸入端（包括連線），到輸出端y的延時是0.12ns。后面的1.66的意思是從路徑起點到u2的y輸出的延時是1.66ns.
...
最后u4/D：這里就是終點了，D觸發器的數據輸入端；當然終點也可能是芯片的輸出端口。
報告中，小數點后默認的位數是二，如果要增加有效數(字)，在用report_timing命令時，加上命令選項“-significant_digits"。報告中，Inc:是連線延遲和其后面的單元延遲相加的結果。如要分別報告連線延遲和單元延遲，在使用report_timing命令時，加上命令選項"-input_pins"。
report_timing -max_paths 2 ;#可指定一個組的兩條路徑
report_timing -nworst 3 -max_paths 2 ;#report一個組內的兩條最差路徑
·第三部分是路徑要求部分，如下圖所示：
這個路徑要求部分是我們約束所要求的部分；值-0. 06從庫中查出，其絕對值是寄存器的建立時間。值2.17為時間周期加上延時減去時鍾偏斜值再減寄存器的建立時間(假設本例中的時鍾周期是2 ns)。
·第四部分是時間總結部分，如下圖所示：
DC得到實際數據到達的時間和我們要求的時間后，進行比較。數據要求2.17ns前到達（也就是數據延時要求不得大於2.17ns），DC經過計算得到實際到達時間是2.15ns，因此時序滿足要求，也就是met，而不是時序違規（violation）。時間冗余(Timing margin)，又稱slack，如果為正數或‘0'，表示滿足時間目標。如果為負數，表示沒有滿足時間目標。這時，設計違反了約束(constraint violation)。
3：timing_report的選項與debug
在進行靜態時序分析時，report_timing是常用的一個命令，該命令有很多選項，如下所示（具體可以通過man進行查看）：
我們可用report_timing的結果來查看設計的時序是否收斂，即設計能否滿足時序的要求。我們也可以用其結果來診斷設計中的時序問題，對於下面的報告，
外部的輸入延遲為22 ns，對於時鍾周期為30 ns的設計，顯然是太大了。設計中，關鍵路徑通過6個緩沖器，需要考慮這些緩沖器是否真的需要；OR單元的延遲為10.72ns，似乎有問題。關鍵路徑通過四個層次划分模塊，從模塊u_proc，經模塊u_proc/u_dcl，經模塊u_proc/u_ctl，到模塊u_int。前面我們說過，DC在對整個電路做綜合時，必須保留每個模塊的端口。因此，邏輯綜合不能穿越模塊邊界，相鄰模塊的組合邏輯並不能合並。這4個層次划分模塊使得DC不能充分使用組合電路的優化算法對電路進行時序優化，是否考慮需要進行模塊的重新划分。
三：查看violations
report_constraint -all_violation
1: 規則
查看是否有timing違規：hold time violation在后端可優化，所以可忽略；set time violation需要解決。
查看DRC是否有違規：一定要解決掉。
查看area是否有違規：有時可忽略。
2： 例子：
當然有時候並不是真正的設計違規，有可能是約束設計過緊，有可能是設計的輸入延時太緊導致violation，比如前面那個實戰中，綜合得到的結果是可以滿足要求的，但是由於約束不當而導致DC爆出違規。
四：查看分組優化結果：
主要是查看路徑分組之后，路徑的時序情況是什么樣的，如下所示：
五：DC內部集成STA工具（static timing analyse）
計算每條路徑實際延時信息，與期望延時（約束延時）做比較，看是否有violation