引言
在之前我的文章中，已經寫過時序分析，但當時僅解決了step slack的問題，爲了加深進一步的理解，隨着資料的不斷增多，現在，重新進一步整理，當然這一次整理將是乾貨的歸納，並且納入IC學習路線一文中，爲IC中的PT工具的時序分析先鋪墊道路。
參考文章：https://blog.csdn.net/ciscomonkey/article/details/88046646
1、建立餘量
從圖中可以看出，data arrival time 的時間點和data require time的時間點，只要兩個相減，就是setup slack的值。並且需要保證slack>0.
而Fmax的值=1/（Tcycle -setup slack）
關於這個Fmax的理解：如果要讓時鐘可以快，更快，更快，顯然，setup slack的餘量更加充足，更容易讓時鐘更快，如果slack足夠充足，我可以把Tsu這一段整體往前移動，移動，從而時鐘的上升沿更快的到來，然而，想一下，如果slack很小很小，你想把Tsu往前提，也提不了，所以時鐘快不起來。如果以極限來考慮，也就是說，我可以最多將Tsu提前slack這麼一個長度，因此，得到Fmax的公式。
2、建立時間餘量的Vivado軟件分析
在實現或者綜合後，點擊編輯時序約束
在進行時序約束前，需要分配管腳，否則時序分析是沒有意義的。如下圖所示，創建時鐘約束。如果系統中使用了PLL，就沒必要設置時鐘約束，因爲系統已經知道了你的時鐘。
現在需要重新編譯。重新編譯後，在Timing summary中。
如下圖所示，最糟糕的情況下，slack還有5.906ns的餘量,而所有負的salck爲0，是沒有的。
WNS 代表最差負時序裕量 (Worst Negative Slack)
TNS 代表總的負時序裕量 (Total Negative Slack)(所有path-slack 加起來)，也就是負時序裕量路徑之和。
關閉窗口後，然後report timing，報告100條路徑
slack代表的餘量，level代表該路徑是否有組合邏輯，比如if
雙擊某一條路徑後，可以對該條路徑顯示細節，通過點擊右鍵進行highlight標亮後，然後再device中查看，從而可以看到路徑
始終要根據此模型
首先通過外部的時鐘晶振，時鐘通過時鐘緩衝器buffer，進行輸出，當然一路時鐘（黃色）輸出給了源寄存器，另一路時鐘輸出給了目的寄存器。
然後看到，第一路時鐘給了一個觸發器，觸發器的類型是FDRE，代表同步復位，復位值爲0。
然後數據線經過了一個組合邏輯
然後數據到達目的寄存器，從而這條路徑完全符合我們的經典兩級寄存器時序分析模型
下面來看一下計算的數據
首先是數據到達時間，表裏面理出了，經過每一條路徑的時間累加，incr代表這條線（器件）增加的時間，path代表總的累加時間，直到計算出累加的時間是3.937.
接着是數據需求時間，在詢問後，其實我覺得可這樣來理解，真正進入寄存器的採集還需要一定延時，與建立時間之和後，可能爲正，也可能爲負。
最後用需求時間減去數據到達時間即可。
疑問？
爲什麼下圖經過同樣的ibuf，結果會不一樣呢？
前面那個相當於TCLK1，後面那個相當於TCLK2
爲了以最壞的角度考慮，TCLK1應該取最大值，TCLK2應該取最小值。所以下面的結果不一樣，是考慮的最悲觀的角度。
3、保持時間
如下圖所示，爲了計算hold slack的時間，需要計算兩個點
所以hold slack與時鐘的快慢（時鐘週期）是沒有關係的。
所以看出，增加組合邏輯的延時，可以改善hold 的slack
4、保持時間餘量的Vivado軟件分析
同樣是符合公式的
約束時鐘的意義在於軟件更好的優化佈局佈線，所以需要綁定好管腳。