文章目錄

• 引言
• 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、調(diào)節(jié)時序的另類方法
• • • 方法1
    • 方法2
    • 方法3
• 4、增加Fmax的另類方法
• 5、解決時序問題salck的正確辦法
• • 5.1 解決setup slack的正確方法
  • 5.2 解決hold slack的正確方法
• 參考資料

引言

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

1、time-quest的GUI

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

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

1.1 時鐘約束

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

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

1.2 Fmax Summary最大時鐘頻率

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

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

1.3 Report timing 報告時序

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

正如上圖所示，From Clock \ To Clock可以指定時鐘區(qū)域，要知道，我們的時序都是建立在時鐘域的基礎(chǔ)上的，沒有時鐘，何談時序分析，這里，我們?nèi)绻侨吭O(shè)計只有一個sysclk的時鐘域的話，我們把兩個參數(shù)都選為sysclk即可。
Target的from、through、to這三者包含了我們要查看的時鐘域里面的哪些節(jié)點(diǎn)部分。一般來說，我們都是查看整個時鐘域。 Analysis type就是我們查看時序的哪一種slack，后面兩種屬于異步復(fù)位，我們暫時不去了解，但是在這里我建議，不要用太多的rst，寫狀態(tài)機(jī)，用一個即可了，甚至很多工程都不用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(注意：此處應(yīng)該是減去0.021才對)=22.481
setup slack=data required time-data_arrival_time=22.481-12.601= 9.88
這才是真正的建立時間的余量，所以上圖和下圖的計算都是有誤的，不過這關(guān)系不是很大，但是如果我們的setup slack很少的一部分就要注意了。但是實(shí)際上，我們的time是非常嚴(yán)格苛刻環(huán)境，已經(jīng)是分析最壞情況了，所以，這一點(diǎn)計算誤差，也影響不大。

我們可以根據(jù)上圖來計算一下，其實(shí)算出來，我們就知道，會和報告的22.523的需求時間相差一點(diǎn)，為什么呢？那是因為Time quest算錯了！按照波形圖，它表示的正負(fù)關(guān)系都是對的，但是在上圖紅色圈圈處，它把tsu用的加法，而實(shí)際上與它的波形圖，還有官方的文檔，都是減法，所以，這里是他算錯了的。我不知道在后續(xù)版本發(fā)現(xiàn)這個問題沒，我是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
這里是正確的，符合官方文檔公式。圖和數(shù)據(jù)也是符合的。
從圖中，我們可以看出來launch沿其實(shí)是next launch沿，這再次說明了我們之前的理解是正確的。

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

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

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

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

2.1.1 create clock

以上默認(rèn)是占空比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正式時鐘的不確定性的約束，其實(shí)也是我們建立時間余量和保持時間余量的不確定性的值。

2.2 set_clock_groups

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

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

2.3 Create Generated Clocks

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

2.4 Set Clock Latency

2.5 set_input_delay

2.6 Output Constraints

2.7 set_false_path

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

3、調(diào)節(jié)時序的另類方法

方法1

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

方法2

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

方法3

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

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

4、增加Fmax的另類方法

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

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

更改后：

實(shí)驗結(jié)果發(fā)現(xiàn)也沒提高，我們了解一下即可。

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

5.1 解決setup slack的正確方法

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

5.2 解決hold slack的正確方法

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

參考資料

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。