《XDC約束技巧》系列中討論了XDC約束的設(shè)置方法、約束思路和一些容易混淆的地方。我們提到過(guò) 約束是為了設(shè)計(jì)服務(wù),寫入Vivado中的XDC實(shí)際上就是用戶設(shè)定的目標(biāo),Vivado對(duì)FPGA設(shè)計(jì)的實(shí)現(xiàn)過(guò)程必須以滿足XDC中的約束為目標(biāo)來(lái)進(jìn)行。那么:
如何驗(yàn)證實(shí)現(xiàn)后的設(shè)計(jì)有沒有滿足時(shí)序要求?
如何在開始布局布線前判斷某些約束有沒有成功設(shè)置?
如何驗(yàn)證約束的優(yōu)先級(jí)?
這些都需要用到Vivado中的靜態(tài)時(shí)序分析工具。所以讓我們來(lái)從如何讀懂和用好Timing Report開始吧。
靜態(tài)時(shí)序分析
靜態(tài)時(shí)序分析(Static Timing Analysis)簡(jiǎn)稱STA,采用窮盡的分析方法來(lái)提取出整個(gè)電路存在的所有時(shí)序路徑,計(jì)算信號(hào)在這些路徑上的傳播延時(shí),檢查信號(hào)的建立和保持時(shí)間是否滿足時(shí)序要求,通過(guò)對(duì)最大路徑延時(shí)和最小路徑延時(shí)的分析,找出違背時(shí)序約束的錯(cuò)誤并報(bào)告。
STA不需要輸入向量就能窮盡所有的路徑,且運(yùn)行速度很快、占用內(nèi)存較少、覆蓋率極高,不僅可以對(duì)芯片設(shè)計(jì)進(jìn)行全面的時(shí)序功能檢查,而且還可利用時(shí)序分析的結(jié)果來(lái)優(yōu)化設(shè)計(jì)。所以STA不僅是數(shù)字集成電路設(shè)計(jì)Timing Sign-off的必備手段,也越來(lái)越多地被用到設(shè)計(jì)的驗(yàn)證調(diào)試工作中。
STA在FPGA設(shè)計(jì)中也一樣重要,但不同于一般數(shù)字集成電路的設(shè)計(jì),F(xiàn)PGA設(shè)計(jì)中的靜態(tài)時(shí)序分析工具一般都整合在芯片廠商提供的實(shí)現(xiàn)工具中。在Vivado中甚至沒有一個(gè)獨(dú)立的界面,而是通過(guò)幾個(gè)特定的時(shí)序報(bào)告命令來(lái)實(shí)現(xiàn)。
OCV與PVT
即便是同一種FF,在同一個(gè)芯片上不同操作條件下的延時(shí)都不盡相同,我們稱這種現(xiàn)象為OCV(on-chip variation)。OCV表示的是芯片內(nèi)部的時(shí)序偏差,雖然很細(xì)小,但是也必須嚴(yán)格考慮到時(shí)序分析中去。
產(chǎn)生OCV的原因主要有PVT(Process / Voltage / Temperature)三個(gè)方面,而STA要做的就是針對(duì)不同工藝角(Process Corner)下特定的時(shí)序模型來(lái)分析時(shí)序路徑,從而保證設(shè)計(jì)在任何條件下都能滿足時(shí)序要求,可以正常工作。
通常PVT對(duì)芯片性能的影響如下圖所示,
不同的PVT條件組成了不同的corner,另外在數(shù)字電路設(shè)計(jì)中還要考慮RC corner的影響,排列組合后就可能有超過(guò)十種的corner要分析。但是在FPGA設(shè)計(jì)中的靜態(tài)時(shí)序分析一般僅考慮Best Case和Worst Case,也稱作Fast Process Corner 和Slow Process Corner,分別對(duì)應(yīng)極端的PVT條件。
Multi-Corner
Vivado中的STA支持多角時(shí)序分析(Multi-Corner Timing Analysis),會(huì)對(duì)以上兩種corner下的時(shí)序同時(shí)進(jìn)行分析,然后報(bào)告最差的情況。因?yàn)槊總€(gè)corner下的延時(shí)也會(huì)有一定的變化范圍,所以時(shí)序分析還會(huì)考慮每種corner下的最大延時(shí)和最小延時(shí)。
如果一個(gè)設(shè)計(jì)在Best Case和Worst Case下都能滿足時(shí)序要求,則可以推算這個(gè)設(shè)計(jì)在其允許的任何操作條件下都能保持正常工作。
這里要提醒大家,不要被corner的名字誤導(dǎo),實(shí)際上,同樣一條路徑可能在Slow Corner中滿足時(shí)序卻在Fast Corner中有時(shí)序違例。但是你在Vivado中看到的時(shí)序報(bào)告只會(huì)顯示其對(duì)兩種corner并行分析后選出的最差情況。
有特殊需要的情況下,可以在Vivado中通過(guò)config_timing_corners-corner -delay_type 來(lái)選擇將某種corner應(yīng)用于setup和/或hold的分析。在Report Timing Summary 和Report Timing的圖形化界面也可以通過(guò)Timer Setting對(duì)corner做調(diào)整,具體界面詳見稍后描述。
這樣最大化考慮OCV的時(shí)序分析方法在處理同一條路徑的共同時(shí)鐘路徑時(shí)也會(huì)應(yīng)用不同的延時(shí)數(shù)據(jù),從而會(huì)得出更為悲觀的數(shù)據(jù)。為了真實(shí)反映路徑延時(shí)情況,這部分延時(shí)必須被糾正,這就是CRPR(Clock Reconvergence Pessimism Removal)。
仔細(xì)觀察時(shí)序報(bào)告便可以發(fā)現(xiàn)在報(bào)告路徑的Slack之前有一行顯示clock pessimism已經(jīng)被考慮在內(nèi),在進(jìn)行Setup Check時(shí)會(huì)加上一定的clock pessimism,而Hold Check時(shí)則會(huì)減去一定的clock pessimism。
下圖顯示了CRPR的來(lái)源以及在Vivado時(shí)序報(bào)告中的具體體現(xiàn)。
時(shí)序命令與報(bào)告
Vivado中用于時(shí)序分析的命令主要有以下兩條,且都有對(duì)應(yīng)的圖形化設(shè)置界面。
report_timing_summary主要用于實(shí)現(xiàn)后的timing sigh-off
report_timing主要用于交互式的約束驗(yàn)證以及更細(xì)致具體的時(shí)序報(bào)告與分析
report_timing_summary
我們先看看report_timing_summary ,實(shí)際上,不僅在布局布線后,在綜合后甚至是更具體的實(shí)現(xiàn)過(guò)程中的每一小步之后都可以運(yùn)行,從而得到一個(gè)全局的時(shí)序報(bào)告。
在Vivado IDE中點(diǎn)擊Report Timing Summary后可以改變報(bào)告的內(nèi)容,例如每個(gè)時(shí)鐘域報(bào)告的路徑條數(shù),是否setup和hold全都報(bào)告等等。每改變一個(gè)選項(xiàng)都可以看到窗口下方的Command一欄顯示出對(duì)應(yīng)的Tcl命令。修改完設(shè)置后可以直接按OK鍵確認(rèn)執(zhí)行,也可以拷貝Command欄顯示的命令到Tcl腳本中稍后執(zhí)行。
這里有個(gè)小竅門,通過(guò)-name指定一個(gè)名字,就可以在Vivado IDE中新開一個(gè)窗口顯示這條命令的執(zhí)行結(jié)果,這個(gè)窗口還可以用來(lái)跟其他諸如Device View或是Schematic View等窗口之間cross probing。這一點(diǎn)也同樣適用于包括report_timing 在內(nèi)的絕大部分Vivado中的report命令。
在設(shè)置窗口中還有Timer Settings一欄(report_timing中也有),可以用來(lái)改變報(bào)告時(shí)采用的具體corner、速度等級(jí)以及計(jì)算布線延時(shí)的方式。很多時(shí)候我們可以借助Timer的設(shè)置來(lái)快速驗(yàn)證和調(diào)試設(shè)計(jì)需求。
舉例來(lái)說(shuō),在實(shí)現(xiàn)后的報(bào)告中顯示時(shí)序違例比較嚴(yán)重,我們可以直接在Timer設(shè)置中改變速度等級(jí)后重新報(bào)告時(shí)序,來(lái)驗(yàn)證把當(dāng)前這個(gè)已經(jīng)布局布線完畢的設(shè)計(jì)切換到更快一檔的芯片中是否可以滿足時(shí)序要求。
另外,在布局布線后的設(shè)計(jì)上報(bào)告時(shí)序,往往不能更直觀地發(fā)現(xiàn)那些扇出較大或是邏輯級(jí)數(shù)較高的路徑。此時(shí)我們可以修改連線模型為estimated,報(bào)告出布局后布線前的時(shí)序而無(wú)需另外打開對(duì)應(yīng)階段的 DCP并重新運(yùn)行時(shí)序報(bào)告命令來(lái)操作,這么做節(jié)約時(shí)間的同時(shí),也更容易找到那些高扇出路徑以及由于布局不佳而導(dǎo)致的時(shí)序違例。我們也可以修改連線模型為none,這樣可以快速報(bào)告出那些邏輯延時(shí)較大以及邏輯級(jí)數(shù)較高的路徑。以上這些改變Timer設(shè)置的方法可以幫助我們快速定位設(shè)計(jì)中可能存在的問(wèn)題和缺陷。
report_timing_summary實(shí)際上隱含了report_timing、report_clocks 、check_timing 以及部分的report_clock_interaction命令,所以我們最終看到的報(bào)告中也包含了這幾部分的內(nèi)容。另外自Vivado 2014.3版起,打開實(shí)現(xiàn)后的結(jié)果時(shí)會(huì)直接打開一個(gè)預(yù)先產(chǎn)生好的報(bào)告。
Timing Summary報(bào)告把路徑按照時(shí)鐘域分類,每個(gè)組別下缺省會(huì)報(bào)告Setup、Hold以及Pulse Width檢查最差的各10條路徑,還可以看到每條路徑的具體延時(shí)報(bào)告,并支持與Device View、Schematic View等窗口之間的交互。
每條路徑具體的報(bào)告會(huì)分為Summary、Source Clock Path、Data Path和Destination Clock Path幾部分,詳細(xì)報(bào)告每部分的邏輯延時(shí)與連線延時(shí)。用戶首先要關(guān)注的就是Summary中的幾部分內(nèi)容,發(fā)現(xiàn)問(wèn)題后再根據(jù)具體情況來(lái)檢查詳細(xì)的延時(shí)數(shù)據(jù)。其中,Slack顯示路徑是否有時(shí)序違例,Source和Destination顯示源驅(qū)動(dòng)時(shí)鐘和目的驅(qū)動(dòng)時(shí)鐘及其時(shí)鐘頻率, Requirement顯示這條路徑的時(shí)序要求是多少,Data Path顯示數(shù)據(jù)路徑上的延時(shí),Logic Level顯示這條路徑的邏輯級(jí)數(shù),而Clock Path Skew和 Clock Uncertainty則顯示時(shí)鐘路徑上的不確定性。
以上圖這條路徑來(lái)舉例,通過(guò)Summary我們可以得到這樣的信息:這是一條clk時(shí)鐘域內(nèi)的路徑,時(shí)鐘周期為3.125ns,這條路徑有0.268ns的時(shí)序違例。違例的主要原因是邏輯級(jí)數(shù)較高導(dǎo)致的數(shù)據(jù)鏈路延時(shí)較大,但連線延時(shí)的比例也較高,所以可以仔細(xì)看看這條路徑的數(shù)據(jù)路徑上有沒有可能改進(jìn)布局、降低扇出或者是減少邏輯級(jí)數(shù)的優(yōu)化方向。
report_timing
report_timing是更具體的時(shí)序報(bào)告命令,經(jīng)常用來(lái)報(bào)告某一條或是某些共享特定節(jié)點(diǎn)的路徑。用戶可以在設(shè)計(jì)的任何階段使用report_timing,甚至是一邊設(shè)置XDC,一邊用其來(lái)驗(yàn)證約束的可行性與優(yōu)先級(jí)。在Vivado IDE中可以由Tools > Timing > Report Timing 調(diào)出其圖形化設(shè)置窗口。
與report_timing_summary類似,調(diào)整選項(xiàng)后對(duì)應(yīng)的Tcl命令也會(huì)在Command欄生成,在Targets一欄還可以設(shè)置需要報(bào)告路徑的起始點(diǎn)/途經(jīng)點(diǎn)/結(jié)束點(diǎn),可以三個(gè)都設(shè)置或是僅設(shè)置其中任何一項(xiàng),每一項(xiàng)都支持通配符匹配甚至是正則表達(dá)式查找。report_timing報(bào)告出的路徑延時(shí)與report_timing_summary中具體到每根路徑上的報(bào)告一致,可以以此為依據(jù)幫助我們定位時(shí)序失敗的原因。
用report_timing來(lái)報(bào)告時(shí)序其實(shí)還有一些更常見的應(yīng)用場(chǎng)景,用來(lái)幫助我們?cè)O(shè)置和驗(yàn)證約束,尤其是那些時(shí)序例外約束。
舉例來(lái)說(shuō),在設(shè)計(jì)過(guò)程中我們約束了一條或數(shù)條多周期約束,不同于UCF必須讀入約束后重跑設(shè)計(jì),我們可以直接在Tcl Console中輸入這條XDC,無(wú)需重跑設(shè)計(jì),直接用report_timing來(lái)驗(yàn)證。在隨之顯示的時(shí)序報(bào)告Summary部分可以看到Timing Exception后列出這條路徑被設(shè)置了怎樣的時(shí)序例外約束(注意,不加額外option時(shí),以下兩條命令都僅針對(duì)setup check )。
單純的一條多周期約束沒有什么特別,但是如果使用了通配符后的時(shí)序例外有重疊的情況下,Vivado會(huì)根據(jù)優(yōu)先級(jí)來(lái)決定對(duì)某條路徑應(yīng)用怎樣的約束。當(dāng)設(shè)計(jì)較大,XDC較多時(shí),一邊設(shè)置XDC一邊用report_timing來(lái)驗(yàn)證就變得尤其重要。
另外,僅僅輸入report_timing而不加任何option,Vivado便會(huì)報(bào)告出時(shí)序違例最嚴(yán)重的那條路徑,方便我們快速了解當(dāng)前設(shè)計(jì)的WNS,找到最差的那條路徑。在驗(yàn)證I/O約束時(shí)也常常用到report_timing,只要指定-from 某個(gè)輸入或是-to某個(gè)輸出便可以快速驗(yàn)證當(dāng)前設(shè)計(jì)在接口上的時(shí)序。
get_timing_paths
除了上述兩個(gè)大家比較熟悉的時(shí)序報(bào)告命令,Vivado中還提供一個(gè)get_timing_paths的命令,可以根據(jù)指定的條件找到一些特定的路徑。我們可以利用其返回值中的一些屬性來(lái)快速定位設(shè)計(jì)中的問(wèn)題。
例如邏輯級(jí)數(shù)這個(gè)影響FPGA性能的一大因素,因?yàn)榻?jīng)常隱藏在時(shí)序報(bào)告后很難被發(fā)現(xiàn)。在Vivado中,除了借助綜合后的報(bào)告來(lái)找到那些可能因?yàn)檫壿嫾?jí)數(shù)較高而導(dǎo)致的時(shí)序難滿足的路徑外,還有一個(gè)更直接的辦法,可以一次性報(bào)告出設(shè)計(jì)中那些高邏輯級(jí)數(shù)的路徑,方便我們有針對(duì)性的深入分析和優(yōu)化。
下圖這個(gè)例子報(bào)告了時(shí)序最差的10條路徑的邏輯級(jí)數(shù)。需要注意的是,在綜合后和在布局布線后用一樣的腳本報(bào)告出的結(jié)果會(huì)稍有不同,對(duì)邏輯級(jí)數(shù)較為關(guān)注的情況,還是建議以綜合后的結(jié)果為主要依據(jù)。
-
數(shù)字電路
+關(guān)注
關(guān)注
193文章
1579瀏覽量
80180 -
靜態(tài)時(shí)序分析
+關(guān)注
關(guān)注
0文章
28瀏覽量
9561
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論