這些都需要用到Vivado中的靜態時序分析工具。所以讓我們來從如何讀懂和用好Timing Report開始吧。

靜態時序分析

靜態時序分析（ Static Timing Analysis）簡稱STA，採用窮盡的分析方法來提取出整個電路存在的所有時序路徑，計算訊號在這些路徑上的傳播延時，檢查訊號的建立和保持時間是否滿足時序要求，通過對最大路徑延時和最小路徑延時的分析，找出違背時序約束的錯誤並報告。

STA不需要輸入向量就能窮盡所有的路徑，且執行速度很快、佔用記憶體較少、覆蓋率極高，不僅可以對晶片設計進行全面的時序功能檢查，而且還可利用時序分析的結果來優化設計。所以STA不僅是數字積體電路設計Timing Sign-off的必備手段，也越來越多地被用到設計的驗證除錯工作中。

STA在FPGA設計中也一樣重要，但不同於一般數字積體電路的設計，FPGA設計中的靜態時序分析工具一般都整合在晶片廠商提供的實現工具中。在Vivado中甚至沒有一個獨立的介面，而是通過幾個特定的時序報告命令來實現。

OCV與PVT

即便是同一種FF，在同一個晶片上不同操作條件下的延時都不盡相同，我們稱這種現象為OCV（on-chip variation）。OCV表示的是晶片內部的時序偏差，雖然很細小，但是也必須嚴格考慮到時序分析中去。

產生OCV的原因主要有PVT（Process / Voltage / Temperature）三個方面，而STA要做的就是針對不同工藝角(Process Corner)下特定的時序模型來分析時序路徑，從而保證設計在任何條件下都能滿足時序要求，可以正常工作。

通常PVT對晶片效能的影響如下圖所示，

不同的PVT條件組成了不同的corner，另外在數位電路設計中還要考慮RC corner的影響，排列組合後就可能有超過十種的corner要分析。但是在FPGA設計中的靜態時序分析一般僅考慮Best Case和Worst Case，也稱作Fast Process Corner 和Slow Process Corner，分別對應極端的PVT條件。

Multi-Corner

Vivado中的STA支援多角時序分析（Multi-Corner Timing Analysis），會對以上兩種corner下的時序同時進行分析，然後報告最差的情況。因為每個corner下的延時也會有一定的變化範圍，所以時序分析還會考慮每種corner下的最大延時和最小延時。

如果一個設計在Best Case和Worst Case下都能滿足時序要求，則可以推算這個設計在其允許的任何操作條件下都能保持正常工作。

這裡要提醒大家，不要被corner的名字誤導，實際上，同樣一條路徑可能在Slow Corner中滿足時序卻在Fast Corner中有時序違例。但是你在Vivado中看到的時序報告只會顯示其對兩種corner並行分析後選出的最差情況。

有特殊需要的情況下，可以在Vivado中通過config_timing_corners -corner -delay_type 來選擇將某種corner應用於setup和/或hold的分析。在Report Timing Summary 和Report Timing的圖形化介面也可以通過Timer Setting對corner做調整，具體介面詳見稍後描述。

這樣最大化考慮OCV的時序分析方法在處理同一條路徑的共同時鐘路徑時也會應用不同的延時資料，從而會得出更為悲觀的資料。為了真實反映路徑延時情況，這部分延時必須被糾正，這就是CRPR（Clock Reconvergence Pessimism Removal）。

仔細觀察時序報告便可以發現在報告路徑的Slack之前有一行顯示clock pessimism已經被考慮在內，在進行Setup Check時會加上一定的clock pessimism，而Hold Check時則會減去一定的clock pessimism。

下圖顯示了CRPR的來源以及在Vivado時序報告中的具體體現。

時序命令與報告

Vivado中用於時序分析的命令主要有以下兩條，且都有對應的圖形化設定介面。

report_timing_summary

我們先看看report_timing_summary ，實際上，不僅在佈局佈線後，在綜合後甚至是更具體的實現過程中的每一小步之後都可以執行，從而得到一個全域性的時序報告。

在Vivado IDE中點選Report Timing Summary後可以改變報告的內容，例如每個時鐘域報告的路徑條數，是否setup和hold全都報告等等。每改變一個選項都可以看到視窗下方的Command一欄顯示出對應的Tcl命令。修改完設定後可以直接按OK鍵確認執行，也可以拷貝Command欄顯示的命令到Tcl指令碼中稍後執行。

這裡有個小竅門，通過-name 指定一個名字，就可以在Vivado IDE中新開一個視窗顯示這條命令的執行結果，這個視窗還可以用來跟其他諸如Device View或是Schematic View等視窗之間cross probing。這一點也同樣適用於包括report_timing 在內的絕大部分Vivado中的report命令。

在設定視窗中還有Timer Settings一欄（report_timing中也有），可以用來改變報告時採用的具體corner、速度等級以及計算佈線延時的方式。很多時候我們可以藉助Timer的設定來快速驗證和除錯設計需求。

舉例來說，在實現後的報告中顯示時序違例比較嚴重，我們可以直接在Timer設定中改變速度等級後重新報告時序，來驗證把當前這個已經佈局佈線完畢的設計切換到更快一檔的晶片中是否可以滿足時序要求。

另外，在佈局佈線後的設計上報告時序，往往不能更直觀地發現那些扇出較大或是邏輯級數較高的路徑。此時我們可以修改連線模型為estimated，報告出佈局後佈線前的時序而無需另外開啟對應階段的 DCP並重新執行時序報告命令來操作，這麼做節約時間的同時，也更容易找到那些高扇出路徑以及由於佈局不佳而導致的時序違例。我們也可以修改連線模型為none，這樣可以快速報告出那些邏輯延時較大以及邏輯級數較高的路徑。以上這些改變Timer設定的方法可以幫助我們快速定位設計中可能存在的問題和缺陷。

report_timing_summary實際上隱含了report_timing、report_clocks 、check_timing 以及部分的report_clock_interaction命令，所以我們最終看到的報告中也包含了這幾部分的內容。另外自Vivado 2014.3版起，開啟實現後的結果時會直接開啟一個預先產生好的報告。

Timing Summary報告把路徑按照時鐘域分類，每個組別下預設會報告Setup、Hold以及Pulse Width檢查最差的各10條路徑，還可以看到每條路徑的具體延時報告，並支援與Device View、Schematic View等視窗之間的互動。

每條路徑具體的報告會分為Summary、Source Clock Path、Data Path和Destination Clock Path幾部分，詳細報告每部分的邏輯延時與連線延時。使用者首先要關注的就是Summary中的幾部分內容，發現問題後再根據具體情況來檢查詳細的延時資料。其中，Slack顯示路徑是否有時序違例，Source和Destination顯示源驅動時鐘和目的驅動時鐘及其時鐘頻率， Requirement顯示這條路徑的時序要求是多少，Data Path顯示資料路徑上的延時，Logic Level顯示這條路徑的邏輯級數，而Clock Path Skew和 Clock Uncertainty則顯示時鐘路徑上的不確定性。

以上圖這條路徑來舉例，通過Summary我們可以得到這樣的資訊：這是一條clk時鐘域內的路徑，時鐘週期為3.125ns，這條路徑有0.268ns的時序違例。違例的主要原因是邏輯級數較高導致的資料鏈路延時較大，但連線延時的比例也較高，所以可以仔細看看這條路徑的資料路徑上有沒有可能改進佈局、降低扇出或者是減少邏輯級數的優化方向。

report_timing

report_timing是更具體的時序報告命令，經常用來報告某一條或是某些共享特定節點的路徑。使用者可以在設計的任何階段使用report_timing，甚至是一邊設定XDC，一邊用其來驗證約束的可行性與優先順序。在Vivado IDE中可以由Tools > Timing > Report Timing 調出其圖形化設定視窗。

與report_timing_summary類似，調整選項後對應的Tcl命令也會在Command欄生成，在Targets一欄還可以設定需要報告路徑的起始點/途經點/結束點，可以三個都設定或是僅設定其中任何一項，每一項都支援萬用字元匹配甚至是正則表示式查詢。report_timing報告出的路徑延時與report_timing_summary中具體到每根路徑上的報告一致，可以以此為依據幫助我們定位時序失敗的原因。

用report_timing來報告時序其實還有一些更常見的應用場景，用來幫助我們設定和驗證約束，尤其是那些時序例外約束。

舉例來說，在設計過程中我們約束了一條或數條多週期約束，不同於UCF必須讀入約束後重跑設計，我們可以直接在Tcl Console中輸入這條XDC，無需重跑設計，直接用report_timing來驗證。在隨之顯示的時序報告Summary部分可以看到Timing Exception後列出這條路徑被設定了怎樣的時序例外約束（注意，不加額外option時，以下兩條命令都僅針對setup check ）。

單純的一條多週期約束沒有什麼特別，但是如果使用了萬用字元後的時序例外有重疊的情況下，Vivado會根據優先順序來決定對某條路徑應用怎樣的約束。當設計較大，XDC較多時，一邊設定XDC一邊用report_timing來驗證就變得尤其重要。

另外，僅僅輸入report_timing而不加任何option，Vivado便會報告出時序違例最嚴重的那條路徑，方便我們快速瞭解當前設計的WNS，找到最差的那條路徑。在驗證I/O約束時也常常用到report_timing，只要指定-from 某個輸入或是-to某個輸出便可以快速驗證當前設計在介面上的時序。

get_timing_paths

除了上述兩個大家比較熟悉的時序報告命令，Vivado中還提供一個get_timing_paths的命令，可以根據指定的條件找到一些特定的路徑。我們可以利用其返回值中的一些屬性來快速定位設計中的問題。

例如邏輯級數這個影響FPGA效能的一大因素，因為經常隱藏在時序報告後很難被發現。在Vivado中，除了藉助綜合後的報告來找到那些可能因為邏輯級數較高而導致的時序難滿足的路徑外，還有一個更直接的辦法，可以一次性報告出設計中那些高邏輯級數的路徑，方便我們有針對性的深入分析和優化。

下圖這個例子報告了時序最差的10條路徑的邏輯級數。需要注意的是，在綜合後和在佈局佈線後用一樣的指令碼報告出的結果會稍有不同，對邏輯級數較為關注的情況，還是建議以綜合後的結果為主要依據。