在用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同时跑；

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

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

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

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

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