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
關於DC的綜合學習（1） 原理基礎
何謂綜合？一言以蔽之就是講高層次描述轉化成門級網表的過程。門級網表是什麼，裡面是各種單元和ip核。於是這個轉化過程必定是要在標準單元庫和施加特定時序約束的基礎之上。工藝庫，在綜合裡面就是邏輯庫，其中包含了標準單元以及巨集單元的延時資訊 邏輯資訊 面積等描述。綜合的最終目的一是設計中沒有時序違例。二是...
Spring 學習之 bean的前 後處理
在bean被建立以及裝配後，beanpostprocessor 介面為你提供了二次機會來修改這個bean。public inte ce beanpostprocessor public class fuddifier implements beanpostprocessor public objec...
Python學習筆記9 異常處理
就看這篇部落格吧 一篇搞定所有的異常處理，講的很詳細。異常 python中各種異常也是類，類exception繼承自類baseexception，還有其他各種異常等等，此外，通過繼承baseexception或者exception可以自定義異常。異常處理 python直譯器檢測到錯誤，觸發異常 也允...