L
Lars Asplund
Guest
VUnit, the open source unit testing framework for VHDL (https://github.com/LarsAsplund/vunit), has now added support for multithreaded execution. Thanks to the nature of unit testing with several independent test cases in each testbench (test suite) it lends itself to parallel execution. Simply take your VUnit run script and add the -p option to specify the number of threads/test cases you want to run in parallel.
python run.py -p <number of threads>
For example, the figures below show the relative speed improvements for different number of threads when running on my quad core laptop with ModelSim-Altera Starter Edition under Windows. My script runs a couple of testbenches, each with several test cases, for a total of about 60 test cases. If my simulation threads never blocked on anything like I/O it wouldn't be much point in using more threads than the number of cores but since that's not the case the example shows improved performance beyond that point. Eventually you don't get any more performance by adding threads and there are different reasons for that. You can't be faster than your slowest test case, there's no point in having more threads than the number of test cases, at some point the overhead of another thread is larger than the gain of the added parallelism. You have to experiment to find your optimum.
number of threads: speed improvement
1: 1.0x
2: 1.8x
3: 2.5x
4: 2.8x
5: 3.1x
6: 3.3x
7: 3.4x
8: 3.4x
9: 3.5x
10: 3.5x
11: 3.6x
12: 3.5x
13: 3.5x
14: 3.4x
15: 3.4x
16: 3.3x
17: 3.3x
18: 3.3x
19: 3.2x
20: 3.1x
python run.py -p <number of threads>
For example, the figures below show the relative speed improvements for different number of threads when running on my quad core laptop with ModelSim-Altera Starter Edition under Windows. My script runs a couple of testbenches, each with several test cases, for a total of about 60 test cases. If my simulation threads never blocked on anything like I/O it wouldn't be much point in using more threads than the number of cores but since that's not the case the example shows improved performance beyond that point. Eventually you don't get any more performance by adding threads and there are different reasons for that. You can't be faster than your slowest test case, there's no point in having more threads than the number of test cases, at some point the overhead of another thread is larger than the gain of the added parallelism. You have to experiment to find your optimum.
number of threads: speed improvement
1: 1.0x
2: 1.8x
3: 2.5x
4: 2.8x
5: 3.1x
6: 3.3x
7: 3.4x
8: 3.4x
9: 3.5x
10: 3.5x
11: 3.6x
12: 3.5x
13: 3.5x
14: 3.4x
15: 3.4x
16: 3.3x
17: 3.3x
18: 3.3x
19: 3.2x
20: 3.1x