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

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

 

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

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

??我們首先來(lái)看jobs的定義，在UG904中這樣寫(xiě)道：

   

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

 

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

 

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

set_param  general.maxThreads 8

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

get_param  general.maxThreads

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

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

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

• Test2把jobs降為1，線程還是2，仍然需要19min，說(shuō)明在只有一個(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í)跑；

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

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

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

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

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