Vivado中jobs和threads的区别？选择多个jobs能加快实现速度么？

作者： 猫叔 文章来源：科学计算technomania微信公众号

在用Vivado对工程编译时，会弹出下面的对话框：

备注：虽然FPGA不能叫编译，但很多工程师为了方便起见，将综合+实现+生成bit文件的过程统称为编译了，这种说法大家理解就好。

很多工程师都会选择多个jobs进行编译，以为这样会更快一些，而且这个jobs的数量跟本地CPU的线程数是一致的，这就更加让工程师们认为这个选项就是多线程编译了。

  但对Vivado更加熟悉的工程师，肯定会知道，Vivado中的多线程是通过tcl脚本去设置的，而且目前最大可使用的线程数是8个，那这个jobs跟多线程有什么关系呢？使用多个jobs能加快编译速度么？

  我们首先来看jobs的定义，在UG904中这样写道：

因此，这个jobs是我们在同时有多个runs在跑的时候才起效的，如果只有一个Design run，那这个参数是不起效的。

对于多线程，在UG904中是这样说的：

Implementation过程，最多使用8个线程，在Windows上，默认是2线程；在Linux上，默认是8线程；我们可以通过tcl脚本改变线程数，使用方式为：

set_param  general.maxThreads 8

也可以获取当前使用的线程数：

get_param  general.maxThreads

为了更直观的体现jobs和threads的使用方式，下面进行惨无人道的试验：

首先，处理器为Intel的i7-8700k,6核12线程，下面记录的时间仅是Implementation的时间，不包括Synthesis。

Test1为默认的2线程，最大jobs（12）的情况下，需要19min；

Test2把jobs降为1，线程还是2，仍然需要19min，说明在只有一个Design Run的时候，jobs的数量不影响编译时间；

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

Test4是在8线程的基础上，把jobs降为1，此时还是17min，再次验证了单个design run时，jobs的数量不影响编译时间；

Test5是总共有6个Implementation的Design runs，采用8线程12jobs同时跑；

在下面这个图中也可以看出来，此时CPU的利用率已经很高了。

Test6也是6个Implementation的Design runs，8线程，但jobs设置为1，此时可以看出，只有一个design run在跑，其他都在等待中，要等这个前一个跑完后，后面的才会开始。

Num	jobs	threads	time
Test1	12	2	19min
Test2	1	2	19min
Test3	12	8	17min
Test4	1	8	17min
Test5	12	8	38min
Test6	1	8	120min

从上面的试验，我们可以总结如下：

1. 对于单个design run，jobs的数量不影响编译速度；

2. 在Windows上，默认的线程数是2，我们可以通过tcl来改变线程数，但每打开工程后都要重新设置一下，多线程会使综合实现的时间缩短，但效果并不是很明显；网上有个工程师说本来2线程1小时编译完的工程，用了8线程后，编译时间为50分钟；

3. 在多个design runs时，jobs的数量是当前可以同时运行的design run的个数。