文章目錄

• 引言
• 1、time-quest的GUI
• • 1.1 時鐘約束
  • 1.2 Fmax Summary最大時鐘頻率
  • 1.3 Report timing 報告時序
  • • 1.3.1分析setup slack余量
    • 1.3.2分析hold slack余量
• 2、 constraints列表（約束列表選項的含義）
• • 2.1、create clock\derive pll clocks\Derive clock uncertainty
  • • 2.1.1 create clock
    • 2.1.2 derive pll clocks
    • 2.1.3 Derive clock uncertainty
  • 2.2 set_clock_groups
  • 2.3 Create Generated Clocks
  • 2.4 Set Clock Latency
  • 2.5 set_input_delay
  • 2.6 Output Constraints
  • 2.7 set_false_path
• 3、調節時序的另類方法
• • • 方法1
    • 方法2
    • 方法3
• 4、增加Fmax的另類方法
• 5、解決時序問題salck的正確辦法
• • 5.1 解決setup slack的正確方法
  • 5.2 解決hold slack的正確方法
• 參考資料

引言

本文在銜接上一講的基礎上，推出了，針對時序約束的解決方案，這些方案來源于本博主目前所掌握的一些工作經驗。
不少人總說，好的時序都是設計出來的，不是約束出來的。什么叫好的設計？你覺得你的代碼好，我還覺得我的比你更好呢？有什么評判標準呢？個人覺得應該是你正常的先完成RTL的設計，然后再做約束，如果發現EDA工具不能滿足你的約束要求，然后再看能否修改你的邏輯代碼。有必要從官網下手，從各方資料下手，來講清楚這其中的來龍去脈。如果，你現在還是連steup 的slack和hold 的slack還沒搞清楚，那我建議你好好看一下上一篇文章，特別是最后必備公式的圖片。
作者：ciscomonkey
鏈接在此啦：https://blog.csdn.net/ciscomonkey/article/details/88046646

1、time-quest的GUI

首先，我們點進去都會叫我們選擇一個模型，來建立網表，如果，我們選擇slow，那么我們知道對setup slack自然會有影響更大，如果我們選擇fast模型，就會對hold slack的模型影響更大。slow模型通常是針對綜合完成后的環境的仿真，如果你選擇fast模型，你綜合后的FPGA未必能在惡劣的環境下正常使用，所以，根據經驗，建議選擇slow模型。

只有在編譯filter（布線綜合器）后，，然后再進行添加約束，最后再進行時序分析，如果你熟悉SDC的話，你可以自己手寫腳本，如果不熟悉，你可以使用GUI的模式。另外，注意在時序分析時候，關掉signal tap, 有可能signal tap II會影響到時序約束，從而使得布線更加緊湊，違規更加嚴重。

1.1 時鐘約束

時鐘約束是必要的，你至少要先建立時鐘再進行時序分析，因為所有的時序都是建立在時鐘的基礎上。

在添加或者更改約束后，請務必記得每次Write SDC File
如果要進行時序分析，請務必記得重新編譯后，再進行時序分析，另外如果你有signal tap II，要關掉signal tap II.不然可能會影響到時序分析。

1.2 Fmax Summary最大時鐘頻率

在report 的datasheet當中有一個按鈕Reoort Summary，此報告的意思是，按照這樣的設計（你的verilog硬件電路設計），你在當前的環境下（比如80度低電壓），你在當前時鐘域下的設計最大的速度能夠跑到多少，按照上面的最大的時鐘速度只能跑到99.23M。

以上是官方的文檔解釋，我們來看一下
說了Restricted Fmax，這個值是因為保持時間的限制，也就是說，在這樣的設計下，我們要，滿足setup slack的要求，寄存器能正確的捕獲到值，最大這個速度就只能是99.23M了。

1.3 Report timing 報告時序

custom Reports—》Report Timing…
這個功能可以說非常強大了，通過此功能，可以查看設計的所有時序問題，包括建立時間的余量和保持時間的余量都是很方面的可以看到的。

正如上圖所示，From Clock \ To Clock可以指定時鐘區域，要知道，我們的時序都是建立在時鐘域的基礎上的，沒有時鐘，何談時序分析，這里，我們如果是全部設計只有一個sysclk的時鐘域的話，我們把兩個參數都選為sysclk即可。
Target的from、through、to這三者包含了我們要查看的時鐘域里面的哪些節點部分。一般來說，我們都是查看整個時鐘域。 Analysis type就是我們查看時序的哪一種slack，后面兩種屬于異步復位，我們暫時不去了解，但是在這里我建議，不要用太多的rst，寫狀態機，用一個即可了，甚至很多工程都不用rst的。我們指定1000條目錄，足矣。
后面report pannel name是生成這個報告的名字。Fle name，我們可以把生成的另外保存下來。

1.3.1分析setup slack余量

data_arrival=0+2.597+10.004(注意：10.004就包括了utco、組合邏輯延時等)=12.601
data required time=20+2.522-0.020-0.021(注意：此處應該是減去0.021才對)=22.481
setup slack=data required time-data_arrival_time=22.481-12.601= 9.88
這才是真正的建立時間的余量，所以上圖和下圖的計算都是有誤的，不過這關系不是很大，但是如果我們的setup slack很少的一部分就要注意了。但是實際上，我們的time是非常嚴格苛刻環境，已經是分析最壞情況了，所以，這一點計算誤差，也影響不大。

我們可以根據上圖來計算一下，其實算出來，我們就知道，會和報告的22.523的需求時間相差一點，為什么呢？那是因為Time quest算錯了！按照波形圖，它表示的正負關系都是對的，但是在上圖紅色圈圈處，它把tsu用的加法，而實際上與它的波形圖，還有官方的文檔，都是減法，所以，這里是他算錯了的。我不知道在后續版本發現這個問題沒，我是quartus13.1.

1.3.2分析hold slack余量

計算：
data_arrval_time=0+2.542+0.746(這里面包括了utco)=3.288
data required time=0+2.625+0+0.212=2.837
這里是正確的，符合官方文檔公式。圖和數據也是符合的。
從圖中，我們可以看出來launch沿其實是next launch沿，這再次說明了我們之前的理解是正確的。

• 總結
  我們只需要掌握好了上一篇我們講的公式，一共6個公式。實際上只用記住register to register之間的setup和hold的slack計算即可。

2、 constraints列表（約束列表選項的含義）

上面，我們介紹了如何分析時序的方法，并且驗證了我們第一篇的公式，第一篇連接：https://blog.csdn.net/ciscomonkey/article/details/88046646
并且我重點介紹了report timing。下面，我們要開始正式來學習GUI界面下的約束命令了。

2.1、create clock\derive pll clocks\Derive clock uncertainty

2.1.1 create clock

以上默認是占空比50%，如果要指定占空比，請指定-waveform option.

2.1.2 derive pll clocks

The Derive PLL Clocks (derive_pll_clocks) constraint automatically creates
clocks for each output of any PLL in your design.

2.1.3 Derive clock uncertainty

Allows you to specify the expected clock setup or hold uncertainty associated with jitter, skew, and a guard band when performing setup and hold checks for clocks or clock-to-clock transfers. You can specify separate clock uncertainty for setup (-setup) and hold (-hold). The Timing Analyzer subtracts the setup uncertainty from the data required time Definition for each applicable path, and adds the hold uncertainty to the data required time for each applicable path.

從上面的官方文檔，我們可以知道這個clock uncertainty正式時鐘的不確定性的約束，其實也是我們建立時間余量和保持時間余量的不確定性的值。

2.2 set_clock_groups

設置時鐘組允許你指定在設計中不相關的時鐘，默認情況下，時需分析器件會假定所有的時鐘都是通過共有的時鐘而相關的，因此所有在時鐘域間的傳遞對于時序分析來說都是有效的，你可以通過切分成時鐘組來排除時鐘域之間的傳遞。

比如說，如果有兩個時鐘8ns和10ns的時鐘，即使時鐘是完全異步的，這個時序分析器件仍然企圖建立2ns的建立時間關系，除非你用時鐘組來指定這兩個時鐘是不相互關聯的。另外時鐘組并不是只能設置兩個，你也可以繼續無限制的添加。

2.3 Create Generated Clocks

此約束用于內部生成的時鐘約束，比如說PLL，或者分頻生成的時鐘，但是分頻生成的時鐘我們一般不建議用來作為時鐘信號。source指的是時鐘源，比如說將clk進行倍頻，那么clk就是時鐘源。

2.4 Set Clock Latency

2.5 set_input_delay

2.6 Output Constraints

2.7 set_false_path

set_false_path指的是不做時序檢查，比如一些跨時鐘域之間的數據傳輸可以不做時序檢查，因此可以設置為set_false_path

3、調節時序的另類方法

方法1

更改分析和綜合的設置選項，第一種為速度型，就會更加兼顧速度，第三種將更加兼顧布線的面積。更改這些值后，重新編譯，如果時序偽劣較小，很可能，更改后，時序偽例就消失了。

方法2

綜合種子，這個值默認是1，但是也可以更改為1~12等都可以嘗試，不同的值可能會影響最后的布線，可能最后偽劣會消失。

方法3

更改布線的預計最壞slack，如果時序違規在在0.5ns左右，可以通過此方法，如果違規太嚴重，那可能用此方法也未必生效。

以上三種方法都屬于工程經驗，記住即可, 都是試出來的，有可能你三個方法都用了會適得其反。

4、增加Fmax的另類方法

設置為3，雖然編譯時間會增加，但是可以以運行時間為代價尋找到更好的路由。

并且把router Timing optimization level 更改為max
更改前的fmax:

更改后：

實驗結果發現也沒提高，我們了解一下即可。

5、解決時序問題salck的正確辦法

5.1 解決setup slack的正確方法

通過減少阻塞邏輯，減少rigister-to-register 的數據延時，所以最好就是if語句里面不要寫太多的組合邏輯了，如果寫了很多組合邏輯，我們可以輸出flag標志的寄存器來處理，從而實現路徑的分割。這也是插入pipeline的方法。

5.2 解決hold slack的正確方法

一般來說解決hold violation的情況是比較少見的，如果遇到，可以通過加一個lockup latch來解決。

參考資料

https://www.intel.com/content/www/us/en/programmable/quartushelp/current/index.htm

總結

以上是生活随笔為你收集整理的彻底理解Intel FPGA时序约束---解决方案篇（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。