UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Contributor
Contributor
1,845 Views
Registered: ‎01-22-2014

Vivado 2017.3 slower then 2015.2

Hi,

I'm moving a lot of work from Vivado 2015.2 to Vivado 2017.3

The new version seems to have a significant problem:
The software interface, in particular editing BD designs is incredibly slow,
expecially when the project complexity grows up.

It takes several seconds
to validate BD design,
to make a connection between IP blocks,
to switch from a bd to another,
to refresh ip catalog,
to upgrade IPs
and so on.

This problem is surely related to the size of the project: bigger the project, slower the interface.
Is also relative to the presence of OOC synthesis: more OOC synth, slower the interface.

Can I do something to solve this problem?
There is a patch related to?

I noticed this "bad" behaviour starting from Vivado 2016.4, while Vivado 2015.2 continues to run fluently.

I use a Workstation with Ubuntu 16.04, 8-Core, 64GB RAM

I have no congestions problems in terms of CPU usage or RAM usage

Thank you in advance
Giovanni Chiurco

0 Kudos
10 Replies
Scholar austin
Scholar
1,811 Views
Registered: ‎02-27-2008

Re: Vivado 2017.3 slower then 2015.2

Try:

 

set_param project.hsv.draftModeDefault  only

Execute in TCL console.  Seems newer versions have been thrashing for no reason.   Let us know if that solves it.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
Contributor
Contributor
1,753 Views
Registered: ‎01-22-2014

Re: Vivado 2017.3 slower then 2015.2

Dear austin,

thanks for the suggestion ...

It goes better than before, but the TCL doesn't completely solve it.
0 Kudos
Scholar austin
Scholar
1,726 Views
Registered: ‎02-27-2008

Re: Vivado 2017.3 slower then 2015.2

g,

 

OK, that is odd, as for me, it is faster.  Check it is using all the threads (processors) it should in your system.  The latest Vivado is able to use 6 processors for many operations, as opposed to the earlier versions which maxed out at 4.  2017.4 finds and uses 6 threads with no extra TCL commands by itself (for me).  Never used .3 (but I suspect is is identical).  Fairly big change between .2 and .4 (moving towards a unified HLS/SDx version for everything), so perhaps .3 needs some extra TCL help (for threads? etc.)?

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Contributor
Contributor
1,678 Views
Registered: ‎01-22-2014

Re: Vivado 2017.3 slower then 2015.2

Hi austin,

 

vivado use all the threads it should.

 

The problem is evident when the OOC ip are run: more OOC synth, slower the interface

 

It works fine with no OOC synth and with the TCL command

set_param project.hsv.draftModeDefault  only

 

The project is very huge, because of it fit the xczu9eg

In the project there are 4-5 BDs with a common wrapper and every BD has various xilinx and custom IPs.

Moreover I use also the RTL modules in the BDs so I can't use the TCL command:

set_property source_mgmt_mode DisplayOnly

Any other suggestions?!?

 

Thanks in advance

 

0 Kudos
Xilinx Employee
Xilinx Employee
1,648 Views
Registered: ‎07-22-2008

Re: Vivado 2017.3 slower then 2015.2

How many OOC runs would you say you have in the project (tens, hundreds, thousands)?

Do you generate output targets for the BDs as OOC per IP or OOC per BD?

One thing I've seen if there are hundreds of OOC runs (generated with OOC per IP) was that Vivado was slowed down due to the overhead of monitoring the status of all of the OOC runs.  There was a fix put in back in 2015.x time frame to cut down the interval of the monitor checks if the time to complete all of the checks exceeded the interval.  However, there is still going to be a performance degradation with a significant number (hundreds).  The slowness will be more obvious is the project is on a network drive.

0 Kudos
Contributor
Contributor
1,598 Views
Registered: ‎01-22-2014

Re: Vivado 2017.3 slower then 2015.2

Thank you howardp for the reply

I generate output targets per IP and I have hundreads of OOC runs.

What you wrote is what I, too, thought: Vivado slow down due to the overhead of monitoring the status of all of the OOC runs.

Could it go better with OOC per BD?
Can I do anything to reduce the interval of the monitor checks in 2017.3?!?
Are any improvements planned for 2018.1?

Bye
G
0 Kudos
Xilinx Employee
Xilinx Employee
1,586 Views
Registered: ‎07-22-2008

Re: Vivado 2017.3 slower then 2015.2

If what you are seeing is in any way related to the number of runs, then generating with OOC per BD should definitely help.  This will reduce the OOC runs for the BD from hundreds to one.

 

The specific issue I was referring to is documented in https://www.xilinx.com/support/answers/67729.html

 

In Vivado 2016.3 there was a fix made to resolve the slow down problem.  This fix takes the time to monitor all the runs and automatically adjusts the frequency of the monitoring so that it is never greater than 20%.  That fix is still in the Vivado 2017.x code so the degradation of a lot of runs should not be as great but could still take a bit of processing time.

 

It is possible the developer put in some type of param when he implemented the fix that would allow the interval to be adjusted.  However, if changing to OOC per BD is an option, that would be your best solution.

 

0 Kudos
Scholar dpaul24
Scholar
1,546 Views
Registered: ‎08-07-2014

Re: Vivado 2017.3 slower then 2015.2

@austin, Have tagged you in this thread.
https://forums.xilinx.com/t5/Simulation-and-Verification/Speed-up-true-DP-RAM-simulation/m-p/838426#M21427
--------------------------------------------------------------------------------------------------------
FPGA enthusiast!
All PMs will be ignored
--------------------------------------------------------------------------------------------------------
0 Kudos
Xilinx Employee
Xilinx Employee
1,535 Views
Registered: ‎07-22-2008

Re: Vivado 2017.3 slower then 2015.2

FYI: I followed up with the developer mentioned in my previous post.  There was not a param added to manually adjust the monitor interval.  The software just manually adjust based on the time it takes to monitor all runs. 

He asked if you could create an SR and submit the design in order to get this fixed.

He was also interesting in knowing if turning off the automatic update of hierarchy had any effect on the responsiveness.

  You can do this from the Tcl console by running "set_property source_mgmt_mode None [current_project]"

0 Kudos
Contributor
Contributor
774 Views
Registered: ‎01-22-2014

Re: Vivado 2017.3 slower then 2015.2

Unfortunately, because of company policies rules I can't submit the design.

About turning off the automatic update of hierarchy, it has positive effects on the responsiveness but unfortunately I use also RTL modules in my design, so turning off the autoupdate VIVADO says me:

[filemgmt 56-176] Module references are not supported in manual compile order mode and will be ignored.

:-(


At this point I will try with OOC per BD, I will not maximize synth compilation time, but however I will improve synth time a little bit.

I hope that this issue could be figure out in next VIVADO releases.

Thanks
0 Kudos