在用Vivado對工程編譯時，會彈出下面的對話框：

備注：雖然FPGA不能叫編譯，但很多工程師為了方便起見，將綜合+實現(xiàn)+生成bit文件的過程統(tǒng)稱為編譯了，這種說法大家理解就好。

很多工程師都會選擇多個jobs進行編譯，以為這樣會更快一些，而且這個jobs的數(shù)量跟本地CPU的線程數(shù)是一致的，這就更加讓工程師們認為這個選項就是多線程編譯了。

但對Vivado更加熟悉的工程師，肯定會知道，Vivado中的多線程是通過tcl腳本去設置的，而且目前最大可使用的線程數(shù)是8個，那這個jobs跟多線程有什么關(guān)系呢？使用多個jobs能加快編譯速度么？

我們首先來看jobs的定義，在UG904中這樣寫道：

因此，這個jobs是我們在同時有多個runs在跑的時候才起效的，如果只有一個Design run，那這個參數(shù)是不起效的。

對于多線程，在UG904中是這樣說的：

Implementation過程，最多使用8個線程，在Windows上，默認是2線程；在Linux上，默認是8線程；我們可以通過tcl腳本改變線程數(shù)，使用方式為：

set_param general.maxThreads 8

也可以獲取當前使用的線程數(shù)：

get_param general.maxThreads

為了更直觀的體現(xiàn)jobs和threads的使用方式，下面進行慘無人道的試驗：

首先，處理器為Intel的i7-8700k，6核12線程，下面記錄的時間僅是Implementation的時間，不包括Synthesis。

Test1為默認的2線程，最大jobs（12）的情況下，需要19min；

Test2把jobs降為1，線程還是2，仍然需要19min，說明在只有一個Design Run的時候，jobs的數(shù)量不影響編譯時間；

Test3是采用8線程，jobs跟Test1相同，都是12，此時需要17min，比默認的2線程快了2min；

Test4是在8線程的基礎上，把jobs降為1，此時還是17min，再次驗證了單個design run時，jobs的數(shù)量不影響編譯時間；

Test5是總共有6個Implementation的Design runs，采用8線程12jobs同時跑；

在下面這個圖中也可以看出來，此時CPU的利用率已經(jīng)很高了。

Test6也是6個Implementation的Design runs，8線程，但jobs設置為1，此時可以看出，只有一個design run在跑，其他都在等待中，要等這個前一個跑完后，后面的才會開始。

Test112219min

Test21219min

Test312817min

Test41817min

Test512838min

Test618120min

Numjobsthreadstime

從上面的試驗，我們可以總結(jié)如下：

對于單個design run，jobs的數(shù)量不影響編譯速度；

在Windows上，默認的線程數(shù)是2，我們可以通過tcl來改變線程數(shù)，但每打開工程后都要重新設置一下，多線程會使綜合實現(xiàn)的時間縮短，但效果并不是很明顯；網(wǎng)上有個工程師說本來2線程1小時編譯完的工程，用了8線程后，編譯時間為50分鐘；

在多個design runs時，jobs的數(shù)量是當前可以同時運行的design run的個數(shù)。

原文標題：Vivado中jobs和threads的區(qū)別？選擇多個jobs能加快實現(xiàn)速度么？

文章出處：【微信公眾號：OpenFPGA】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責任編輯：haq