時序分析基本概念介紹<sdc檢查>

sdc是整個設(shè)計中最重要的文件，它的正確與否直接決定了PR能否順利進行以及timing的最終sign off。很多設(shè)計團隊經(jīng)常只有等到做完綜合，STA，PR后才發(fā)現(xiàn)到sdc上的問題，再去修改sdc重新run job。這樣就浪費了項目寶貴的schedule。而且，不同的工具，不同的design team處理約束的方式都不盡相同。這些因素，都要求我們必須在設(shè)計前期盡早的完成sdc的檢查。

sdc的問題有很多種，我大致羅列了以下一些：

Missing clock definition

和clock相關(guān)的問題都要引起特別大的重視，因為它會嚴(yán)重影響到timing還有CTS的質(zhì)量。有沒有正確地定義generate clock， 關(guān)鍵節(jié)點上的時鐘有沒有傳過去，哪些地方應(yīng)該stop clock propagation......這些問題我們都應(yīng)該第一時間去檢查確認(rèn)。

Unconstrained endpoint

這也是很嚴(yán)重的一點問題，unconstrained就代表著工具不會去檢查該條timing path，也就不會發(fā)現(xiàn)潛在的時序問題了。有的endpoint確實可能是靜態(tài)信號，但也不排除我們遺漏input/output delay或者錯誤地設(shè)置了false path。因此，這也值得我們重點檢查。

No input/output delay

理論上，每個端口上都需要設(shè)置端口約束。因此，我們必須正確地檢查它有沒有遺漏，以及掛在正確的clock上。

set_case_analysis conflict

通常我們會在DFT模式切換時設(shè)置case analysis值。因此，需要和DFT team確認(rèn)值的正確性。因為設(shè)了case analysis的port就不會再去檢查該條timing path了。

Incorrect timing exception

timing exception也是很重要的，false path和multicycle path的設(shè)定也需要和前端team確認(rèn)，設(shè)置完以后也要檢查一下是否正確運行，或是被別的exception覆蓋。

那我們?nèi)绾卧谇捌谌プ鰏dc的檢查呢？

方法有很多，首先最基本的需要做到以下幾點：

Log

首先，檢查zero wire load階段的timing log是最重要的一點，我們需要確保沒有任何的Error，每個warning也要逐條分析，有合理的解釋，記得需要把message條數(shù)的限制關(guān)掉，工具默認(rèn)報出的條數(shù)有限。

set_message_info –id UITE-123 –limit 10000

check_timing

這也是普遍常用的一個命令，它能檢查出No clock，Unconstrained endpoint，No input/output delay等最基本的約束問題。完整的檢查列表如下所示：

STA和PR工具里都能使用，而且建議兩邊都檢查一下，因為PR工具里會用ETM model， 而STA工具通常都是flatten運行，檢查的數(shù)據(jù)有所不同。為了便于區(qū)分，通常把function mode和DFT mode分開檢查。

可以使用以下命令檢查：

check_timing -verbose > func_check_timing.rpt

report_analysis_coverage

這是個檢查timing check覆蓋率的命令?？梢詧蟪霎?dāng)前約束下，各種timing check (setup, hold,min_period,min_pulse_width等) 的覆蓋率，報告如下所示：

我們主要關(guān)注報告中的Untested這一欄，它說明我們約束沒有覆蓋的點，造成untested的原因有很多，主要有以下幾點。因此我們必須逐條歸納分析原因，如果是sdc造成的，那就要修改sdc。

如果要看那么多文件的話，也許會很麻煩，而且總會覺得遺漏了一些。其實，很多公司也是有專門檢查sdc的小工具。學(xué)會用這些工具，會專業(yè)方便得多，起到事半功倍的效果。這邊推薦Galaxy Constraint Analyzer和SpyGlass這兩個專門檢查sdc的工具。

最后，對于上述檢查出來的這些問題，有很多是可以waive的，那我們?nèi)绾稳シ治瞿兀?/p>

工具本身提供很多很方便的debug命令

all_fanin/all_fanout

這兩個命令可以很容易的trace timing path的起點和終點，大家可以對應(yīng)對IO設(shè)計表格和sdc，來檢查一下約束是否有錯。

pt_shell> all_fanin –only_cells –flat –startpoints –to F1/CLK

get_attribute

這個db的命令大家一定很熟悉，我們可以使用它來得到pin上的clock，arrival window等信息，來檢查clock有沒有正確propagation

還有以下一些常用命令也可以幫我們報出各種有用的信息，不分別介紹了

report_cell

report_case_propagation

report_disable_timing

講到這，大家對該如何檢查sdc有個簡單認(rèn)識了吧，一定要記住，sdc很重要，一定要好好寫。