Tcl與Design Compiler（十二）——綜合後處理
概述
前面也講了一些綜合後的需要進行的一些工作，這裡就集中講一下DC完成綜合了，產生了一些檔，我們就要查看它生成的網表和資訊，下面就來介紹DC綜合完成之後要進行哪些工作：
也就是說，DC一般完成綜合後，主要生成.ddc、.def、.v和.sdc格式的檔（當然還有各種報告和log）
.sdc文件：標準延時約束檔：
裡面都是一些約束，
Scan_def.def文件：DFT、形式驗證可能用到
裡面包含的是一些掃描鏈的佈局資訊，需要注意的是，必須在生成ddc網表檔之前生成.def（也就先生成.def檔），以便將def檔包含在ddc檔中。
.sdf、.v文件：
標準延時格式和網表格式檔，用於後模擬。
下面是輸出（生成）文件的一些命令：
1.綜合網表處理與生成
（1）綜合網表的處理：
完成綜合並通過時序等的分析後，我們需要把設計和約束以某種格式存儲好，作為後端工具的輸入。
把設計以VHDL或Verilog格式存檔時，需要去掉或避免檔中有assign指令，因為該指令會使非Synopsys公司的工具在讀入文件時產生問題。該指令也可能會在反標( back-annotation)流程中產生問題。此外，要保證網表中沒有特別的字元。例如，寫出網表時，有時網表中會有反斜線符號“\”，
·assign：
多埠連線(multiple port nets)會在網表中用assign指令表示，如下圖所示：
上面的設計中有冗餘的埠(包括內部埠，又稱層次引腳)。如果我們將設計展開（flatten）, DC可能把它們優化掉，即去掉這些埠。但是如果我們不展開設計，將得到下面的結果:
Output Reset_AluRegs，Latch_Instr,....
assign Reset_AluRegs=Latch_Instr;
多埠連線，即一條連線連接多個埠，三種類型:直通連線(Feedthroughs)，即從輸入端直接到輸出端；連線驅動多個埠(也就是上面的那個情況)；常數連線驅動多個埠。
在預設的情況下，如遇到上述的情況，DC寫出網表時，會在網表產生assign指令。如果設計中有多埠連線，應該在編譯過程中將它們去掉。去掉多埠連線使用下面的命令:
set_fix_multiple_port_nets -all -buffer_constants [get_designs *]
·特殊符號：
特別字元是指除數字，字母或底線以外的任何字元。當DC寫出網表時，如果遇到信號Bus[31]，它會插入反斜線符號“\”，將其變為\BUS[31]。但是匯流排Bus[31:0」中的一個信號還用Bus[31]，沒有用反斜線符號，
用change_names命令可將設計中的特別字元去掉。change_names命令的其中一選項是“-rules"，後面可跟用自訂的命名規則或Verilog命名規則。在DC中用define_name_rules命令來規定自訂的命名規則。例如我們可以用該命令來指定可以使用哪些字元，禁止使用哪些字元，名字的長度等。一般來說，Verilog命名規則可以處理幾乎所有的特殊字元。
執行change_names命令後，它會把不允許使用的字元用允許使用的字元來代替。VHDL語言中，多維陣列(multi-dimensionalarrays)使用方括弧作為字下標的分隔符號(word subscript delimiters)。為了避免使用反斜線符號，先使用change_names命令把字下標的分隔符號轉換為底線。如下所示：
（2）相關檔的生成
經過處理之後的網表就可以生成了，除了了網表之外，我們還可以生成時序、面積報告等，相關命令如下所示：
一個是生成.ddc檔，裡面包含了很多資訊。一個是生成.v的門級網表。一個是生成標準約束檔，以供後面進行佈局佈線提供參考。
最後，進行網表處理和生成檔的綜合命令如下所示：
2.時序檢查與報告的生成
最後，我們要講檢查設計報告、連接設計報告、DC綜合過程中的資訊報告、時序檢查報告、面積檢查報告等進行生成，方便我們進行檢查：
# Get report file
redirect -tee -file ${REPORT_PATH}/check_design.txt {check_design };
redirect -tee -file ${REPORT_PATH}/check_timing.txt {check_timing };
redirect -tee -file ${REPORT_PATH}/report_constraint.txt {report_constraint -all_violators};
redirect -tee -file ${REPORT_PATH}/check_setup.txt {report_timing -delay_type max };
redirect -tee -file ${REPORT_PATH}/check_hold.txt {report_timing -delay_type min };
redirect -tee -file ${REPORT_PATH}/report_area.txt {report_area };
這裡使用的重定位的命令redirect，意思是將後面{}中命令的執行結果保存到檔中（命令的具體用法前面有講到，也可以通過man redirect進行查看）
（1）時序報告的查看：
下面主要介紹時序報告的檢測，畢竟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"。
·第三部分是路徑要求部分，如下圖所示：
這個路徑要求部分是我們約束所要求的部分；值-0. 06從庫中查出，其絕對值是寄存器的建立時間。值2.17為時間週期加上延時減去時鐘偏斜值再減寄存器的建立時間(假設本例中的時鐘週期是2 ns)。
·第四部分是時間總結部分，如下圖所示：
DC得到實際資料到達的時間和我們要求的時間後，進行比較。資料要求2.17ns前到達（也就是資料延時要求不得大於2.17ns），DC經過計算得到實際到達時間是2.15ns，因此時序滿足要求，也就是met，而不是時序違規（violation）。時間冗餘(Timing margin)，又稱slack，如果為正數或‘0'，表示滿足時間目標。如果為負數，表示沒有滿足時間目標。這時，設計違反了約束(constraint violation)。
（2）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不能充分使用組合電路的優化演算法對電路進行時序優化，是否考慮需要進行模組的重新劃分。
（3）設計違規檢查：
當然有時候並不是真正的設計違規，有可能是約束設計過緊，有可能是設計的輸入延時太緊導致violation，比如前面那個實戰中，綜合得到的結果是可以滿足要求的，但是由於約束不當而導致DC爆出違規。
（4）查看分組優化結果：
主要是查看路徑分組之後，路徑的時序情況是什麼樣的，如下所示：
本節的基本內容就是這樣了，本節就沒有什麼實戰之類了。
用有效的字元代替非有效(特別)的字元。用change_names命令可將設計中的特別字元去掉。change_names命令的其中一選項是“-rules"，後面可跟用自訂的命名規則或Verilog命名規則。在DC中用define_name_rules命令來規定自訂的命名規則。例如我們可以用該命令來指定可以使用哪些字元，禁止使用哪些字元，名字的長度等。一般來說，Verilog命名規則可以處理幾乎所有的特殊字元。
執行change_names命令後，它會把不允許使用的字元用允許使用的字元來代替。VHDL語言中，多維陣列(multi-dimensionalarrays)使用方括弧作為字下標的分隔符號(word subscript delimiters)。為了避免使用反斜線符號，先使用change_names命令把字下標的分隔符號轉換為底線。如下所示：
（2）相關檔的生成
經過處理之後的網表就可以生成了，除了了網表之外，我們還可以生成時序、面積報告等，相關命令如下所示：
一個是生成.ddc檔，裡面包含了很多資訊。一個是生成.v的門級網表。一個是生成標準約束檔，以供後面進行佈局佈線提供參考。
最後，進行網表處理和生成檔的綜合命令如下所示：
2.時序檢查與報告的生成
最後，我們要講檢查設計報告、連接設計報告、DC綜合過程中的資訊報告、時序檢查報告、面積檢查報告等進行生成，方便我們進行檢查：
# Get report file
redirect -tee -file ${REPORT_PATH}/check_design.txt {check_design };
redirect -tee -file ${REPORT_PATH}/check_timing.txt {check_timing };
redirect -tee -file ${REPORT_PATH}/report_constraint.txt {report_constraint -all_violators};
redirect -tee -file ${REPORT_PATH}/check_setup.txt {report_timing -delay_type max };
redirect -tee -file ${REPORT_PATH}/check_hold.txt {report_timing -delay_type min };
redirect -tee -file ${REPORT_PATH}/report_area.txt {report_area };
這裡使用的重定位的命令redirect，意思是將後面{}中命令的執行結果保存到檔中（命令的具體用法前面有講到，也可以通過man redirect進行查看）
（1）時序報告的查看：
下面主要介紹時序報告的檢測，畢竟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"。
·第三部分是路徑要求部分，如下圖所示：
這個路徑要求部分是我們約束所要求的部分；值-0. 06從庫中查出，其絕對值是寄存器的建立時間。值2.17為時間週期加上延時減去時鐘偏斜值再減寄存器的建立時間(假設本例中的時鐘週期是2 ns)。
·第四部分是時間總結部分，如下圖所示：
DC得到實際資料到達的時間和我們要求的時間後，進行比較。資料要求2.17ns前到達（也就是資料延時要求不得大於2.17ns），DC經過計算得到實際到達時間是2.15ns，因此時序滿足要求，也就是met，而不是時序違規（violation）。時間冗餘(Timing margin)，又稱slack，如果為正數或‘0'，表示滿足時間目標。如果為負數，表示沒有滿足時間目標。這時，設計違反了約束(constraint violation)。
（2）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不能充分使用組合電路的優化演算法對電路進行時序優化，是否考慮需要進行模組的重新劃分。
（3）設計違規檢查：
當然有時候並不是真正的設計違規，有可能是約束設計過緊，有可能是設計的輸入延時太緊導致violation，比如前面那個實戰中，綜合得到的結果是可以滿足要求的，但是由於約束不當而導致DC爆出違規。
（4）查看分組優化結果：
主要是查看路徑分組之後，路徑的時序情況是什麼樣的，如下所示：
本節的基本內容就是這樣了，本節就沒有什麼實戰之類了。