在用Vivado對(duì)工程編譯時(shí)，會(huì)彈出下面的對(duì)話框：

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

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

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

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

因此，這個(gè)jobs是我們?cè)谕瑫r(shí)有多個(gè)runs在跑的時(shí)候才起效的，如果只有一個(gè)Design run，那這個(gè)參數(shù)是不起效的。

對(duì)于多線程，在UG904中是這樣說的：

Implementation過程，最多使用8個(gè)線程，在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線程，下面記錄的時(shí)間僅是Implementation的時(shí)間，不包括Synthesis。

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

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

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

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

Test5是總共有6個(gè)Implementation的Design runs，采用8線程12jobs同時(shí)跑；

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

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

Test112219min

Test21219min

Test312817min

Test41817min

Test512838min

Test618120min

Numjobsthreadstime

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

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

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

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

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

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

責(zé)任編輯：haq