時(shí)序分析基本概念介紹<sdc檢查>

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

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

Missing clock definition

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

Unconstrained endpoint

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

No input/output delay

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

set_case_analysis conflict

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

Incorrect timing exception

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

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

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

Log

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

set_message_info –id UITE-123 –limit 10000

check_timing

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

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

可以使用以下命令檢查：

check_timing -verbose > func_check_timing.rpt

report_analysis_coverage

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

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

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

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

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

all_fanin/all_fanout

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

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

get_attribute

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

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

report_cell

report_case_propagation

report_disable_timing

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