04-23-2016 11:00 AM
After the mixed-language DPI bug is fixed in Vivado 2016.1 (see post) I port all my test benches to Vivado.
However, I see sometimes that xelab is extremely slow. Here the numbers for some straight forward behavioral simulation models:
In other simulators it takes 10-15 seconds to build these test benches.
When looking at the console I see
Completed static elaboration
Starting simulation data flow analysis
Completed simulation data flow analysis <-- runs fast up up to here
Time Resolution for simulation is 1ps <-- over 10 sec to come
Compiling package std.standard <-- libs, take many seconds each
Compiling package ieee.std_logic_1164 <-- from now every step at snails pace
So up to 'simulation data flow analysis' all seems fine, and afterwards is slows down dramatically. It takes a long time for the needed libs to compile, in other cases that's very fast. The compilation of the individual modules afterwards take many seconds per module, even when they are almost trivial. 100% of a single CPU is used.
If one has the patience to wait for xelab to finish one gets a nicely working model, no functional issues seen (so far).
That's Vivado 2016.1 under Ubuntu 14.04 LTS.
Any hint help highly appreciated.
With best regards, Walter
04-24-2016 08:55 PM
Can you please provide and the steps to reproduce the issue for us to look into?
04-30-2016 01:13 AM
I've checked whether the slowness depends on either DPI usage or mixed langage. Both doesn't seem to be the case, a hacked model with only vhdl sources was still very slow.
I've attached an example, code is from an open source project. Just unpack the tar ball and run 'build.sh'. Alltogether 17000 lines of vhdl code, but lots of libs and comments. Takes about 7 minutes in xelab.
05-01-2016 08:45 PM
Thanks for the design. I will check and getback to you.
05-18-2016 05:19 AM
any news about this?
I am having the very same problem with a VHDL design. The funny thing is elaborate is taking ages (>10 minutes) to compile even the VHDL standard libraries on a powerful PC (i7 Octa 16 GB RAM):
Compiling package ieee.std_logic_1164
Compiling package ieee.std_logic_arith
Compiling package ieee.std_logic_unsigned
Then, when it reaches my design files, it takes very long for trivial files, as initial reporter mentioned.
This is making it very hard to switch to Vivado Simulator, which otherwise looks like a very good option.
05-22-2016 05:38 AM
05-23-2016 08:50 AM
I'm also experiencing this issue.
I'm using Vivado to co-simulate a project written in C++ and synthesized with Vivado HLS.
I tried both Vivado 2015.4 and 2016.1, but the behaviour is the same: the xelab compilation phase may take up to 30-45 minutes for a set of relatively simple files.
The strange thing is that for some designs the compilation is quite fast and doesn't take more than a couple of minutes, while for others the issue appears.
I tried some tweaks to the design's C and RTL codes, but, up to now, I couldn't find what is causing this behavior (e.g., using specific IEEE libraries, instancing AXI for the I/O ports, etc.).
I also noticed that the actual simulation phase seems pretty fast (couple of minutes for the design I'm currently debugging).
This is seriously limiting my ability to use the Vivado simulator to perform any verification task.
I hope someone in Xilinx will give an answer soon.
Even a temporary workaround could be acceptable, until they fix it in a next release.
06-10-2016 11:58 AM
just installed 2016.2. I see no improvement in the 'slow xelab' issue, for one modest design I get as time to build a behavioral simulation model
vivado 2016.2: real 7m05.768s user 7m03.907s sys 0m0.628s
vivado 2016.1: real 7m19.046s user 7m12.553s sys 0m0.732s
With best regards, Walter
06-18-2016 06:28 AM
Did a few more tests with vivado 2016.2 (under Ubuntu 14.04 LTS)
Compared the test benches for 4 different designs, either in behavioral simulation or in post-synthesis functional simulation (done with a model generated in vhdl). The size of the test benches is
DPI --- behavioral --- -- post-syn func -- #ent #ins lines #ent #ins lines serloop1 no 34 48 8350 45 1008 16768 rlink yes 64 100 15980 84 3281 51096 sram yes 64 116 16334 101 3021 45992 w11a yes 113 212 35422 162 8845 142555
#ent -> number of entities
#ins -> number of instantiations
I get the xsim compilation times (sum of xvhdl, xvlog, xsc and xelab time):
------- 2016.1 ----- ------- 2016.2 ----- behavioral post-syn-fu behavioral post-syn-fu serloop1 0m01.394s 0m14.064s 0m01.423s 0m15.648s rlink 0m05.266s 0m51.844s 0m04.579s 0m40.205s sram 9m12.601s 147m54.592s 9m08.565s 152m29.101s w11a 25m28.828s 355m45.069s
while 'serloop1' and 'rlink' compile reasonably fast for both behavioral and post-synthesis the 'sram' model, even almost same size as 'rlink', is much slower. Using DPI does not seem to be the culprit. The some larger (but on an absolute scale still very modest sized) 'w11a' model gives compile times which are absurd, almost 6 hours for post-synthesis !
The problem is xelab. When looking at post-synthesis models one sees lots of
Compiling architecture lut6_v of entity unisim.LUT6 [\LUT6(init="...] Compiling architecture lut4_v of entity unisim.LUT4 [\LUT4(init="...] Compiling architecture lut6_v of entity unisim.LUT6 [\LUT6(init="...] Compiling architecture lut6_v of entity unisim.LUT6 [\LUT6(init="...]
lines, and it takes several seconds per lut.
Bottom line is