Vivado中jobs和threads的區(qū)別是什么

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

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

 

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

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

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

   

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

 

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

 

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

set_param  general.maxThreads 8

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

get_param  general.maxThreads

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

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

• Test1為默認(rèn)的2線程，最大jobs（12）的情況下，需要19min；

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

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

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

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

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

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

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

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

3. 在多個design runs時，jobs的數(shù)量是當(dāng)前可以同時運(yùn)行的design run的個數(shù)。