03-08-2017 09:55 AM
I am trying to simulate a block that contains an FIR Compile 7.2 core. Reload time for the simulation is very long, about 10 minutes. I find that if I comment out the FIR core the simulation reloads in a few seconds. I am using Vivado simulator version 2016.4.
What kind of thing could cause these impractically long simulator load times?
03-08-2017 11:29 AM
Please check similar issue in the below thread.Hope it helps.
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
03-08-2017 11:51 AM - edited 03-09-2017 02:01 PM
Yes, I saw that one but it looks ISE specific. I am using the Vivado simulator.
Still, the same idea may apply so I looked through all the tabs on the FIR Compiler GUI. I found nothing about simulation model, structural versus behavioral. In my simulation project settings I found this and switched it to "Blackbox model". That has not reduced load time.
Any other ideas? I really cannot debug my design with these load times.
03-10-2017 08:49 AM - edited 03-10-2017 09:11 AM
This is the pop up that runs 10 or 15 minutes at simulation (re)load time.
I also get a huge number of these messages when the FIR core is included in the simulation.
WARNING: [VRFC 10-516] comparison between unequal length arrays always returns FALSE [/wrk/2016.4/nightly/2016_12_14_1733598/packages/customer/vivado/data/ip/xilinx/xbip_utils_v3_0/hdl/xbip_utils_v3_0_vh_rfs.vhd:1957]
03-21-2017 11:38 AM
I still have no relief on this. It is very hard to work with this core when I cannot simulate.
If anyone can take a look I attach a zipped up project. Under ./sim there is a setup.tcl file that sets up the simulation. I would be curious to know if you can load the simulation in a finite amount of time in Vivado 2016.4.
06-28-2017 12:41 AM
Still a problem in 2017.2. Doing som interpolation and decimation with about 120 DSP elements takes 20 minutes to start simulation on new i7-core machine with 32GB RAM.
06-28-2017 07:50 AM
I have same issue its ridiculous long time. using 2017.2 anyone got it working faster?
My only solution right now is to either disable the FIR cores (if that particular sim is not testing them) or switch o the incremental compile option. This obviously only helps after the first fir but it did seem to speed things up.
Either was it's stupid that such a bug got reported (in more than one thread) and didn't get fixed in the next update.
06-28-2017 07:57 AM
07-05-2017 09:33 AM
I just retried this in Vivado 2017.2. The problem has not been solved. Simulation (re)load is about 15 minutes on a pretty good Win7 machine.
I think the simulator is resynthesizing the entire FIR core at load time, yikes.
07-07-2017 04:57 AM
I have the same problem of long simulation elaboration times with the FIR filters. I tried the incremental compile setting, but it didn't help.
03-14-2018 07:56 AM
Can anyone say whether this issue has been fixed on 2017.3/4? This really is a big deal. Simulations are taking so long now when a FIR is involved. If this hasn't been fixed it needs doing asap.
03-11-2019 10:54 AM
That this is still an issue is unforgiveable. Proof in itself that Xilinx does not give a flying **** about it's simulator. Bug ridden mess.
05-29-2020 03:35 PM
I have the same problem in Vivado 2019.2. It is massively slowing down my development time. Xilinx, please have mercy on us and fix this issue.
06-01-2020 12:34 AM
@thakurr you are the only Xilinx employee to respond to this thread so I'm tagging you. This bug has been in Vivado sim for over 3 years. It makes a huge difference to our ability to run sims. We know that you guys aren't interested in furthering your simulator capabilities but this isn't really acceptable. It's a bug fix,if you put someone on it I'm sure it can be resolved relatively quickly, after all it didn't used to be an issue.
Is someone going to look at fixing it? Anyone?
12-15-2020 09:59 AM - edited 12-16-2020 01:04 PM
For any one else irritated by this,
I have found that if I synthesize just the fir cores, the simulation goes from taking tens of minutes to start up to less than a minute.
Edit: Starting with a project with no simulation products:
If you run simulation first, synthesis will not help.
12-16-2020 10:07 AM
Can you explain a little more about what you mean when you say 'synthesize just the fir cores'. Are they not included OOC anyway and so pre-synthesized?
12-17-2020 01:14 AM
It's been so long since I could be bothered to simulated a FIR core.. but I'm pretty sure I always had them synthesized OOC when I ran a sim? Or is this again release version dependent. What version of Vivado are you using @ekigwana ?
12-17-2020 03:29 AM
I'm interested in this because I'm pretty sure it relates to a post I've just created...
My DUT is my own custom IP (which has a xfft IP simular to the FIR IP in it) that I've previously created in another project and add/instantiate it to the simulation project by adding it's IP generation location to the IP Catalog.
When I run the simulation xelab takes the vast majority of the time (4 out of the total time of 5 mins), even though the only difference when I run simulation is that my scripts change a testbench test number via the --generic_top switch to xelab. Without the XFFT IP total time is less than 1 min.
In the elaborate.log it takes the 4 mins to go from this step...
Pass Through NonSizing Optimizer
...to this step...
Completed static elaboration
INFO: [XSIM 43-4323] No Change in HDL. Linking previously generated obj files to create kernel
....is there was some way of locking the IP (or the whole DUT) from being re-elaborated I'm sure this would speed things up?
12-17-2020 08:28 AM
Great idea. Unfortunately I believe I am already doing that for both compile and elaborate.....
xvlog --incr --relax -L axi_vip_v1_1_6 -L axi4stream_vip_v1_1_6 -L xilinx_vip -prj testbench_top_vlog.prj 2>&1 | tee compile.log
xvhdl --incr --relax -prj testbench_top_vhdl.prj 2>&1 | tee -a compile.log
xelab -wto 073e1cba47e54ffdbc10374d5158b3df --incr --debug typical --relax --mt 8 -L xilinx_vip -L xpm -L xbip_utils_v3_0_10 -L axi_utils_v2_0_6 -L c_reg_fd_v12_0_6 -L xbip_dsp48_wrapper_v3_0_4 -L xbip_pipe_v3_0_6 -L xbip_dsp48_addsub_v3_0_6 -L xbip_addsub_v3_0_6 -L c_addsub_v12_0_14 -L c_mux_bit_v12_0_6 -L c_shift_ram_v12_0_14 -L xbip_bram18k_v3_0_6 -L mult_gen_v12_0_16 -L cmpy_v6_0_18 -L floating_point_v7_0_17 -L xfft_v9_1_3 -L axis_infrastructure_v1_1_0 -L axis_register_slice_v1_1_20 -L axis_dwidth_converter_v1_1_19 -L xil_defaultlib -L axi4stream_vip_v1_1_6 -L axi_infrastructure_v1_1_0 -L axi_vip_v1_1_6 -L xilinx_vip -L unisims_ver -L unimacro_ver -L secureip --snapshot testbench_top_behav xil_defaultlib.testbench_top xil_defaultlib.glbl -log elaborate.log -sv_lib dpi